Release candidate

[mopoona]

Oh you are right. Maybe I remembered this bug from an earlier Version. Sorry ^^

[Carl]

I've got a savegame which is saved in 10.11, and is loadable in an earlier release candidate version (from about 2 weeks ago) -- but which crashes on load in the latest version which James posted on the airport topic. Trying to load the save in that version yields a quickstone error (slot 256 already taken).


Savegame and required pak folder are bundled together here: https://dl.dropbox.com/u/61716/error.rar

[jamespetts]

Thank you for the report - found and fixed on -devel.

[Carl]

Brilliant - thanks!

[Junna]

Will there be a new build, not compiled with Mingw?

[ӔO]

Since I finally have an i5 system, I think I will be able to try it out as well.

[Carl]

Junna - here's a version I compiled with MSVC a week ago. https://dl.dropbox.com/u/61716/SimutransExperimentalRC.exe

[jamespetts]

I am just waiting for Bernd to fix a few bugs with the effect of some of his new work on braking physics on aircraft before releasing a new release candidate; in the meantime, feel free to use Carl's.

[Junna]

Junna - here's a version I compiled with MSVC a week ago. https://dl.dropbox.com/u/61716/SimutransExperimentalRC.exe

Thank you.

I have noticed some strange behaviours I had not seen before (it is very possible I had simply missed them, however) - sometimes, when game is paused, and you delete a stop (as public player) from another player, the stop will not vanish (sometimes with the name left). If you then build a stop on-top of this tile, game crashes.

I loaded my save game and played around for a while. Set up an underground network, etc. However, the same game has been corrupted. To load in initially with the new version I saved it as version 9 and loaded it up in the current. But now the game will not be loaded (a autosave from 10 minutes earlier is similarly not possible to load). It repeats an error I have seen before on an earlier version with some bug that was supposedly corrected:

FATAL ERROR: loadsave_t::rdwr_str()
string longer (511 or 23551) than allowed size (256)

Here is the attached save game in question:
http://www.mediafire.com/?v613e3w7be13fnt

The PAK is the same as that posted on the first page of this thread should it be necessary (0.8.4 beta, some tracks from the Japanese player ebi for pretty elevated sections). Here's a link for convenience should it be necessary:

http://www.mediafire.com/?egf7pxch78w7kva

[jamespetts]

Thank you for the report. Unfortunately, it's extremely difficult to deduce what bug(s) cause a saved game to be corrupted just by looking at the corrupted game. Do you have a copy of the original, non-corrupted saved game that I could look at?

[Junna]

Thank you for the report. Unfortunately, it's extremely difficult to deduce what bug(s) cause a saved game to be corrupted just by looking at the corrupted game. Do you have a copy of the original, non-corrupted saved game that I could look at?

http://www.mediafire.com/?14fjl47z49w91f6

The most recent (saved earlier today) non-corrupt save-game. A great many things were constructed after this save and the corrupt ones, so it is difficult to know at which stage it went kaput.

[Carl]

I'm getting an occasional crash when zooming in on the minimap. The text is:

"FATAL ERROR: sim_new_handler()
OUT OF MEMORY or other error allocating new object

Any idea what might be causing this?

[jamespetts]

Hmm - very hard to tell without being able to trap it in the debugger. I haven't experienced this one myself. Is there a particular saved game with which it occurs?

[Carl]

Savegame here with pak folder: https://dl.dropbox.com/u/61716/ZoomCrash.rar

The crash seems to happen reliably when trying to zoom past 1:3 on the minimap using a recent devel build.

The error text is not always shown, incidentally: sometimes there is merely a blank error box and a crash.

[Dwachs]

You could test whether these fixes also fix your crash:

https://github.com/aburch/simutrans/commit/3538623d168ea2f3e6409b99402f8d917d77cb60
https://github.com/aburch/simutrans/commit/ee591c2fd61b27aa6db5c0565bd733e1d15c9ded

[jamespetts]

Dwachs and Carl,

thank you for linking to those. Those seem to be recent fixes for the new minimap from Standard, which has yet to be incorporated into Experimental. Since this issue arises in code not specific to Experimental, it will probably be difficult for me to isolate it effectively; but it ought be solved whenever I am able to merge a more recent version of Standard that incorporates the new mini-map.

Thank you for the report/suggestions nonetheless!

[Dwachs]

The fixes, to which I linked, are not bound to additional minimap features. They address an integer overflow error that can occur with large maps and zoom in.

[jamespetts]

Hmm - I couldn't find the code to which they referred in the Experimental version of karte.cc.

[jamespetts]

I have now uploaded a new release candidate, no. 3, with fixes for a number of previously reported issues and other issues that have been discovered meanwhile. I should be very grateful for any feedback following testing. Thank you everyone for the work so far!

[Carl]

James, I just noticed that the new executable linked to in the original post has a date-modified stamp of July 20th. Is this correct?

[jamespetts]

Hmm, that's odd: when I download it, I get a date of the 18th of August.

[Carl]

For me, the zipped archive displays 18/8 but the executable displays 20/7. If it's displaying correctly for you, then no matter - it's probably just an error.

I note, at any rate, that the bug discussed here is still present -- not sure whether that had been fixed yet, but thought I should mention it nevertheless.

[jamespetts]

That bug I am aware of - Bernd is working on that at present. Thank you for noticing it, though.

As to the date of the executable - is that the file modification date listed in the .zip file or the date displayed in the startup dialogue box in the game itself?

[Carl]

The date in question is displayed in the Windows file details box. I didn't think to look in the game itself -- that shows August 10th, which I take it is correct.

[jamespetts]

Ahh, in which case, all is fine - an executable compiled in July won't show an August date

[Carl]

Just realised nobody's replied to this. In my testing, this release candidate seems to be very stable and to work very well -- notwithstanding the couple of small problems already noted.

[jamespetts]

Splendid - thank you for testing. Both of the problems already noted are being looked into, but the physics one requires some recalibration of things generally, so it might be a while before that is out.

[Carl]

Hi James,

I just wanted to register some feedback on the last round of commits regarding gear, default global power and resistances.

Applying the recommended changes in the latest version -- a gear of 50 for diesel vehicles, and default global_power_factor of 50 -- seems to worsen rather than solve some of the problems. For instance, a vehicle with the stats of a Class 156 DMU can now only reach 66kph top speed (out of 120kph) and takes over 5 kilometres to reach even that speed.

Even at global_power_factor of 100, its top speed is only 86kph. One has to raise the vehicle's gear value to around 130, keeping global_power_factor at 100, before it can reach its top speed of 120kph. As before, these oddities are mitigated gradually if you doubl up the vehicles -- though at a gear value of 50, even six-car arrangement only scrapes in at 119kph top speed.

It may be that the recent changes are part of some larger plan which is yet to be completed, but I thought I should note these results just in case.

(I should note I'm using the version of makeobj distributed some time ago for use with release candidates, and that it may be that a recent change there has had some impact here.)

[jamespetts]

Firstly, the change to the default global power factor is intended only in the base simuconf.tab, not in the pakset simuconf.tab for Experimental paksets - the idea is that only Standard paksets have this change.

Secondly, you will need to recompile Makeobj, since the defaults for air and rolling resistance are set in Makeobj for more recent versions. The thing that is yet to be completed (and I will post on this and other related physics changes in due course) is the balancing of steam locomotives, which is not straightforward, as there is little direct data as to their power.

[Carl]

Thanks for the clarification. Sorry for the confusion on the global power factor -- I had assumed that the default of 50 applied to both Standard and Experimental paksets, but I see now that I've misread that.


I'll have a go at compiling makeobj, but having tried and failed before I suspect I'll have to sit tight on this for the time being.

[jamespetts]

Thank you for your report on this. Apologies that the next version is so long in coming: there has been quite a lot of work needing to be done on the physics which has delayed things considerably, as well as a lot of pakset work; also, I have been quite busy in the last few weeks. I am hoping to have a new version released presently, and to start the server once again.

[Carl]

No worries, James -- I know there has been a lot of work required to iron out all the bugs. I eagerly await the release! :-)

[Carl]

I'm pleased to rescind my earlier worries -- using the new makeobj, the problems with topspeeds etc seem to be entirely fixed.

[jamespetts]

Excellent!

[Carl]

A quick query, if I may: what .dat file parameter should I use to indicate that a platform can be built underground?