News:

Use the "Forum Search"
It may help you to find anything in the forum ;).

Bugs on -devel branch

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

Previous topic - Next topic

0 Members and 2 Guests are viewing this topic.

Bernd Gabriel

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

Carl

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

jamespetts

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?
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

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



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

jamespetts

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?
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 on Windows 7 64-bit. Given that you're getting the same results as Bernd, I'll re-compile and re-test some more.

jamespetts

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

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

jamespetts

Hmm. Carl - which version of Pak128.Britain are you using?
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 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

jamespetts

Don't worry - thank you for the work!
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

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

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

Carl

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.

jamespetts

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!
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,

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


jamespetts

Thank you both for your reports! Hein - would you mind uploading the saved game that you used to enable further 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.

HeinBloed

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
new devel 10.12 game: http://simutrans-germany.com/files/upload/circular_broken_again.sve
(previously known as "tttron")

jamespetts

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

#55
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:



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:


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







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

jamespetts

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

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:





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

jamespetts

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

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

2. Map rotation speed heavily degraded (not in 10.11)
As mentioned here: 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

4. Convoy replacing doesn't respect convoy constraints
The bug reported here: 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

6. Slope physics broken (not in 10.11)
As mentioned here: 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, 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.
(previously known as "tttron")

jamespetts

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

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

jamespetts

Hein,

thank you for the report. I think that I have fixed this - would you mind re-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.

HeinBloed

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

jamespetts

Can you be more specific as to the circumstances in which the crashes occur?
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

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

jamespetts

I think that I have managed to fix the crash - would you mind re-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.

HeinBloed

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

jamespetts

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!
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 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









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