The International Simutrans Forum

Thought I'd start a new topic for these as people find them. Here are three to be going on with.


1. Loading some saves from 10.x versions yields errors like the following:

FATAL ERROR: loadsave_t::rdwr_str()
string longer (25959) than allowed size (1024)

I suspect this is related to the fact that the maps in question are large.


2. Loading some perfectly ordinary savegames leads to a freeze (i.e. Simutrans not responding).


3. The bug discussed here (http://forum.simutrans.com/index.php?topic=9186.msg87646#msg87646) (reported fixed on that thread) persists in its original form.


Would you like examples of (1) and (2)?

Examples would be helpful - thank you.

Here goes:

For a save which suffers fatal errors of the type described in (1), see here:
http://dl.dropbox.com/u/61716/screenshots2.sve (http://dl.dropbox.com/u/61716/screenshots2.sve) (doesn't matter what pakset you load in, the error will occur).

(The file that omikron previously uploaded exhibits the same bug, too:
http://dl.dropbox.com/u/61716/Sebrim_4_-_1912b.sve (http://dl.dropbox.com/u/61716/Sebrim_4_-_1912b.sve) )

I now doubt that this is related to map size, since some earlier large maps load fine.



For a save which merely hangs on loading, and never resolves (bug 2), see this old version of the network save:
http://www.2shared.com/file/sOHwOz7z/client1-network.html (http://www.2shared.com/file/sOHwOz7z/client1-network.html)
(apologies for the download site -- it's a big file).

As for the braking physics bug, the thread linked above has lots of discussions and examples.

Hmm - error (1) seems to affect most games with an Experimental save game version number of 10. I have not yet tracked the cause, as debugging load/save issues is tricky, but I note that it appears very early in the loading process.

As to (2) do you mean that it hangs at the beginning of the loading process? That is what I seem to get. If so, I suspect that it is related to (1). Will investigate further...

Update: I have found and fixed this on the -devel branch - I should be very grateful for any re-testing. I also think that I have tracked down the uninitialised variable in the braking physics code - I should be very grateful for any testing of that, too.

On first glance it appears that the load/save issue and the braking physics issue reported above are fixed. Thanks James. Later today I'll be able to do some meaningful testing on the workings of the new braking physics and waiting times features.


One initial report: it seems that trains always display an orange "warning" status in the convoy window (underneath the mini-picture) -- the kind that would normally be reserved for when they can't find a route.

Here's an issue with the braking physics: the braking distances one witnesses are substantially longer than those calculated and displayed in the depot.

Here are two savegame examples, identical but for the "meters per tile" setting. (I was investigating whether the behaviour was sensitive to this value, but it appears to arise equally in both cases)

http://dl.dropbox.com/u/61716/brakingtest250.sve (http://dl.dropbox.com/u/61716/brakingtest250.sve)
http://dl.dropbox.com/u/61716/brakingtest400.sve (http://dl.dropbox.com/u/61716/brakingtest400.sve)


In each of these saves, there is one convoy whose the advertised braking distance from full speed is about 3km (which seems about right). But you can witness each convoy braking at around 5km or 6km before the station. Even when not at full speed, braking commences well before 3km.


(I also noticed some teleporting when I first started the convoy in the first save -- but I'm not sure if that persists.)

Carl,

thank you for testing. I have e-mailed Bernd Gabriel and asked him to look into this issue. In the meantime, may I ask what pakset that you are using here?

Thanks, James. Those are pak128.Britain-ex saves -- sorry, I forgot to mention that.

------

Edit: I've also noticed that trains are reserving a lot more track ahead of their current position than they used to. Is this intended?

For instance, this image shows a train reserving a path through four whole signal blocks -- around 10km of track in total, which seems over the top. This is typical behaviour in the latest version -- reservations are up to 25km in some cases.

(http://dl.dropbox.com/u/61716/reserve.jpg)

The reservations are based on the stopping distance - the longer that the train takes to stop, the greater the reservation will be, as, if the train cannot reserve through to its furthest stopping point at any given speed, it will have to slow down so that it can stop in time if the signal beyond which it cannot reserve remains at danger.

I do plan to add some more sophistication to signalling at some point (with proper distant signals and multiple aspect signalling having their real life effect), but this is a worthwhile compromise in between.

That feature makes perfect sense. However, it's clearly not quite functioning properly as can be seen above -- in order to reserve its stopping distance, the train would only need to reserve one or two signal blocks, not a whole 10 kilometers worth of track. In almost every case trains are reserving far more distance than they need. As I reported above, in one case I noticed a reservation of 25km.

Hmm. I shall have to look into that when I get a chance.

Hi,

as to the too early braking convoys:

the math seems to be correct, but there are different scales for the economic model (which is set by meters per tile) and the physical model, which is based on simutrans standard yards and steps. It is closer to the convoys scale and thus distances are larger than in the economic scale. For more reasonable movement according to economic scale, the physical scale is scaled up and down with the economic scale. In the standard economic scale of 1 km per tile you won't like a 6 tile / 12 waggon highspeed train to start braking at the first station tile (= 6 km before the actual stop).

But on the other hand, in a 50 m per tile economic scale (which is about the vehicle/physics scale) a fixed relation to the economic scale of about 4 (the current factor) is strange, too. Should we use an adaptive scale between at least 1 at 50m/tile to the current about 4 at 1 km/tile (and still growing for even larger scales)? What do you think?

BTW: both savegames use the same simtime factor of 0.25, which is meters per tile / 1000.

Bernd,

thank you very much for replying: that is helpful. I think that we need to make the physical model follow the economic model for economic reasons: the purpose of simulating the physics is their economic significance; so, if, in reality, a train would take, say, 2km to brake from a certain speed, that should be the distance that it takes in the game, too; and the same should apply to acceleration. Anything else would, I think, skew the otherwise carefully calibrated time/distance/speed/power/brake force/cost ratios that we are aiming for.

Thank you very much for your work on this!

I'm a little confused -- is the upshot of your exchange that long braking distances are desired, or that the braking distances will be reduced to be in line with what's displayed in the depot?

Quote from: Bernd Gabriel on April 12, 2012, 08:59:05 PM
BTW: both savegames use the same simtime factor of 0.25, which is meters per tile / 1000.

That's strange -- the map scale displayed in the minimap is different, indicating that meters-per-tile has been set differently.



By the way: there's definitely a teleporting bug here, too. Load the 250.sve file and watch the train as it arrives at the first station. Upon leaving it simply teleports to the second station.

I had thought that the physics was designed to use the distance per tile scale; it seems that it does not currently do that (at least for braking), but it should be made to do that in order to be economically accurate.

As to the teleporting, I think that this might be physics related, too; Bernd - can you investigate? Thank you!

I just committed a fix for the missing simtime_factor update after loading a savegame.

I could not see the teleporting, but I will try it again...

I will adjust the distance calculation to a constant 1:1 relation to the meters_per_tile ...

Bernd,

thank you very much for your work - that is most helpful. Do let me know when you have finished the meters per tile adjustment. Thank you again for all your hard work on this - it is much appreciated.

I committed the physics using the meters_per_tile figure to my new branch "devel" where braking starts at the expected locations now.

As I had no idea yet how to decouple location scale from speed scale convoy speed depends on meters_per_tile as well, which is awfully slow at 1km/tile.

Bernd,

thank you for working on this. However, I do not really understand what you mean in the last paragraph, and I thought that the way in which speed/distance/time/scale worked had been clarified before.

The actual speed of vehicles in the game should be constant no matter what the distance scale. As the distance scale increases, the time scale correspondingly decreases. So, suppose that a particular convoy going at a particular speed will always take one real life second to traverse one tile. An increase of the distance scale (from, say, 250m/tile to 500m/tile) would mean that the convoy will still take one real life second to traverse the tile, but the amount of game time that passes in one second of real time would be doubled to compensate. Likewise, if the distance scale were reduced to 125m/tile from 250m/tile, the amount of game time passing in any given real life second would halve to compensate, but the convoy  would still take 1 real life second to traverse that tile at that speed.

This means that, at a distance scale of 500m/tile, the convoy would take half the number of real life seconds and half the number of tiles to accelerate to any given speed as it would at 250m/tile, but would take the same number of game seconds and the same number of game meters. Likewise, at a distance scale of 125m/tile, a convoy would take twice the number of real life seconds and twice the number of tiles to reach any given speed as it would at 250m/tile, but, again, the same number of game seconds and game meters. Indeed, I thought that this was what already had been implemented for acceleration - had we not discussed this before?

Braking should work in the same way: at 500m/tile, a convoy should take half as many real life seconds and half as many tiles to come to a halt from any given speed as it would at 250m/tile, and at 125m/tile the convoy should take twice as many real life seconds and twice as many tiles to stop as at 250m/tile, but, in each case, the same number of game meters and the same number of game seconds.

This is all an integral part of how the scale system works in Experimental, and it is quite fundamental to the balance. If you are not able to find a way of making the physics work in this way, I should be very grateful if you could let me know where in the physics code that you deal with the scale so that I can try to implement this myself.

Thank you again for your hard work on this.

Ok, my brain seems to be back to normal at last ;)
I committed the fix.

settings_t now offers a ticks_to_seconds() conversion and since last commit steps_to_meters() and meters_to_steps() conversions.
The conversion factors are updated in set_simtime_factor().

Splendid - thank you very much! I will test that when I get a chance.

Let me know when this is updated to -devel and I'll be happy to do some more testing.

Bernd,

I have now had a chance to look at this briefly, and it seems to affect acceleration as well as braking. Was that intended? I remember testing previously and finding that acceleration was correct as it was before. I have pushed the changes for now so that all can test, but this will need careful consideration.

The braking distances now seem to be in line with what's shown in the depot -- and acceleration does not seem excessive (though I'm not sure how to tell if it's too great -- I'll look at this a bit more closely later). Thanks Bernd!


However, I get perpetual teleporting on the following (pak128.britain) map:

http://dl.dropbox.com/u/61716/brakingtest400.sve (http://dl.dropbox.com/u/61716/brakingtest400.sve)

After the convoy in this map reverses at the eastern end of the line, it reliably teleports, one station at a time, back to the western end of the line. Can others reproduce this with this test map?


Note also that convoys still permanently display the orange "warning" status.

In addition to the above, a confirmation that the signalling reservation bug reported further above is still present. Here's another example with a further twist:

(http://dl.dropbox.com/u/61716/reserve2.jpg)

Not only is the train making these reservations still 40km away from the station pictured, it has even reserved through a choose signal (circled) and thereby blocked the throat of the whole station until it arrives. Nothing can even leave northbound until it arrives. As you can imagine, this can cause chaos at busy junctions!

I have now fixed the issue with the status colour. I shall have to look into the block reservation thing.

Bernd - what is the position with the acceleration? Was it not correct before? Also, can you check whether the teleporting is a physics issue?

Carl - thank you for testing.

I have now fixed the block reservation issue.

Excellent, thanks -- I shall test some more tomorrow.

I've made a test run, which led to the following observations:

1) Building the executable from your devel branch and using the exact same settings as before (i.e. just replacing Simutrans-Experimental.exe in the Windows Complete package), the map builder always creates absolutely gigantic cities (but take note that I'm comparing the released binaries with the devel branch so I could be missing something in between):

before:
(http://i.imgur.com/Lt3gm.png)

after:
(http://i.imgur.com/d1W9I.png)

2) There is a new crash bug which occurs at the beginning of a new month. When I started a new game with the devel executable, the crash occured after exactly one year and one month had passed, i.e. on the change from January 1901 to February 1901. Since I have autosave set to yearly, I tried to start with the autosave from the beginning of 1901, but what happens is that it crashes while loading that savegame.

That made me a little curious, because what I had tried at first was to continue my old 10.11 savegame with the new executable, which had seemed to work fine until I experienced the new month crash there too. I had blamed that on the savegame change format you announced in the commit, but after I experienced the crash with a new game too, I realized that the crash with my old game had also happened after saving before. As long as I don't save (manually or autosave), the old game will run on the new executable seemingly forever without crashes. As soon as I save, the game will crash at the beginning of the next month. So this is most likely related to the saving function.

Here's the seemingly corrupt autosave I mentioned above: http://simutrans-germany.com/files/upload/autosave01.crashes.sve

3) The physics code is somehow broken: the increase of friction when going uphill is delayed by at least one tile now, e.g. a road vehicle will go up a single sloped tile (literally the slope itself, not even the tile before it where friction used to kick in already) without friction/slowing down, but instead it will be slowed down on the next two flat tiles behind (before it was only the next one tile).

Quote from: jamespetts on April 21, 2012, 09:36:24 PM
I have now fixed the block reservation issue.

Testing confirms that this is fixed -- Thanks James! :-)

--
On acceleration:

I set out to test acceleration speeds empirically in Pak128.Britain-Ex (results later -- so far, they seem sensible) but came upon a few bugs which don't appear to be pakset-related. They do not occur in 10.11.

The class 142 Pacer in 4-car formation is unable to reach top speed, maxes out at 68kph after 600m. But in-depot this formation is said to be capable of 114kph.

What's more, Pacers are for some reason unable to run in 2-car formation -- that is, the depot displays a max speed of 0kph for a 2-car pacer.

Indeed, Classes 158, 166 and 180 appear to be unable to run in *any* formation.

--

One more unrelated bug. Min/max loading times currently seem to vary with the meters-per-tile parameter. At 300m, the Class 221's min/max figures are 0:42 - 4:48. But at 100m, the same train's figures are just 0:14 - 1:36. I don't think this variation is intended.

Thank you both for your reports.

Bernd - would you mind looking into the physics related issues? I'll have a look at the month end/saving crash.

As for the city sizes - this is related to Richard Smith's pareto distribution patch. I mentioned this to him when I found it, but he hasn't replied, and I haven't seen him around for a few months. I shall have to look into this, but this will take a long time, because I did not write the code myself.

As to the year and a month crash, I am afraid that I am having some difficulty in tracking this down: see the topic that I have posted here (http://forum.simutrans.com/index.php?topic=9806.new#new) asking for help.

James, since that crash bug turned out to be so difficult to track down, I made some more experiments and found this:

1) I must partly withdraw my statements about manually saving the game triggering the crash - I could not reproduce this starting a new game with the devel executable consistently, only playing on an old 10.11 savegame causes it to happen for sure. But still, most of the time manual saving will cause the crash at the end of the current month even with a newly started game.
2) The "one year and one month" symptom seemed to point to autosaving, and I could indeed prevent the crash entirely by setting the autosave interval to 0.
3) The most interesting thing however is that even with autosave after 12 months on (or saving manually), it will not ever crash on a map with 0 cities. I guess this strongly points into the direction of the new private car or city placement code.

On acceleration:

With the default figures:
- global power factory = 100%,
- BR_TRACK = 1/2,
- and Pak128.Britain.Exp 0.8.3
I'm getting a maximum speed of 102 km/h for a Class 142 couple.

Class 142 has very weak engines. Thus a 4-car convoy can run significantly faster than a 2-car convoy.
While all cars are motored and add power, only the first car is faced to the air resistance.

Thanks, Bernd. Can you reproduce the problem whereby some trains (158, 166, 180) display a max speed in depot of 0kph no matter what formation you put them in?

These are my results:
158/166: 1-car: 97 km/h; 3-car: 139 km/h; >= 4-car: 145 km/h
180: 1-car: 142 km/h; 2-car: 178 km/h; >= 3-car: 200 km/h

Ok, I'll check that my results aren't being affected by deviant base-settings.

Quote from: Bernd Gabriel on April 26, 2012, 07:47:47 PM
On acceleration:

With the default figures:
- global power factory = 100%,
- BR_TRACK = 1/2,
- and Pak128.Britain.Exp 0.8.3
I'm getting a maximum speed of 102 km/h for a Class 142 couple.

Class 142 has very weak engines. Thus a 4-car convoy can run significantly faster than a 2-car convoy.
While all cars are motored and add power, only the first car is faced to the air resistance.

Interesting. I have increased the power of these units for the next release of Pak128.Britain-Ex to 168kw/each, which represents the power of the engines with which they were fitted later in life. Does this result perhaps suggest, however, that the air resistance is a tad too high?

Using a release version compiled from the -devel branch, here's what I get for the equivalent of Bernd's image:

(http://dl.dropbox.com/u/61716/pacer.jpg)

There must be a discrepancy here, somewhere...is anybody else able to test this against the -devel branch?

Hmm - that's very odd. The results that I get are the same as Bernd's, both for Pak128.Britain-Ex 0.8.3 and 0.8.4 (as on the current Github branch). Are you using Linux or Windows?

More generally as to DMU physics, I note that the tractive effort values are not set manually, leading to very low calculated values. I wonder whether this is giving them unrealistically low performance?

I'm on Windows 7 64-bit. Given that you're getting the same results as Bernd, I'll re-compile and re-test some more.

Quote from: carlbaker on April 28, 2012, 01:41:57 PM
I'm on Windows 7 64-bit. Given that you're getting the same results as Bernd, I'll re-compile and re-test some more.

Hmm - so am I. Very odd.

Carl's image shows, that we are using different Class 142 cars. My "front" car has a different name and costs 10 times of Carl's. Other invisible figures might vary as well.

Hmm. Carl - which version of Pak128.Britain are you using?

I'm certain I had 0.8.3 already, but having re-downloaded the latest version, the problem goes away and now I get identical results to Bernd. How strange! I must have had 0.8.3 since otherwise I wouldn't have been able to access the server game...

Sorry for wasting your time on this!  :-X

Don't worry - thank you for the work!

Quote from: HeinBloed on April 23, 2012, 11:38:02 AM
James, since that crash bug turned out to be so difficult to track down, I made some more experiments and found this:

1) I must partly withdraw my statements about manually saving the game triggering the crash - I could not reproduce this starting a new game with the devel executable consistently, only playing on an old 10.11 savegame causes it to happen for sure. But still, most of the time manual saving will cause the crash at the end of the current month even with a newly started game.
2) The "one year and one month" symptom seemed to point to autosaving, and I could indeed prevent the crash entirely by setting the autosave interval to 0.
3) The most interesting thing however is that even with autosave after 12 months on (or saving manually), it will not ever crash on a map with 0 cities. I guess this strongly points into the direction of the new private car or city placement code.

Hein,

can you try again to recreate this from scratch using the latest -devel branch? I can now only recreate this on games saved with an earlier version (although I have not tested extensively, as it takes a while to run through a year and a month).

James,

I think you didn't change any relevant files on the repository yet ...? I tried it quickly anyway and could reproduce all three points again. As a small "bonus", I could crash the game with cities (and cars) and with autosave turned OFF after it had safely passed the change of January->February one year in by manually saving during February (crashed at the end of February then).

By the way, you can start several instances in parallel without problems as long as there's not much going on, CPU usage hovers well below 5% for each of them.

So having testing the older -devel version: the crash seems to occur not after thirteen months, but rather always at the end of January. Upon running some older saves I received regular end of January crashes regardless of the load date.

I think that I have managed to fix this now (although have still not discovered the cause - it is fixed by means of a workaround). Can people re-test? Thank you for all the testing!

James,

a quick late-night feedback (just came back from the cinema): I was daring and loaded my current 10.11 game, fast-forwarded and saved several times, let autosave happen, no crashes. I could test with new games tomorrow, but I guess it's likely enough that this problem is gone now. :) There are virtually no more city cars though, and maybe those very few I'm seeing now are even still left from the savegame. I don't remember, didn't you disable them entirely ...?

However, there's another problem which would prevent playing on this game for now, which must be related to the new city placement code (which should still be fixed too before a new release): whereas before new industry chains seemed to appear relatively rarely, there is now a real industry chain founding spree happening. In fact, it seems that there's exactly one new chain created each month.

The crash bug appears to be fixed. Thanks, James.

Thank you both for your reports! Hein - would you mind uploading the saved game that you used to enable further testing?

First, I must admit that I'm very uncertain about the amount of city cars appearing. It could be that it's lower, but I'm not (yet) sure of that. But my former statement that they were almost completely gone is wrong. Looking at the traffic in my biggest city with the 10.11 executable, I realized that even there private traffic is very low already, due to the good coverage I guess.

I found an old bug though which either reappeared or hadn't been fixed properly in the first place, which is the circular route travelling time bug. I observed it playing the continued 10.11 game with the devel executable first, so I started a new game and could verify that it exists there too. The mass industry chain problem also exists in the new game.

old 10.11 game continued on devel 10.12: http://simutrans-germany.com/files/upload/10_11_continued.sve (http://simutrans-germany.com/files/upload/10_11_continued.sve)
new devel 10.12 game: http://simutrans-germany.com/files/upload/circular_broken_again.sve (http://simutrans-germany.com/files/upload/circular_broken_again.sve)

Hein,

I think that I have managed to fix the residual issues affecting the circular routes (in fact, I think that it was a related bug in which the table of departures was not cleared when the schedule changed), and the factory issues. I can't reproduce any difficulty with the city cars, of which there seem to be plentiful numbers (they take one month after the game starts to appear, however; this is normal).

James,

I'm afraid it's still not really fixed.  :-[ And what makes it more difficult now is that what I'm observing is quite inconsistent.

Using the old 10.11 savegame and fast-forwarding for some time, the travelling times did change gradually. But when they stabilized, there was a weird skew into one direction, as illustrated on this screenshot:

(http://i.imgur.com/Q3CUG.png)

Those 3 stops are in sequence of a circular line. As you can see, the travelling times between adjacent stations seem to be about twice as long in one direction than in the other direction. Also compare the travelling times Greencrocer Stop<->Corporation Street Stop, which I forgot to highlight, showing the same skew, although it's not twice as long there. The ground is all flat there and I can't think of any reason why the time should differ so much in the two directions, as there are also only few city cars and the convoys definitely take the same route. In fact, I observed the same pattern in the other circular lines too. Since the convoys are all horse carriages at 18km/h, the shorter of the two times seem to be pretty much the accurate real time (also verified that by just watching live).

So I started a new game again to see if this could be reproduced. However, at first there were no problems at all, travelling times were accurate in both directions:

(http://i.imgur.com/RdG2h.png)
(forgot to include adjacent stations in that screenshot, but the times were consistent)

I played around with that line a little then, adding new stops to it and removing other stops. I can't say what triggered it, but I noticed some time later that times were going astray again, although this time not with that skew but the old problem of same times to all the stops (change over a few months):

(http://i.imgur.com/kFd6N.png)

(http://i.imgur.com/JSJfX.png)

(http://i.imgur.com/ja73A.png)

Since I had let it run for a few years untouched before and this happened after I had added/removed stops (and convoys too), my guess on the cause is on that.


Edit:
Oh, and two more things I noticed: rotating a large map takes (much) longer than before, and the "over capacity" special filter in the stop list isn't working anymore. I didn't test any of this with Standard yet though.

Hein,

thank you for re-testing. I have just pushed a fix, which should help, although you will need to change the schedule on an affected game for the changes to work properly. As for the skew in directions, because each direction in a circular line is now treated as a separate line for timing purposes, local conditions can cause results to be inconsistent depending on the direction. Are you able to eliminate that as a cause here? It may be better to use a fresh game to make sure that no residuaries of the original problem remain first.

James,

this fix seems to cure the problem for a new game, thank you! :)

Since I don't want to stop my old game just yet, I re-tested with that too. This time, I let it run in fast-forward for over 10 years and found something interesting: while the said skew was there at the beginning, it became gradually smaller over time. At first, the longer time was dropping quite rapidly, later that decline almost came to a standstill when the difference was only like 5% - which for some of the short trips between adjacent inner-city stations could be perfectly accurate due to the slightly different route, i.e. turning left vs. turning right, 1-2 more tiles to move etc.

So my question now is how travelling times are calculated and stored, especially for how long? Since the behaviour I observed could be perfectly explained by some averaging/weighting happening with historic data which delays the convergence of those times (on an old line) for so long.  And if that is a generic phenomenon, new games might become affected too.


There may still be another minor problem with city cars though, as I already suspected before: compare those screenshots of the city traffic one month after starting the game (as you pointed out, cars started appearing from there) and two other screenshots some years later:
(http://i.imgur.com/haXU0.jpg)

(http://i.imgur.com/LfRO2.jpg)
(http://i.imgur.com/2aP9T.jpg)

The high traffic density of the beginning must have remained for about 3 years or so before it dropped, I didn't check the running game often enough to tell for sure. But it never went fully back up again after.

I'll check tonight or tomorrow with the latest Standard nightlies for the non-working filter and the slow map rotation. Other than that, there's still the "giant city" problem. By the way, did you ever consider using some sort of bug tracking software to keep an overview? Could be handy. ;)

Thank you for retesting - that is helpful! To understand how the travelling times are stored, see references to "departures" in simconvoi.cc.

As to the traffic, could the effect be due to reported congestion? Have a look in the city graphs. Try starting a game with congestion_density_factor=0 - I have noticed that the congestion values seem to be poorly calibrated at present.

Edit: I have recalibrated the congestion slightly, and it seems to work a little better now.

James,

I compiled a list of open bugs which should be fixed for the next release. That's why I was suggesting some sort of bug tracking. ;) The list probably isn't complete, those are mostly bugs I've encountered while playing an actual game.


1. City creation code broken (not in 10.11)
The bug reported here: http://forum.simutrans.com/index.php?topic=9709.msg92641#msg92641 (http://forum.simutrans.com/index.php?topic=9709.msg92641#msg92641)

2. Map rotation speed heavily degraded (not in 10.11)
As mentioned here: http://forum.simutrans.com/index.php?topic=9709.msg93075#msg93075 (http://forum.simutrans.com/index.php?topic=9709.msg93075#msg93075), map rotation speed is much worse than in 10.11. I verified this by comparing Standard 111.1 and 111.2.1/111.2.2 and even the latest nightly. Speed was constant throughout and at about 3-4 seconds for a 2048x2048 map with 256 cities still acceptable.

To have an objective measurement with the devel executable (cf. the giant city bug above), I created a 2048x2048 map with 256 cities in 10.11, which I saved and used for the devel executable too. Rotating the map in 10.11 took about 1.5-2 seconds for every single rotation, regardless of the number of rotations, even if rotated constantly for some time. With the devel executable, it was noticeably slower to start with at around 3-4 seconds, but it became really bad when I kept rotating the map some more times. Time went up to 6 or 8 seconds at first, sometimes a little faster again in between, and eventually it took more than 15 seconds. It didn't play a role if I kept rotating constantly or let it rest for some time again in between (on a side note; looking at the display settings window, I noticed that after every rotation, there seems to be a re-run of some routing algorithms, why is that? That doesn't seem to be specific to Experimental though).

So to sum it up, the base speed is already somewhat slower, but most of all it gets a lot slower still when rotating multiple times.

The broken station list filter I mentioned in that post is broken in Standard since 111.2.1 too (111.1 still fine), going to report it there.

3. Foot routing link doesn't get removed
The bug reported here: http://forum.simutrans.com/index.php?topic=9678.msg90835#msg90835 (http://forum.simutrans.com/index.php?topic=9678.msg90835#msg90835)

4. Convoy replacing doesn't respect convoy constraints
The bug reported here: http://forum.simutrans.com/index.php?topic=9752.msg91924#msg91924 (http://forum.simutrans.com/index.php?topic=9752.msg91924#msg91924)

5. Too high production when building industries
The bug reported here: http://forum.simutrans.com/index.php?topic=5694.msg92186#msg92186 (http://forum.simutrans.com/index.php?topic=5694.msg92186#msg92186)

6. Slope physics broken (not in 10.11)
As mentioned here: http://forum.simutrans.com/index.php?topic=9709.msg92641#msg92641 (http://forum.simutrans.com/index.php?topic=9709.msg92641#msg92641), the increase of friction for vehicles going uphill is delayed by 2 tiles. Conversely, when going downhill, reaching negative friction is also delayed by two tiles. I verified that this happens for road and train vehicles.

7. Double Deck Closed-top Tram going insane speed (not in 10.11)
I've uploaded a save game here: http://simutrans-germany.com/files/upload/tram_going_crazy.sve (http://simutrans-germany.com/files/upload/tram_going_crazy.sve), which shows quite a curious bug. The speed display of the (only) Double Deck Closed-top Tram is jumping around very rapidly, while the actual speed still seems to be more or less correct at 50km/h. But if you increase the game speed to 1.5 (which was my normal setting, having started in 1900 and running lots of horse carriages ...), that jumping speed display goes even more nuts and it's showing a three-digit value too. And in fact, the tram also clearly goes a lot faster indeed. This has to be some physics problem too (possibly in conjunction with a Pakset problem since it's the only tram existing at that point in time with which it happens) as I didn't make any changes to the Pak128.Britain-exp 0.8.3, just exchanged the executables.

8. Industry/city connected substation doesn't get reset
I've obverved a pretty peculiar bug which I couldn't preserve in a save game: there's an industry at the outskirts of a city, which I could supply with power through the city substation. Some time later I noticed that for some reason, power supply for that industry had gone. Clicking on it, I realized that it must have fallen just outside of the city limits as the indication "City: xxx" had gone (as far as I know, city limits can indeed shrink sometimes). But I wasn't allowed to build a substation next to that industry now due to "Each industry may have only one attached substation." My guess is that the former connection to the city substation wasn't deleted. The reason I couldn't preserve it in a save game is because apparently all the city affiliations of industries are reset when loading a saved game and only re-checked again at the end of the month, so this could serve as a workaround, but if that bug is easy to fix, that would still be preferable.


And finally, I still have suspicions that the travelling times on circular routes with alternating directions turned on still don't behave completely correctly, but I didn't get around to testing that more thoroughly yet.

Hein,

thank you very much for your reports. I think that I have fixed nos. 3, 5 and 8 - would you mind re-testing? 6 and 7 are physics issues, and I have asked Bernd to look into these when he has time. I shall have to look further into nos. 1, 2 and 4.

Edit: No. 4 also fixed - please re-test.

Edit 2: No. 2 is a rather tricky one, as I have not knowingly altered anything specific to rotation between 10.x and -devel. Performance related bugs are also very difficult to track down.

Edit 3: No. 1 turns out not to be a bug at all, but an absence of settings. Adding:


max_city_size = 16000
max_small_city_size = 3000


to simuconf.tab seems to solve this.

Hmm, I started with testing for #3 and was faced with a crash.

What I did: build two stops in walking distance, wait until the link is set up, extend one of the stops by adding more station tiles away from the other stop, remove the station tile which is in walking distance, wait a short time again, query tool on one of the stations -> crash. Repeated it, that time it didn't crash and one of the two stops had the link removed immediately (the other a little time after), but instead there was a weird bug with some trains which were only going max. 3km/h (?). Repeated it again, this time it crashed shortly after removing the station tile, without even getting to use the query tool.

I think I could preserve the last one here: http://simutrans-germany.com/files/upload/about_to_crash.sve. Delete the walking distance tile of Ottobrunn Junction Stop -> crash shortly after.

Hein,

thank you for the report. I think that I have fixed this - would you mind re-testing?

I'm afraid it's not fixed - still crashes (inconsistently).

Edit:

#4 and #5 seem to be fixed though.  :) #8 will be hard to reproduce obviously ...

As for #2; I can imagine that this will be difficult to track down. However, I think it's really quite important to do it. Remember, the times I cited were for an undeveloped, newly created map. On my developed 1024x1024 map (i.e. 1/4th the size of the test map), it will easily take well above 10-15 seconds for a single rotation, which makes rotating to quickly get a different perspective on things very unattractive.

As I said, there's apparently a re-run of some routing algorithms happening at every rotation, as witnessed by the status label in the display settings window, so even if there weren't any changes directly related to map rotation, I'd suspect that's what's actually causing it.

Did you actually reproduce it on your system? Just to be sure you can follow me ...

Maybe the profiling environment you set up recently to track down the city car performance problems might be helpful for this.

Can you be more specific as to the circumstances in which the crashes occur?

You should just play around with building station tiles a little, building in walking distance and deleting tiles. As I said, it's inconsistent. When I tried it just now, it happened once before even deleting a tile. The next try, it seemed to be stable for several tries in a row, until I selected "New Map", which led to a crash. Next try, I could build and delete a couple of tiles before it suddenly crashed without any user interaction.

Edit:

I edited my previous post only 2 seconds after you had posted a reply here, please don't overlook the additions I made. ;)

I think that I have managed to fix the crash - would you mind re-testing?

Yes indeed, it's fixed now. Thank you! :)

At the risk of appearing nitpicky, there's a tiny issue left with this now: when you delete a station tile which provides the walking distance link to another station, the direct routes from this station are updated immediately, but those from the other station are only updated at the end of the month. This is in conformance with how I understand your code changes. In an ideal world, the other station would be updated immediately too, which could be realized by using the reference to it in the halt object which has its tile deleted, I suppose. But if that code isn't already there in some form (which seems to be the case), it might not be worth the effort to add that ...

Hmm - an attempt to fix this using a simple approach resulted in a stack overflow, so I might leave this one for the time being. Thank you for all of your reports, though!

I have an addition to bug no. 7 on my list: my trams have gone completely crazy. The faster ones aren't merely moving anymore, but instead they're beaming from station to station.  ;D And it's not limited to running the game at 1.5 speed anymore either. In fact, if I slow the game down to 0.06 speed, it can be seen that the trip to each next station takes exactly one second. Looking at the tram depot, I saw something which I remembered having seen here before, posted by carlbaker: http://forum.simutrans.com/index.php?topic=9709.msg93005#msg93005 (http://forum.simutrans.com/index.php?topic=9709.msg93005#msg93005)

(http://i.imgur.com/IFLBe.png)

(http://i.imgur.com/iqhaD.png)

(http://i.imgur.com/YnbwY.png)

(http://i.imgur.com/QnyKK.png)

The last two are the ones which are running at seemingly infinite speed, the 2nd one "only" accelerates to about 400 km/h, and the first one is the only one that is behaving nicely still ...

The only change I've made I'm aware of, other than having played on for some more time, is to use the new devel executable. New save game is here: http://simutrans-germany.com/files/upload/trams_broken.sve (http://simutrans-germany.com/files/upload/trams_broken.sve)

Hmm, that's very odd indeed: I can't reproduce this one, either with Pak128.Britain-Ex 0.8.3 or the current Github latest (0.8.4). Are you on a Windows or Linux system?

I'm on Windows, using 0.8.3.

And yes, this is odd: I started a new game, and the beaming behaviour was gone, but the Double Deck Closed-top Tram still showed that behaviour of a jumpy speed display and the dependency of speed on the time scale. However, I then saved that game, restarted Simutrans, reloaded the game, and voilà it was beaming again (save game here: http://simutrans-germany.com/files/upload/broken1.sve (http://simutrans-germany.com/files/upload/broken1.sve)). You should witness the same loading my other save game.

Edit:

And I noticed that unfortunately, the recent bug fixes seem to have introduced a new bug: if you changed the time scale to 1.50 for example and do a fast-forward, after turning off fast-forward again the time scale is reset to 1.00.
Nevermind, that was rubbish. I somehow thought the time scale was preserved before.  :-X

Hmm - this really is bizarre: loading broken.sve with my current -devel in debug mode, the tram behaves perfectly. Are you compiling debug or release builds, may I ask?

I'm compiling release builds, retesting everything right now.  ???

Hmm, I've tried a release build, and it worked without difficulty. Try my compiled binary, here (http://simutrans-germany.com/files/upload/Simutrans-Experimental.zip).

Ok, this is completely beyond me. I rebuilt my release binary, resulting in beaming. I ran with your release binary, resulting in beaming. I ran with a newly built debug binary, everything fine! Are you sure you tried it with your release build too?

Aaaah I think I found the culprit: it must be the settings-experimental.xml file! If I delete it before starting the game, everything is fine. If I restart the game then, not deleting it, broken1.sve will show the beaming.

Edit:

To add to the confusion, the presence of settings-experimental-debug.xml before starting the game (i.e. the debug build) doesn't cause it.  :o

Very curious. There must have been some errant setting in there from an earlier version of -devel, I think. Glad that it's fixed now! Does this fully fix no. 7?

Err no, I think you got me wrong there. It's only fixed for the first start of Simutrans if I deleted the xml file before. If I close the game and re-open it so it's using the newly created xml file, the beaming is there again (but only with the release builds!).

Edit:

I forgot to say that while the beaming is absent if the xml file wasn't present before, the speed dependency of said tram on the timescale remains, but only for the release builds; the debug build is always fine

Edit 2:

This is the content of the xml file which is being created by the release build you sent me: http://pastebin.com/K8hv6k0V (http://pastebin.com/K8hv6k0V) Maybe you can find a problem there.

Edit 3:

There's yet another oddity, which might give a hint at the solution though: I noticed the new "Minimum braking distance" display on a convoy window when running my debug build only, both your and my release build don't show it (!)

Very, very odd. I have tried with my release build and your settings-experimental.xml, and still no beaming/teleporting.

Edit: The braking distance display showing only on debug builds is intentional.

Ok, so this remains mysterious.  :-[ I've uploaded my release build here: http://simutrans-germany.com/files/upload/Simutrans-Experimental_Hein.zip (http://simutrans-germany.com/files/upload/Simutrans-Experimental_Hein.zip) I noticed it's 3 KB larger than yours, the latest commit which was included is this one: "FIX: toolbars with only metatools always returned empty icon (from Standard)". But the different code size may be due to other reasons (e.g. Premium VS vs. Express Edition?). If there's anything consistent at all, you'll probably not get the beaming with my executable either.

By the way, I'm on Windows XP 32bit. I remember you were on Windows 7 64bit ... hopefully this is not a case of one of those many warnings during compilation actually turning into something bad (i.e. loss of precision ...).  ;)

Now, this is odd - even with your binary, I get no teleporting. Could it be a pakset difference?

It won't be a loss of precision between different systems: I use Windows 7 64-bit, but compile a 32-bit binary for Windows. Also, floating point variables are not used for any code other than graphics/UI, as it is not network safe to do so.

You followed the procedure I described, right? I.e. delete the xml file once, run the game and close it, run the game again?

I think I should record a video tomorrow, you must be thinking I'm screwing something up here. ;) But seriously, I guess we need other people testing this too. What I've been trying before is to change some of the release build parameters to match the debug build, particularly optimization or the floating-point model ("precise" vs. "fast"), but to no avail. I didn't go about it systematically though, which I could try tomorrow. Have to call it a night now.

Edit: Completely forgot to confirm that I left all the Pak128.Britain-Ex 0.8.3 (config) files untouched from the Windows Complete Binary.

I had not hitherto tried that specific sequence as described, but, when I do, I still cannot reproduce the issue. I don't think that changing the floating point model will make any difference, however, as floating point arithmetic is not used in any critical areas.

James,

I found the cause of it. But what is the reason can only be determined after some code inspection I guess ...

Since Carl had mentioned a Pakset problem when he made that post I cited above, I thought I'd give it a try even though I was certain I had left all the files untouched. I unpacked the content of Simutrans-Experimental-Complete.zip to a new folder, copied your release executable into that and bang, no more teleporting or speeding trams. Needless to say, I tried it with my release executable then with the same result.

So I checked file by file in the whole Simutrans folder hierarchy to see if I could find any difference. And as I had been certain of, none of the Pak files were changed in my old installation folder, which left me even more confused at first. But then I realized that there are exactly two differences in the folder structure: 1) I had a copy of the standard Pak128 in mine and 2) I had an extra file citylist_en.txt in Pak128.Britain-Ex-0.8.3\text.

I copied the Pak128 folder to the new folder structure, and can you guess it? Speeding trams.  :o Then I removed the Pak128 folder in my old folder structure, but trams were still speeding. So I removed it from the new folder structure too, which cured it again. The only difference left was that citylist file. I'm not kidding you, having deleted it (and the Pak128 folder still gone), my old installation didn't show any speeding trams anymore ...

I made some more tests and noticed that if either the Pak128 folder or the cityfile were present, I got speeding trams, and if both were present, I got teleporting (or I guess rather infinite speed) trams. That the presence of the additional Pak folder could cause a problem seems more easy to imagine to me since you get that extra window when starting the game, asking you which Pakset to use. But that the sheer presence of an extra citylist file (which wasn't actually used by me since I only loaded the save games all the time) can cause this is quite awkward. I became a little more curious and tested with the Pak128 folder gone and different contents of the citylist file, and indeed this led to different tram behaviours. E.g. when I copied the content of citylist_dk.txt into citylist_en.txt, the tram was suddenly crawling like a snail instead of speeding. With other content, sometimes it's speeding, teleporting etc.

You should probably at first try to reproduce this.

And yet another update:

even though what I describe above fixed the behaviour for the Double Deck Closed-top Tram, I realized now that there are other trams which are broken instead/still. If you load http://simutrans-germany.com/files/upload/broken4.sve in your clean environment, you should see a speeding tram.

The conclusion is that it's inconsistent throughout and the presence and content of files in the Simutrans folder structure has an effect on it.

Hmm, this is very peculiar. I tried replacing the citylist_en.txt file in my Pak128.Britain-Ex 0.8.3 folder (I usually disable it, as I find that the automatic generation of city names provides more variety if seeded with enough parts), and ran again with both broken1.sve and broken4.sve (release builds), and noticed no difficulties. I had previously tried broken4.sve with both release and debug builds without re-enabling citylist_en.txt, again without difficulties.

I already had in any case a folder structure with a very large number of different paksets, which I use for testing, and always get the pakset selector screen. Bizarely, after all this, I still cannot reproduce the tram problems at all. It is all exceptionally odd. I even tried running Dr. Memory to see whether there were any heap corruption issues, and the only errors that I could find were memory leaks (which would not create odd behaviour, and in any case originated in code unchanged from Standard) and an error from GUI code which people more familiar with these things than I had thought was nothing about which to be concerned, and was not fixable as it was caused by the compiler rather than the code itself. This is extraordinarily odd.

Sigh, this is frustrating indeed.  :-[

Ok, what I tested now should add another piece to the puzzle:

I ran the game on my sister's PC, which uses Win7 64bit. No problems there. Then I ran it inside a Virtual PC VM on my own computer, the OS of which is XP SP3 too like my desktop OS. Gives me the broken trams. Next was a Vista 32bit laptop, all trams going fine there. And finally, I tried it in XP mode (the one that comes with Win7 starting from the Professional edition) on my sister's PC again . Broken trams there again.

So it seems to come down to an XP-specific/compiler settings(?) problem. James, if you happen to have Win7 Professional or better, you might try it for yourself in XP mode.

Other than that, maybe someone else is willing to give it a try on XP? The instructions would be:

1. Get https://github.com/downloads/jamespetts/simutrans-pak128.britain/Simutrans-Experimental-Complete.zip (https://github.com/downloads/jamespetts/simutrans-pak128.britain/Simutrans-Experimental-Complete.zip), unpack into an empty folder
2. Get James' devel release build: http://simutrans-germany.com/files/upload/Simutrans-Experimental.zip (http://simutrans-germany.com/files/upload/Simutrans-Experimental.zip) and unpack the contents into the folder created in step 1, overwriting all the existing files
(3. Run Simutrans-Experimental.exe once to have the settings folders structure created in "My Documents" - only needed if a Simutrans folder there doesn't exist yet)
4. Get this save game: http://simutrans-germany.com/files/upload/broken4.sve (http://simutrans-germany.com/files/upload/broken4.sve), save it into the "save" folder of the Simutrans folder in My Documents
5. Run Simutrans-Experimental.exe, load that save game and see what's happening to the tram. If everything seems to be going fine at first, you should also try with the "Double Deck Open-top Tram", which is usually affected too

Update: made a release build with all the optimization settings turned off, so the options are very similar to a debug build - this is working!

Hello

I hope not to create confusion, but it may be that the problem is related to this old bug? Prissi spoken word "orphans", that they can go and create our own problems?
Have you tried to see if the pak128 is plagued by the same problems?

http://forum.simutrans.com/index.php?topic=8163.msg77408#msg77408

Giuseppe

When you said that you tried it in XP mode, do you mean that you selected "Run this program in compatibility mode for: Windows XP (Service Pack 3)" in the "properties" box of the executable? I ask because I tried that, and still with the same result: no teleporting trams.

Edit: Giuseppe - I'm not sure how they might be related - do you care to elaborate? That bug was fixed in Standard a while ago, I think.

Thanks for the input Guiseppe, but I'm quite sure this is a different issue.

James, no, I was referring to the proper XP Virtual Machine which is bundled with Win7 Professional or better, as described here: http://en.wikipedia.org/wiki/XP_Mode#Windows_XP_Mode

But this may not be necessary anymore. In fact, I already managed to isolate the problematic compiler setting: it's the runtime library setting. I suspected it could be that because of the different behaviour on the different OS, which could be explained by the presence of different versions of DLLs.

If I make a release build with the runtime library setting "Multi-threaded Debug (/MTd)" instead of the currently specified "Multi-threaded DLL (/MD)" and leave all the other (optimization) settings unchanged, all the tram problems are gone. I tried to build with the simple "Multi-threaded (/MT)" too, but with that setting I get lots of unresolved external symbol errors.  ???

1>imagelist3d_reader.obj : error LNK2001: unresolved external symbol _fread
1>libbz2.lib(bzlib.obj) : error LNK2001: unresolved external symbol _fread
1>imagelist3d_reader.obj : error LNK2001: unresolved external symbol "void * __cdecl operator new(unsigned int)" (??2@YAPAXI@Z)
1>libcpmt.lib(newaop.obj) : error LNK2001: unresolved external symbol "void * __cdecl operator new(unsigned int)" (??2@YAPAXI@Z)
1>libcpmt.lib(syserror.obj) : error LNK2001: unresolved external symbol "void * __cdecl operator new(unsigned int)" (??2@YAPAXI@Z)
1>libcpmt.lib(locale0.obj) : error LNK2001: unresolved external symbol "void * __cdecl operator new(unsigned int)" (??2@YAPAXI@Z)
1>gameinfo.obj : error LNK2001: unresolved external symbol "public: virtual char const * __thiscall std::exception::what(void)const " (?what@exception@std@@UBEPBDXZ)
1>libcpmt.lib(xthrow.obj) : error LNK2001: unresolved external symbol "public: virtual char const * __thiscall std::exception::what(void)const " (?what@exception@std@@UBEPBDXZ)
1>libcpmt.lib(syserror.obj) : error LNK2001: unresolved external symbol "public: virtual char const * __thiscall std::exception::what(void)const " (?what@exception@std@@UBEPBDXZ)
1>gameinfo.obj : error LNK2001: unresolved external symbol "public: virtual __thiscall std::exception::~exception(void)" (??1exception@std@@UAE@XZ)
1>libcpmt.lib(xthrow.obj) : error LNK2001: unresolved external symbol "public: virtual __thiscall std::exception::~exception(void)" (??1exception@std@@UAE@XZ)
1>libcpmt.lib(syserror.obj) : error LNK2001: unresolved external symbol "public: virtual __thiscall std::exception::~exception(void)" (??1exception@std@@UAE@XZ)
1>gameinfo.obj : error LNK2001: unresolved external symbol "public: __thiscall std::exception::exception(char const * const &)" (??0exception@std@@QAE@ABQBD@Z)
1>libcpmt.lib(xthrow.obj) : error LNK2001: unresolved external symbol "public: __thiscall std::exception::exception(char const * const &)" (??0exception@std@@QAE@ABQBD@Z)
1>libcpmt.lib(syserror.obj) : error LNK2001: unresolved external symbol "public: __thiscall std::exception::exception(char const * const &)" (??0exception@std@@QAE@ABQBD@Z)
1>gameinfo.obj : error LNK2001: unresolved external symbol "public: __thiscall std::exception::exception(class std::exception const &)" (??0exception@std@@QAE@ABV01@@Z)
1>libcpmt.lib(xthrow.obj) : error LNK2001: unresolved external symbol "public: __thiscall std::exception::exception(class std::exception const &)" (??0exception@std@@QAE@ABV01@@Z)
1>libcpmt.lib(syserror.obj) : error LNK2001: unresolved external symbol "public: __thiscall std::exception::exception(class std::exception const &)" (??0exception@std@@QAE@ABV01@@Z)
1>gameinfo.obj : error LNK2001: unresolved external symbol _memmove
1>libcpmt.lib(syserror.obj) : error LNK2001: unresolved external symbol _memmove
1>gameinfo.obj : error LNK2001: unresolved external symbol "void __cdecl operator delete[](void *)" (??_V@YAXPAX@Z)
1>gameinfo.obj : error LNK2001: unresolved external symbol "void __cdecl operator delete(void *)" (??3@YAXPAX@Z)
1>libcpmt.lib(xthrow.obj) : error LNK2001: unresolved external symbol "void __cdecl operator delete(void *)" (??3@YAXPAX@Z)
1>libcpmt.lib(syserror.obj) : error LNK2001: unresolved external symbol "void __cdecl operator delete(void *)" (??3@YAXPAX@Z)
1>libcpmt.lib(locale0.obj) : error LNK2001: unresolved external symbol "void __cdecl operator delete(void *)" (??3@YAXPAX@Z)
1>gameinfo.obj : error LNK2001: unresolved external symbol _stricmp
1>OLDNAMES.lib(stricmp.obj) : error LNK2001: unresolved external symbol _stricmp
1>gameinfo.obj : error LNK2001: unresolved external symbol _atol
1>gameinfo.obj : error LNK2001: unresolved external symbol "const type_info::`vftable'" (??_7type_info@@6B@)
1>libcpmt.lib(xthrow.obj) : error LNK2001: unresolved external symbol "const type_info::`vftable'" (??_7type_info@@6B@)
1>libcpmt.lib(syserror.obj) : error LNK2001: unresolved external symbol "const type_info::`vftable'" (??_7type_info@@6B@)
1>libcpmt.lib(locale0.obj) : error LNK2001: unresolved external symbol "const type_info::`vftable'" (??_7type_info@@6B@)
1>livery_scheme.obj : error LNK2001: unresolved external symbol "struct __type_info_node __type_info_root_node" (?__type_info_root_node@@3U__type_info_node@@A)
1>livery_scheme.obj : error LNK2001: unresolved external symbol "public: char const * __thiscall type_info::name(struct __type_info_node *)const " (?name@type_info@@QBEPBDPAU__type_info_node@@@Z)
1>network_address.obj : error LNK2001: unresolved external symbol _strchr
1>network_address.obj : error LNK2001: unresolved external symbol _atoi
1>network_cmd_ingame.obj : error LNK2001: unresolved external symbol _sprintf
1>zlibstat.lib(gzlib.obj) : error LNK2001: unresolved external symbol _sprintf
1>network_cmd_ingame.obj : error LNK2001: unresolved external symbol _feof
1>zlibstat.lib(zutil.obj) : error LNK2001: unresolved external symbol _free
1>libbz2.lib(bzlib.obj) : error LNK2001: unresolved external symbol _free
1>libcpmt.lib(locale0.obj) : error LNK2001: unresolved external symbol _free
1>libcpmt.lib(xmbtowc.obj) : error LNK2001: unresolved external symbol _free
1>network_cmd_ingame.obj : error LNK2001: unresolved external symbol _free
1>zlibstat.lib(gzread.obj) : error LNK2001: unresolved external symbol _free
1>zlibstat.lib(gzlib.obj) : error LNK2001: unresolved external symbol _free
1>zlibstat.lib(gzwrite.obj) : error LNK2001: unresolved external symbol _free
1>network_cmd_ingame.obj : error LNK2001: unresolved external symbol _rewind
1>network_cmd_ingame.obj : error LNK2001: unresolved external symbol _strdup
1>OLDNAMES.lib(strdup.obj) : error LNK2001: unresolved external symbol _strdup
1>network_cmd_ingame.obj : error LNK2001: unresolved external symbol _remove
1>libcpmt.lib(xmbtowc.obj) : error LNK2001: unresolved external symbol _atexit
1>libcpmt.lib(iosptrs.obj) : error LNK2001: unresolved external symbol _atexit
1>network_cmd_ingame.obj : error LNK2001: unresolved external symbol _atexit
1>libcpmt.lib(syserror.obj) : error LNK2001: unresolved external symbol _atexit
1>libcpmt.lib(locale0.obj) : error LNK2001: unresolved external symbol _atexit
1>libcpmt.lib(xlock.obj) : error LNK2001: unresolved external symbol _atexit
1>network_cmd_ingame.obj : error LNK2001: unresolved external symbol _fopen
1>libbz2.lib(bzlib.obj) : error LNK2001: unresolved external symbol _fopen
1>network_cmd_ingame.obj : error LNK2001: unresolved external symbol __purecall
1>libcpmt.lib(syserror.obj) : error LNK2001: unresolved external symbol __purecall
1>network_cmd_ingame.obj : error LNK2001: unresolved external symbol _ftell
1>network_cmd_ingame.obj : error LNK2001: unresolved external symbol _fseek
1>network_cmd_ingame.obj : error LNK2001: unresolved external symbol _fclose
1>libbz2.lib(bzlib.obj) : error LNK2001: unresolved external symbol _fclose
1>network_cmd_ingame.obj : error LNK2001: unresolved external symbol _chdir
1>OLDNAMES.lib(chdir.obj) : error LNK2001: unresolved external symbol _chdir
1>network_file_transfer.obj : error LNK2001: unresolved external symbol _fflush
1>libbz2.lib(bzlib.obj) : error LNK2001: unresolved external symbol _fflush
1>network_file_transfer.obj : error LNK2001: unresolved external symbol _printf
1>network_file_transfer.obj : error LNK2001: unresolved external symbol _strnicmp
1>OLDNAMES.lib(strnicmp.obj) : error LNK2001: unresolved external symbol _strnicmp
1>network_file_transfer.obj : error LNK2001: unresolved external symbol _fwrite
1>libbz2.lib(bzlib.obj) : error LNK2001: unresolved external symbol _fwrite
1>display_settings.obj : error LNK2001: unresolved external symbol _strncat
1>server_frame.obj : error LNK2001: unresolved external symbol _strncmp
1>server_frame.obj : error LNK2001: unresolved external symbol _strstr
1>server_frame.obj : error LNK2001: unresolved external symbol _fgets
1>simsys.obj : error LNK2001: unresolved external symbol _mkdir
1>OLDNAMES.lib(mkdir.obj) : error LNK2001: unresolved external symbol _mkdir
1>simsys_w.obj : error LNK2001: unresolved external symbol ___argv
1>simsys_w.obj : error LNK2001: unresolved external symbol ___argc
1>zlibstat.lib(zutil.obj) : error LNK2001: unresolved external symbol _malloc
1>libbz2.lib(bzlib.obj) : error LNK2001: unresolved external symbol _malloc
1>libcpmt.lib(locale0.obj) : error LNK2001: unresolved external symbol _malloc
1>simsys_w32_png.obj : error LNK2001: unresolved external symbol _malloc
1>zlibstat.lib(gzread.obj) : error LNK2001: unresolved external symbol _malloc
1>zlibstat.lib(gzlib.obj) : error LNK2001: unresolved external symbol _malloc
1>zlibstat.lib(gzwrite.obj) : error LNK2001: unresolved external symbol _malloc
1>cbuffer_t.obj : error LNK2001: unresolved external symbol __vsprintf_p
1>einstellungen.obj : error LNK2001: unresolved external symbol _sscanf
1>einstellungen.obj : error LNK2001: unresolved external symbol _memchr
1>zlibstat.lib(gzread.obj) : error LNK2001: unresolved external symbol _memchr
1>fahrplan.obj : error LNK2001: unresolved external symbol _isdigit
1>libbz2.lib(bzlib.obj) : error LNK2001: unresolved external symbol _isdigit
1>font.obj : error LNK2001: unresolved external symbol _calloc
1>libbz2.lib(blocksort.obj) : error LNK2001: unresolved external symbol ___iob_func
1>font.obj : error LNK2001: unresolved external symbol ___iob_func
1>libbz2.lib(bzlib.obj) : error LNK2001: unresolved external symbol ___iob_func
1>libbz2.lib(compress.obj) : error LNK2001: unresolved external symbol ___iob_func
1>libbz2.lib(decompress.obj) : error LNK2001: unresolved external symbol ___iob_func
1>font.obj : error LNK2001: unresolved external symbol _strtol
1>libbz2.lib(blocksort.obj) : error LNK2001: unresolved external symbol _fprintf
1>font.obj : error LNK2001: unresolved external symbol _fprintf
1>libbz2.lib(bzlib.obj) : error LNK2001: unresolved external symbol _fprintf
1>libbz2.lib(compress.obj) : error LNK2001: unresolved external symbol _fprintf
1>libbz2.lib(decompress.obj) : error LNK2001: unresolved external symbol _fprintf
1>font.obj : error LNK2001: unresolved external symbol _getc
1>gebaeude.obj : error LNK2001: unresolved external symbol _strrchr
1>gebaeude.obj : error LNK2001: unresolved external symbol _toupper
1>gui_component_table.obj : error LNK2001: unresolved external symbol ___RTtypeid
1>gui_flowtext.obj : error LNK2001: unresolved external symbol _strncpy
1>loadsave.obj : error LNK2001: unresolved external symbol _fputc
1>loadsave.obj : error LNK2001: unresolved external symbol _strerror
1>zlibstat.lib(gzread.obj) : error LNK2001: unresolved external symbol _strerror
1>zlibstat.lib(gzwrite.obj) : error LNK2001: unresolved external symbol _strerror
1>libcpmt.lib(syserror.obj) : error LNK2001: unresolved external symbol _strerror
1>libcpmt.lib(xmbtowc.obj) : error LNK2001: unresolved external symbol __errno
1>loadsave.obj : error LNK2001: unresolved external symbol __errno
1>zlibstat.lib(gzread.obj) : error LNK2001: unresolved external symbol __errno
1>zlibstat.lib(gzwrite.obj) : error LNK2001: unresolved external symbol __errno
1>libcpmt.lib(xwctomb.obj) : error LNK2001: unresolved external symbol __errno
1>loadsave.obj : error LNK2001: unresolved external symbol _ferror
1>libbz2.lib(bzlib.obj) : error LNK2001: unresolved external symbol _ferror
1>loadsave_frame.obj : error LNK2001: unresolved external symbol _tolower
1>loadsave_frame.obj : error LNK2001: unresolved external symbol _strftime
1>loadsave_frame.obj : error LNK2001: unresolved external symbol __localtime64
1>loadsave_frame.obj : error LNK2001: unresolved external symbol __stat64i32
1>float32e8_t.obj : error LNK2001: unresolved external symbol _memmove_s
1>float32e8_t.obj : error LNK2001: unresolved external symbol "public: virtual __thiscall std::bad_cast::~bad_cast(void)" (??1bad_cast@std@@UAE@XZ)
1>float32e8_t.obj : error LNK2001: unresolved external symbol "public: __thiscall std::bad_cast::bad_cast(char const *)" (??0bad_cast@std@@QAE@PBD@Z)
1>float32e8_t.obj : error LNK2001: unresolved external symbol "public: __thiscall std::bad_cast::bad_cast(class std::bad_cast const &)" (??0bad_cast@std@@QAE@ABV01@@Z)
1>float32e8_t.obj : error LNK2001: unresolved external symbol _sprintf_s
1>float32e8_t.obj : error LNK2001: unresolved external symbol _localeconv
1>float32e8_t.obj : error LNK2001: unresolved external symbol _strcspn
1>log.obj : error LNK2001: unresolved external symbol _abort
1>libcpmt.lib(iosptrs.obj) : error LNK2001: unresolved external symbol _abort
1>log.obj : error LNK2001: unresolved external symbol _vsprintf
1>log.obj : error LNK2001: unresolved external symbol _fputs
1>log.obj : error LNK2001: unresolved external symbol _vfprintf
1>log.obj : error LNK2001: unresolved external symbol _puts
1>obj_reader.obj : error LNK2001: unresolved external symbol _fgetc
1>libbz2.lib(bzlib.obj) : error LNK2001: unresolved external symbol _fgetc
1>savegame_frame.obj : error LNK2001: unresolved external symbol __findnext64i32
1>savegame_frame.obj : error LNK2001: unresolved external symbol __findclose
1>savegame_frame.obj : error LNK2001: unresolved external symbol __findfirst64i32
1>simgraph16.obj : error LNK2001: unresolved external symbol _access
1>OLDNAMES.lib(access.obj) : error LNK2001: unresolved external symbol _access
1>simgraph16.obj : error LNK2001: unresolved external symbol _exit
1>libbz2.lib(bzlib.obj) : error LNK2001: unresolved external symbol _exit
1>simmain.obj : error LNK2001: unresolved external symbol _getcwd
1>OLDNAMES.lib(getcwd.obj) : error LNK2001: unresolved external symbol _getcwd
1>simmem.obj : error LNK2001: unresolved external symbol _realloc
1>sprachen.obj : error LNK2001: unresolved external symbol _atof
1>LINK : error LNK2001: unresolved external symbol _WinMainCRTStartup
1>zlibstat.lib(gzread.obj) : error LNK2001: unresolved external symbol _read
1>OLDNAMES.lib(read.obj) : error LNK2001: unresolved external symbol _read
1>libcpmt.lib(syserror.obj) : error LNK2001: unresolved external symbol _memcpy
1>libcpmt.lib(locale0.obj) : error LNK2001: unresolved external symbol _memcpy
1>zlibstat.lib(gzread.obj) : error LNK2001: unresolved external symbol _memcpy
1>zlibstat.lib(gzwrite.obj) : error LNK2001: unresolved external symbol _memcpy
1>zlibstat.lib(inflate.obj) : error LNK2001: unresolved external symbol _memcpy
1>zlibstat.lib(deflate.obj) : error LNK2001: unresolved external symbol _memcpy
1>zlibstat.lib(gzread.obj) : error LNK2001: unresolved external symbol _close
1>zlibstat.lib(gzwrite.obj) : error LNK2001: unresolved external symbol _close
1>OLDNAMES.lib(close.obj) : error LNK2001: unresolved external symbol _close
1>zlibstat.lib(gzlib.obj) : error LNK2001: unresolved external symbol _lseek
1>OLDNAMES.lib(lseek.obj) : error LNK2001: unresolved external symbol _lseek
1>zlibstat.lib(gzlib.obj) : error LNK2001: unresolved external symbol _open
1>OLDNAMES.lib(open.obj) : error LNK2001: unresolved external symbol _open
1>zlibstat.lib(gzwrite.obj) : error LNK2001: unresolved external symbol _write
1>OLDNAMES.lib(write.obj) : error LNK2001: unresolved external symbol _write
1>libbz2.lib(decompress.obj) : error LNK2001: unresolved external symbol _memset
1>libbz2.lib(blocksort.obj) : error LNK2001: unresolved external symbol _memset
1>zlibstat.lib(gzwrite.obj) : error LNK2001: unresolved external symbol _memset
1>zlibstat.lib(deflate.obj) : error LNK2001: unresolved external symbol _memset
1>libbz2.lib(bzlib.obj) : error LNK2001: unresolved external symbol _memset
1>libbz2.lib(compress.obj) : error LNK2001: unresolved external symbol _memset
1>zlibstat.lib(gzwrite.obj) : error LNK2001: unresolved external symbol __vsnprintf
1>libbz2.lib(bzlib.obj) : error LNK2001: unresolved external symbol _ungetc
1>libbz2.lib(bzlib.obj) : error LNK2001: unresolved external symbol _fdopen
1>OLDNAMES.lib(fdopen.obj) : error LNK2001: unresolved external symbol _fdopen
1>libbz2.lib(bzlib.obj) : error LNK2001: unresolved external symbol _setmode
1>OLDNAMES.lib(setmode.obj) : error LNK2001: unresolved external symbol _setmode
1>libbz2.lib(bzlib.obj) : error LNK2001: unresolved external symbol _fileno
1>OLDNAMES.lib(fileno.obj) : error LNK2001: unresolved external symbol _fileno
1>libcpmt.lib(xmbtowc.obj) : error LNK2001: unresolved external symbol ___security_cookie
1>libbz2.lib(bzlib.obj) : error LNK2001: unresolved external symbol ___security_cookie
1>libbz2.lib(compress.obj) : error LNK2001: unresolved external symbol ___security_cookie
1>libbz2.lib(decompress.obj) : error LNK2001: unresolved external symbol ___security_cookie
1>libbz2.lib(blocksort.obj) : error LNK2001: unresolved external symbol ___security_cookie
1>libcpmt.lib(syserror.obj) : error LNK2001: unresolved external symbol @__security_check_cookie@4
1>libcpmt.lib(locale0.obj) : error LNK2001: unresolved external symbol @__security_check_cookie@4
1>libcpmt.lib(xmbtowc.obj) : error LNK2001: unresolved external symbol @__security_check_cookie@4
1>libbz2.lib(bzlib.obj) : error LNK2001: unresolved external symbol @__security_check_cookie@4
1>libbz2.lib(compress.obj) : error LNK2001: unresolved external symbol @__security_check_cookie@4
1>libbz2.lib(decompress.obj) : error LNK2001: unresolved external symbol @__security_check_cookie@4
1>libbz2.lib(blocksort.obj) : error LNK2001: unresolved external symbol @__security_check_cookie@4
1>libbz2.lib(bzlib.obj) : error LNK2001: unresolved external symbol __chkstk
1>libbz2.lib(huffman.obj) : error LNK2001: unresolved external symbol __chkstk
1>libbz2.lib(compress.obj) : error LNK2001: unresolved external symbol __fltused
1>libbz2.lib(blocksort.obj) : error LNK2001: unresolved external symbol __fltused
1>libcpmt.lib(xthrow.obj) : error LNK2001: unresolved external symbol __CxxThrowException@8
1>libcpmt.lib(syserror.obj) : error LNK2001: unresolved external symbol __CxxThrowException@8
1>libcpmt.lib(xwctomb.obj) : error LNK2001: unresolved external symbol ____mb_cur_max_l_func
1>libcpmt.lib(xmbtowc.obj) : error LNK2001: unresolved external symbol ____mb_cur_max_l_func
1>libcpmt.lib(xwctomb.obj) : error LNK2001: unresolved external symbol ____lc_codepage_func
1>libcpmt.lib(xmbtowc.obj) : error LNK2001: unresolved external symbol ____lc_codepage_func
1>libcpmt.lib(xwctomb.obj) : error LNK2001: unresolved external symbol ____lc_handle_func
1>libcpmt.lib(xmbtowc.obj) : error LNK2001: unresolved external symbol ____lc_handle_func
1>libcpmt.lib(syserror.obj) : error LNK2001: unresolved external symbol _strlen
1>libcpmt.lib(syserror.obj) : error LNK2001: unresolved external symbol ___CxxFrameHandler3
1>libcpmt.lib(locale0.obj) : error LNK2001: unresolved external symbol ___CxxFrameHandler3
1>libcpmt.lib(syserror.obj) : error LNK2001: unresolved external symbol __EH_epilog3
1>libcpmt.lib(locale0.obj) : error LNK2001: unresolved external symbol __EH_epilog3
1>libcpmt.lib(syserror.obj) : error LNK2001: unresolved external symbol __EH_prolog3_catch
1>libcpmt.lib(locale0.obj) : error LNK2001: unresolved external symbol __EH_prolog3
1>libcpmt.lib(locale0.obj) : error LNK2001: unresolved external symbol _setlocale
1>libcpmt.lib(uncaught.obj) : error LNK2001: unresolved external symbol "bool __cdecl __uncaught_exception(void)" (?__uncaught_exception@@YA_NXZ)
1>libcpmt.lib(stdhndlr.obj) : error LNK2001: unresolved external symbol "int (__cdecl*__cdecl _set_new_handler(int (__cdecl*)(unsigned int)))(unsigned int)" (?_set_new_handler@@YAP6AHI@ZP6AHI@Z@Z)
1>libcpmt.lib(xmbtowc.obj) : error LNK2001: unresolved external symbol __create_locale
1>libcpmt.lib(xmbtowc.obj) : error LNK2001: unresolved external symbol __ui64toa_s
1>libcpmt.lib(xmbtowc.obj) : error LNK2001: unresolved external symbol __free_locale
1>libcpmt.lib(xmbtowc.obj) : error LNK2001: unresolved external symbol __malloc_crt
1>libcpmt.lib(xmbtowc.obj) : error LNK2001: unresolved external symbol ___pctype_func
1>OLDNAMES.lib(stricmp.obj) : error LNK2001: unresolved external symbol __stricmp
1>OLDNAMES.lib(strdup.obj) : error LNK2001: unresolved external symbol __strdup
1>OLDNAMES.lib(chdir.obj) : error LNK2001: unresolved external symbol __chdir
1>OLDNAMES.lib(strnicmp.obj) : error LNK2001: unresolved external symbol __strnicmp
1>OLDNAMES.lib(mkdir.obj) : error LNK2001: unresolved external symbol __mkdir
1>OLDNAMES.lib(access.obj) : error LNK2001: unresolved external symbol __access
1>OLDNAMES.lib(getcwd.obj) : error LNK2001: unresolved external symbol __getcwd
1>OLDNAMES.lib(read.obj) : error LNK2001: unresolved external symbol __read
1>OLDNAMES.lib(close.obj) : error LNK2001: unresolved external symbol __close
1>OLDNAMES.lib(lseek.obj) : error LNK2001: unresolved external symbol __lseek
1>OLDNAMES.lib(open.obj) : error LNK2001: unresolved external symbol __open
1>OLDNAMES.lib(write.obj) : error LNK2001: unresolved external symbol __write
1>OLDNAMES.lib(fdopen.obj) : error LNK2001: unresolved external symbol __fdopen
1>OLDNAMES.lib(setmode.obj) : error LNK2001: unresolved external symbol __setmode
1>OLDNAMES.lib(fileno.obj) : error LNK2001: unresolved external symbol __fileno
1>.\simutrans\Simutrans-Experimental.exe : fatal error LNK1120: 132 unresolved externals


I'm not sure what to make of those results. Just accepting that it is like this and switching to "Multi-threaded Debug (/MTd)" doesn't seem to be satisfactory to me because ignorance about the true reason could lead to other problems. Maybe there's an expert who has some ideas about this? I should add that I'm compiling with VS2010 (Premium), James with the Express edition as far as I remember, but since his executable caused the same problems, it can't be a matter of different editions.

Hmm - I wonder, then, whether the problem is caused by bad DLLs? The complete package and executable zip file come with some DLLs, some for XP and some for 7/Vista. Have you tried unpacking those into your simutrans directory (where the executable is) and seeing whether that makes a difference?

Yes, I've always extracted the whole content of the complete package, including those two DLLs.

However, I've noticed this: I removed the DLLs from the folder, but the dynamically linked executable was still working, which has to be because I had installed the "Microsoft Visual C++ 2010 Redistributable Package" some time before already so the DLL instances from System32 are apparently used.

I'm looking into the different versions of those DLLs which are available, for example I'm not sure if I installed the SP1 for that (software administration remains unclear). My version of both msvcr100.dll and msvcp100.dll in System32 is 10.0.40219.325.

Edit: Indeed, if I rename the two DLLs in System32 and delete the DLLs in the folder too, when I'm trying to run the dynamically linked executable, I'm getting the error that the DLLs are missing. But adding the DLLs from the complete package to the folder again doesn't solve the tram problem ... so this could still be a version conflict

Thank you for your work in looking into this - much appreciated! If you can find a version of the .DLL files that do not cause the problems, that would be extremely helpful.

Edit: Do you still get the problem if you remove the .DLLs in the folder but keep the system copies?

Unfortunately, no version of the DLLs I tried fixes it.  :-[

I have 10.0.40219.325 (both msvcp and msvcr) from System32, which apparently is the SP1 version. I have 10.0.40219.1 (both msvcp and msvcr) which is in Microsoft Visual Studio 10.0\VC\redist\x86\Microsoft.VC100.CRT, and the version bundled with the Experimental complete package is 10.0.30319.1 for msvcr100.dll respectively 10.0.30128.1 for msvcp100.dll.

Only the statically linked executable is working fine. Since the DLL version doesn't seem to make a difference, it only seems to be the difference of statical (combined with debug cf. above /MT option not working) vs. dynamical linking. Anyone has an idea?

Edit: It makes no difference either if the DLLs are used from System32 or the game folder (tested by deleting them in the other place each time)

This is very odd, and rather beyond me, I'm afraid. Do you want to test whether performance is affected on a big map by comparing the statically linked and dynamically linked versions? I should be very grateful if you could.

Hmm - it seems that I can reproduce the bug using the XP Mode emulator available with Windows 7 Professional. The only thought that I have at present as to how to solve it is to use static linking henceforth. Does anyone have any other ideas? Thanks particularly to Hein for all the work in tracking down the bug.

I had some time to test the static linking. In order for the release build (option /MT) to work, I removed libcmt.lib from %(IgnoreSpecificDefaultLibraries), as discussed here: http://forum.simutrans.com/index.php?topic=9888.0 (http://forum.simutrans.com/index.php?topic=9888.0), which solved all the unresolved external symbol errors.

BUT the bad news is that the same tram physics bugs exist with that build. So in order to having tested with all the options, I also made a dynamically linked debug build (option /MDd), for which I had to add libcmt.lib to the list of ignored libraries again due to some conflicts, and sure enough, no physics bug can be observed with that. Which means that it's not the static vs. dynamic linking which makes the difference but linking against the release or the debug version of the runtime libraries. I can only guess that the debug version might use some additional measurements against memory-related (stack/heap) bugs, but I have no experience at all with that. And I couldn't find anything on the web after a quick search either.

When I have some more time, I'll try to track down the commit after which this bug occurs first. Since after all, the official 10.11 release doesn't show it.

debug libraries uses to use safer heaps (reserving extra memory before and after the bock), and uses to initialize memory. I think the behaviour you describe is caused by a corrupted/misaligned/uninitialized pointer in the code, a programming bug.

But this is just a guess by me. :)

Just checked out and compiled the current version.  Using pak128.britain-experimental: houses that should have level 1, instead demand 0 passengers and 0 mail.  This occurs both with newly checked-out and newly-compiled pakset and with an old existing one (so it's not makeobj).

Hello

Quote from: wlindley on May 09, 2012, 01:26:08 PM
Just checked out and compiled the current version.  Using pak128.britain-experimental: houses that should have level 1, instead demand 0 passengers and 0 mail.  This occurs both with newly checked-out and newly-compiled pakset and with an old existing one (so it's not makeobj).

I believe that this phenomenon is due to the parameter "passenger_factor" (simuconf.tab) which is currently set to a value below 16.
The formula works roughly like this: Passenger_generation = passenger_factor * building level / 16
We do not know if in this case the passengers are actually generated 0 or 0.8 ...

Giuseppe

Hein and Markohs,

thank you both for your input - that is most helpful. I shall have to ask Bernd to look into this issue. Do either of you have any idea as to why such memory corruption would not be spotted in Dr. Memory?

James.

Edit: Hmm - this doesn't really explain why it does not occur in dynamically linked builds for Windows 7 or Vista, however. Does anyone have any ideas?

Quote from: Milko on May 09, 2012, 01:39:46 PM
I believe that this phenomenon is due to the parameter "passenger_factor" (simuconf.tab) which is currently set to a value below 16.
The formula works roughly like this: Passenger_generation = passenger_factor * building level / 16

Surely that should be: Passenger_generation = (passenger_factor * building level + 8) / 16 ...which would properly round 0.8 up to 1, as well as 1.6 up to 2...?

One consequence of that is presumably that passenger generation would go up. There are already few low passenger levels to choose from, and this would reduce them further.

IMO we need a greater fineness of grain at lower passenger_factor levels -- there are situations where one would want to go as low as 1 or 2 for passenger_factor. Any simulation with a realistic frequency of service would have to go for a very low passenger factor.

With same version as exhibits the zero-passenger buildings:  Vehicles continue to accelerate forever, leading to this:
(http://wlindley.com/images/simscr19.jpg)

I just found about a c++ stetic code analyzation tool http://sourceforge.net/apps/mediawiki/cppcheck/index.php?title=Main_Page

I'll have it a look and pass over the experimental code and see if I find something relevant

Thanks for helping out Markohs. :)

I had meant to post some more information about this already, which I forgot. I've actually tracked down the exact commit since when the bug was introduced, it's this one: https://github.com/jamespetts/simutrans-experimental/commit/99ec6a773849768326d843653de18a00a181507c (https://github.com/jamespetts/simutrans-experimental/commit/99ec6a773849768326d843653de18a00a181507c)

It definitely doesn't occur on the devel branch in the previous commit, nor on the braking-physics branch in the previous commit, and seemingly in every devel branch commit since then. Unfortunately, my C(++) skills are still far too modest to make an attempt to find something in the code there or else I would have had a look myself already.

it's still processing, takes lots of CPU...

I'm processing standard and last experimental, to compare results, so far only a few hard errors showed up (about warings, he has tons already)

Top of the image is simutrans STANDARD, the one down, is EXPERIMENTAL.

(http://dl.dropbox.com/u/30024783/cpp.png)

Okay, I got the results. Generated 2 outputs for each project, experimental and standard. One is a report of what cppcheck considers as pure errors, one of them has already been solved today in svn by Dwachs, even I think none of the "bugs" were critical.

Experimental throws a few extra bugs than standard, the relevant ones are:

- Possible null pointer dereference: w - otherwise it is redundant to check if w is null at line 4063, line 4077 vehicle\simvehikel.cc

having a look at the code, seems correct to me, no bug here to my eyes, since thge check_access checks if it's null before refering it. *BUT* this is one of the files modified in the problematic commit, so this *might* be the bug.

- Memory leak: password line="503" file="nettools\nettool.cc"

This is indeed a bug but it's even documentated in the code, and it's not really important.

- Null pointer dereference line="67" dataobj\livery_scheme.cc

I had it a look, and I don't really know if that's a bug or not, but I think it isn't.

The rest of errors are present already in standard and are nto really a severe problem.

I'm sorry I coudn't help more, I'll have it another look this weekend if I got time. :)

http://dl.dropbox.com/u/30024783/ccpcheck/experimental.xml (http://dl.dropbox.com/u/30024783/ccpcheck/experimental.xml)
http://dl.dropbox.com/u/30024783/ccpcheck/experimental-full.xml (http://dl.dropbox.com/u/30024783/ccpcheck/experimental-full.xml)
http://dl.dropbox.com/u/30024783/ccpcheck/standard.xml (http://dl.dropbox.com/u/30024783/ccpcheck/standard.xml)
http://dl.dropbox.com/u/30024783/ccpcheck/standard-full.xml (http://dl.dropbox.com/u/30024783/ccpcheck/standard-full.xml)


The full report is too verbose to be useful, but the bug you describe might be in that report, hidden somewere. ;)

EDIT: Posting here fast what in a fast overlook of the report I think it *CAN* corrupt memory

-<error verbose="%s in format string (no. 1) requires a char* given in the argument list" msg="%s in format string (no. 1) requires a char* given in the argument list" severity="warning" id="invalidPrintfArgType_s"> <location line="63" file="besch\writer\root_writer.cc"/> </error>

<error verbose="%s in format string (no. 1) requires a char* given in the argument list" msg="%s in format string (no. 1) requires a char* given in the argument list" severity="warning" id="invalidPrintfArgType_s"> <location line="101" file="besch\writer\root_writer.cc"/>

Edit2: According to Hein, we can narrow the search to this files:

   
besch/reader/vehicle_reader.cc
besch/vehikel_besch.h
besch/writer/vehicle_writer.cc
dataobj/translator.cc
gui/components/gui_convoy_assembler.h
gui/convoi_filter_frame.h
gui/halt_list_filter_frame.h
simconvoi.cc
simconvoi.h
simhalt.cc
vehicle/simvehikel.cc

I am trying to compile devel branch of simutrans experimental on Linux. Compilation is ok, but linkage not:

===> LD  build/default/simutrans-experimental
build/default/path_explorer.o: In function `path_explorer_t::compartment_t::step()':
/home/pokus/src/simutrans-experimental/path_explorer.cc:790: undefined reference to `convoi_t::get_average_journey_times()'
/home/pokus/src/simutrans-experimental/path_explorer.cc:794: undefined reference to `convoi_t::get_average_journey_times()'
/home/pokus/src/simutrans-experimental/path_explorer.cc:799: undefined reference to `convoi_t::get_average_journey_times()'
/home/pokus/src/simutrans-experimental/path_explorer.cc:892: undefined reference to `convoi_t::get_average_journey_times()'
/home/pokus/src/simutrans-experimental/path_explorer.cc:1017: undefined reference to `convoi_t::get_average_journey_times()'
collect2: ld returned 1 exit status
make: *** [build/default/simutrans-experimental] Error 1


Probably reintroduced bug from this thread:
http://forum.simutrans.com/index.php?topic=9706.0 (http://forum.simutrans.com/index.php?topic=9706.0)

Following patch fixes problem  (removes inline keyword causing linkage not to work):

diff --git a/simconvoi.cc b/simconvoi.cc
index 89a7071..5453982 100644
--- a/simconvoi.cc
+++ b/simconvoi.cc
@@ -6138,7 +6138,7 @@ void convoi_t::emergency_go_to_depot()
        }
}

-inline koordhashtable_tpl<id_pair, average_tpl<uint16> > * const convoi_t::get_average_journey_times()
+koordhashtable_tpl<id_pair, average_tpl<uint16> > * const convoi_t::get_average_journey_times()
{
        if(line.is_bound())
        {

Thank you everyone for all the work on this, and sorry that I have not hitherto been able to respond more fully: I have been rather busy this week with work. I have made the change suggested by JK to fix the compile error - thank you for that. Thank you also to Hein for finding in exactly which commit the error occurs. The error first occurring in a merge commit makes it very awkward to track down, however: I cannot imagine what I altered on the -devel branch to make the braking-physics branch code go wrong when merged with it. It does seem very peculiar indeed.

@Markohs

How did you compile the list of files which might contain the (apparent) physics bug? Based on the diff with the previous commit on the devel branch ("Merge branch 'fare-stages' into devel") and then narrowing it down to files that are at least remotely related to physics code?

Going through the list, I remembered two more aspects of the bug which shouldn't be forgotten and which might indeed point to one of those files. It's the two things I've written about here (http://forum.simutrans.com/index.php?topic=9709.msg93489#msg93489) and here (http://forum.simutrans.com/index.php?topic=9709.msg93516#msg93516). Since the presence and content of seemingly arbitrary files in the Simutrans folder structure is apparently having an influence on the bug, it could be one of the vehicle loading routines that's broken. Maybe the fact it doesn't happen on Windows Vista/7 or XP with debug libraries could be explained by subtly different I/O routines ...? And as for my other post, those screenshots look like the braking force (and possibly other stats) could be wrong for the vehicles in question, which could be connected to the I/O too.

What makes it so awkward to track this down is that it only happens on XP (which requires James to use a VM) and that it doesn't happen with the debug libraries, so how can you really debug it ...  :-[

I have had a thought about the static/dynamic issue of this: Hein, you compiled a statically linked version on your XP machine, and found the same (bad) results as using dynamic linking on your XP machine. From that, we concluded that static linking was not a solution.

However, it has since struck me that that might not be right. When you statically linked on your XP machine, you were probably statically linking in the same versions of the libraries as those to which you were linking dynamically, producing the same errors. The problem may well not persist if you run on your XP machine an executable statically linked on Windows 7. To test this, I have produced such an executable, which can be downloaded here (http://simutrans-germany.com/files/upload/Simutrans-Experimental-static.zip): I should be grateful if you could give it a go and let me know how you get on.

Thanks for the effort James. I tested this immediately, but I'm sorry to say that it doesn't fix the bug:

(http://i.imgur.com/XTRwc.png)

(that's one of the cases where the speed display is jumping around wildly, but that doesn't really matter as another type of tram is going infinite speed in the same game and a third type is crawling)

Hmm - very odd.

I just noticed that the bug we've been talking about before here (http://forum.simutrans.com/index.php?topic=9709.msg93444#msg93444) isn't fully gone yet either. I've uploaded a savegame here (http://simutrans-germany.com/files/upload/crash_on_remove.sve) with which you should be able to reproduce the crash on deleting a station within walking distance of another station. You should delete "München Victorian School Stop" for that. What might be peculiar about this one is that I had previously redesigned "München Brownfriars Railway Station" so it (involuntarily, I still keep forgetting about that sometimes) ended up in walking distance, which it wasn't at first.

Hein,

thank you for your work. Bernd has been working on some fixes this week-end, which I have just pushed to -devel: one on a so far unreported bug in loading a certain version of Standard saved games, and an uninitialised variable issue in the vehicle reader code that might well have caused the reported issues with teleporting (etc.). I have just pushed the changes - would you mind testing to see whether they help?

I shall now turn to seeing if I can fix the re-report of the walking issue.

Edit: I think that I have fixed the crash - I should be grateful if you could re-test.

Buggy trams not fixed, I'm afraid. Does Bernd have access to an XP (virtual) machine to test? Otherwise, it could be very laborious for him to deal with this ...  :-[ By the way, releasing a "workaround" build just for XP which is linked to the debug libraries wouldn't be an option either, I think. I read somewhere on a Microsoft site that one is not allowed to ship the debug libraries with a program. Whether that applies to a statically linked build too, I don't know. But seeing the performance detriments, which are not very bad though, I guess this would never be an option anyway ... I've only used this as a resort to play on my running game a little.

Oh, and if you're reading this Bernd - there's also still bug No. 6 (http://forum.simutrans.com/index.php?topic=9709.msg93429#msg93429) present in the latest code.

The station removal crash (as displayed in my savegame) is gone though, thank you. :)

Bernd tells me that he doesn't have access to an XP machine for testing, but I'm not sure whether he's able to set up a virtual machine. At least one bug is gone!

Hein,

I didn't try to fix bug 6 yet.

And I don't have access to Win XP or Win 7 Professional.

But if it is correct, that both branches were okay before the merge, but the merge result isn't, then I'm sure, that I will find some more fishy differences.

I just found another bug ... (or at least I think it is one, and it doesn't happen with 10.11 either)

It can be observed in the savegame (http://simutrans-germany.com/files/upload/crash_on_remove.sve) I've already uploaded before. All the trains are slowing down a little at free signals, but only on diagonal tiles, which means they don't reach full speed there if the signal density is sufficiently high (4 in my case). However, it doesn't happen exlusively on diagonal tiles but also on straight tiles in apparently rare cases. If you follow a train going from Buxtehude to Döbeln, you'll notice that it slows down two or three times on the straight section behind Mühlacker somewhere near a signal and when going downhill.

I'll also renew my assertion that travelling times on circular lines with alternate directions turned on are still buggy. Granted this is based on a savegame carried over from 10.11 (the same as linked above), but if you check any of the Berlin inner city stations, the travelling times to all the stops on the line have gone up a huge lot and seem to have approached the old buggy time of a trip to the most distant stop again. Which means in particular that it reportedly takes way longer than an hour to reach an adjacent station only 1-2km away ...

And while there is a little variation of the pax travelling times still, the mail travelling times are all uniformly on an interval of about 5 minutes around 1:35h-1:40h.

I just don't have the time at the moment to start a new game from scratch with the devel executable and continue it until reaching such a developed stage, only to verify that it happens in that situation too. I must admit that the whole process is also getting a little frustrating because I seem to be the only one right now and the number of open bugs isn't really going down.  :-[

Thank you for the reports. The slowing down for signals issue might be related to the current bug preventing the slowing down for corners working properly, which Bernd is looking into, but I shall see if I can look into that, too, as it might not be related.

The issue with the reverse circular routes I shall look at again. You say that the journey times seem to increase over time; can you elaborate a little on the behaviour, and in particular what you consider the start point to be (i.e., when they start increasing, and what they are at the beginning)? Knowing that might materially assist in finding the bug.

Sorry that you're feeling frustrated - part of the issue is that many of the bugs are physics related, which I cannot sensibly investigate, as I do not know how the physics works in detail. Bernd, who wrote the code, is investigating, but his free time is limited, so, whilst we are waiting for that to be fixed, I am spending my Simutrans time on pakset work and on fixing any non-physics bugs that might be reported.

Your work to track down bugs is very much appreciated, however!

Most likely the slowing down before signals is related to the physics.

I assume that, the convoys must start braking, because the signal is not yet green.

I didn't check the block reservation code, but I think there must be an extension in experimental, that considers the braking distance.

The physics code gives a 10% safety difference, thus it starts braking 1100m before the end position, if the braking distance is 1000m. If the block reservation does not calculate the same way, the convoy has to slow down to a braking distance of 909m.

BTW: While trying to fix the slope issue, I'm watching another curious braking at the bottom of a 2 tile slope to almost 0 km/h.

Thanks to both of you for looking into this. I must admit that I may be a little impatient at the moment due to some stress in life. But I always appreciate the work you put into Experimental.  :)

@James

That's the problem with circular line issue, it seems to be so difficult to pinpoint where things start going awry unless one would invest a lot of time to monitor it ...  :-[ However, since mail is apparently completely unfazed by the changes you've implemented so far (cf. my savegame, both Berlin and Hamburg), could that give a clue maybe? Insofar as a problem with mail only carries over to pax too and screws those times in the long run too?

A convoy slows down before a signal, if the pre-calculated route ends at the signal. To avoid braking, precalcultion of the next partial route should be done before braking is required. James, if you will give it a try, please notice that convoys start braking 10% before the minimum braking distance to avoid abrupt stops due to too roughly rounded calculations.

A reason, why this can be observed mostly on diagonal routes, could be, that maybe the route calculation thinks in tiles only, but should consider the shorter diagonals?


Actually slope "drag" is considered at the end of a tile. And due to the "Cumulative drag for hills" the friction lags another 1-2 tiles. James, what was the intention of the "Cumulative drag for hills"?

I'm trying to move slope consideration to the beginning of the tile...
I moved the slope consideration to the beginning of the tile and temporarily switched back to "Simple drag for hills".

Bernd,

thank you very much for looking into this. I was not aware of the 10% thing, so the method for checking when signals need to determine whether they are to clear is not based on the 10% figure, which I expect is what is causing the problem. Shall I fix that, or would you like to do it?

The additional slope drag was added to make hill climbing more realistic - previously, hills did not have anything like enough of an effect on acceleration/speed to give players a realistic incentive to avoid them, and this seemed to be the most effective way of dealing with that. Specifically, I wanted to simulate different steepnesses of hill, which is not possible directly in Simutrans, by assuming that multiple hill tiles in succession means a steeper hill, which is as good an approximation as one can get, I think. If you are able to move the calculation of the drag to the beginning of the tile, that would very much help one of the reported issues.

Hein,

when you write that mail is unfazed by the changes, do you mean the reverse circular route bug still exists in its original form for mail?

James,

could you please add the 10% lookahead to the block reservation?

Thanks, also for clarification about "Cumulative drag for hills".

I have had a go with the 10%: I think that I have got this right. Can people test to make sure? Thank you all very much!

Slowing down at signals is not fixed ...

As for the circular routes, can you think of a reason why a game carried over from 10.11 could show a different behaviour than a newly started game? Are there any variables which could preserve wrong travelling times forever? I'm asking because I just can't reproduce it in a new devel branch toy game, but as I said, I can't start a full new game at the moment.

Testing the latest version, I can also reproduce the "unnecessary braking for signals on diagonal track" bug. It's odd that the behaviour on diagonal track should be different from on straight track.

If a route for a convoy is pre-calculated only up to the next waypoint, the convoy brakes to stop at the waypoint until the next partial route is pre-calculated.

That's why my test-bus stops at the bottom of a slope  ::(

I'm going to see, if I can avoid braking before signals ...
I could avoid braking before signals ...

Now waggon_t::ist_weg_frei() uses the same convoy_t::calc_min_braking_distance() method that convoi_t::calc_acceleration() uses. It includes the 10% safety margin.
And waggon_t::ist_weg_frei() considers diagonal tile distances correctly now by using the route_infos convoi_t::calc_acceleration() does as well.

My test-bus of course still stops at waypoints, as the above fix is in waggon_t  ::(
I'm going to see, how I can help the bus ...

Bernd,

thank you very much for your work - that is helpful. Shall give it a test when I get a chance. In the meantime, may I ask why you have disabled the cumulative drag for hills?

I switched it off for testing. I found it easier to test with immediate drag effect.
Feel free to remove the added line and activate it again.

Bernd,

thank you very much for your work on this. I have now integrated this into -devel (and reverted the disabling of cumulative drag for hills). Can people test whether this fixes it?

As to the circular routes, the difficulty is that it is extremely difficult to isolate any particular cause in a game with a large number of different routes, as it is almost impossible to identify when the code is stopped at a breakpoint whether any particular route is being used, which is why I always test with one route games. Have you checked whether amending the schedules will cause the timings to revert to a sensible level?

There doesn't seem to be any more unnecessary braking on diagonals in the latest version. Thanks Bernd!

Thank you for testing, Carl - most helpful!

@James

I'll give amending of schedules a try later today.

Hein,

as to the weird XP bug with the physics - you mentioned that the result was affected by whether you had a cityrules.txt file in the directory, is that right? Can you confirm whether this remains the case, and whether it works correctly on an entirely clean install?

Edit: Can you also re-test the circular route thing with the latest version of -devel? I am wondering whether the issue that afflicted docks might have had some relevance here.

In my branch "devel" at https://github.com/BerndGabriel/simutrans-experimental (https://github.com/BerndGabriel/simutrans-experimental) the following fixes and changes are present:

Fixed:

   
• Rolling resistance issue: Was: the longer the convoy the lesser the rolling resistance. Now: Calculate median rolling resistance of the vehicles.
• Avoid division by zero in Carl's "new formula" in simhalt.cc (happened in a standard savegame I loaded).

Changed:

   
• unit of get_effective_power_index() and geared_power from kW to W.
• unit of get_effective_force_index() and geared_force from kN to N.
• geared_power and geared_force become arrays. Array index is speed in m/s, array index range is 0..max_speed. Allows arbitrary power resp. force characteristic curves (e. g. respecting efficiency).

Quote from: Bernd Gabriel on May 28, 2012, 10:17:10 AM
Avoid division by zero in Carl's "new formula" in simhalt.cc (happened in a standard savegame I loaded).

Thanks for catching that one Bernd!

Bernd has recently pushed a fix, which I have now merged into the -devel branch, relating to an uninitialised variable when reading the rolling resistance value. Can anyone re-test to see whether this fixes the Windows XP problem?

It's looking very good indeed, the bugged max speeds are gone! However, I -think- there's now a different smaller problem: some of the trams are showing an extraordinary acceleration. It's not like they reach max speed within zero time, but certainly within a very short time span and much faster than others. Two of those are the Double Deck Open-top Tram and the Double Deck Closed-top Tram.

Edit: Oh, and loading a savegame created with one of the previous devel executables (a debug build) leads to this:
(http://i.imgur.com/JI6ey.png)
I presume that might be because the rolling resistance variables aren't set in those savegames ...

Hein,

thank you for testing that. I'm afraid that I can't reproduce the trams issue (although haven't tried on the XP virtual machine). Can you test to see whether you still get the problem if you re-compile the pakset with the makeobj from -devel?

As to the saved games, there are a few places in the -devel branch when I change the saved game file format - there are usually warnings when I do this, so this is not unexpected behaviour.

Thank you again for testing!

Hein,

if you don't want to build Pak128.Britain-Ex yourself, I have now uploaded a binary version of a testing release to use with -devel here (http://forum.simutrans.com/index.php?topic=10144.new#new).

Schedule Minimum load:

• Tooltip says 'enter a value between 0 and 400', but the actual maximum is 255.  Only really noticeable for stagecoaches, where a full load is 300%; almost nothing else can be over 150%.
• Clicking the arrows does not cycle between typical useful values, including 100%, but around a strange sequence, different in the two directions.  Going up gives 0, 4, 28, 52, 132, 8, 28, ... . Going back gives 0, 144, 132, 52, 28, 4, 0, ... .

Commit 6be2b59 (30/6/2012), compiled on Mac OS X 10.6.8.

Thank you for the report! Found and fixed. The issue was that the variable was a uint8 rather than uint16. Unfortunately, replacing it with a uin16 requires a different save game format, which means that any games saved with previous self-compiles from -devel or the RC binary will not load with the latest -devel build or any subsequent release. This does not affect official release versions.

The latest release candidate (see here (http://forum.simutrans.com/index.php?topic=10145.msg96324#msg96324)) no longer seems to display the trams issue according to my tests with the Windows XP virtual machine. Does anyone care to re-test to verify?

More scheduling issues.  In this savegame (https://www.box.com/s/7395facecb19bb56ca6b), there are three empty Telford-Daventry trains waiting at Telford Station.  There are two distinct errors here:

• The trains should leave when 100% full, and there are enough passengers waiting at the station to completely fill two trains.
• Non-full trains are scheduled to leave 10 times per 'month', but two of the waiting ones have been allocated the same departure slot.

I have seen similar behaviour earlier in the same game.

Commit d2dbf1d (15/7/2012), compiled on Mac OS X 10.6.8, plus Pak128.Britain-Ex-0.8.4.

Error (2) occurs pretty rarely, but it's been present since the advent of convoy spacing.

As for error (1) -- this is intended behaviour. Convoys will only load passengers 10 minutes before their scheduled departure. (If you accrue more than 100% load worth of passengers before this point, you probably need to increase the frequency of service!) The reason for this feature is that, otherwise, passengers could potentially board a convoy which still has (e.g.) 1 hour to wait before departure, and in the process miss several other services which would leave before that.



If you want a convoy to leave whenever its full load is present, I recommend you turn off convoy spacing and just use "minimum load = 100%".

Quote from: carlbaker on July 26, 2012, 12:02:44 PM
Error (2) occurs pretty rarely, but it's been present since the advent of convoy spacing.

It wasn't the only time it occurred at this station.

QuoteAs for error (1) -- this is intended behaviour. Convoys will only load passengers 10 minutes before their scheduled departure. (If you accrue more than 100% load worth of passengers before this point, you probably need to increase the frequency of service!)

Hmm.  OK.  I had noticed the new 'don't load until shortly before departure' behaviour, but it hadn't occurred to me that it might be intended to apply even when there were enough passengers for an early departure.   

I understand the motive for it, and clearly it is a good thing when spacing is entirely determined by the schedule, but it does rather break the combination that I had been using in the previous released version of primarily scheduled services with occasional early departure 'specials'.   The motive for this was mainly to allow for a little sloppiness in time-keeping; if an incoming convoy just missed the scheduled time, and demand was heavy, it would leave soon anyway, rather than making the whole line slip a slot.   This was good for road services, where congestion always makes strict timetables iffy; more relevantly to the present case, it also helped smooth transitions from one schedule to another, when the frequency of services was changed.  This was exactly how the mess in this savegame arose: because there was a backlog of passengers, I had just increased the frequency of services, which meant that successive incoming trains just missed the new scheduled departure times, which (thanks to this 'ten minute' rule) further increased the backlog ... 

Best wishes,
Matthew

I'm a big fan of options that allow everyone to tailor functionality to their needs. As such I'd be in favour of an option in the settings menu which disables the "wait until 10 minutes before departure before boarding" -- though I think it should be enabled by default. This should be fairly easy to code, I'd have thought. What do you think, James?

QuoteIt wasn't the only time it occurred at this station.

There are certain patterns that can set it off. If a convoy arrives at a spacing station at around the same time as another has been timed to leave, then that convoy can often be placed into the "wrong" slot, leading to more than one convoy being timed to leave in a single slot. I'm not sure we've managed to pin down the cause of this, yet.

Thank you both for your feedback on this - this is a most useful discussion. It is a good idea, I think, to make the waiting until ten minutes before departure time optional, but I think that this might well be done better on a per schedule basis than applied generally to the game as a whole. This would allow greater flexibility. Do you think that you could manage to code it in that way, Carl? I can provide assistance as far as modifying the loading/saving element of things if necessary (I can't remember whether you are familiar with this aspect of things or not - it can be slightly tricky to code if you're not familiar with it). It would need to be a variable of the schedule_t (formerly fahrplan_t) class, and load and save with schedules.

I've not yet had any successful experience with coding loadsave stuff -- modifying equations and departure conditions has been about my limit so far. I think I could just about figure out how to code this as a universal setting, but I doubt I could do it on a per-line basis. I never even managed to figure out how to convert the "max wait for load" into an integer :(

Actually: it may be beneficial to have both a universal setting and a line-specific setting for this. The universal setting would specify the default status of a line (i.e. wait until 10 minutes before departure, or don't) and the line-specific setting could be designed for exceptions to this rule. My thought here is that if we make it purely a per-line setting, then one of two groups -- either players like me or players like mcollet -- are going to have a lot of tedious work in switching this setting to either on or off on all their lines (depending on the default setting). If the default status of the setting can be altered, along with per-line alterations, we'll avoid this. 

If you are able to code a value into the schedule class, and you let me know that it will need loading/saving, I shall be able to code the loading/saving routine for it. The way to do it on a per line basis would be to have an option in the schedule dialogue box entitled something like, "always load immediately" and a tooltip stating something like, "If this option is selected, this convoy will always load immediately on arriving at a stop, even if its scheduled departure time is more than 10 minutes in the future". There could be a bool load_immediately member in the schedule_t class recording the status of this option.

As for the default setting, this can work, and can be saved locally only (in umgebung_t rather than settings_t), as the per line settings are the only things that will need to be loaded/saved over the network.

That sounds do-able. I'll take a look at this in the next few days, then. Thanks for the pointers, James! :)

One thing of which you ought to take note, however: when you are implementing the UI for changing schedules, make sure that it is network safe (in other words, that, in a network game, the instruction to change the schedule (in this case, the always load immedaitely option) should be trasmitted from the client to the server, and from the server to all the clients). This means using the tool interface from simwerkz.cc. What I recommend is looking at the way in which other boolean items in the schedules are changed and copy that, modifying the identifiers for the particular tool as necessary.

I hope that that is clear.

Quote from: carlbaker on July 27, 2012, 10:59:43 AM
There are certain patterns that can set it off. If a convoy arrives at a spacing station at around the same time as another has been timed to leave, then that convoy can often be placed into the "wrong" slot, leading to more than one convoy being timed to leave in a single slot.

Yes, that might be the culprit in this case -  odd things seemed to happen more often when one convoy arrived while another was in the process of reversing to leave. 

Quote from: jamespetts on July 27, 2012, 11:15:12 AM
It is a good idea, I think, to make the waiting until ten minutes before departure time optional, but I think that this might well be done better on a per schedule basis than applied generally to the game as a whole.

If an explicit option is introduced, then per schedule, please: even though I have pointed out some drawbacks of the ten-minute rule, I still agree that is is desirable for stably running rail timetables, and would not want to disable it globally.   But even better than 'yet another option' would be automatic determination:  if the route has an impossibly large early departure target (i.e. is running strictly to schedule), the ten-minute rule should apply; if it has an achievable one (i.e. is at least partly demand-driven) it should not.

Best wishes,
Matthew

Here's a small puzzling thing I just noticed. In the latest version, the Class 170 turbostar in Pak128.BritainEx, in 3-car formation, reports only being able to max out at 133km/h with an empty load. In fact, such a convoy should be able to reach 160kph. All of the vehicle's stats seem to be correct in the dat file (verified via TheRailwayCentre etc), so I presume something is up on the game's side of things.

I note that this is in fact unchanged since 10.11, so whatever's wrong here has not been introduced by recent changes.

Thank you for the report - I have asked Bernd to look into this.

Thanks. I should note that this is not isolated to that vehicle, but occurs with several of the sprinters in pak128.BritainEx. 2 and 3 car formations of these will often display max speeds much lower than they presumably should be.

Yes, I noticed that, too. I am wondering whether it is related to air resistance, as longer trains do not exhibit this problem.