Release candidate

jamespetts · June 30, 2012, 07:08:26 PM

I have produced a binary release candidate for the next release of Simutrans-Experimental, here. This is just the executable - no other files are included. Edit: This is the third release candidate.

This is a testing version - those wishing to play the game ought download a release version.

Please see here and here for previous discussion on the testing of the latest builds of Simutrans-Experimental.

Edit: The link has been updated to point to the latest, third release candidate.

Carl · June 30, 2012, 08:55:36 PM

Just given this a spin -- running very well and looking very stable!

jamespetts · June 30, 2012, 09:03:59 PM

Splendid! Did you try with the testing pakset 0.8.4?

Carl · June 30, 2012, 09:55:14 PM

Not yet. I will, but since I've not spent much time with Pak128.Britain-Ex previously, I suspect that some of the veterans of that pakset will be able to carry out more useful testing of the newest version.

jamespetts · June 30, 2012, 10:02:54 PM

Ahh, the reason that I ask is because it makes use of new features (braking physics, fare stages, etc.) which it would be helpful to have tested.

Carl · July 01, 2012, 08:56:38 AM

I've had a look with the newest version of the pakset now. I must say that the braking physics are a joy to behold -- i'm very excited that smaller distance-per-tile values will now be properly playable.

Just two minor things to note.

First, on braking physics: very occasionally when braking for a station, trains will slow to almost zero before the end of the platform and then have to accelerate a little in order to reach the end of the platform. This doesn't happen often, but I've seen it happen a few times (and not just in pak.Britain). It doesn't cause any major issues, though.

Second, on map generation: this works much better now than in previous devel versions (and I must say that the generated cities look notably better with the new code. However, "median citizens per city" is not functioning quite properly. In fact, the supposed median turns out to be the minimum: on a map with a median of 1600 and 256 cities, there is no city smaller than 1100, and the median is more like 2500-3000.

(A quick question about map generation. I copied the latest pak.Britain cityrules to a personal customised pakset, and found that the "placing cities" aspect took a huge amount longer than it does in pak.Britain. What could be causing this?)

Braking physics seems to work well with legacy paksets, too.

jamespetts · July 01, 2012, 09:44:44 AM

Thank you for the testing. The first issue relates to the braking physics, and I have notified Bernd.

As to the map generation, this is an interesting observation. It was Richard Smith who wrote the new map generation code based on Zipf's law. He's no longer contactable, unfortunately, so I can't ask him about his work. The following entry in simuconf.tab provides two further parameters:

Code Select


# These values are used in the city generation algorithm to determine the maximum size of cities.
# max_city_size is the maximum size, in citizens, of any city at the point of generation.
# max_small_city_size is the size, in citizens, of any city other than a "big city" at the point of generation. 
# TIP: Set a lower number for these values the earlier that the game is started.

max_city_size = 16000
max_small_city_size = 3000

One solution would simply be to rename "median citizens per city" to "Minimum city size", which would then make sense in conjunction with those two parameters. Do you have any thoughts on that?

Carl · July 01, 2012, 10:01:16 AM

My initial reaction is that those values should be displayed (and alterable) in the "new map" dialogue box somewhere -- even if only under advanced settings. Renaming "median citizens" to "minimum citizens" seems sensible, but it would seem odd if that were the only city-size-determining option available to edit upon starting a new map.

I should say that in general the algorithm seems to work very well and gives an excellent spread of city sizes.

Junna · July 03, 2012, 11:20:53 PM

Game crashes when a train is launched from a depot, not exiting this due to reservation of track outside by other trains, and then clicking the send to depot button. Crash instantaneous. Error message mentions the tpl/vector stuff like some others have.

jamespetts · July 03, 2012, 11:49:58 PM

Hmm - having trouble reproducing this. Do you think that you could upload a saved game in which it occurs? Thank you for your report!

Junna · July 04, 2012, 09:21:34 AM

Pak: http://www.mediafire.com/?egf7pxch78w7kva (contains addons, not sure if necessary to load)

Save game: http://www.mediafire.com/?7z8jqp2rgy2y06p

Togwich Railway station is at least one location where the error occurs. Make up a set, give it some destinations beyond the station itself, wait for the tracks in the way to be occupied, release train - while it waits, click it and set it to return to depot. Then follows the crash.

jamespetts · July 04, 2012, 10:40:13 AM

Should be fixed on -devel - thank you for the report!

Junna · July 06, 2012, 10:09:17 AM

Is there a reason that some of the GUI-changes to standard have not yet been incorporated into ex? In particular that sassy new display of network schedules as map-overlay?

jamespetts · July 07, 2012, 11:18:51 AM

Yes - the -devel branch was feature frozen a few months ago to what was then the latest stable release of Standard, and since then, only bug fixes have been permitted. Those bug fixes have taken somewhat longer than anticipated. Because merging from Standard can be a very involved task and is prone to introducing new bugs, I no longer merge from Standard after a feature freeze.

I do hope that the latest changes in Standard will make it into a future version of Experimental, however.

jamespetts · July 15, 2012, 07:58:03 PM

There has been some more work done (thanks to Bernd Gabriel) on fixing bugs with the braking physics, particularly relating to waypoints. I have produced a second release candidate build for testing (Windows only, but Linux users can self-compile from the -devel branch), which can be downloaded here.

I should be very grateful for any testing; thank you to those who have tested so far.

Junna · July 15, 2012, 10:21:15 PM

James, I've experienced certain random crashes I have not been able to tie to any specific action taken in game, is there a way for me to enable one of those debug views so I can perhaps share details if this recurs? I remember that nightlies of normal simutrans used to run a debug window on the side in the past.

jamespetts · July 15, 2012, 10:29:07 PM

Hmm - Experimental isn't set up to do that. Can you upload a saved game with which you experienced crashes?

jamespetts · July 16, 2012, 09:45:10 PM

Bernd has pushed a fix to deal with the crashes, which appears to work so far: the modified executable is available in the same location as linked above.

Junna · July 20, 2012, 06:22:15 PM

Still getting inexplicable crashes (varying frequency, sometimes not for several hours, other times quite abruptly, always when not taking any specific in-game actions myself, which makes it hard to try and pinpoint what might be the cause).

Here is the save game (same pak as before):

http://www.mediafire.com/?73nopgx6fmx56ez

jamespetts · July 20, 2012, 10:33:39 PM

Junna,

thank you for the report. I have fixed the issue now: the version with the fix can be found here. This version has been compiled with MinGW, so I should be interested to see how that performs and whether there are any other issues with this version compared to the version compiled with MSVC++.

Junna · July 21, 2012, 01:09:49 AM

Quote from: jamespetts on July 20, 2012, 10:33:39 PM
This version has been compiled with MinGW, so I should be interested to see how that performs and whether there are any other issues with this version compared to the version compiled with MSVC++.

Initial notes: exe is almost six times larger, initial loading and pak-loading seems slighty slower (might potentially be due to other reasons), and the overall framerate is decidedly lower and CPU use seems a tad bit higher; game slightly less responsive (menu's lag more than on previous RC.)

jamespetts · July 21, 2012, 11:10:36 AM

Thank you for the feedback - that is most helpful. Does it seem all right apart from those things?

Junna · July 21, 2012, 05:50:11 PM

Quote from: jamespetts on July 21, 2012, 11:10:36 AM
Thank you for the feedback - that is most helpful. Does it seem all right apart from those things?

Apart from that I have yet to experience crashing, and have not noticed any further irregularities (month-end update seems to take a bit longer). The slowness of the menus and the lower frame-rate are quite noticeable, however - I'd estimate the frame-rate might be as much as 30% lower than before on normal speed, and fast-forward scarcely moves much faster what-so-ever. I'll have to reboot and test it a bit further once I get around to it.

jamespetts · July 21, 2012, 06:02:29 PM

Thank you - that's a helpful indication. I shall probably avoid releasing versions compiled with MinGW in the future, especially as recent investigations have discovered that it was not the use of MinGW but something else that solved the original problem. I expect that it is the use of MinGW that is producing the slower builds.

Milko · July 23, 2012, 10:34:12 AM

Hello

Quote from: Junna on July 21, 2012, 01:09:49 AM
Initial notes: exe is almost six times larger

If I remember correctly the problem is related to the fact that the resulting executable using MinGW incorporates the dll. The executable can work if you delete two DLLs contained in the directory simutrans.

Giuseppe

prissi · July 24, 2012, 02:21:33 AM

Mostly strip sim.exe should help too. And mingw compiles with debug code, which MSVC compiles without (espeically without all assertions).

jamespetts · July 24, 2012, 09:58:52 AM

Quote from: prissi on July 24, 2012, 02:21:33 AM
Mostly strip sim.exe should help too. And mingw compiles with debug code, which MSVC compiles without (espeically without all assertions).

Ahh, but doesn't the latter depend on the config.default settings?

prissi · July 24, 2012, 09:23:43 PM

Only if you remove the debug entry fully in config default, no debug code will be added at all. However such build will not stay in sync with debug builds.

jamespetts · July 24, 2012, 11:00:06 PM

Quote from: prissi on July 24, 2012, 09:23:43 PM
Only if you remove the debug entry fully in config default, no debug code will be added at all. However such build will not stay in sync with debug builds.

Over the network you mean? Interesting - why would it desync with a debug build? Would it desync with a release build compiled with GCC or MSVC++?

prissi · July 25, 2012, 08:56:08 AM

I am not sure we hammered this out. Some code in assert changed something affecting the game state. THus all our release are release with assertions on.

jamespetts · July 25, 2012, 09:40:48 AM

Ahh - if that is the case, it would work equally well with all release builds having asserts off, as we do in Experimental currently.

mopoona · July 30, 2012, 08:07:06 PM

I noticed that airplanes slow down at waypoints (not airports). Is this behavior intended?

jamespetts · July 30, 2012, 10:21:03 PM

That does indeed appear to be a bug - thank you for spotting that! Might I ask, however - why do you need to set waypoints for aircraft in the first place...?

mopoona · July 31, 2012, 06:33:40 AM

I just don't like airplanes flying through populated areas. By the way, I think trains fast than 200 kph slow down too at waypoints...

jamespetts · July 31, 2012, 10:01:43 AM

Hmm, are you sure about the trains? I thought that we had fixed the trains/waypoints issue. Can you upload a saved game in which you can reproduce this?

News:

Release candidate