Development update

Topic: Development update (Read 8743 times) previous topic - next topic

Development update

September 26, 2009, 01:20:18 pm

Since there was no new release of Simutrans-Experimental last week, I thought that it might be useful to explain the latest work that has been done with the Simutrans-Experimental code, and why there has been a delay from the normal release schedule.

I am currently preparing Simutrans-Experimental version 7.0, which contains a number of significant changes from 6.8 (and have also been busy with work and personal matters, including preparing to move into a new flat, and I have a holiday next week).

Industries

The most significant new addition to 7.0 will be an overhaul to the way in which industries are built and closed down during the game. In existing versions of Simutrans-Experimental, industries that have p****ed their retirement date will close down over time. However, in testing, it was found: (1) that the industries closed down too quickly after their retirement dates; and, more significantly, (2) new industries did not grow up to replace them.

In Simutrans-Standard and existing versions of Simutrans-Experimental, new industries were built whenever there had been a certain growth in the global population (commonly 5,000). This formula does not work well, however, when industries close down, as it does not take account of the loss of existing industries, with the result that the overall number of industries is greatly reduced over time, which upsets the game balance.

In 7.0, there will be a totally new system of determining when new industry chains are built. The game will detect the overall industry density (industries in proportion to the population) when the game starts, and then seek to maintain that same density throughout the game. It is not just the number of industries that are measured, however: it is their weighting, and this is particularly important for pakset authors. Below is some more detailed techincal information on how the new system works that is important to those involved in creating paksets that might be of more limited interest to others.

There will also be a small change to the way in which messages for when industries are closing down are handled to make them more consistent with other messages about industries (i.e., controlled by the "industries" option in the message dialogue window), as well as a new formula for deciding when to close industries, so that they do not close down too quickly after their retirement dates.

Technical information for pakset authors

The new system for maintaining industry density in the forthcoming 7.0 will use the concept of industry density ratings. This will be achieved by adding up one divided by each industry's distributionweight setting and dividing it by the total population. (Note: the variable "chance" is not used for industries and should not appear in any industry .dat files). The game will then attempt to maintain that value throughout the game. As the population increases, so does the target industry density. If the actual industry density falls below the target industry density at the beginning of any month, then there will be a chance of a new industry being created, which chance will be higher the greater the disparity between the two.

For this reason, it is very important to use the distributionweight setting carefully. Industries with a higher distributionweight are not only more likely to be generated whenever a new industry is called for, but, because they increase the actual industry density less than industries with a higher distributionweight, more of them can be accommodated at any given level of population than industries with a higher distributionweight.

This means that it is possible to use varying distributionweight settings of different versions of the same types of industry over different eras to simulate: (1) the consolidation of large numbers of small industries into small numbers of large industries (or the converse); (2) industrial decline in a particular sector or overall; and (3) industrial growth in a particular sector or overall over time, greater than in proportion to population growth.

Other items

There are a number of important changes to merge from Simutrans-Standard, including the new system of multiple orientations of railway crossings/points (which will, in turn, require a new version of Makeobj), as well as the new ambient sounds feature.

Bernd Gabriel is also working on an overhauled physics model, which should more accurately simulate acceleration and maximum speed of different types of vehicles, and I will be looking into the application of way constraints to open ocean tiles to enable pakset authors to create boats that can only travel on rivers or canals.

I am grateful for everyone's patience, and hope that people will agree that 7.0 will be worth the wait.

Re: Development update

Reply #1 – September 26, 2009, 03:52:53 pm

This sounds really interesting and grabs attention!
It opens so much design value.

If I understood (2) and (3) correctly, taking forexample brick industry,
it will have 1 chain for each 10,000 population for example in early era,
pakauthor can designate so it is 100,000 per one chain?
(since brick will be used as decoration)
(ah but in this case if population multiplied by ten, it would maintain same level...)
Also, I don't think it work by specific population number but if it could, it is also would be really handy.

I had hard time understand (1). Is this means forexample, chain which produce same final product but
using buildings of different capacity?

Anyway, really interesting. Hope you good luck with it.
On other hand, do you accept any suggestion? If so where can I post it?

Re: Development update

Reply #2 – September 26, 2009, 03:57:58 pm

Colonyan,

I am glad that you like the ideas. However, I am having trouble understanding your second and third paragraphs - can you elaborate?

Re: Development update

Reply #3 – September 26, 2009, 04:33:15 pm

paragraph2
I guess I understood (2) and (3) correctly.
I confused you making example which certain group(each X growth) of population establishing
industry chain.

paragraph3
Does this mean small factories will be replaced by large factories?
Like textile workshop to textile factory?

Re: Development update

Reply #4 – September 26, 2009, 04:38:13 pm

Colonyan,

I am still not sure what you mean to ask in respect of paragraph 2. As to paragraph 3, it does not necessarily mean that, but, if the pakset is set up correctly, the overall effect will be that several smaller factories will close down, and the factories that are built to replace them will be larger and fewer in number.

Re: Development update

Reply #5 – September 26, 2009, 04:45:40 pm

I'm really sorry. I did not read what I wrote.

taking forexample brick industry,
it will have 1 chain for each 10,000 population for example in early era,
pakauthor can designate so it is 100,000 per one chain?

Above was supposed to be

Is it possible to design so that taking for example imaginary brick industry,
1M population will ask for 5 brick chain in early stage of game
and later same population will require only 1 chain.

Re: Development update

Reply #6 – September 26, 2009, 04:47:42 pm

Approximately, although note that there is no demarcation between chains: one cannot specify that one will have an exact number of one or other chains. One can only use the distributionweight parameter in each individual industry file to set things.

Re: Development update

Reply #7 – September 26, 2009, 05:07:50 pm

Thankyou for clarification. This will be powerfull addition.

Re: Development update

Reply #8 – September 26, 2009, 06:06:07 pm

I am glad that you like it!

Re: Development update

Reply #9 – October 01, 2009, 01:27:23 pm

James,

Some further thoughts on industries...

(1) Currently the industries shut down after their retire year. In reality, there may be a time when new industries of that type are not introduced, but are not closed down either. After a later point they start to shut down. Could this be incorporated into the dat file with a new parameter (obsolecense year?) ? Incidentally, the same principle could apply to vehicles, and when the excessive maintenance charges start to apply from.

(2) In the current implementation (even in your plan above), the only way an old industry gets replaced by its more modern equivalent is if the old one shuts down due to random chance and a new one springs up elsewhere. However, it may be more realistic in some cases that an industry upgrades on the same site (especially for farms, for instance). There could be a new parameter in the dat file along the lines of Upgrade=NewIndustryObjectName, along with a chance of this happening, and the new industry would then take the site of the old one with a random chance after the retire year of the old industry and the intro year of the new one. This would require the two objects to have the same dimensions of course, but that would be for pakset maintainers to ensure.

Would either of these be worth further thought or programming effort?

Re: Development update

Reply #10 – October 02, 2009, 03:00:15 am

Quote from: The Hood – on October 01, 2009, 01:27:23 pm

(2) In the current implementation (even in your plan above), the only way an old industry gets replaced by its more modern equivalent is if the old one shuts down due to random chance and a new one springs up elsewhere. However, it may be more realistic in some cases that an industry upgrades on the same site (especially for farms, for instance). There could be a new parameter in the dat file along the lines of Upgrade=NewIndustryObjectName, along with a chance of this happening, and the new industry would then take the site of the old one with a random chance after the retire year of the old industry and the intro year of the new one. This would require the two objects to have the same dimensions of course, but that would be for pakset maintainers to ensure.

Would either of these be worth further thought or programming effort?

I really really like the idea of an industry upgrading on site, so if it is feasible please consider it!

Re: Development update

Reply #11 – October 04, 2009, 05:27:10 pm

I have been thinking about the industry upgrade idea. The most difficult part of it would be replacing the industry with another of a different size or shape. If the the upgraded industry was always the same size and shape as the original industry, then upgrading should, in theory at least, be very easy: just a matter of substituting one base type for another, leaving everything in place. If, however, the new industry was a different size or shape, then the whole industry would have to be deleted, then a mechanism devised for checking which is the nearest suitable location to put the new industry. That second step would likely be very difficult.

So, perhaps I should ask this: would the feature still be as attractive if there was a limitation that any upgrade must occupy exactly the same dimensions (fields notwithstanding) as its predecessor, and that, if, in a .dat file, a differently sized/shaped industry was specified as an upgrade, that stipulation would simply be ignored?

Edit: For simple upgrading to work, the upgraded factory would also have to have identical output and input goods, if it was to fit seamlessly into the same chain.

Re: Development update

Reply #12 – October 04, 2009, 06:07:34 pm

IMHO it would still be desirable even with the restriction that the upgraded industry must occupy the same area (or smaller?) than the older industry. I presume that it would be possible for pak maintainers to f ex add some storage area around the graphic of the older industry if it is the only way to "reserve" the area needed for the upgrade.

Re: Development update

Reply #13 – October 04, 2009, 06:15:31 pm

It couldn't be smaller either, or else it could not be a straight swap of types.

Re: Development update

Reply #14 – October 04, 2009, 06:40:09 pm

Then, the exact same size will have to do *smile*

Re: Development update

Reply #15 – October 04, 2009, 08:32:40 pm

Such restriction seems rather natural.

Re: Development update

Reply #16 – October 04, 2009, 08:43:37 pm

I think that restriction would be workable and realistic enough. If you need a bigger factory, it needs to be new somewhere else...

About suppliers/customers - could these not be recalculated if necessary when the upgrade happens, and any new industries built as appropriate?

Re: Development update

Reply #17 – October 04, 2009, 10:16:14 pm

Ahh, if one were to have different suppliers and consumers, then the existing links could not be preserved. What would happen to factories with severed links; what would happen if building new factories to service the necessary new links exceeded the prescribed industry density? Furthermore, building new factories to link in with a chain in that way is something for which entirely new code would have to be written - and that is a highly complicated task in itself (existing methods simply add new chains or factories to existing chains haphazardly).

Re: Development update

Reply #18 – October 05, 2009, 09:55:23 pm

@james
When I first time made a question about this update, I guess I understood something wrongly
if I think about it now.
Your feature was about that, pak designer can decide how much whole delivering freight to
consumer affect the population growth.
In standard, its 40% for p****enger, 30% for mail and 20% for freight.
So with your implementation, we can modify the percentage depending on age?

Re: Development update

Reply #19 – October 05, 2009, 10:06:54 pm

Colonyan,

this update will not have any effect on the extent to which transporting goods causes population growth. It is solely concerned with replacing industries that have closed down through obsolescence, and new industries being created in consequence of population growth.

More generally, I have now implemented some early prototype code for very basic industry upgrading: the upgraded types will need to be of exactly the same size and dimensions, and have exactly the same inputs and outputs as the old industry. However, because of the way in which I have written the code, one can specify any industry as an upgrade in the .dat file (even if it does not meet those criteria), and, if I or anyone else makes a more sophisticated algorithm for industry upgrading, .pak files produced with the version of makeobj released with 7.0 containing upgrades to industries with different sizes, etc. will be able to be used, as the check for suitability is done at the time of replacement, not at the time of compiling the .pak file.

Re: Development update

Reply #20 – October 10, 2009, 09:22:20 pm

Update: I have now added in my development code a feature to enable the capacity, price and maintenance cost of stations to be able to be set individually in the .dat files. I am still awaiting the updated physics model before I am able to produce a final version of the code, however.

Re: Development update

Reply #21 – October 10, 2009, 10:45:05 pm

Station code sounds useful. I hope this could be included in the main code too, maybe worth creating a patch to see if anyone on the standard dev team is interested?