News:

Simutrans Chat Room
Where cool people of Simutrans can meet up.

Potential feature discusion: economic integration

Started by jamespetts, January 03, 2016, 12:39:17 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

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.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

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.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

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.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

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.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

HarrierST

#7
Quote from: jamespetts on January 03, 2016, 12:39:17 PM
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%.  8)

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.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

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).
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

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.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

zook2

QuoteScamps: 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.
---
QuoteThe 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.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

isidoro

Quote from: jamespetts on January 06, 2016, 07:06:29 PM
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

QuoteBanksie_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.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

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

Quote from: Vladki on January 09, 2016, 01:30:44 PM
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.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Ves


Quote from: jamespetts on January 09, 2016, 02:53:00 PM
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"?

Quote
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

Quote from: Ves on January 09, 2016, 04:13:53 PM
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.

Quote
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.

QuoteWhat 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.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Vladki

Quote from: Ves on January 09, 2016, 04:13:53 PM
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.

Quote
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

Quote from: jamespetts on January 09, 2016, 04:52:14 PM
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.

Quote
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.

Quote
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

Quote from: Vladki
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.

QuoteAnd 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.

Quote from: Ves on January 09, 2016, 05:45:49 PM
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.

QuoteHow 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.

QuoteRegarding 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.

Quote
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.

Quote from: IluvalarNo 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.

QuoteIt 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).

QuoteYou'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.

Quote from: VladkiBack 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.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Ves

#26
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
Quote from: jamespetts on January 09, 2016, 07:54:05 PM
* 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

Quote from: jamespetts on January 09, 2016, 07:54:05 PM
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.

Quote from: VladkiAnd 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!

Quote from: jamesThis 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

Quote from: Ves on January 09, 2016, 07:58:47 PM
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.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

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. :P

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.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

isidoro

Quote from: Iluvalar on January 10, 2016, 07:58:38 PM
[...]
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:
Quotecan 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

Quote from: Ves on January 11, 2016, 08:21:11 PM
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...?
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.