Current coding priorities?

[jamespetts]

With the recent release of Simutrans-Experimental 11.0, it is worthwhile giving some consideration to which of the outstanding coding projects are a priority for further work.

One possibility is to focus now on the set of balancing features (marked with [*B] in the list) to enable cost balancing to take place, as this is now being done on Pak128.Britain (Standard).

Another possibility is to tackle the relatively straightforward, but perhaps less important, features relating to canal navigation now that Pak128.Britain-Ex 0.9.0 has a comprehensive selection of canal transport.

A furhter possibility is to continue to work on passenger transport related projects, such as the newly added car parking and town growth features listed in the coding projects thread, in order to complete the work on passenger transport before starting on balancing features. This might have the advantage that it alters the sort of revenue and cost that one is able to generate from a passenger network enough to have an impact on how a pakset should be balanced.

Finally, there is the option of prioritising merging from Standard (which is not mentioned in the projects list, as it is an ongoing matter). Standard's latest changes include the new climates/terrain feature, which changes are, I understand, quite fundamental, and would take some considerable work - of a very techincal nature - to merge into Experimental. However, the benefits of doing this would be considerable, as, not only would compatibility with newer Standard saved games be maintained, but the new terrain feature, allowing two different heights of tiles, allows much greater variety of terrain, which can have many economically significant consequences. Further, some of the canal navigation related features might be enhanced by being related to this feature, for example, by permitting certain canals to ascend only the shallower inclines.

Any thoughts on this matter would be much appreciated, and even more appreciated would be offers of assistance with these various matters.

[Junna]

I think merging the new terrain work would probably best? How much does this part of the code differ between Ex. and Standard anyway?

[Jando]

I'm a newbie here and have only scratched the surface of this gem of a game.

Anyway, my vote would go to balancing features.

[jamespetts]

I think merging the new terrain work would probably best? How much does this part of the code differ between Ex. and Standard anyway?

I think that the terrain changes have very wide-reaching consequences throughout the code.

[kierongreen]

The longer you leave merging changes from standard the more difficult it would be I'd imagine...

[jamespetts]

The longer you leave merging changes from standard the more difficult it would be I'd imagine...

That is true, I suppose. Could you briefly summarise the parts of the code that this change has affected?

[kierongreen]

Well what's added is: alpha blending for images, landscape tiles formed by alpha blending transitions on the fly, double height images for ground tiles, vertical slopes, ways and bridges, all climates now checked by coordinate rather than height, all water checks by coordinate rather than groundwater height, tools to manipulate height extended to cope with two height levels, extra code in map generation to give more varied shore lines and tools to set climate and water height.

Look at one of the diffs in the new landscape thread (http://forum.simutrans.com/index.php?topic=10242.msg117939#msg117939 is the last one before it was incorporated) to get an idea of the files changed.

[jamespetts]

Thank you - that is helpful.

[neroden]

I agree that merging from standard should be prioritized.  (As a note, one of the hardest things to merge from standard is the "departure board".  Experimental has a completely different routing system, which should theoretically make it easier to implement a departure board, but the departure board will have to be implemented using completely different code.)

With the terrain improvements, the big question here is what requires pak support.  Most of the things added are pretty straightforward to merge.  We can merge the alpha blending without actually using it, for instance.

These, however, are an issue:

double height images for ground tiles, vertical slopes, ways and bridges,

Suppose the pak hasn't got these images.  What do we do then?

----
My personal projects:
(1) to make cities look prettier: to get buildings facing towards roads, stuff like that.  At the moment city buildings are in good shape, but factories are still looking odd.
(2) to clean up city borders.  The current system with "overlapping cities" has bad and confusing consequences for city growth.   I have a complete rewrite of the city limits code on the fix-city-limits branch, which prevents city borders from overlapping, and I prefer it to the current system, but there are some issues which are causing me to think hard about it.  I'll start another thread for them.
(3) Stacked stations.  This belongs in standard, of course, but standard may have some issues implementing it due to its station routing code, and experimental seems to have no issues at all.
(4) After that, balancing for "freeplay mode" (weights, speeds, power, rate of production, etc.)

[Junna]

Insofar as we want a departure board at all, this would be a preferable implementation:



Final destination in large or bold text, and intermediate stops listed...

(4) After that, balancing for "freeplay mode" (weights, speeds, power, rate of production, etc.)

What exactly does this mean, would the balance be different for freeplay?

[neroden]

What exactly does this mean, would the balance be different for freeplay?

What I mean is, first we balance the things which don' t involve money.  After we've got all the things which don't involve money working right, *then* we go back and balance the things involving money.  Why?  Because if weight, power, capacity, passenger generation, goods generation etc. are wrong, and we change them later, then we have to change ALL the money stuff... but the same is not true the other way around, we can change money stuff without affecting the other stuff.

[Junna]

What I mean is, first we balance the things which don' t involve money.  After we've got all the things which don't involve money working right, *then* we go back and balance the things involving money.  Why?  Because if weight, power, capacity, passenger generation, goods generation etc. are wrong, and we change them later, then we have to change ALL the money stuff... but the same is not true the other way around, we can change money stuff without affecting the other stuff.

Ah, I see what you mean now.

[kierongreen]

paks without double height images mean that simutrans disables this functionality. The only slight issues are 1) there is a missing climate transition in older paks so when this appears ingame it looks a bit odd and 2) some of the conversion routines are based on a fixed game version in saves - that is if a pak is not converted at that time then it won't properly convert afterwards.

Should also note the pak128.Britain (and thus with editing of dat files, pak128.Britain expermental) has almost complete support for double height tiles with only a few bridges left. pak128 progress is well underway too while the idea is for pak64 seemingly to remain single height as far as I can tell (or at least, use double heights in a different way).

[greenling]

Hello all
Here some Points.
The Front and Backimages for Ways and Bridges miss i.
I Think that at the project double height tiles better it wait unit all ways,Bridges,Tunnels,grounds and the
another Things complete it.
The loadingtimes in pak128.britain exp and in Carls Pakset need a workaround.Sometime get i a trafficjam.
The timetablesystem it in Simutrans Standart and Simutrans exp it sometime to coarse.
Here it a finer timetable more useful. A SimutransFan out Japan have for those problem find a idea.
http://forum.japanese.simutrans.com/index.php?topic=511.msg2421#msg2421
The possibility to looks how many pakfiles they be use in a running game. And how many they in the game not be use it.

[jamespetts]

Thank you all for your input on this: much appreciated. The terrain changes and departure boards are in the nightlies, but not yet, I think, a Standard release - is that correct? There might be something to be said for waiting until this code is mature enough for a release before merging it.

As to terrain pakset support, it would not be too hard for me to produce a branch of Pak128.Britain-Ex with this support for the reasons that Kieron gives. Many of the source files for the way graphics already have extra images for half height ways waiting to be used.

On the departure boards, I have not looked in much detail as to how this works; I wonder, however, and depending on how it works, whether this feature might enable a further optimisation of routing - to allow passengers/mail/goods more accurately to select which convoy to board that will get them to their next transfer point the fastest?

As to no. 4 in the list, Nathaneal, being "weights, speeds, power, rate of production, etc." (or "weight, power, capacity, passenger generation, goods generation etc."), what further work do you think needs to be done in this area before cost balancing work is commenced? I am currently doing some work on passenger generation (quite recently started) by making universal lists in karte_t for passenger origins, commuter targets, visitor targets and mail origins and destinations, so that all that passengers/mail need to do when generated is to pick a target from these weighted vectors at random without first having to choose whether to go to one or another city or whether to go to an attraction or a factory, etc.. The main problem encountered so far is that a factory is not in fact an object of type gebaeude_t, so careful work is needed to make factories sit in the same list as city buildings, town halls and attractions.

Greenling - can you elaborate on what you mean by "too coarse" here? What further refinement is needed for what purpose(s)? The thread in the Japanese forum I cannot read, I am afraid, since I do not speak Japanese.

[prissi]

The departure board is in 112.3, i.e. in the stable.

[jamespetts]

Thank you - that is useful to know.

[waerth]

Belated, but my vote would go to integrating the main branch code. I love the look of the departure boards

W

[Carl]

I haven't looked at the departure boards in Standard, but having read about them on the forum, here are some thoughts about transferring the feature:

-- Since the boards seem to estimate when the next train on a given line will arrive, the system will have to be developed to take account of Experimental's differing distance and time code.

-- It will also have to be somehow connected to the convoy spacing feature, since, given this, there is often no need to estimate the time a service will be departing: the service will be programmed to leave at a specific time, and any departure board feature should take account of this.

-- If departure boards could be made accurate, and could be fully integrated into routing, this would presumably obviate the need for waiting times as a feature altogether. However, I suspect that this is a rather distant possibility.


One related observation:

-- The point-to-point journey time system of Experimental already records the departure times of specific convoys from specific stations. Perhaps this data in itself is rich enough to be displayed in some kind of departure boards/estimated timetable system?

[Bear789]

As a player (so i'm egoistically thinking about how I play and a game that I'd like to start in Exp, but I keep postponing because I'd like to have some recent Standard features), my ideal priority list would be:

1 - merging and adding the new terrain
2 - passengers and city development

Balancing and canals are low priorities to me. Of course I'm not a programmer and I have no idea if this is reasonable or not. Just my two cents.

[neroden]

paks without double height images mean that simutrans disables this functionality. The only slight issues are 1) there is a missing climate transition in older paks so when this appears ingame it looks a bit odd and 2) some of the conversion routines are based on a fixed game version in saves - that is if a pak is not converted at that time then it won't properly convert afterwards.

Ohhh.  I need to know that savefile version and where it is checked.

I can implement a "convert_pak_to_double_grounds_NOW" simuconf.tab option which can be temporarily turned on to force immediate savefile conversion, which will allow people to work around this problem.

Should also note the pak128.Britain (and thus with editing of dat files, pak128.Britain expermental) has almost complete support for double height tiles with only a few bridges left.

Merging from pak128.Britain to pak128.Britain experimental is a bit of a bear, and we're way behind on the merging.  This is mostly due to translations being broken by prissi a couple of years back.  I've been doing coding, but I should get back to fixing the translations some time.

I do not advise trying to merge the double grounds patch from standard to experimental until I've gotten the translations fixed in pak128.britain so that it's viable to merge the pak changes from standard to experimental.  This is going to take a lot of work.  For starters, I need to have a simutranslator category for pak128.britain.experimental.  Then I have to get back to correcting the translations in the standard version of pak128.britain.  I'm not ready to start this project yet, due to a number of other projects ongoing.

It's also slow to merge from pak128.britain to pak128.britain experimental due to *practically every* dat file being different.  I guess the terrain files are easy enough, but the waytype files are going to be a lot of .dat work, and the bridges are going to be even more work.

I checked -- it appears that you decided to go with "conversion_factor 2" for pak128.britain.  So, shallow beaches, and no steep mountains?  :-(

pak128 progress is well underway too while the idea is for pak64 seemingly to remain single height as far as I can tell (or at least, use double heights in a different way).

[jamespetts]

Hmm - I have been merging most changes from Pak128.Britain (Standard) manually, so there isn't a great deal to do. The translation files for the pakset definitely need work - you reminded me that I had meant to request a Pak128.Britain-Ex category in Simutranslator due to the divergence. I could probably handle merging the double heights thing in the pakset if you could do the code.

[kierongreen]

Ohhh.  I need to know that savefile version and where it is checked.

It's checked in a few places rdwr (koord3d, grund_t, brueckenboden_t), load (karte_t) maybe a few others - search for 112007 and that pinpoints all of them. Some of these are associated with climates or water height maybe rather than slopes though.

I can implement a "convert_pak_to_double_grounds_NOW" simuconf.tab option which can be temporarily turned on to force immediate savefile conversion, which will allow people to work around this problem.

Actually all saved games are converted immediately. The problem comes later if someone wants to load a game and the pakset have changed from conversion factor 1 to 2. If you're writing a patch a better idea might be to have a conversion_factor_game_version parameter which uses that to decide whether to multiply koordinates and slopes. Depending on how quick a pakset is converted a saved game might undergo two conversion steps - the first from single to double height slopes, the second multiplying existing slopes and coordinates by 2. Loading an old saved game once the pakset has been converted would do these both at once (as it does for pak128.Britain now double heights have been enabled in it).

I checked -- it appears that you decided to go with "conversion_factor 2" for pak128.britain.  So, shallow beaches, and no steep mountains?  :-(

Yes I did. For a start because most players complaining about slopes have been saying that they are too steep, rather than too shallow. Notice how Locomotion, Transport Tycoon and thus ottd all have slopes half that of simutrans so far. Also steep slopes would start to be problematic in terms of seeing the landscape - as slopes facing away from the player are invisible. Also existing slopes work out to be a gradient of 22.5 degrees, with half slopes being 11.25 degrees. Double slopes would have been 45 degrees - it's actually pretty rare you get slopes that steep on a landscape. Cliffs can always be used to give a larger height difference if required. Finally because it's what I wanted, and since I've drawn all the new graphics I think I'm entitled to that ;p

Of course, if you or someone else wants to draw steep graphics you're welcome to create a fork (actually for steep slopes there's not nearly as much graphics required because way images aren't needed - only bridge ends).

[jamespetts]

For reference, I am currently considering which features should be provisionally considered for inclusion in the future 12.x releases. So far, I think, it would be worthwhile to include the following features:
(1) stacked stations (Nathaneal);
(2) city limits improvements (Nathaneal); and
(3) passenger generation improvements.

I should add that the above of Nathaneal's features also include any ancillary changes that he has made on the relevant Github branches. Other things under consideration would be Nathaneal's (I think so far preliminary) work on city population growth, although city growth generally requires such a major rewrite that it might well be worth putting everything but the bug fix (which has made it into Standard) being included until 13.x (together with the feature linking town growth with local transport provision), and, if just a bug fix is being included, it might as well go into 11.x unless that alone requires stepping the saved game version.

Another possibility for consideration for addition to 12.x is my proposed overcrowded stations feature, which should be a relatively minor feature (compared at least to the passenger generation feature, which requires some quite substantial engineering).