I have produced a binary release candidate for the next release of Simutrans-Experimental, here (http://simutrans-germany.com/files/upload/simutrans-experimental-rc.zip). 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 (http://forum.simutrans.com/index.php?topic=9186.0) and here (http://forum.simutrans.com/index.php?topic=9709.0) 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.
Just given this a spin -- running very well and looking very stable! :)
Splendid! Did you try with the testing pakset 0.8.4?
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.
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.
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.
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:
# 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?
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.
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.
Hmm - having trouble reproducing this. Do you think that you could upload a saved game in which it occurs? Thank you for your report!
(http://i1207.photobucket.com/albums/bb463/Junnapon/ggreakgtrd.jpg)
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.
Should be fixed on -devel - thank you for the report!
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?
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.
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 (http://simutrans-germany.com/files/upload/Simutrans-Experimental-rc.zip).
I should be very grateful for any testing; thank you to those who have tested so far.
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.
Hmm - Experimental isn't set up to do that. Can you upload a saved game with which you experienced crashes?
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 (http://simutrans-germany.com/files/upload/Simutrans-Experimental-rc.zip).
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
Junna,
thank you for the report. I have fixed the issue now: the version with the fix can be found here (http://simutrans-germany.com/files/upload/simutrans-experimental-rc.zip). 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++.
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.)
Thank you for the feedback - that is most helpful. Does it seem all right apart from those things?
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.
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.
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
Mostly strip sim.exe should help too. And mingw compiles with debug code, which MSVC compiles without (espeically without all assertions).
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?
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.
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++?
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.
Ahh - if that is the case, it would work equally well with all release builds having asserts off, as we do in Experimental currently.
I noticed that airplanes slow down at waypoints (not airports). Is this behavior intended?
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...?
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...
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?
Oh you are right. Maybe I remembered this bug from an earlier Version. Sorry ^^
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
Thank you for the report - found and fixed on -devel.
Brilliant - thanks! :)
Will there be a new build, not compiled with Mingw?
Since I finally have an i5 system, I think I will be able to try it out as well.
Junna - here's a version I compiled with MSVC a week ago. https://dl.dropbox.com/u/61716/SimutransExperimentalRC.exe
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.
Quote from: carlbaker on August 08, 2012, 07:16:36 AM
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
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?
Quote from: jamespetts on August 08, 2012, 10:33:07 PM
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.
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?
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?
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.
You could test whether these fixes also fix your crash:
https://github.com/aburch/simutrans/commit/3538623d168ea2f3e6409b99402f8d917d77cb60
https://github.com/aburch/simutrans/commit/ee591c2fd61b27aa6db5c0565bd733e1d15c9ded
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!
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.
Hmm - I couldn't find the code to which they referred in the Experimental version of karte.cc.
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!
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?
Hmm, that's odd: when I download it, I get a date of the 18th of August.
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 (http://forum.simutrans.com/index.php?topic=9709.msg98139#msg98139) is still present -- not sure whether that had been fixed yet, but thought I should mention it nevertheless.
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?
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.
Ahh, in which case, all is fine - an executable compiled in July won't show an August date ;-)
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.
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.
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.)
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.
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.
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.
No worries, James -- I know there has been a lot of work required to iron out all the bugs. I eagerly await the release! :-)
I'm pleased to rescind my earlier worries -- using the new makeobj, the problems with topspeeds etc seem to be entirely fixed. :)
Excellent!
A quick query, if I may: what .dat file parameter should I use to indicate that a platform can be built underground?
allow_underground=1
Thanks!
I'm finding that platforms compiled with the "allow_underground=1" tag are not visible in the "railway tools" window in-game. Here's some sample dat code; any idea what I might be doing wrong?
obj=building
name=wa-platform-2
Type=stop
waytype=track
copyright=wa
NoInfo=1
Dims=1,1,16
enables_pax=1
Level=3
allow_underground=1
cursor=platform-2.4.1
icon=> platform-2.4.0
BackImage[0][0][0][0][0]=platform-2.0.0
BackImage[1][0][0][0][0]=platform-2.0.1
BackImage[2][0][0][0][0]=platform-2.1.0
BackImage[3][0][0][0][0]=platform-2.1.1
BackImage[4][0][0][0][0]=platform-2.2.0
BackImage[5][0][0][0][0]=platform-2.2.1
BackImage[6][0][0][0][0]=platform-2.3.0
BackImage[7][0][0][0][0]=platform-2.3.1
FrontImage[8][0][0][0][0]=platform-2.0.2
FrontImage[9][0][0][0][0]=platform-2.0.3
FrontImage[10][0][0][0][0]=platform-2.1.2
FrontImage[11][0][0][0][0]=platform-2.1.3
FrontImage[12][0][0][0][0]=platform-2.2.2
FrontImage[13][0][0][0][0]=platform-2.2.3
FrontImage[14][0][0][0][0]=platform-2.3.2
FrontImage[15][0][0][0][0]=platform-2.3.3
They should be visible in underground mode - have you tried this?
Ah, I see the problem -- they are visible in underground mode, but not in *sliced* underground mode -- and I had only so far looked at the latter. It would be good to be able to view them in sliced mode too, however, since sometimes the underground tracks one is looking for are hiding underneath other tracks.
Hmm - I shall have to look into this. Thank you for spotting that!
I have pushed a fix for this to my -devel branch: feedback would be appreciated!
That seems to fix it -- thanks!
A quick small query/request that didn't seem worth its own topic.
In the advanced settings menu, in the Experimental=>Passengers tab, the "min dist tiles" value for long distance passengers appears to have a maximum value of 1000. On large maps, however, it's plausible that one might want to set this value higher than 1000 tiles. Would it be possible for the limit on this value to be raised? (I know this can be set higher in simuconf.tab, but that doesn't help if one wants to raise the value above 1000 in an existing save).
Would 4096 be enough?
Yes, that should be plenty! Many thanks.
Splendid. Will change...
convoy 116 serving line 59 - is waiting to load passengers in leeds - even though the station is full. once the waiting time finishes - he will load the pax full and go.
http://host03.pipebytes.com/get.php?key=103158100399867
Convoys using the "convoy spacing" feature will not load until 10 minutes before their scheduled departure time. If you find that the station is full before that, the best course of action is to increase the frequency of service - or just turn off convoy spacing and set the vehicle to leave when 100% full.
cool, thanks!
can the line management window be widened a bit?
the graphs have a problem with displaying numbers over 3 digits at the sides.
it's hard to tell between $50,000.00 and $5000.00, since only 000.00 will be displayed
Quote from: carlbaker on October 15, 2012, 07:47:08 PM
Convoys using the "convoy spacing" feature will not load until 10 minutes before their scheduled departure time. If you find that the station is full before that, the best course of action is to increase the frequency of service - or just turn off convoy spacing and set the vehicle to leave when 100% full.
In previous versions, the convoy would fill (to the minimum load specified) and leave early if enough pax were loading. It seems that now there's nothing tying minimum load and spacing, you rather have to choose whether to space by schedule or load, but without a combination of both much micro is involved.
I thought the reason 400% was given there was to force the convoy to waiting even if it fills. it would be better to have a chance for early departure in such a case, no? convoy spacing is very important in low pax stops, since you don't wanna lose too much money, but you wanna keep the waiting time reasonable. If the station becomes full (a train just arrived for instance), it could be good to get a move on automatically and not wait while the station is full. Then again, IRL we have schedules that are kept, and pax can only wish loads are considered.
Hi asaphxiix,
The thinking behind the new feature is as follows. If pax board vehicles too early, they may miss the opportunity to board a different service which leaves sooner. So a passenger might board a service which doesn't leave for another half-hour, even though there will be a different service to their destination which arrives and leaves sooner. In my experience, things can get somewhat messed up if pax are allowed to board whenever they like, and not allowing them to board until 10 minutes before departure avoids this for the most part.
What's more, I'm tempted to think that the cases where the station fills up early can often be avoided by tailoring the service to the level of demand. Also, don't forget about "max wait for load", which -- in conjunction with a minimum load of 100% -- behaves almost exactly as you describe.
That said, it has already been agreed that this new feature should be made optional on a per-line basis. (Some people like it, some people don't, and there's no reason to alienate one or the other group. People play in different ways, after all.) So we're hoping to introduce a tickbox that would turn it off for a particular line. However, I'm not at all sure that I have the capability to code this, as I had previously suggested... will look into it again soon.
Hello James
I have seen that ras52 has published fix on his sim-ex repository (branch city-population and devel branch) but are not included in your release candidate.
Giuseppe
Hmm - I have merged all of Richard's work on the -devel branch (the latest being a fix for the display of prices in the depot and replacer windows, which I have merged just now). There is work that Richard has done on his city-population branch, but I have not merged that, as that work needs to be incorporated into a wider review of the relationship between city sizes and passenger numbers before being incorporated, which will need to be done after the next release, as this will be a significant new feature.
Hello
The purchase price of the aircraft are very low.
Edit: updating text and config files and building the last github 0.8.4 version prices appear as (null), updating text and config files and using your 0.8.4 prices simutrans crash.
Giuseppe
This was a problem in older versions, now fixed in the latest development versions. Apologies that I have not had the time lately to finish work on 0.9, but I shall prepare it when I have an opportunity.
Hello James
I compiled myself the last exp -devl version and I built myself pak brit exp -master.
I think there is another problem (follow the blue arrow). The cost i not correct, the cost continues to change over time (if I leave the mouse pointing is constantly changing and very fast).
The red arrow indicates a text that seems to be wrong ... is a translation problem?
The text shown in the ellipses are not translatable in simutranslator.
Giuseppe
Giuseppe,
hmm - I can't reproduce the issue with the cost, I'm afraid. It's rather odd: I get 50,000c for that aircraft in the development version of Pak128.Britain-Ex 0.9.0. Are you sure that you are compiling yours with the -devel branch's version of Makeobj?
As to the translation texts: LOCO_CAP should already be translatable, as ought "Pulls:" (although I have re-added the latter to the list to be uploaded). I have now added the new texts to be translated for the next version to Simutranslator to enable translators to prepare translation texts for the next version. I hope that this helps!
Hello James
I'm unable to compile the makeobj. I used a makeobj dated 28/07/2012, Probably is not a compatible version.
Giuseppe
Ahh, that is the problem, I think.
Quote from: Milko on October 26, 2012, 07:13:42 AM
Hello James
I'm unable to compile the makeobj. I used a makeobj dated 28/07/2012, Probably is not a compatible version.
Giuseppe
Here is a recently compiled version of makeobj which should be compatible: https://dl.dropbox.com/u/61716/Makeobj-new.exe
(James -- I hope you don't mind me posting this!)
Not at all - anything to help the testing process. I am not entitled to object in any event, as this is all open source.
I do hope to be able formally to release the next version soon, but I need a substantial block of time in which to do so.
Hello
Using carlbaker's makeobj the problem is solved! :)
Thank's
Giuseppe
Hello
The cost problem is a translation problem:
http://forum.simutrans.com/index.php?topic=10705.msg103086#msg103086 (http://forum.simutrans.com/index.php?topic=10705.msg103086#msg103086)
Giuseppe
Please note that there has now been an official release of version 10.12, and those using the release candidate builds are encouraged to upgrade.
Congratulations! This has been a very major release!
I second this -- many thanks to James (and Bernd, too!) for their hard work in making this big step forward possible.
Thank you; thank you also to all of those who have helped with it, both testing and coding - it is much appreciated.
Excellent work!
It's pretty easy to see how much work was put into it by the sheer size of the fixes/changes list