Potential feature discusion: economic integration

[jamespetts]

Mod note: Please note that I have split off some conversation from this thread, but some posts addressed conversation that got split as well as conversation that didn't, so you will see references to things that got split. My apologies, but there's no cleaner way to do this. -Isaac Eiland-Hall

I should be grateful for people's views on a possible new feature that I am considering. I have written about it before, but in connexion with a much longer thread on town growth, and it is likely to have been lost in that discussion of that much more complex issue. The original plan was to implement this at the same time as town growth, but I am considering deferring the town growth code to a future version to enable an earlier release, provided that I can adjust the actual rate of town growth well enough using the existing mechanisms to prevent the infinite sprawl problems of previous long-term games and also confirm that the town building mechanisms are working better than they once were (what I had thought was a town growth problem may well have been a road building problem caused by not properly implementing some of the half-height changes from Standard a long time ago, which I think may now be fixed; can anyone still reproduce the problem with roads getting cut off in towns when they expand, for example?). However, this feature should in principle be considerably simpler to implement than town growth itself, and is potentially quite worthwhile.

The basic idea is to give a much stronger connexion between passenger transport and industry. This will be important when the new town growth algorithm is eventually implemented, as passenger transport will be the basis for town growth, but it is likely to be worthwhile even before the new algorithm is implemented. It depends upon the new passenger generation system, which distinguishes between commuting and visiting passengers (the former being passengers travelling to work, the latter being any other sort of passenger) and introduces the new concept of jobs. The system would consist of the following additional restrictions on industrial production and passenger transport to industries:

(1) consumer industries with no products to sell would not accept visiting passengers (i.e. customers);
(2) consumer industries with no (or insufficient) staff available would not accept visiting passengers;
(3) consumer industries (except those with a 0 visitor demand, such as a gasworks, which would continue to use the current time based system) would consume products in proportion to the number of visiting passengers arriving, rather than based on time elapsed (a consumer industry receiving 100% of its monthly visitor demand in a month would consume 100% of its specified monthly consumption, 50% at 50%, 200% at 200% and so forth);

(4) producing industries would produce only in so far as they have enough workers (i.e., will only produce at 100% of the normal rate if they have 100% or more of the number of workers that they need; at 50% of the workers, they will produce at 50% of the normal rate, etc.);
(5) producing industries that require inputs to produce goods would not accept any commuting passengers (i.e. workers) if they do not have enough input goods to produce anything; and

(6) (edit) attractions with no staff would not accept visitors.

To put this in context, the new passenger generation system (in devel-new, not the released 11.35) already has a jobs system in which:

(1) each building that is not a residential building has a defined number of jobs;
(2) commuting passengers travelling to that building take up one job slot each for a fixed period of time after their arrival (representing a working day); and
(3) when there are no job slots left, the building cannot accept any more commuting passengers.

The rejection of passengers when there are no more jobs left counts as a failed journey attempt, although passengers are permitted a number of attempted journeys each before giving up entirely. When commuting passengers do give up entirely (either because they have few alternatives allowed to them by random assignment, or because all of the other alternatives fail for some reason) after trying to get to a building which has no jobs left, they will show up as a dark red dot on the passenger destination map. The same failure system I plan to use in all of the above cases in which passengers are unable to travel to a destination.

Currently, the success rate of passengers travelling from residential buildings and the number of visitors received by non-residential buildings is shown in their statistics, but has no effect on game-play. When the new town growth system is implemented, however, the success rates will directly determine how likely that any given building is to develop, and how likely that neighbouring tiles will develop.

I should be very interested in any feedback on these proposals, and in particular if anyone can find any potentials for deadlocks or unwanted consequences.

[Ves]

I'm not home so i can't check wether it's already possible, but in case it's not:
Is it possible to combine everything so what's today is a factory in simutrans  also can have living residents? What I mean is buildings with a store in the bottom floor and apartments in the upper floors, a quite typical building in most cities.

Otherwise I think your suggestions sounds really nice and promising!

Consider in regard to the factories not getting its good and therefore will refuse workers as well: there still might be some workers that is needed on the factory, eg people in the office etc. Are they on purpose left out to simplify things or should they be considered as well?

Also, it might be useful to keep the possibility to make good disappear at the end consumer factory during time (as it currently does) if the consuming is not dependent on passengers going there (eg an airplane manufacturer or similar)

[jamespetts]

Thank you for your feedback: that is most helpful. It is not currently possible to have buildings that are both residential and commercial/industrial at the same time, but this is under consideration for the town growth improvements. This can be dealt with separately and at a later time than what is proposed here.

As to a small number of staff needed to maintain things even when there are no goods, such gameplay as this might improve hardly seems worth it for the extra work involved; I suspect that this is one of the things that is better kept simple.

As to your last suggestion, this is already part of the original proposal: see the reference above to the example of gasworks. This state of affairs would be denoted by the building having a visitor demand of zero.

[scamps]

You definitely don't follow KISS principle

There at least needs to be a way to see whether a factory is staffed and to what amount (interface work required?)

Players already have to set up transport to whole supply chains, and amount of investment to provide longer chains with transport can be off-putting.

The system will be more player-friendly if:
- The majority of trips will be to workplaces and shops (people go to work 5 days a week, visit attractions no so often).
- Passengers that reach their destination on foot or on personal transport count.
That way industry and shops, located in towns, will be at least partially supplied with labourers and will not strictly require players to set up transport


Please clarify:
- Do shops (attractions) require both staff and customers? Are customers ignored completely if the shop is not fully staffed?
- If for example a shop requires 4 staff and 15 passengers arrive, do 11 passengers become coutomers or are discarded?
- What do you mean by 200% consumption in (3)? Is top consumption rate no longer limited? Makes sense to tie number of accepted customers to staff avialible.

[jamespetts]

Iluvalar: what you suggest is really quite a different thing to what is being discussed here. Unlike what I propose here, which is a relatively straightforward extension to an already existing system, what you suggest would involve a radical redesign of the game which would probably take me years (literally). It is also not clear precisely how what you suggest would work, especially with respect to the idea that things "flow along roads". Would this require an entire new pathfinding algorithm? That is likely to be too computationally intensive for an extremely large map. Indeed, this sounds very similar to the Sim City (2013) Glass Box engine, which was largely a failure precisely because it was too computationally intensive (which is why the city sizes were so restricted). It is also not clear how the idea of these things "flowing along roads" is consistent with the idea of simulating the transport of things directly (with 'buses, lorries, walking, private cars, etc.).

It also does not seem to make sense to treat "shopping", "entertainment", etc. as a resource: shopping is the act of a person purchasing resources from a shop. The resources are not the idea of shopping in the abstract, but what is bought. Similarly, entertainment can involve myriad differnet things, some of which do not require any resources. It is not itself a resource.

However, the town growth system that I plan to add later will have some sort of concept of desirability. I have not decided quite how it will work yet, but one idea would be for buildings and other objects to have a radius of effect on different types of desirability and a level: an industrial building might have a 10 tile radius of -5 residential desirability, for example, which would (albeit indirectly) simulate pollution. (Indeed, the existing town growth system from Standard does something a little bit like this, but only for types of city buildings, not indiviually determinable by specific buildings).

***

Scamps: there should be a way already to see how many jobs are being taken in industry buildings using the graphs. Is this not clear? I could add the same indicator as in city buildings (e.g., "Jobs: 2/25") if that would help.

It is definitely intended that passengers reaching their destination on foot and by private car count: that is an important part of the system. Indeed, this element is largely already present. The idea would be for industries in the early days to be within walking distance of towns (as they were in reality), and only later would there be so many industries (and so large a set of towns) that people would have to use public transport, provided by players (and, indeed, it is intended that this sort of growth will only be possible when players provide transport in the first place, creating a sort of positive feedback cycle).

As to the destinations of trips, there are two types of passengers: commuting passengers and visiting passengers. Commuting passengers are travelling to work, and find buildings with jobs. Visiting passengers are making any other kind of journey, and find buildings with a visitor demand (the greater the visitor demand, the more likely that the passengers are to go to the buildings: the destinations are chosen using a weighted random system). When commuting passengers arrive at the destination, they diminish the number of available jobs at that destination. When visiting passengers arrive at a destination, they are recorded as a visitior in the statistics.

To answer your questions, shops (that is, consumer industries) and attractions are quite different things. Under the proposed system, they will require staff to operate and accept visiting passengers (unless the number of jobs is set to zero, as it might be at, for example, a monestary where everyone lives in). Visiting passengers and only visiting passengers will consume the resources of consumer industries (unless the visitor demand is set to zero, as in a gasworks, in which case resources will be consumed on a time basis as at present). A commuting passenger cannot be converted to a visiting passenger or vice versa once generated. If a shop has 4 job slots and 15 commuting passengers arrive, the shop will have -11 job slots. It would then be 11/4 months before any job slots are available again. No commuting passengers will be able to start their journey to that particular shop until there are job slots.

The idea is not to require a 100% complement of staff, but a certain minimum level, as it is unlikely that anything will be able to maintain 100% all the time. The minimum level will probably be able to be specified at pakset level as a proportion of the total number of job slots. This is realistic, as a shop being a little  short staffed does not necessarily mean that it will close.

By 200% consumption, I mean 200% of the specified rate of consumption in the .dat file. The consumption rate of a consumer industry would no longer be fixed on a time basis (except for those industries that have zero visitor demand), but would depend on the number of visitors. However, the likelihood of passengers wanting to visit the particular industry would still be weighted based on the visitor demand.

The actual mechanics are not entirely simple (although considerably simpler than what Iluvalar seems to be proposing), but the actual operation should be quite intuitive.

***

Thank you both for your feedback: it is much appreciated.

[isidoro]

Those are great ideas.

However, I would implement workers and customers differently to be more realistic.  Usually, albeit less and less nowadays (a pity!), workers flow have "memory".  People work in a place and go to their work place every day and back.  So, I would make factories have a list of workers addresses and request passengers from there (when enough input).

Customers or visitors can have the proposed behavior, though. 

[jamespetts]

I did consider the idea of people having specific jobs, but rejected it because of what would be likely to be excessive memory bandwidth requirements which would affect performance. The difference in gameplay would be relatively modest.

[HarrierST]

I should be grateful for people's views on a possible new feature that I am considering. 

The basic idea is to give a much stronger connexion between passenger transport and industry.

Silly me. 

I thought this was a necessary and built in feature of all the paks. When playing my first game on Pak64, after connecting goods yards to an industry -  I then connected passenger services to get the workers there.  Did not realise I was wasting my time - and money.

So - yes I support this 100%. 

EDIT.

Where  do I download the "DevelNew" version from ? I do not mind playing in-progress and potentially bug ridden versions. As long as I do not have to compile them my self.

[jamespetts]

Thank you for your feedback - that is most useful. I think that there is some element of passenger transport to industries in Standard, but the relationship between passenger transport and industrial production is different to what I propose here (there was a time when there was no relationship at all, but a system implemented a few years ago can boost industrial production if the industry is supplied with enough passengers; this is different from the idea of commuting passengers specifically filling job slots as in devel-new).

As for downloading devel-new, I do not release binary versions as it changes so often, it would take too much time to do so for every change (and if I did so only periodically, people would forever be reporting bugs that have already been fixed). The people who  are playing it at present are those who have compiled it themselves. It will be put out in binary form as a release candidate when it is feature complete for the next release for further testing and refinement.

[Vladki]

I like this proposal. Just a note to point 6. There should be attractions and factories with 0 jobs, that are not affected by these rules - think about freely accessible atractions: monuments, castle ruins, stonehenge, nature, or photovoltaic and wind power plants. Those things need some maintenance, but most of the time they work unattended.

And be cateful about deadlock like this: factory has empty input so it does not accept workers, but it does not order goods because it has no staff to process them.

[jamespetts]

Vladki: thank you - both points are noted. 0 jobs having the effect that you describe seems sensible and industry demand must not depend on the presence of workers (things can be delivered even if the factory is short of staff so that work can begin once some employees arrive).

Iluvalar: there are two separate suggestions in your post, as far as I can tell: firstly, the idea that the the desirability parameters be fully customisable and secondly the idea of workforce being a resource. (There is also the suggestion of holding the adjusted desirability values in memory in the individual tiles, which is what I had planned to do in any event: a building will add its desirability values when it is built and remove them when it is deleted, which is the most computationally efficient way of doing this).

I shall deal with each in turn. Firstly, the customisable parameters. This is actually quite an interesting idea and should not in principle be much more difficult to code than fixed "residential", "commercial", "industrial", etc. parameters. There might be something to be said for having a mixed system to make it easier for pakset creators to do common things: have a "residential" desirability, for example, but also some customisable parameters which can be set in a building's .dat file. For example, a building might be coded to have susceptability to desrability type 5, and other buildings might then radiate positive or negative values for desirability type 5, the meaning of which can be determined by the pakset author. One possible problem with this, however, is that, for each type of desirability, a further variable needs to be held in memory for every single tile in the game. For extremely large maps, this might be quite significant, so both the number of these variables and their size in bits needs to be carefully limited (a signed 8 bit integer should suffice for each type of desirability). Quite what the memory bandwidth implications of this might be will have to be considered in more detail in due couse. However, this is, of course, an issue to consider when formulating the revised town growth algorithms, which is a somewhat separate issue and is likely to be addressed later (and possibly even in a later release).

As to the second idea, the idea of a workforce being distributed from residential buildings by proximity: this idea seems to me inconsistent with the idea that the game is inherently about simulating transport. The idea is for commuting passengers to travel, either by walking, by private car or on player transport, to their destinations and for that transport to be an inherent part of the game mechanic. The idea that you suggest of distributing workers by radius seems to me to be a way of approximating very basically what the game sets out to (and already does) model in detail as part of its core mechanic. A fundamental principle of the desirability model that I set out above is that it is intended to apply only to things (such as pollution or visual amenity) that are not moved from place to place by transport of the kind simulated in the game (including walking and private cars).

[jamespetts]

Sarlock: the distribution of industries (whether in cities or outside cities) is something that can largely be set at pakset level. In the half-heights branch of Pak128.Britain-Ex (the development branch of the pakset to go with the devel-new branch of the code), I have made most types of industries with the exception of farms, forests and some later heavy industries town rather than country industries, with the result that, unless there be insufficient space in towns, most should be built in or around towns.

Iluvalar: if you are imagining an A* routing system, then this really is very computationally intensive (and will require considerably more than 8 CPU operations per tile per tick; I had not understood you to be referring to low level CPU operations above; there are lots of those for each line of C++ code). However, it is not clear whether this is what you are intending, since A* is a means of finding the shortest path to a specified destination using a heuristic. It is not actually clear precisely how what you propose would work, so it is difficult to assess accurately the computational load, but anything that requires actual path-finding along roads (rather than just simple effect radii) is likely to be too computationally intensive if it has to be done from all buildings even periodically. You will recall what I wrote above about it not being possible to use A* for all of the private cars even on a modestly sized map (tens, rather than hundreds, of cities, and dimensions both under 1,000 tiles). Edit: Note also that it is not just about the number of CPU operations, but also the memory  bandwidth required.

However, the main issue with what you suggest is that it is not consistent with the idea of simulating transport directly: having two independent and totally different means of simulating workers going to jobs is unworkable.

What do you mean exactly by missing 1 job every 11 trips? I do not understand what you think that it means to miss a job per given number of trips in the context of the system that I describe. I consequently do not understand the rest of your calculations. Can you explain them?

As I wrote above, the passenger generation system is already implemented and has already been tested extensively. It does indeed produce a realistic level of job fulfilment. The idea is that industries need not have a 100% level of job fulfilment in order to function, but that the level of job fulfilment required be specified at pakset level.

[zook2]

Scamps: there should be a way already to see how many jobs are being taken in industry buildings using the graphs. Is this not clear? I could add the same indicator as in city buildings (e.g., "Jobs: 2/25") if that would help.

That currently requires four clicks, if memory serves.
---
What if a factory like a steel mill with thousands of jobs opens up in a small town with only 500 inhabitants, and the nearest city where the other workers live is 200 tiles away, as in the 11.35 version? Is Granny Smith required to put on a hard hat, too? (BTW, I still think that the current 11.35 version serves well to simulate the early Soviet economy)
---
If a stop serves two or more businesses: in what order are jobs being filled? If it's random (or proportional): could you end up with a bakery next to a steel mill never getting any (or enough) workers?
---
You might consider putting your Reply #16 in a new post and sticky it. It very useful.
---

The reason for the failure is recorded on the colour coded "passenger destinations" overlay in the minimap

Is there a way to enlarge it, or put it as an overlay in the main overview map window? On a large map it''s much too small to be useful.

[Banksie_82]

I hope you don't mind if I briefly dumb the conversation down to my level.

Sometimes I like to play maps where I concentrate exclusively on freight transport. Something about the simplicity and the network patterns appeals to my mildly autistic mind when I just want to mentally 'switch off'. When I'm in that kind of mood, I don't want to fiddle with passenger networks.

Will passenger transport to industry be compulsory, or at least strongly encouraged to get the most out of the freight transport? If that's the case, can the feature be switched off and the current arrangement maintained where passengers only provide a small boost?

[jamespetts]

Zoosk2: checking again in the latest devel-new version, the "Jobs (available): x (y)" display is now shown on the main industry information window, so this should make things easier.

If a large steel mill opens in a tiny town miles from anywhere, then it may struggle to produce a great deal unless the player is able to send plenty of fast transport to it from a neighbouring large town. However, residential buildings in that town would then show a very high success rate for commuting trips which, when the new town growth system is implemented, would tend to cause that town to grow at a fast rate, as people tend to want to live where they can find jobs.

As to stops serving multiple destinations, remember that passengers choose their destinations at the time that they are generated, so it does not matter how many buildings that a stop serves: passengers are going to one specific place and that place only. It therefore does not much matter where the bakery is relative to the steel mill: it mainly matters where the bakery is relative to houses.

As to the passenger destinations display, it cannot be made an overlay in the main map window, but the minimap can be zoomed so that one can clearly see the detail at the level of individual towns.

Iluvalar: I am still having some difficulty following precisely what you mean, I am afraid. What do you mean by "3 travels" here? Also, what do you mean by not simulating all of the traffic for a month? As I explained, a month is constituted as a fixed number of hours (6.2 by default), and a realistic amount of traffic for 6.2 daylight hours is indeed generated in a game month (at default settings). I do not understand what you mean by "extreme sawtooth" here: can you be more precise as to the specific mechanism to which you are referring that you think might produce this result? I really do not think that you understand fully the system that I have described, but it is very hard to tell since it is very difficult to understand what you write.

As to the simulation being "unresponsive", it is again unclear what you mean by this. It does take a little while for the jobs to fill initially when a new game is started or when a building is created, so there are some time lags, but this is not significant for the overall simulation.

I am unclear what you mean about a shop "hav[ing]" the consumers for 3 months: you seem to be confusing what I suggest for consumers with what already exists for jobs, which are quite different. As I wrote in the initial post, the idea for consumers (visiting passengers to consumer industries) is that they consume a proportion of the consumer industry's stocks at the moment that they arrive. There is (and is proposed to be) no concept of an industry "having" consumers for any period of time in the same way that a building retains workers (in the form of filled job slots) for a period of time.

I understand the system that you suggest in itself: what I do not understand is how you imagine it interacting with a game whose principal objective is the direct simulation of transport. What you propose is in effect a completely different (and much more approximate) way of simulating transport that seems to be focussed on simulating walking. I do not understand how you think that this would (or why one would want it to) fit into a game whose primary purpose is to simulate public transport (i.e., 'buses, trains, ferries, aircraft, etc.). To put it another way, if workers are simulated as a resource flowing slowly from tile to tile (whether along roads or otherwise), how are players to transport some of them to their jobs by 'bus, tram, train or ferry? How do we tell which workers have a car, how many car trips that there are and how that number of car trips affects congestion in a city, which in turn affects the journey time of all other car transport, which, in turn, affects whether any given journey is viable or whether people choose to take their car or public transport? How would that system allow a causative relationship between a good tram network and an industry being able to produce at full capacity?

Your idea is very interesting in itself, but it really is not - as far as I can tell - something that is useful in Simutrans.

Banksie_82: That is an interesting question. I had not considered that sort of limited play. You might organise a map in which the industries are well served by walking passengers, perhaps, or enable "assume_everywhere_connected_by_road" and edit the privatecar.tab (importantly before you generate the map, or else your edits will not apply to the map) to have 100% private car ownership in all eras so that workers can always get to industries by car. That latter method will probably be the easiest way of doing it, as I am not sure how easy that it would be to code a way of disabling this feature at the user (rather than pakset creator) level.

[isidoro]

I think that you have made two misunderstandings of the simulation of passenger transport. First of all, you appear (although this is not clear because your description is rather vague) to think that, in any given month, a job slot is either filled for the whole month or not at all. This is not how it works. A building with 3 job slots will accept commuting passengers until such time as it has zero job slots remaining. Job slots will become available again one by one as the effect of the existing commuting passengers elapses with time. The actual way of modelling the fulfilment of job slots does so using a single 64-bit integer representing the time (in internal units) when all job slots will be unfilled.
[...]

If you only add a pair of world coordinates to those slots (the place where the worker lives), you can simulate normal workforce transportation patterns, can't you?

When the slot is unfilled, you generate one passenger with origin in the coordinates, destination the industry building.  When time expires, you generate one passenger from the industry building to the coordinates (his home)...

[Ves]

Banksie_82: That is an interesting question. I had not considered that sort of limited play. You might organise a map in which the industries are well served by walking passengers, perhaps, or enable "assume_everywhere_connected_by_road" and edit the privatecar.tab (importantly before you generate the map, or else your edits will not apply to the map) to have 100% private car ownership in all eras so that workers can always get to industries by car. That latter method will probably be the easiest way of doing it, as I am not sure how easy that it would be to code a way of disabling this feature at the user (rather than pakset creator) level.

To acheave this, couldnt it (on map creation) create first the raw industries, then place cities next to them matching the job slots, and then the rest of the industries (job slots automatically matched with the number of citiescents)? Obviously as a setting so one can get lonely industries as well.

By the way, you made a very nice explanation in this thread about the passenger commuting/visiting mechanism, so even I understood it. It would be a shame if that couldnt at some point get into a helpfile inside simutrans, but for the moment, I will keep that text for future reference!

I maybe spotted some deadlocks:
I asked earlier about industries and residents, but forgot to ask about normal COM-buildings: Do you in generel intend to allow a building to contain both residents AND work slots?
If then, will the people living in the house always go to the jobslots inside the house, thus never going outside to generate transportable passengers?

Also if there exist in general many COM-buildings in a city, will it then be difficult to extract people from the city into the nearby factory (using proper player infrastructure)?

If the above statement is true (which not necesarily would be bad), how can one forbid players from deleting COM-buildings with job-slots in order to create workers for their industry?

[jamespetts]

Isidoro: that is not quite how job slots work. The idea of a "slot" is an emergent property from the simulation: the actual slots are not simulated directly. Instead, there is a number per type of building for the number of jobs that it provides, and another single 64-bit integer (as described above) giving the time at which all job slots will be unfilled if no more commuting passengers arrive. Those are all that data that are stored. Anything else would require too much computational effort on very large maps. As should be apparent, this system does not allow for any long-term linkage of particular passengers to particular workplaces.

(Also, passengers are generated by iterating through residential buildings at random, so there is not a mechanism for picking specific buildings in the way that you describe; again, anything like that would require too much memory bandwidth on very large maps).

Ves: consideration will need to be given in due course to how to handle map creation, but this needs to be done at the same time as the city growth algorithm, as they are part of the same mechanism. One thing that will need to be considered is whether the economic integration system can work properly without the new city growth system.

Allowing buildings to contain both residents and jobs is under consideration for the future (the town growth phase), but no final decision has been taken yet on whether to do this, or, if it is to be done, how it is to be handled (including whether the residents automatically fill the in-building job slots or not).

It is possible for there to be an element of competition for job slots as passengers pick their destination using a weighted random system as described, but all buildings with jobs reachable by any given commuting passenger are in competition with all such others. The idea is that the town growth system will ensure that there are not significantly more jobs than there are people to fill them, and that new residential development is usually within commuting distance of jobs so that an element of equilibrium prevails. (Again, consideration will have to be given to whether this integration should be implemented before the town growth system for this reason).

As to the disincentive to demolish commercial buildings, such buildings ought to be expensive to demolish to make it almost inevitably unprofitable to do so. Additionally, when the town growth system is implemented, there ought to be little incentive to do this in any event as there should generally be more than enough workers to fill the jobs.

[Vladki]

Yes I was thinking about noise pollution as well, I just wrote about both together. Population density could be reduced to noise pollution, to simplify the simulation. The only dynamic (and thus more complicated) aspect would be air/noise pollution from traffic.

[jamespetts]

Yes I was thinking about noise pollution as well, I just wrote about both together. Population density could be reduced to noise pollution, to simplify the simulation. The only dynamic (and thus more complicated) aspect would be air/noise pollution from traffic.

It would be very difficult to simulate noise pollution from traffic without simulating private car traffic on a per tile basis, which is not feasible within the limits of the computational power of any current computer or any likely to be produced in the foreseeable future for the sort of map sizes interesting in Experimental. One could add negative desirability from large public transport hubs (and especially airports), however.

This is rather straying into discussion of town growth rather than the economic integration system set out initially, however.

[Ves]

It would be very difficult to simulate noise pollution from traffic without simulating private car traffic on a per tile basis, which is not feasible within the limits of the computational power of any current computer or any likely to be produced in the foreseeable future for the sort of map sizes interesting in Experimental. One could add negative desirability from large public transport hubs (and especially airports), however.

Would it not be possible if a way count no of vehicles (it already counts number of player vehicles I think) and then have that as a "traffic pollution". People don't want to live next to too much traffic, being it vehicles with standard diesel/benzin engines or electric engines. Or maybe this is what you meant with "private traffic per tile basis"?

This is rather straying into discussion of town growth rather than the economic integration system set out initially, however.

I think that what you proposed in the initial post sounded very good and that people mostly think so too.

But to touch back to the initial topic:
Player buildings which contains work slots (eg signal boxes), will there be some form of penalty if the slots are not filled, eg signals get operated slower?
What about job slots in station houses (if they are possible which I think they should)?
Also the headquarters should in my opinion have work slots.

One could even reach out to say that all vehicles have work slots, but this might very well be too overkill. However the work slots could add to the headquarters (a steam loco with two employe will add two work slots to the headquarters).

[jamespetts]

Would it not be possible if a way count no of vehicles (it already counts number of player vehicles I think) and then have that as a "traffic pollution". People don't want to live next to too much traffic, being it vehicles with standard diesel/benzin engines or electric engines. Or maybe this is what you meant with "private traffic per tile basis"?

Yes, I am afraid that it is: counting non-player vehicles per tile in a meaningful way would require a whole new pathfinding system which would not be workable except on very small maps.

Player buildings which contains work slots (eg signal boxes), will there be some form of penalty if the slots are not filled, eg signals get operated slower?

I have not finally decided, but I am leaning against this as this has the potential to create deadlocks (how would passengers get to work if the systems are not operating?). Actually implementing the penalty is likely to be very awkward, too.

What about job slots in station houses (if they are possible which I think they should)?
Also the headquarters should in my opinion have work slots.

One could even reach out to say that all vehicles have work slots, but this might very well be too overkill. However the work slots could add to the headquarters (a steam loco with two employe will add two work slots to the headquarters).

Stations, depots, etc. already have job slots, but passengers cannot travel to a vehicle as a destination, so it would not make much sense for vehicles to have job slots; it would make more sense for depots to have such slots.

[Vladki]

But to touch back to the initial topic:
Player buildings which contains work slots (eg signal boxes), will there be some form of penalty if the slots are not filled, eg signals get operated slower?

I know I will get more even off-topic, but I was thinking about speed of signal operation as a way to further distinguish absolute block and circuit block methods. But I did not think it thoroughly yet.

One could even reach out to say that all vehicles have work slots, but this might very well be too overkill. However the work slots could add to the headquarters (a steam loco with two employe will add two work slots to the headquarters).

And one more per guard (brake) van, and one or two per passenger train, a few per restaurant car... Ooooh there's a lot of options.
Those jobs could be added either to headquarters or to the depot, where the vehicle was built. (And transferred to nearby depot or headquarters if depot is deleted.)

[Ves]

Yes, I am afraid that it is: counting non-player vehicles per tile in a meaningful way would require a whole new pathfinding system which would not be workable except on very small maps.

Ok, would it then not be feasible to only use player vehicles to create traffic pollution? After all, there are probably mainly player vehicles on a map anyway and dozens of trucks every day IS more inconvenient than dozens of normal cars after all.

I have not finally decided, but I am leaning against this as this has the potential to create deadlocks (how would passengers get to work if the systems are not operating?). Actually implementing the penalty is likely to be very awkward, too.

Now that's a real challenge (if signals stop working if there are no workers)!
The time penalty should reflect that fewer staff members have to keep control of the same area (and this takes more time). Obviously if no workers are in the box, the signals should still work but with the maximum time penalty. But you are right that it in this case things may get awkward if say stations or other player buildings have no penalty.

Stations, depots, etc. already have job slots, but passengers cannot travel to a vehicle as a destination, so it would not make much sense for vehicles to have job slots; it would make more sense for depots to have such slots.

How can I access the work slot information? I have tried click multiple times on different buildings with no luck of finding wether there are any work slots (and if they are filled).
Regarding vehicles, I meant that the more vehicles you operate, the more work slots would eg the head quarter or maybe the origin depot have. So more vehicles = more work slots for those buildings.
This could be expanded further to say that eg for every km track = one work slot in head quarter
For every station = additional work slots in head quarter (in addition to the work slots in the station itself)
And I could go on

Possible penalties for player buildings:
Signal box: signals operate slower
Station house: slower transfer times
Depot: ??
Head quarter: minor money penalty?

[Vladki]

Back to the topic: someone mentioned combined res/com buildings. One could "fake" them in case of old shops, where the shopkeeper lives in the same house and only his family is working in the shop. That could be simulated as consumer factory with no job slots available and considered to be fully staffed all the time.

[jamespetts]

I know I will get more even off-topic, but I was thinking about speed of signal operation as a way to further distinguish absolute block and circuit block methods. But I did not think it thoroughly yet.

The trouble is that implementing a delay for the operation of signals would be really rather tricky, and is much lower in priority than a great many other things.

And one more per guard (brake) van, and one or two per passenger train, a few per restaurant car... Ooooh there's a lot of options.
Those jobs could be added either to headquarters or to the depot, where the vehicle was built. (And transferred to nearby depot or headquarters if depot is deleted.)

This is actually a rather interesting idea, especially as I am soon going to work on convoy based balancing mechanics, which include allocating a per vehicle staff cost and adjusting that by wage inflation. Vehicles already have a home depot, so this might not be too much extra work. I shall consider this.

Ok, would it then not be feasible to only use player vehicles to create traffic pollution? After all, there are probably mainly player vehicles on a map anyway and dozens of trucks every day IS more inconvenient than dozens of normal cars after all.

This would not work, as public transport is a very incomplete model of traffic based pollution: this model would be a worse simulation than just taking the total traffic in the whole city and distributing it evenly among all tiles. In modern times, the great majority of all road traffic comprises private cars.

How can I access the work slot information? I have tried click multiple times on different buildings with no luck of finding wether there are any work slots (and if they are filled).

This is a good point, as this is currently not possible for depots and stops. I will have to look into making this more readily available.

Regarding vehicles, I meant that the more vehicles you operate, the more work slots would eg the head quarter or maybe the origin depot have. So more vehicles = more work slots for those buildings.
This could be expanded further to say that eg for every km track = one work slot in head quarter
For every station = additional work slots in head quarter (in addition to the work slots in the station itself)
And I could go on

This is similar to what Vladki suggested above, although the job slots in the headquarters should relate to the size of the headquarters (which can be upgraded). I have yet to settle upon a satisfactory function for a headquarters.

Possible penalties for player buildings:
Signal box: signals operate slower
Station house: slower transfer times
Depot: ??
Head quarter: minor money penalty?

Aside from the last, these are all likely to be very tricky to implement in terms of game mechanics, and are likely also to upset balance, make the game more fiddly to play than it needs to be and be difficult for a player to understand.

No you're not... You're simulating 6 hours instead of a month. This is 120x less traffic. This will cause the improbable events to happens 120x more often then it should and even worst near impossible situation to happen quite frequently. Like having no employee hitting a specific shop for months in row despite the fact that the network is covered at 90% efficiency.

I don't think that you really understand the relationship between the two time scales in Simutrans-Experimental if you think that this is the case. You also do not appear to have corrected your previous misunderstanding about job slots being filled during a month on which misunderstanding this assertion still seems to be based.

It would still be viable, if you were simulating 1 shop somewhere. You could live with odd events... But you guys are simulating hundreds of town and impossible events will happen all the time in your simulation.

I feel just like Malcom in Jurassic park trying to explain chaos theory, statistical certainty and butterfly effects to people who don't understand such things. lol.

I am afraid that it is rather more that you are not understanding how the system that I describe works, that you are proceeding on the basis of a misunderstanding about it, that you are not explaining how you arrive at conclusions, that your explanations are excessively vague despite requests for clarification, and that you are greatly overestimating the actual adverse consequences of job slots being unfilled for a period of time (and, rather oddly, when I point out that shops will not go bankrupt by job slots being unfilled for a month, you proceed instead to suggest that I implement a mechanism whereby they do go bankrupt rather than accept that as reason that your original suggestion that the system that I describe is infeasible is not correct).

You'd have an viable approximation count of the amount of traffic on road with the system I suggest. And we already made the maths, I need 1 second calculation on a 1ghz computer to simulate the traffics in a 100km radius of every building in 1 month. The key here is that i'm running the SAME A* algorithm for ALL the passengers.

I really don't think that you have thought this through. Your system would simulate only local traffic. Most traffic on roads with heavy traffic is through traffic. Most roads with only local traffic have only light traffic that would not create significant amounts of pollution. What you suggest would not distinguish between walking passengers and those taking a car.

You are in no position to continue to insist that your suggestion be adopted when you have been unable to explain how it would actually work in conjunction with what is already in the game or meet the basic objection that it is at odds with the fundamental purpose of Simutrans.

Back to the topic: someone mentioned combined res/com buildings. One could "fake" them in case of old shops, where the shopkeeper lives in the same house and only his family is working in the shop. That could be simulated as consumer factory with no job slots available and considered to be fully staffed all the time.

This would not work as the people who work in the shop should still count towards the population total and still make visiting trips.

[Ves]

Sorry Im drifting off topic a short moment.

Iluvalar, I think maybe you have to realize that James is not implementing your proposal for passenger generation/city generation. As you probably very well are aware of, this (the entire Simutrans-franchise except some specific paksets) are all open source and 100% based on volunteers. That means: use it as it is, or make something different out of it. That is exactly what James have done and the result of today is Simutrans Experiemental.
If you have a feature that you would very much like to see in Simutrans (Experiemental), your first option is to ask the developers if they are willing to work on your idea. If that is not the case (due to lack of time, interrest, game policy or something else), you still have the option to fork the game and try to code it yourself and possibly persuade the developers to implement your work. I admit that this might be a gargonic task or even impossible if one lack programming skills (as I do), however I see no other way.

That being said, one are still allowed to comment and make suggestions, as James (and also the standard developers) luckily are very openminded about their work! But in order to keep the good tone and mood existing in this forum, one are never to forget the upper section in this post.

Im sorry if Im sounding rude, english is not my first language


---
edit: oh, someone posted while I was typing

* About unoccupied jobslots in playerbuildings *

Ok, so then its probably best if there are no penalties at all for missing job slots in any playerbuilding

This is a good point, as this is currently not possible for depots and stops. I will have to look into making this more readily available.

Currently you can click multiple times on a tile, and each time, the more "underlaying" object window appears. Maybe that could be used? If I click once on a depot, the normal depot window opens, if I click again (while the depot window is open) I get the building window (with succesrates, jobslots and all that stuff). The same for station tiles, question is only wether the entire station should count as one building or multiple buildings.

And one more per guard (brake) van, and one or two per passenger train, a few per restaurant car... Ooooh there's a lot of options.
Those jobs could be added either to headquarters or to the depot, where the vehicle was built. (And transferred to nearby depot or headquarters if depot is deleted.)

This could actually be really fun!

This is similar to what Vladki suggested above, although the job slots in the headquarters should relate to the size of the headquarters (which can be upgraded). I have yet to settle upon a satisfactory function for a headquarters.

An alternative way of upgrading the head quarter could be that it upgrades when it reaches a specific number of jobs?

[jamespetts]

An alternative way of upgrading the head quarter could be that it upgrades when it reaches a specific number of jobs?

The trouble with this is that this gives players no incentive to build the headquarters in the first place. It is also potentially problematic to balance, as it is difficult to work out what a realistic apportionment of funds to central administration is of having a network of any given size. This is not necessarily impossible, but would need very careful thought and I cannot see a good way of making it work at present.

[Isaac Eiland-Hall]

I have split off posts and locked the split topic. This thread was warned against continuing, and continued anyway. Please do not make me take further action. -Isaac Eiland-Hall

[Iluvalar]

Allright, I got censored.

I gonna post calmly what belong strictly to this post.

I don't know exactly, I'm not crazy enough to reverse engineer your code myself to figure out how many trips per population you manage to simulate in the 6.2 hours long month. But, considering that the scale of the road, the vehicles and the houses are matching and that your aim is to simulate the traffic realistically, I don't think I'm misunderstanding anything when I  expect every citizen to not take their car (or bus) more then once (and back home) during that 6 hours. Tell me the real numbers if i'm wrong here.

This can only lead to one thing : The amount of trips in your simulation will be much lower then in reality. To explain it quickly with math, If you have 120 trips with a success rate of 70% there is a  1x10E-61% chance that none of those trips will reach the destination. If I'm not mistaken, it's at the scale all atoms in the solar system once per thousand year (to give you an sens of scale). However, if you only simulate 8 trips the odds become .006%. This still look small but if you consider 20 buildings in 100 towns, it WILL turns out to happen to 13 buildings each month.

In other words, extreme events that would never happens in a larger simulation will occur every months in yours. If you reuse these data for changing the simulation, it will create a butterfly effect and snowball effect. Most of these events might cancel each others. But some will multiply and cause even more unlikely events.

Your free to not believe me and code those changes and see for yourself I'm not mad, I'm just trying to save everyone a bit of spaghetti codes. The little evil part inside me will actually extremely enjoy the "I told you" that is coming from this.

About the moderation :
I've seen in James comments some curiosity. This is why I keep trying to explain here. Obviously we are meeting a little difficulty understanding each other. I'm sorry if I looked aggressive. The IS a little bit of frustration on both side, but for me, at least, it's manageable.

James, if at any point I go too far or become annoying, feel free to directly tell me here or in private message, I won't bite. If there is any misunderstanding, it's likely a cultural one.

Also, I've been using words like "chaos", "failures" and "catastrophic events". I've been using them in their mathematical meaning, because that's what I'm talking about. It doesn't aim anyone in any way or form. If they looked aggressive, they are not.

Again, I'm sorry.

[jamespetts]

I don't think that continuing this in any detail is likely to be productive; however, one brief point should be made, which is this: there are two separate time scales for a reason, and both work consistently internally. The short scale (in which things are measured in hours and minutes) deals with passenger/freight trips (including all revenue, timing, statistics and reporting, passenger and freight generation and consumption), whereas the long scale (in which things are measured in months and years) deals with the progress of technology, interest rates and capital expenditure. The pakset is not balanced yet, but, when it is, capital and revenue will be balanced against each other taking account of the different time-scales to produce a realistic ratio of capital to revenue over the longer scale. However, as far as passenger and freight generation and consumption are concerned, there are no months: only hours. The quantity of passenger and freight generation and consumption (and therefore passenger and freight traffic) is calibrated to be a realistic amount per hour. It thus does not make sense in the context of Simutrans-Experimental to ask whether there are a realistic number of passengers being generated per month if one is referring to game months.

[isidoro]

[...]
I don't know exactly, I'm not crazy enough to reverse engineer your code myself to figure out how many trips per population you manage to simulate in the 6.2 hours long month.
[...]

Please do.  The source code of the project is open.  You can check yourself the information you need.  ST is the work of many people, not a single one of them know all the details, even some of them.  Don't think there's a conspiracy to hide information or the like...

Knowing James for some time here, I truly believe that he's doing his best to understand you and provide you with the information you need.  For sure.

[Ves]

I know this is the wrong thread, but a short comment:

can anyone still reproduce the problem with roads getting cut off in towns when they expand, for example?

Yes, I just experienced this when a city was growed. It happened twice just recently.
Could open a new thread if this should be a bug report?

[Junna]

I know this is the wrong thread, but a short comment:Yes, I just experienced this when a city was growed. It happened twice just recently.
Could open a new thread if this should be a bug report?

Well, I think it's known... Phillip was doing a revision of the road code, but he disappeared for whatever reason, and hasn't posted since last year. So it ended up partially unfinished. He was planning some neat things that would allow ways to avoid roads being appropriated by cities as well without having to build powerlines/fences along the sides of the road.

The goods transport system is quite cumbrous and much less fluid than that in, for example, OTTD. It would be much neater if it worked without player involvement in some degree, i.e. that transports unfulfilled would travel on their own, similar to how the goods work in Railroad Tycoon 3. AEO wrote about this in the past, but it's worth being rehashed; the goods in RT3, travel independently if there is no adequate transportation provided. This is slow and limited and limit industrial output when not served, but also eases the bother of providing it; goods can travel to stations on their own, and the map need not be filled with countless branches serving very small industrial enterprises with minimal production; instead, they would travel to a general merchandise station and, like passengers, hitch a ride to a station near their destination and proceed. This would also allow for much more mixed-use rolling stock rather than, even in early years, forcing almost exclusive use of block trains.

[jamespetts]

Junna: that is an interesting idea: something similar to private cars, but for freight? Private lorries, perhaps...?

[Ves]

Although interesting idea, will that not conflict with the concept of different players? Although some companies own their own rolling stock, which actually often includes rail and rail vehicles, many companies don't and "who" are they hiring to transport things if not one of the players (which represent all the state and private transport companies in the entire world)?

[Junna]

Junna: that is an interesting idea: something similar to private cars, but for freight? Private lorries, perhaps...?

Indeed. Private lorries and/or independent shipping via navigable canals, etc (the transport system in RT3 was oriented around water bodies as natural 'highways' in the absence of game railways, for example).

Although interesting idea, will that not conflict with the concept of different players? Although some companies own their own rolling stock, which actually often includes rail and rail vehicles, many companies don't and "who" are they hiring to transport things if not one of the players (which represent all the state and private transport companies in the entire world)?

But it would be largely similar to how passengers work at the moment. More convenient connections, etc. It would also make much easier connections between players for the conveyance of goods -- as currently, this is very troublesome without very close coördination and exchange between players and intentional effort to make an interconnected network.

Naturally, there would be benefits to better connections (increased production, improved demands, etc) so it would not be entirely independent, but it would guarantee a sort of base level of economic activity even in the absence of player-operated goods activity. The amount of transport this system should be able to support should be limited (i.e., the capacity would be throttled in the absence of player input). But goods ought also be willing to travel some distance to a nearby station (i.e. coal could, if there is a road (perhaps, depending on how it would be implemented in terms of what is easiest and least cumbrous in terms of processing requirement), travel to a nearby station where goods platforms are present and take trips from there, rather than requiring a private siding. I think that it would be good to, for high-production and high-requirement industry to give some production bonus if the distance to the station is very short (and/or is a exclusive private siding for the industry), but for many small industries this is seldom very feasible without being extremely complex and prohibitively intricate. This system would for example allow the concentration of goods deliveries to cities to general merchandise stations, etc; rather than having individual stops for every industry there-- though I do think that, again, some positive results should be granted to the player when they so chose to serve (perhaps, the money paid for a partial trip would be less than, if say, the player provided lorries for the distribution within the city, i.e. the final- and initial trips when not provided by the player directly would be discounted from the revenue, as if they were handled by an independent horse carriage/road haulage/river contractor in an unspecified manner.)

[jamespetts]

This could get quite complicated and rather tricky (and more so than passengers with private cars). How would it be determined whether any given industry had access to private goods vehicles, their capacity, their speed and how many of them that there are? This is relatively straightforward with private cars: passengers are generated individually and are randomised as to whether they have access to private cars based on the proportion of people with access to them at that time (based, in turn, on government statistics). This would not really work in the same way for industry: one could not say that a particular industry sometimes did and sometimes did not have access to private lorries.

Further, if one were to involve waterways, that would require a whole new path finding mechanism for waterways with consequent impact upon computational load; one would then have to decide whether trips over sea would be able to be made, or whether privately owned boats (did these even exist?) would be restricted to inland waterways.

There is also the problem of why any industry with access to private lorries would ever use player transport unless there were no road connexion; the mechanism for determining which route to use is based on speed; there is no historical reason why privately owned lorries should be any slower than the player owned equivalent; given the transfer and waiting time inherent in player transport by road (the equivalent of which does not exist for passenger transport by car), the only way in which player transport would be likely to succeed is if, for example, it involved a railway journey faster than an available road route. One might then wonder why private owner lorries could not take the goods to a railway station, which would involve another level of simulation (and attendant large amount of coding work), although something like this is planned - eventually - for private cars.

As to delivering goods to general merchandise stations in cities, this can in principle be done already, so long as players then organise light goods vehicles to take them from there to their ultimate destinations.

[Iluvalar]

It's rather quite simple in my eyes. No serious company would build such factory without verifying for a transport solution. So if they open and there is no players willing to do the transport they must have a private solution. But maybe that's just me ?

[HarrierST]

It's rather quite simple in my eyes. No serious company would build such factory without verifying for a transport solution.

I think your problem is, you can not separate reality - from game play.   

No matter how much a developer tries  to make it realistic - there are compromises.

Yes -  to quote you "no serious company would build such factory without verifying for a transport solution."

But this is a game - and to live with the constraints of various computers (still in use)  - concessions have to be made. So that the game can be played by all,  at all stages and  at a reasonable speed etc.

So sometimes to much realism has to take a backseat.  JMO.

[Isaac Eiland-Hall]

It's rather quite simple in my eyes. No serious company would build such factory without verifying for a transport solution. So if they open and there is no players willing to do the transport they must have a private solution. But maybe that's just me ?

To add on to HarrierST's reply: Anything that doesn't happen in Simutrans is assumed to have happened outside of the scope of the player(s) and/or public service. After all, no citizens purchase groceries. No vehicles have to stop for fuel or breakdowns. No accidents ever happen. No laws or politics.

It's a game that tries to have some sort of basis in reality, but the simple reality is that no game will ever be a true simulation, and while Simutrans strives for some realistic elements, ultimately there are some basic constraints that limit the closeness to reality (scale is one major problem: the size of buildings/vehicles vs. the 1km/tile most paks use to simulate distance for financial purposes)

[Iluvalar]

To add on to HarrierST's reply: Anything that doesn't happen in Simutrans is assumed to have happened outside of the scope of the player(s) and/or public service. After all, no citizens purchase groceries. No vehicles have to stop for fuel or breakdowns. No accidents ever happen. No laws or politics.

It's a game that tries to have some sort of basis in reality, but the simple reality is that no game will ever be a true simulation, and while Simutrans strives for some realistic elements, ultimately there are some basic constraints that limit the closeness to reality (scale is one major problem: the size of buildings/vehicles vs. the 1km/tile most paks use to simulate distance for financial purposes)

This post make me smile . First because I suggested a way to calculate all the traffic for citizens doing their groceries in the posts you censored. Maybe it struck your imagination ?

And mostly, because I had that huge chat two months ago with jamespetts about how he would have to compromise between reality and gameplay at some point. I'm the one told that we can reach full realism while jamespetts is talking about using government statistics ^^.

[Isaac Eiland-Hall]

The moderation had nothing to do with any Simutrans topic. If you'd like to discuss in further detail, please open a topic http://forum.simutrans.com/index.php?board=88.0 or PM me and I'll gladly discuss what happened. It sounds like I didn't explain it well enough.

[Ves]

Another "economic" topic:
Selling the buildings.
Currently, if you have built a station or similar, only way to get rid of it is to tear it down. That means that the invested money in the building gets wasted. What if it where to be possible to sell the building instead and get some of the invested money back to your account? Alternative also "abandon" of the estate (like the mothballed way)

Thoughts on top of my head:
When insolvent, instead of using money to get rid of infrastructure, you can actually earn money from the estate sale including money from the land value.
There are many examples of real life station houses and similar that are today privately owned buildings.
When old buildings get obsolete, you can sell them instead of tearing it down.

What will the sold infrastructure become? Residence? Com? Should each sellable building have a twin citybuilding?
A decision should be made as to what can be sold like a small bus stop should not be possible, but the "staggered in" in pak Britain could be suitable. Platforms are also not suitable but the station house and possibly also some storage buildings probably are etc.
What if you want to buy it back?

This also could lead to the question of selling infrastructure to other players but I don't remember if this had been discussed?

[Junna]

well, buying and selling of company assets was on the list as I remember (including taking over companies and merging them should players wish), but this seems to have been given an unwarranted low priority.

[Ves]

Oh, you are right, I forgot that! However the possibility to sell buildings to private (ie becoming city buildings) was my initial thought which I don't remember was part of that plan.

[jamespetts]

Thank you for all your feedback. There are a number of separate ideas here, which I will address in turn. Many of these issues are more complex than they appear at first.

It's rather quite simple in my eyes. No serious company would build such factory without verifying for a transport solution. So if they open and there is no players willing to do the transport they must have a private solution. But maybe that's just me?

Having every industry have access to private lorries would certainly make one step of the process easier, but it produces its own problems. Firstly, the rationale of the original suggestion is not fulfilled if the industry in question does not in fact have road (or, if applicable, depending on the implementation, water) access to its destination industries. There has been some suggestion of a mechanism to ensure that all out of town industries be built along roads, but this would probably take a considerable amount of time and effort to implement (and therefore not be able to be done for a very long time, as in probably quite a number of years), and in any event, this would not ensure that the road, river or canal network in question would in fact be connected to the destination. Secondly, on the realistic assumption that industries that have access to road transport have access to the same vehicles as players, there would be no way in which industries would ever choose player road transport above their own. This is realistic for industries that do in fact have their own fleet of road vehicles, but would render redundant road goods transport in the game except as a single leg of a multi-leg journey (e.g. to a dock or railway station), and would eliminate even this if a mechanism were introduced to allow partial journeys by private road goods transport as is already planned in connexion with the prospective car park feature for private road passenger transport. Because private road goods transport independent from industries (e.g. Eddie Stobart) does exist in reality and is significant, this would thus not be a realistic solution.

The idea that every industry should ensure that it has a means to transport its goods (and receive its raw materials) before being built is realistic enough, but extraordinarily difficult to implement in practice, as there is no way for the game to be able to negotiate with a player, or infer a player's future intent, at least without mechanisms that are way beyond the scope of what can be done given current coding resources (i.e. me on my own with sporadic assistance from others occasionally). The next best solution is for industries to exist but be effectively dormant unless and until they are connected by some sort of transport to their end-point, as more or less happens now and as will be even more so apropos passenger transport if and when the features discussed in the opening post are implemented. This is economically more or less equivalent to industries not existing without first knowing that they can be connected to other industries in the chain.

Another "economic" topic:
Selling the buildings.
Currently, if you have built a station or similar, only way to get rid of it is to tear it down. That means that the invested money in the building gets wasted. What if it where to be possible to sell the building instead and get some of the invested money back to your account? Alternative also "abandon" of the estate (like the mothballed way)

Thoughts on top of my head:
When insolvent, instead of using money to get rid of infrastructure, you can actually earn money from the estate sale including money from the land value.
There are many examples of real life station houses and similar that are today privately owned buildings.
When old buildings get obsolete, you can sell them instead of tearing it down.

What will the sold infrastructure become? Residence? Com? Should each sellable building have a twin citybuilding?
A decision should be made as to what can be sold like a small bus stop should not be possible, but the "staggered in" in pak Britain could be suitable. Platforms are also not suitable but the station house and possibly also some storage buildings probably are etc.
What if you want to buy it back?

This also could lead to the question of selling infrastructure to other players but I don't remember if this had been discussed?

I am planning on simulating land value as part of the town growth feature, as this will be important. It will be very difficult to code for allowing station buildings etc. to change use rather than be demolished and have the land re-used, but what would work quite well (and already does work, in fact, but with only an extremely crude way of determining the land value, which I hope to change) is allowing players to demolish their station buildings and realise the value of the underlying land. With a sophisticated mechanism for determining land value, this should allow players to invest in land.

I am also considering a feature allowing players to build commercial and residential buildings in towns and to earn a market rent from commercial and residential buildings that are owned (buying town buildings is possible already, even in Standard), which will fluctuate with their level of occupation (which I am also planning to simulate in the town growth feature), and incur maintenance charges so that there might be a loss made on such buildings if they are unoccupied or under-occupied. This would allow for the simulation of the practices of, e.g., the Metropolitan Railway, which built railway lines to empty spaces near London and built houses near their own stations, selling them for a profit in view of the increased value of the land that their own railway line had generated, and generating themselves a source of traffic by doing so at the same time.

well, buying and selling of company assets was on the list as I remember (including taking over companies and merging them should players wish), but this seems to have been given an unwarranted low priority.

Buying and selling individual company assets is likely to be difficult to implement for things like ways and stops. I do plan to add the buying and selling of secondhand vehicles as part of the next major release, however.

Merging of companies has not been given a low priority, as such: it is a potentially important feature. However, there are even higher priority things that are essential to basic balance in a way that this is not, such as the proper treatment of vehicles and convoys (including simulating wear, maintenance, overhauls, the secondhand market in vehicles, automatic convoy recombination in operation and related matters) which will be the next major feature after signalling to be worked on. This is likely to be a very major set of features indeed, and require a very large amount of intensive work, but, for reasons discussed at length elsewhere, it is essential for balance.

[Ves]

I am planning on simulating land value as part of the town growth feature, as this will be important. It will be very difficult to code for allowing station buildings etc. to change use rather than be demolished and have the land re-used, but what would work quite well (and already does work, in fact, but with only an extremely crude way of determining the land value, which I hope to change) is allowing players to demolish their station buildings and realise the value of the underlying land. With a sophisticated mechanism for determining land value, this should allow players to invest in land.

Ok but will there be any possibility to cash back some of the investment you made in the building itself, not just the land value as I can read from your text? Would it not be possible to have a tool that demolites the building and in the same turn build its "twin"?

I am also considering a feature allowing players to build commercial and residential buildings in towns and to earn a market rent from commercial and residential buildings that are owned (buying town buildings is possible already, even in Standard), which will fluctuate with their level of occupation (which I am also planning to simulate in the town growth feature), and incur maintenance charges so that there might be a loss made on such buildings if they are unoccupied or under-occupied. This would allow for the simulation of the practices of, e.g., the Metropolitan Railway, which built railway lines to empty spaces near London and built houses near their own stations, selling them for a profit in view of the increased value of the land that their own railway line had generated, and generating themselves a source of traffic by doing so at the same time.

Wow this is very interresting! I was always imagine how cool it could be to just build a station on the country and suddenly a town pops up! What you are saying is that I can build a station and some of those houses, and then it will grow by it self (if "fed" properly by services)? Would this not partially solve the problem rized in this thread where someone only wanted to transport good and not passengers? If I want a coalmine somewhere far away to work, I just build a bunch of those houses and the mine will work!

[jamespetts]

Ok but will there be any possibility to cash back some of the investment you made in the building itself, not just the land value as I can read from your text? Would it not be possible to have a tool that demolites the building and in the same turn build its "twin"?

I am not quite sure how this would work or what it would simulate. Can you elaborate?

Wow this is very interresting! I was always imagine how cool it could be to just build a station on the country and suddenly a town pops up! What you are saying is that I can build a station and some of those houses, and then it will grow by it self (if "fed" properly by services)? Would this not partially solve the problem rized in this thread where someone only wanted to transport good and not passengers? If I want a coalmine somewhere far away to work, I just build a bunch of those houses and the mine will work!

This is an interesting idea indeed. Certainly, what you described is one of the intended functions of the town growth system.

[Ves]

I am not quite sure how this would work or what it would simulate. Can you elaborate?

If I invest lots of money building a house, then when I dont need it anymore, I would try to sell it. That way, my investment in the building wont get lost as well as the building will continue to exist under another ownership. Currently in Simutrans, If I have a building I dont need, I have to tear it down, loosing all the money I invested building it. If I understand you correctly, I will in the next version only get the money back from the land it stood on which I bought, not the building it self.

edit:
With the tool I meant that the house would "upgrade" like the current upgrade function for vehicles do upgrade. Each sellable house would require a doubblet to which it can upgrade. When clicking with the tool on the house I want to sell, the tool demolishes the house, finds which house is its "upgrade" (which would require a dat-parameter in the sellable house like "sell_to=" and then the second building which is the sold house = a total of two buildings) and build the upgrade with the same rotation and location as the old. The pakset manager could then design the sold house with work slots or residences or even other graphics (eg commersials or laundry on the lawn) however its important to keep the size the same and the graphics relative similar in order to not create confusion or bad glitches.

[jamespetts]

Are you referring to players buying and selling city buildings, or are you referring to transport buildings such as station extension buildings, depots, signalboxes and so forth?

[Ves]

Im refering to all player buildings. Like station extensions, stops, depots, signalboxes, Head quarters.
It could in principle work the other way around too: Buy a city building and you could choose it to become the Head quarter, or an old station house (which once in the past has been sold by a player) would be opened up to become a station house again.

Difficulties is however if "stops" and "depots" (which are built on ways) should be allowed to be sold. Maybe then the way underneath could also be sold to the new private owner?

[jamespetts]

The difficulty really is in repurposing buildings (currently, the function of a building is determined by its type, so this would involve a very major rewrite) and changing owners of buildings integrated with a way or stop. What would happen if a player sold a single station building part of a larger station? That would not make any sense.

[Iluvalar]

You also write about taxes on buildings and profit goals; neither of these things exist as features or are planned as part of the city growth or economic integration system. It is very unclear, therefore, how you see this relating to everything else in the game.

I am also considering a feature allowing players to build commercial and residential buildings in towns and to earn a market rent from commercial and residential buildings that are owned (buying town buildings is possible already, even in Standard), which will fluctuate with their level of occupation (which I am also planning to simulate in the town growth feature), and incur maintenance charges so that there might be a loss made on such buildings if they are unoccupied or under-occupied. This would allow for the simulation of the practices of, e.g., the Metropolitan Railway, which built railway lines to empty spaces near London and built houses near their own stations, selling them for a profit in view of the increased value of the land that their own railway line had generated, and generating themselves a source of traffic by doing so at the same time.

allright allright... good idea boss.

[Junna]

If I invest lots of money building a house, then when I dont need it anymore, I would try to sell it. That way, my investment in the building wont get lost as well as the building will continue to exist under another ownership. Currently in Simutrans, If I have a building I dont need, I have to tear it down, loosing all the money I invested building it. If I understand you correctly, I will in the next version only get the money back from the land it stood on which I bought, not the building it self.

edit:
With the tool I meant that the house would "upgrade" like the current upgrade function for vehicles do upgrade. Each sellable house would require a doubblet to which it can upgrade. When clicking with the tool on the house I want to sell, the tool demolishes the house, finds which house is its "upgrade" (which would require a dat-parameter in the sellable house like "sell_to=" and then the second building which is the sold house = a total of two buildings) and build the upgrade with the same rotation and location as the old. The pakset manager could then design the sold house with work slots or residences or even other graphics (eg commersials or laundry on the lawn) however its important to keep the size the same and the graphics relative similar in order to not create confusion or bad glitches.

Have you ever played A Ressha de Ikou ('A-Train') 8 or 9? It is relevant to these ideas (the game as a terribly simplistic passenger system, regrettably, on the other hand...)

[Ves]

If you meant for me, then I never tried these.