The International Simutrans Forum

 

Author Topic: Bored programmer  (Read 26872 times)

0 Members and 1 Guest are viewing this topic.

Offline Yona-TYT ve

  • Devotee
  • *
  • Posts: 1179
    • Simutrans-BLOG
  • Languages: ES
Re: Bored programmer
« Reply #35 on: December 29, 2014, 02:02:38 AM »

  • An option that allow buses not to stop in a stop if there are no people waiting there and there is no passenger in the bus waiting to leave the bus in that station.  That would mean that buses could be more competitive in urban lines.


I would assign a timeout (customizable) at stops. :thumbsup:

Offline TurfIt

  • Dev Team, Coder/patcher
  • Devotee
  • *
  • Posts: 1323
Re: Bored programmer
« Reply #36 on: December 29, 2014, 02:40:06 AM »
Industrial placement is also a nice task to improve
Fourth vote for this! Current personal annoyances with:
  Entire chains packed into very small areas. A 256x256 is no longer huge - spread out.
  Pax boost mechanic has a fixed pax demand. Placement code doesn't take this into account - frequently spawns industry in areas without enough population to support the boost.
  Better balance of supply/demand. Too many times end up with a single 300/month coal mine as the sole coal supplier on the map. 3/4 of the industries sit idle awaiting coal, and yet the next coal demanding industry spawns linked to that same ^&*^&*^ mine again! (This seems a bug, yet last I looked the code looked ok, but it still happens...)


Wow lots of nice ideas! The two lane avenue... I forgot about that one! I think it ended in nothing, maybe it's time to see why it was abandoned.
Very much not abandoned, just bumped down the queue a bit. Has performance implications, hence working to improve the performance first so ideally we end up even. But on again / off again progress, too easily distracted by shiny things...

Offline Yona-TYT ve

  • Devotee
  • *
  • Posts: 1179
    • Simutrans-BLOG
  • Languages: ES
Re: Bored programmer
« Reply #37 on: December 29, 2014, 05:56:08 AM »

Another one for the list .. !! ;)


Zoom on the cursor position for the mini map.

Offline jamespetts gb

  • Simutrans-Extended project coordinator
  • Devotee
  • *
  • Posts: 18555
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Bored programmer
« Reply #38 on: December 29, 2014, 10:51:47 AM »
I was involved in that project and I thought and think that it is not as hard as it is believed to be.  However, I desisted when I got tired of fighting against the establishment.  Too much effort to risk, too much negative feedback, no constructive help, and a foreseeable small probability to get that work incorporated...

Would you like to work on this for Experimental?

It's because it's broken, a guy has proven that the citizen agents don't have a true home or job, they simply go to the nearest non-full. This leads to impossible to solve traffic jams and completely inefficient public transportation.

The real problem with the agent simulation, from what I can reasonably deduce having spent time working on Simutrans-Experimental, is that it is too computationally intensive to be workable. This explains both the extremely small maps (as computational intensity would increase with the square of the map area on average) and also the fudging that you describe: the reason that each individual citizen does not have a specific home or workplace is that this would consume large amounts of memory (and, probably more importantly, memory bandwidth) for them all to remember their individual homes and offices. In programming terms, it would be easy for them to have had individual homes and offices (and it seems reasonable to guess that they did in early, pre-release versions).

I recall the work that I did trying to implement private car route finding for Experimental. The initial approach was to have each city find the optimum route every other city, one city at a time using the A* method. The result of this was that the game became totally unresponsive for an indefinite period, as this task was far too extreme a computational load to be manageable even with modern computers. The problem was solved in the end by using Dijekstra's algorithm to find every destination city in the same searching pass from each origin city. This sort of generalised solution would not, however, work with the original idea for the pure agent model in SimCity: each agent would have to act independently and find routes to all sorts of places, and there would have to be thousands, if not tens or hundreds of thousands of them, all doing this at the same time. It was only a few hundred cities that caused unacceptable performance in previous versions of Simutrans-Experimental.

Simutrans works well on a large scale because of its use of a mix of low level agent modelling for passengers, goods and vehicles, and higher level statistical modelling for other aspects of the game.

Offline Ters

  • Coder/patcher
  • Devotee
  • *
  • Posts: 5469
  • Languages: EN, NO
Re: Bored programmer
« Reply #39 on: December 29, 2014, 11:37:08 AM »
  Entire chains packed into very small areas. A 256x256 is no longer huge - spread out.

Strange. I have the opposite problem: Chains spanning the entire map, making them unexploitable until quite late in the game due to prohibitive infrastructure costs. And even when the infrastructure is in place, the flow of goods can't possibly be stable due to the long time between ordering and delivery. (The problem JIT2 attempts to solve.)

In fact, keeping some industries close together was a wish when discussing more realistic placement of industries, was it not?

Offline rainer

  • SMSC winner
  • *
  • Posts: 100
Re: Bored programmer
« Reply #40 on: December 29, 2014, 06:11:52 PM »
I'm just bored and I fancy coding, for some time.

WOW!

This a really seldom statement from a programmer! Grats! : - )

First of all, I have to praise all the exiting improvements of the last years - and the even more
tiny small improvements I sometimes missed to see in the changes.log, but stumbled over
them while playing. : - )

So here are my praises and maaaaaaaany thanks to the dev-team! Shall the new year be good
to you and your creativity!

(Just a small wish: Can't you make the tree-snow-climate system configurable to switch it off?
This would be _really_ useful on huge maps, running on older machines.)

I am not missing new or improved game features, but lots of tools for pakset maintainers,
merged under a reasonable user interface. Yes, I know, we have some. But either they are
".exe", or outdated, or need programmer skills beyond the basic knowledge, or hardcoded
for special paksets, or web based under unreliable hosts. An you can't trigger one by the
other in an automated way.

Look what TTD is offering, even well documented and sorted:
https://wiki.openttd.org/NewGRF_development_tools

My dreams:

- Handling of pakset objects with a HTML/CSS interface as frontend and a PostgreSQL backend.
  It should be usable on a public server as well as locally (assuming a local webserver and the
  appropiate scripting/programming interpreter/language is installed. Just by chance, I discussed
  that idea with Penny yesterday, but without consensus.)
  It might contain features like this (unsorted, t.b.c.)

-- A nice script, triggering makeobj, a built (make?) for pak objects, the merge option of
   makeobj, a.t.l., for automated pakset building, hopefully following a set of rules (XML?) to have
   readable, consistent filenames.

-- A .dat-checker, looking for frequently appearing (spell) errors and giving hints to new, not yet used
   parameters/options. An/or checking for double entries on every level (data, objects, whatever).

-- Something like a tile-cutter, but with the possibility to produce bigger objects (beyon 5x5 tiles)
    without filling all tiles in it.

-- Automated packing of bigger convoi objects as 96er, 128er (instead of 64er). Ok, I have to
   admit that this is a very special wish : - )

-- Any piece of software being able to produce simplified .pngs, just with the edges of the
   objects (here mostly convois) for every given length/width/height.

Ehm... I'll stop now. That should be enough for boring holidays. : - )

* IgorEliezer grabs popcorn.

* Rainer hands popcorn to IgorEliezer and offers beer.

Offline Markohs

  • DevTeam, Coder/patcher
  • Devotees (Inactive)
  • *
  • Posts: 1559
  • Languages: EN,ES,CAT
Re: Bored programmer
« Reply #41 on: December 29, 2014, 07:18:08 PM »
I'll make a summary of what has been expressed so far as I reach home. Many of the ideas are not hard to implement. Maybe there are other programmers that want to implememt some of them too. Let'dd start.

Offline isidoro

  • Devotee
  • *
  • Posts: 1129
Re: Bored programmer
« Reply #42 on: December 30, 2014, 12:37:16 AM »
Would you like to work on this [the two lane avenue] for Experimental?
[...]

Thanks.  Much appreciated.  But now I'm involved in two programming projects and have not enough time.

Offline Markohs

  • DevTeam, Coder/patcher
  • Devotees (Inactive)
  • *
  • Posts: 1559
  • Languages: EN,ES,CAT
Re: Bored programmer
« Reply #43 on: December 30, 2014, 12:55:56 AM »

 Okay, I think is the summary of all items expressed here. Thanks guys for all your nice and constructive comments. I classified them by size, I think I'll just start on small ones, they should be simple, I'd like to see (F) and (A) specially done, and I think (D) is a very interesting project too. (E) is a *VERY* nice idea. We'll see. I'll open posts for each task being implemented, if anyone wants to help with any oth the items, just do it. :)

 The "Unknown" projects, are really that, an enigma, need further discussion.


Big

 - (A) Two lanes interesections/ways/avenues. Add the concept of one-direction street, and generalize it maybe to avenue/highway.
 - (B) (Sarlock) Alpha channels on images , this will very probably need hw acceleration to perform good.
 - (C) (rainer): Handling of pakset objects with a HTML/CSS interface as frontend
 - (D) (rainer): Revamp pak creation tools, probably mixed with the item before this.
   *  the merge option of makeobj ( ??? )
   * .dat checker
   * Something like a tile-cutter, but with the possibility to produce bigger objects (beyon 5x5 tiles)  without filling all tiles in it.
   * Automated packing of bigger convoi objects as 96er, 128er (instead of 64er).
   * Any piece of software being able to produce simplified .pngs, just with the edges of the objects (here mostly convois) for every given length/width/height.

Medium

 - (R) (colonyan) industry chain placement handling. Previous work in http://forum.simutrans.com/index.php?topic=10235.0 .
   * (spenk009) http://forum.simutrans.com/index.php?topic=14243.msg141006#msg141006
   * (Leartin): http://forum.simutrans.com/index.php?topic=14243.msg140993#msg140993
 - (E) (Isidoro): A spreadsheet-like view of the vehicle available in the depot when buying.  One row for each kind of vehicle, one column for each kind of property.  Sorting data available for any column.
 - (F) (Isidoro): An option that allow buses not to stop in a stop if there are no people waiting there and there is no passenger in the bus waiting to leave the bus in that station.  That would mean that buses could be more competitive in urban lines.
   * (jamesonpetts) Alter the way in which road stops work to allow vehicles to overtake stationary vehicles waiting at the stops, and to allow terminal road stops to accommodate two vehicles at once, rather than only one as at present.
Small

 - (G) (wlindley) Categorize monuments as monuments, not as attractions.
 - (H) (Yona-TYT) Bridges should modify the ground. http://forum.simutrans.com/index.php?topic=14247.msg141070#msg141070
 - (I) (Isidoro) A way to incorporate meta-data in height maps so that placement of cities, for instance, could be added from real place data.
 - (J) (Yona-YTY) Zoom on the cursor position for the mini map.
 - (Q) (rainer) Ability to switch off seasonal change

Unknown

 - (K) (The Hood) Add the concept of "civic" buildings/services to a city, not like atractions like are now. 
 - (L) (colonyan) Think on how to give RSI (Residential Service and Industrial) buildings a meaning, not just cosmetic.
 - (M) (colonyan) Make cities grow in different speeds, regarding more factors, current algorithm is "simple".
 - (N) (colonyan) Revisit city cars.
 - (O) (gauthier) automatic spacing of convoys along a line
 - (P) (DrSuperGood) I would advise revising either growth or adding a convoy type list with planner. (I don't really understand what does this mean :) )

I was involved in that project and I thought and think that it is not as hard as it is believed to be.  However, I desisted when I got tired of fighting against the establishment.  Too much effort to risk, too much negative feedback, no constructive help, and a foreseeable small probability to get that work incorporated...

 I understand what you say, I feel the same often. Let's see if this time it's different.


Very much not abandoned, just bumped down the queue a bit. Has performance implications, hence working to improve the performance first so ideally we end up even. But on again / off again progress, too easily distracted by shiny things...

 I'd really suggest you ignore performance now, I don't really think you can get much extra FPS anywere, and just focus on this project. It's going to be a huge change in our game, and our players will love it. People allways can get a new computer. :) Or not, but there is allways time to try to di`out more performance, that task won't ever go away.

 So, if you still have an eye on this, do you volunteer to start this task again? Do you need help? We start talking again about it on the thread?

Offline An_dz

  • Web Admin
  • Administrator
  • *
  • Posts: 2841
  • D'oh
    • by An_dz
  • Languages: pt, en, it, (de)
Re: Bored programmer
« Reply #44 on: December 30, 2014, 01:56:12 AM »
Off-topic: @jamespetts
Simutrans works well on a large scale because of its use of a mix of low level agent modelling for passengers, goods and vehicles, and higher level statistical modelling for other aspects of the game.
The same reason SimCity4 works. - Thanks a lot for sharing your experience with agents.

Offline DrSuperGood

  • Dev Team
  • Devotee
  • *
  • Posts: 2635
  • Languages: EN
Re: Bored programmer
« Reply #45 on: December 30, 2014, 05:04:20 AM »
Quote
- (P) (DrSuperGood) I would advise revising either growth or adding a convoy type list with planner. (I don't really understand what does this mean :) )

Growth model revision would be using global growth that goes towards a finite population amount when 100% global satisfaction is reached. From the global growth it then propagates down to towns based on their local satisfaction metrics and size (so cities generally grow more than towns etc). Industry growth then increases linearly with global population (or can decay, depends on what people want). To allow better balance of industries they are given a cost weight which means that simple factories like solar power can be made to use less population than large chains like concrete (build with usual industry placement logic when the industry availability counter is greater than 0). This model would solve problems such as city spam resulting in faster growth, infinite population as time goes towards infinity and imbalance between factory chain spawning (specifically green energy spam that can occur).

By "convoy type list with planner" I refer to a window that lists all available convoy types with certain filters for different types. It is also time-invariant allowing you to view both obsolete convoys and convoys that have not yet been introduced, kind of like a convoy encyclopaedia. The planner is for convoys like engines where you can mess around with different coach combinations without having to own a depot and buy/sell the engines. The planner feature would probably look similar to the convoy replace feature of experimental where you can try out a variety of convoy assemblies without committing to anything. It could eventually be turned into a replace feature but that is less important. A list of all waytypes, station components etc could also be useful.

Offline jamespetts gb

  • Simutrans-Extended project coordinator
  • Devotee
  • *
  • Posts: 18555
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Bored programmer
« Reply #46 on: December 30, 2014, 09:54:27 AM »
Off-topic: @jamespettsThe same reason SimCity4 works. - Thanks a lot for sharing your experience with agents.

Ahh, yes, and you will notice that, in Sim City4, all the people in a building tend to go to just one or two workplaces: there is a reason for that, and it's not that the programmers were lazy.

Offline DrSuperGood

  • Dev Team
  • Devotee
  • *
  • Posts: 2635
  • Languages: EN
Re: Bored programmer
« Reply #47 on: December 30, 2014, 01:53:37 PM »
Quote
Ahh, yes, and you will notice that, in Sim City4, all the people in a building tend to go to just one or two workplaces: there is a reason for that, and it's not that the programmers were lazy.
I thought they were too busy vandalizing the premises and stuffing far too many people in it so the city looks dirty to bother working. I could swear it was impossible without mods to keep a reasonable city without housing degradation occurring everywhere.

They did not actually keep track of individual people, more just test if people from one place could find work in another and that the work was not over-used. Apparently several mods were made which improved the model used at the cost of more processing time (which was fine due to the clock inflation of the time) so they were less terrible.

Offline jamespetts gb

  • Simutrans-Extended project coordinator
  • Devotee
  • *
  • Posts: 18555
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Bored programmer
« Reply #48 on: December 30, 2014, 02:23:42 PM »
I used to play with the Rush Hour expansion pack and the Network Addon Mod and managed to get reasonably dense city centres without too much entropy. With the Rush Hour expansion, one could see little lines on the roads with a certain overlay enabled showing where residents from each specific building went to work and where workers in each specific building lived.

Offline Markohs

  • DevTeam, Coder/patcher
  • Devotees (Inactive)
  • *
  • Posts: 1559
  • Languages: EN,ES,CAT
Re: Bored programmer
« Reply #49 on: December 30, 2014, 02:23:55 PM »
What about adding zoning to simutrans like simcity has? Is this a stupid idea? This links with ideas expressed in this thread. Maybe as a mod, a optional addon to the game.
 Maybe just mod this to simulate city cars traffic, and to generate pax with destination
 If done right, all this pax generation, city building can be calculated in extra cpu's and will be assumible. Maybe this calculus can be done outside frame processing, and applied atomically at the end of the day.

Offline jamespetts gb

  • Simutrans-Extended project coordinator
  • Devotee
  • *
  • Posts: 18555
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Bored programmer
« Reply #50 on: December 30, 2014, 02:36:39 PM »
What about adding zoning to simutrans like simcity has? Is this a stupid idea? This links with ideas expressed in this thread. Maybe as a mod, a optional addon to the game.
 Maybe just mod this to simulate city cars traffic, and to generate pax with destination
 If done right, all this pax generation, city building can be calculated in extra cpu's and will be assumible. Maybe this calculus can be done outside frame processing, and applied atomically at the end of the day.

The real question is who would do the zoning (and who would do it in a multi-player game)? The idea of Simutrans is for players to play a transport company and the rest of the environment is taken care of.

Offline Yona-TYT ve

  • Devotee
  • *
  • Posts: 1179
    • Simutrans-BLOG
  • Languages: ES
Re: Bored programmer
« Reply #51 on: December 30, 2014, 10:53:31 PM »

Offline TurfIt

  • Dev Team, Coder/patcher
  • Devotee
  • *
  • Posts: 1323
Re: Bored programmer
« Reply #52 on: December 31, 2014, 12:35:10 AM »
I was involved in that project and I thought and think that it is not as hard as it is believed to be.  However, I desisted when I got tired of fighting against the establishment.  Too much effort to risk, too much negative feedback, no constructive help, and a foreseeable small probability to get that work incorporated...
I just spend a couple hours reading through that thread. While the words each contributor typed were English, clearly everyone was assigning a different meaning to them. Absolutely no communication was occurring, so everyone walking away from that type of environment is not surprising.


So, if you still have an eye on this, do you volunteer to start this task again? Do you need help? We start talking again about it on the thread?
I do definitely still have an eye on it. I just spend 3 days getting my sync_step()/multithreaded/profiling/memory_management patch back into compilable shape (>1 yr since last looked at). My intent was to extract the good parts, then start looking at other unfinished items (such as these multi-lane roads).   The question is, what type of project are you looking for as a bored programmer? i.e. Collaborative, solo, huge, small, etc...


A further suggestion for a project: NEW CLIMATES MODEL (was: The Equatorial Wind).  It's a shame the per tile climates included in Kieron's patch are being completely overshadowed by the double/half heights portion. Perhaps if the map generator could make use of them somehow...

Offline kierongreen

  • Dev Team, Coder/patcher
  • Devotee
  • *
  • Posts: 2269
Re: Bored programmer
« Reply #53 on: December 31, 2014, 02:14:02 AM »
Quote
A further suggestion for a project: NEW CLIMATES MODEL (was: The Equatorial Wind).  It's a shame the per tile climates included in Kieron's patch are being completely overshadowed by the double/half heights portion. Perhaps if the map generator could make use of them somehow
'All' it needs is climate generation code on map initialisation... The sandy bays and not so sandy headlands were meant to be a simple example of the flexibility of the new system. Although if there's a comprehensive new climate model then it will have to be defined what happens when terrain height is altered.

As has been mentioned on other threads though - a new climate model could be coded alongside a resource map and the two in conjunction with topology and proximity to settlements would define likely industry chains. The effect would be that some areas of the map would be agricultural, some forestry, while heavy industry would be clustered near coal and iron seams (and on the coast where possible), and large scale power generation should be close to, but still a certain distance away from larger settlements. Hydro-electric power plants on steep rivers, potentially also sometimes with dams and lakes would be nice too. The question becomes does this all add realism, or is it just added complexity when a bit of imagination by the player could be just as satisfying.

Offline IgorEliezer br

  • Devotee
  • Administrator
  • *
  • Posts: 4083
  • Cake recipes are cool... REALLY!
    • Igor Eliezer Architect and Urban Planner/Arquiteto e Urbanista
  • Languages: PT, EN, AutoLISP, Python
Re: Bored programmer
« Reply #54 on: December 31, 2014, 02:59:28 AM »
What about adding zoning to simutrans like simcity has? Is this a stupid idea?
and
The real question is who would do the zoning (and who would do it in a multi-player game)?
I think there has always been a pent-up demand for more planning or design tools in the game. Once a player has mastered the game he would like to shape the environment and have more control over how the game develops (gaming-wise, not coding-wise). Zoning is one of these aspects which the player has no control yet.

I see two approaches: 1) in single player: a player could design all the terrain, including all infrastructure, city layout and zoning, then upload the world as challenge so other players can play on the map. 2) multiplayer: the server admin would design the cities for client-players to play on the map. More control over the world is meant for server-admins.

Additionally, it's safe to say those planning tools should not be accessible right off the bat for non-advanced players.

Offline colonyan

  • Devotee
  • *
  • Posts: 526
  • Full and Warm
Re: Bored programmer
« Reply #55 on: December 31, 2014, 04:54:06 AM »
about Industry placement.  Density of Industry buildings in any area. Also sheer number of industry on the map

I think this can be controlled, even in standard, by having final consumer to handle several or many freight type and in small quantity.
Say, generalize final consumer industry as commercial district or whole saler. Make them sell most of final product. One final consumer will be able to house
several industry chain expansion.

Offline DrSuperGood

  • Dev Team
  • Devotee
  • *
  • Posts: 2635
  • Languages: EN
Re: Bored programmer
« Reply #56 on: December 31, 2014, 05:42:07 AM »
Quote
I think this can be controlled, even in standard, by having final consumer to handle several or many freight type and in small quantity.
Say, generalize final consumer industry as commercial district or whole saler. Make them sell most of final product. One final consumer will be able to house
several industry chain expansion.
This idea has potential in some form or another.

Currently a shop is a single building, some times as small as 1 tile that can consume a lot of units of product at a time. In real life they would be districts that are considerably bigger in area than a single shop. So a possible idea would be to create a new field type with special placement mechanics. This field is "shops" which are placed just like normal city buildings. As the sector grows (more shops are created) so will its demand. This mechanic would work well for certain industry types such as a industrial area for building materials and a shopping district instead of a supermarket. The core of the district (which you deliver to) is then some distribution depot.

Offline colonyan

  • Devotee
  • *
  • Posts: 526
  • Full and Warm
Re: Bored programmer
« Reply #57 on: December 31, 2014, 06:18:53 AM »
This idea has potential in some form or another.

Currently a shop is a single building, some times as small as 1 tile that can consume a lot of units of product at a time. In real life they would be districts that are considerably bigger in area than a single shop. So a possible idea would be to create a new field type with special placement mechanics. This field is "shops" which are placed just like normal city buildings. As the sector grows (more shops are created) so will its demand. This mechanic would work well for certain industry types such as a industrial area for building materials and a shopping district instead of a supermarket. The core of the district (which you deliver to) is then some distribution depot.


That sounds good. So each city with certain size will have its own final consumer?

In extreme case, I imagined the system where, every single 1X1 commercial and industrial city building above certain level was its own industry which has demand supply of freight. This would be chaotic.

So I was imagining system where like existing passenger and mail, how about if we had
business passenger : Spawn from commercial and industry city building and
only destines other commercial and or industry city building in map. (maybe industry too)

mixed cargo : Spawn from industry city building and destines other I-city building.

Then it will be little redundant so this was not so helpful.


Another thing I've remarked is that current (based on pak64 and assuming also for other paks too) final consumer consumes too much.
Game should be enough with 1~2, max 3 supply chain and much more smaller and distributed final consumer.
So ideally, # of final consumer to be much larger than # of raw/processing factories/plants.

But most importantly,
if we could incorporate current chain industry and city building industry, it will slim the system? Also this involves commercial sector too. As final consumer is commercial building in our view.

Offline Isaac.Eiland-Hall us

  • Benevolent Dictator
  • Administrator
  • *
  • Posts: 3649
  • PanamaCityPC.com/support/
    • Facebook Profile
  • Languages: EN
Re: Bored programmer
« Reply #58 on: December 31, 2014, 07:58:35 AM »
I'm probably too late, but I do have two requests to put in for consideration that I hope are relatively minor and could be optional in simuconf:

1. Some way to protect ways(roads) from the city to take them over and connect to them. I even thought of a method to mark such tiles: click properties for a road tile you own and can check a box for protection. City cannot connect to this tile, nor can it make it city_road. Tedious to do? Yes. So two tools to add to menus - each drags over ways and either checks or unchecks the boxes for all possible tiles.

2. The ability to build bridges like elevated ways - curves, tile-by-tile

I really like a lot of the Simcity-type talk in this thread. I've long felt a natural progression from SimCity to Simutrans taking over that role as SimCity has lost its way.

The avenue discussion and zoning are particularly interesting to me :)

Offline The Hood

  • Devotee
  • *
  • Posts: 2889
  • pak128.Britain developer
Re: Bored programmer
« Reply #59 on: December 31, 2014, 09:49:30 AM »
At the risk of throwing in yet more ideas into the melting pot rather than helping decide:

1) Multi-tile city buildings (to allow for properly proportioned skyscrapers or even whole residential estates)
2) Modular buildings, especially for industry. Pak128.Britain has a number of buildings which are composed from a relatively limited set of 1x1 elements arranged in different ways to create different buildings. So a lot of the 19th century factories have used the same brick factory tiles but combined them with a few tiles unique to that industry (e.g. coal heap) to create different  buildings. This could be used even more flexibly to allow a greater visual variety of buildings of the same type. You can sort of achieve this effect using fields but (a) no rotations are allowed (b) there is no way of constraining which tile goes next to another. If this sounds interesting I can create screenshots to show what I mean...
3) Combine both of the above with the zoning idea to create a zone for 1990s housing development or tall tower blocks that must be surrounded by tiles of park


Definite support for adding new climates to the map generation model, ideally with industry placement too...

Offline Ters

  • Coder/patcher
  • Devotee
  • *
  • Posts: 5469
  • Languages: EN, NO
Re: Bored programmer
« Reply #60 on: December 31, 2014, 10:21:36 AM »
andI think there has always been a pent-up demand for more planning or design tools in the game. Once a player has mastered the game he would like to shape the environment and have more control over how the game develops (gaming-wise, not coding-wise). Zoning is one of these aspects which the player has no control yet.

I see two approaches: 1) in single player: a player could design all the terrain, including all infrastructure, city layout and zoning, then upload the world as challenge so other players can play on the map. 2) multiplayer: the server admin would design the cities for client-players to play on the map. More control over the world is meant for server-admins.

I don't thint static zoning as in #1 can work. Urban development needs to adapt to the evolving game. In a single player game, that would essentially turn the game into some semi-Simugov, where the player plays a government that happens to run a state-owned transportation agency.

Having a player play the government in multiplayer makes more sense. Especially if that player can take an almost antagonistic stance, yet also with an ability to offer rewards, similar to the subsidies one can get in Transport Tycoon.

1. Some way to protect ways(roads) from the city to take them over and connect to them. I even thought of a method to mark such tiles: click properties for a road tile you own and can check a box for protection. City cannot connect to this tile, nor can it make it city_road.

Such roads should however not count as streets in the city rules. In other words, buildings should not be built near such roads (unless other nearby streets are present), as they can not connect their driveways to them either. Otherwise, one could simply replace all city roads with highways, and bypass all the challenges of urban transport (except congestion at junctions).

1) Multi-tile city buildings (to allow for properly proportioned skyscrapers or even whole residential estates)

I thought we got them not too long ago. Something prissi committed that neroden (I think) wrote. Or did I misunderstand what that was about?

Offline jamespetts gb

  • Simutrans-Extended project coordinator
  • Devotee
  • *
  • Posts: 18555
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Bored programmer
« Reply #61 on: December 31, 2014, 10:59:11 AM »
... multiplayer: the server admin would design the cities for client-players to play on the map. More control over the world is meant for server-admins.

As a server admin, I should note that the prospect of having manually to edit the growth of all 419 towns on my large server map in real time is not one that fills me with joy. Really, town growth has to be fully automatic or else it is not workable on large maps or in multi-player games.

Offline Markohs

  • DevTeam, Coder/patcher
  • Devotees (Inactive)
  • *
  • Posts: 1559
  • Languages: EN,ES,CAT
Re: Bored programmer
« Reply #62 on: December 31, 2014, 11:01:39 AM »
I think I'll just wrap my summary, plus the new commented items, post it somewere as reference, as a TO-DO list, for me and for anybody that wants to explore them. I'm on the bridge building improvement Yona/james commented, once I'm done, I'll pick another from the list.

 If any of the items need further discussion, we open a thread for each of them in extension requests.

 EDIT: About zoning, we can have it into a in-between sultion. The zoning and re-zoning (requalification) are done automatically by the city growth algoritm, *AND* the game generates PAX (workers, visitors) between them. Like simcity, but automatically. We also create "tratic congestion", of what we have now with city cars. If we could see the rush-hour feature of seeing thraffic flow, it whould be amazing.

 For those that don't know what we are talking about:




Offline jamespetts gb

  • Simutrans-Extended project coordinator
  • Devotee
  • *
  • Posts: 18555
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Bored programmer
« Reply #63 on: December 31, 2014, 11:12:34 AM »
I think I'll just wrap my summary, plus the new commented items, post it somewere as reference, as a TO-DO list, for me and for anybody that wants to explore them. I'm on the bridge building improvement Yona/james commented, once I'm done, I'll pick another from the list.

 If any of the items need further discussion, we open a thread for each of them in extension requests.

 EDIT: About zoning, we can have it into a in-between sultion. The zoning and re-zoning (requalification) are done automatically by the city growth algoritm, *AND* the game generates PAX (workers, visitors) between them. Like simcity, but automatically. We also create "tratic congestion", of what we have now with city cars. If we could see the rush-hour feature of seeing thraffic flow, it whould be amazing.

I looked into this extensively a while back (private car simulation, that is). This does not scale well: on a very large map, calculating all of the routes would be far too CPU intensive to be viable. In Experimental at present, private car routes just between each city hall and every other city hall are currently computed in one pass from each city hall using Dijekstra's Algorithm, and this has to be spaced throughout the month to avoid a slowdown. Routing from every building would be unworkable in larger maps.

Offline Markohs

  • DevTeam, Coder/patcher
  • Devotees (Inactive)
  • *
  • Posts: 1559
  • Languages: EN,ES,CAT
Re: Bored programmer
« Reply #64 on: December 31, 2014, 11:23:29 AM »
I guess so, James, but you can *maybe* just calculate that "monthly", or less often. Even you could calculate that in a background thread, and just apply it, whan it was done. Just an idea, I'm not saying this is really feasible or not.

 Maybe you don't need to calculate 100% of the travels, maybe you can just calculate 10% of them, and multiply their volumes by 10. After all, it's just a simulation.

Offline jamespetts gb

  • Simutrans-Extended project coordinator
  • Devotee
  • *
  • Posts: 18555
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Bored programmer
« Reply #65 on: December 31, 2014, 11:50:01 AM »
This issue was discussed extensively in connexion with Experimental in this thread, especially here onwards. Even a monthly calculation from each town hall only (which is what is used at present for the Dijekstra search) needs to be spread out over the month to avoid too much computational strain.

Offline colonyan

  • Devotee
  • *
  • Posts: 526
  • Full and Warm
Re: Bored programmer
« Reply #66 on: December 31, 2014, 02:13:07 PM »
Instead of every town hall to visit all other town hall, how about if they have 5 tickets per X population size?
And they use those tickets randomly, instead of visiting 5 different other cities, one could visit city A 4 times
and city B once.

And, designate a capital and regional capital town hall and make all cities mandatory to visit(route to) them to certain frequency?

By visiting same town hall several time game could save some computation burden.

Offline Ters

  • Coder/patcher
  • Devotee
  • *
  • Posts: 5469
  • Languages: EN, NO
Re: Bored programmer
« Reply #67 on: December 31, 2014, 03:52:02 PM »
I guess so, James, but you can *maybe* just calculate that "monthly", or less often. Even you could calculate that in a background thread, and just apply it, whan it was done. Just an idea, I'm not saying this is really feasible or not.

 Maybe you don't need to calculate 100% of the travels, maybe you can just calculate 10% of them, and multiply their volumes by 10. After all, it's just a simulation.

Sounds like the way to do it, if it is doable at all.

Offline jamespetts gb

  • Simutrans-Extended project coordinator
  • Devotee
  • *
  • Posts: 18555
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Bored programmer
« Reply #68 on: December 31, 2014, 08:09:10 PM »
One other thing springs to mind, on the topic of bridges: there is a long-standing extension request to separate the way from the underling bridge (and, for that matter, tunnel). For tunnels, this is half-way implemented to allow for tunnel ways (although bespoke tunnel ways with inside of tunnel graphics are actually not really consistent with the idea of ordinary ways going in tunnels), although there is a need for new portal graphics.

This is desirable because it allows for upgrading a way without having to pay the much greater cost of replacing the bridge/tunnel.

Offline DrSuperGood

  • Dev Team
  • Devotee
  • *
  • Posts: 2635
  • Languages: EN
Re: Bored programmer
« Reply #69 on: December 31, 2014, 09:56:36 PM »
In the current pak64 server game I have noticed an issue regarding public stops. Currently public stops can only be deleted by the public service provider player making them hazards. Additionally public service provider players might not be available or want to go around the map deleting public stops placed there for various reasons (I am guessing either someone trying to abuse free maintenance or who does not understand their purpose).

So a solution to this would be that public service owned stops are automatically deleted if there is no convoys and goods for 12 months. When they are deleted an announcement message is made "X closed down due to inactivity.". This gives players the ability to delete public stops simply by not using them for a year. Accidental public stops or public stop spam will then automatically be fixed after 1 year.

1 year is chosen due to that being the duration of the graph stops use. That might aid in the implementation.