Transport Tycoon Forums

Here's an updated win32 package. Same as before, applied the nma-r24984.diff and compiled without music support and increased Newgrf limit.

cirdan wrote:

maquinista wrote:Maybe I have found a bug. I had this crash thrice, It's when the orange train tries to cross the signal.

Wow, I am getting more bug reports this week than in a whole year (which is fine: if there are bugs, I want them fixed).

maquinista wrote:I have four files (crash.dmp, crash.log, crash.png and crash.sav). If You want, I can post them here.

If you can reliably reproduce the crash, it would be best if you could post a savegame from before the crash.

I hope that this could be useful. This patch is very interesting, I have attached two examples of usage.

NOTE: the file is here: http://www.tt-forums.net/viewtopic.php? ... 0#p1066000

Supercheese wrote:Here's an updated win32 package. Same as before, applied the nma-r24984.diff and compiled without music support and increased Newgrf limit.

Thank you--your help is certainly allowing wider testing.

maquinista wrote:I have four files (crash.dmp, crash.log, crash.png and crash.sav). If You want, I can post them here.

Unfortunately, I have no way of uncompressing a .rar archive. Could you (or anybody else) post its contents in another format? Better yet, could you post a savegame from before the crash (it is easier to debug)?

I got an assert when trying to place tram tracks on a bridge, I took a screencap of the crash to illustrate.
I could also provide the savegame via PM, if needed, but the assert can easily be replicated simply by starting a new game, building a road bridge, and attempting to add tram tracks.

Supercheese wrote:I got an assert when trying to place tram tracks on a bridge, I took a screencap of the crash to illustrate.
I could also provide the savegame via PM, if needed, but the assert can easily be replicated simply by starting a new game, building a road bridge, and attempting to add tram tracks.

Argh, yes, there was a stupid typo in the code that adds a roadtype to an existing bridge. That must have crept in with a recent rebase.

maquinista: I am having trouble finding all the newgrfs used in your savegame, and I cannot reproduce your bug on my own in a new game, so fixing it is going to take longer.

cirdan wrote:

Supercheese wrote:Here's an updated win32 package. Same as before, applied the nma-r24984.diff and compiled without music support and increased Newgrf limit.

Thank you--your help is certainly allowing wider testing.

maquinista wrote:I have four files (crash.dmp, crash.log, crash.png and crash.sav). If You want, I can post them here.

Unfortunately, I have no way of uncompressing a .rar archive. Could you (or anybody else) post its contents in another format? Better yet, could you post a savegame from before the crash (it is easier to debug)?

This is the same file in ZIP, also, I have attached two files which there aren't online (Bananas).
These files are under development, maybe the fail could be caused by a bug on SpainSet or Spaintracks (speedrails_OTTD.grf).

maquinista wrote:This is the same file in ZIP, also, I have attached two files which there aren't online (Bananas).

Thanks for the files; indeed, those were the GRFs I could not find. Now I can load your savegame... only to have OpenTTD complain that the savegame is broken because it references invalid PersistentStorage. Since I am pretty sure I did not touch anything related to PersistentStorage, I am at a loss about how the savegame got broken or what to do with it. The crash log is not of much help, either, because it has no debugging information, so I cannot recover the call stack.

maquinista wrote:These files are under development, maybe the fail could be caused by a bug on SpainSet or Spaintracks (speedrails_OTTD.grf).

Well, the log says something about a GRF error, but I think it is unlikely that this is the cause of the crash (the assertion you got means that the game attempted to update signals on a bridgehead from the wrong side).

Updated binary, used nma-r24987.diff and same process as before.

I'm getting an assert as described in the screenshot.

Steps to reproduce:

-Load a grf that provides articulated road vehicles or trams
-Start a new game, build a road as in the screencap (abrupt end)
-Build any articulated RV/tram and when it reaches the end of the road the assert will trigger

I'm using the binary as posted in the preceding post.

Now, you are making me work hard.

It was just another overzealous assert, or, rather, an assert in the wrong place (it should apply only to one branch of a conditional, not to both).

(Or we could rationalise it because having articulated road vehicles turn around in the open is a danger to road safety. )

Fixed thusly.

Many thanks for the fix (and bump to higher revision) .

Win32 binary attached using nma-r25034.diff and same procedure as the others.

Another small cosmetic item; in-city custom bridgeheads do not generate 'sidewalk' tiles.
See image below.

You have my attention on this patch. Very well done.
Looking forward to custom tunnel entries too.

Just downloaded binary because I have no idea how to compile Openttd and it looks nice! I downloaded game from the 1.3.0-RC1 and when I opened it it seems to work nice, but all one way roads were gone and on their places there were normal roads. Is it possible to fix this or is it only because change from the stable to patched version.

Katve wrote:Just downloaded binary because I have no idea how to compile Openttd and it looks nice! I downloaded game from the 1.3.0-RC1 and when I opened it it seems to work nice, but all one way roads were gone and on their places there were normal roads. Is it possible to fix this or is it only because change from the stable to patched version.

If a savegame made with trunk (or, in this case, a release candidate) does not load properly, then that is a bug. The attached patch should fix this particular one (loading of one-way roads); thanks for the report.

shampie wrote:Another small cosmetic item; in-city custom bridgeheads do not generate 'sidewalk' tiles.
See image below.

Graphical glitches are currently very low priority for me. I hope you understand: I am still trying to iron bugs out (though I am a bit surprised that there are not many of them), and fixing those glitches would increase the size and maintenance burden of an already extremely deep development branch. On the other hand, this particular issue would likely be easy to solve, since the map array has enough spare bits in road bridgeheads to store pavement status.

shampie wrote:You have my attention on this patch. Very well done.
Looking forward to custom tunnel entries too.

I am afraid I do not have any immediate plans to add custom tunnelheads. They were accounted for in the map array design, but they break the "single tile surface" assumption in the code; that is, that (ground) vehicles on a tile always lie on a certain plane such that their height is always a function of their (x,y) position (bridge and tunnel middle parts do not count, since they are not really part of the tile). Implementing custom tunnelheads would therefore imply even greater changes to tile track status callbacks, pathfinding, signal handling, etc. and these subsystems are far from simple.

Moreover, I am hesitant to add new features to this branch without a clear idea of what I am going to do with it in the long term. I posted this patch here for review and testing, and I have received invaluable help with that, but I also did it to get an idea about its chances of trunk inclusion, and I do not think there are many. So, while I am still keeping the patch up to date with respect to trunk, and fixing bugs, I do not intend to add new features unless I really feel it is worth the effort.

New binary using nma-r25048.diff + increased grf limit.

Note some changes regarding cargo subtype refits in trunk (http://binaries.openttd.org/binaries/ni ... ngelog.txt).

Oops..

Assertion failed.
See below image.
When trying to remove the railroad section indicated in the screen shot with the 'red' tracks the error pops up.
Enjoy!

shampie wrote:Oops..

Assertion failed.
See below image.
When trying to remove the railroad section indicated in the screen shot with the 'red' tracks the error pops up.
Enjoy!

Well, a worthy bug at last, and not just a typo or a wrong assertion.

The problem here is that attempting to remove a stretch of rail that includes both endpoints of a bridge will try the removal twice in the test run, leading to mismatching costs in the test and exec runs. Trunk does not have this problem because the rail removal tool just ignores bridges there, but that is out of the question for custom bridgeheads.

Here is a new version of the patch.

New binary, as usual.

Great job! I hope it gets into trunk sometime soon.
One thing about tunnels I think should be very useful and relatively easy to implement (just guessing, I'm not an experienced coder myself) is having sloped tunnel entrances on flat tiles, just as bridge heads can be on flat tiles. Is there some subtlety that makes this particularly hard to implement?

Code-wise, I do not think there is anything that would impede implementing that, although it would have an impact (finding tunnel exits would be less efficient, for instance).

On the other hand, you can already build a tunnel as in the attached screenshot, which more or less achieves what you want.