News:

The Forum Rules and Guidelines
Our forum has Rules and Guidelines. Please, be kind and read them ;).

Bugs on -devel branch

Started by Carl, April 06, 2012, 09:38:00 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Carl

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 (reported fixed on that thread) persists in its original form.


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

jamespetts

Examples would be helpful - thank you.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Carl

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 (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 )

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
(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.

jamespetts

#3
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.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Carl

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.

Carl

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/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.)

jamespetts

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?
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Carl

#7
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.


jamespetts

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.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Carl

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.

jamespetts

Hmm. I shall have to look into that when I get a chance.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Bernd Gabriel

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.
The journey is the reward!

jamespetts

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!
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Carl

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.

jamespetts

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!
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Bernd Gabriel

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 ...
The journey is the reward!

jamespetts

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.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Bernd Gabriel

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.
The journey is the reward!

jamespetts

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.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Bernd Gabriel

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().
The journey is the reward!

jamespetts

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

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Carl

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

jamespetts

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.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Carl

#23
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

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.

Carl

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:



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!

jamespetts

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.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

jamespetts

I have now fixed the block reservation issue.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.


HeinBloed

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:


after:


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).
(previously known as "tttron")

Carl

#29
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.

jamespetts

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.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

jamespetts

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 asking for help.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

HeinBloed

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.
(previously known as "tttron")

Bernd Gabriel

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.

The journey is the reward!

Carl

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?