2.0.1 alpha / 2.5 beta discussion

[michael blunck]

Didn´t you name a few of them yourself?

Apart from those "real bugs", I found especially annoying the many "cosmetic" issues, based on the different behaviour of MU sprites in the different windows (veh list window, train window, depot window). Which the todo list marks as "very urgent" BTW, but mostly date back to 2005.

I´ve filed many reports on these during recent years to Josef.

regards
Michael

[wallyweb]

Nope. Most things listed as "Very Urgent" here also need to be fixed. Especially the crashes.

Many of those would seem to be new features or feature upgrades rather than actual bugs. By any chance were some of those added after Patchman's last release where he said:

By now, the number of open bugs for the 2.5 version on the tracker http://wiki.ttdpatch.net/tiki-view_trac ... rackerId=1 is negligible, so unless new issues crop up in this version, there's a good chance that we'll be able to release the 2.5 stable version soon.

?
If that is the case then perhaps a "milestone" framework would be in order so as to give everybody some reasonable expectations as to when new features and new feature upgrades should be submitted. I can't help but think that some interesting set work might be held back pending stable beta releases which are not forthcoming due to the backdating of a feature. Unlike bugs, not-ready-for-prime-time features can always be put off to the next beta.
What are your thoughts on this?

[PikkaBird]

Didn´t you name a few of them yourself?

Hmm,

Well, if we're talking about articulated vehicles, I'm not aware of any in the current nightlies that can't be worked around with callbacks.

[krtaylor]

For what it's worth, I would welcome a stable "baseline" release. In recent months, it's been all alphas, and few even betas. I know this is better for the developers, and that's very important; however, for players (at least for me), the more stable beta releases were preferable.

[michael blunck]

Well, if we're talking about articulated vehicles, I'm not aware of any in the current nightlies that can't be worked around with callbacks.

Yes, sorry. I was talking about "articulated vehicles" when simply refering to "MUs".

And no, there are indeed a couple of issues which can´t be worked around with CBs:

- "Articulated coaches/waggons made from 2 vehicles with the same ID are showing double capacity in the train window but specified capacity in the buy menu." (bug tracker)

I don´t think I can (and neither should!) "work around" this one. It´s a conceptual flaw which has been discussed since years, and it couldn´t be dealt with using CBs, because we (still) lack CBs for capacity.

- text (name) will be positioned differently in the buying list and in the train windows, see example 1 in the attachment.

- In the train´s detail window, vehicles are displayed always facing the same direction (to the left) independent of their "real" direction of travel at that very moment. However, when using the "push-pull" feature (flipping sprites depending on the train´s direction) the train´s picture in the detail window "jumps" according to the different offsets of those flipped sprites, see example 2 (it could even stick out of the left side of the window, producing spurious litter on-screen).

This is especially nasty because offsets sometimes have to be different to avoid "jumping" of sprites of the real train in game (stop it and change direction: it should not move).

ATM, this is a "catch-22" situation, and it seems to need a complete rewrite, as the "todo" list suggests.

regards
Michael

[PikkaBird]

I don´t think I can (and neither should!) "work around" this one. It´s a conceptual flaw which has been discussed since years, and it couldn´t be dealt with using CBs, because we (still) lack CBs for capacity.

Edit: Sorry, I was wrong about this one.

- text (name) will be positioned differently in the buying list and in the train windows, see example 1 in the attachment.

It's not positioned differently; you're just putting a lot of whitespace in front of it so you can use a longer sprite in the buy menu. If you want different texts in the buy menu and the info window, that sounds like a feature request rather than a bug.

Personally, I'd use a shorter sprite in the buy menu (just one or two cars, rather than the whole set) and less whitespace.

This is especially nasty because offsets sometimes have to be different to avoid "jumping" of sprites of the real train in game (stop it and change direction: it should not move).

This seems to be a shortened vehicle problem; if the first vehicle in the train is shortened, you will get the "jumping" when reversing, regardless of whether that first vehicle is part of an articulated set or not. Personally, I think the "jump" is far more tolerable than the shift in the vehicle window - in fact, as the train has usually just started moving, it's practically unnoticable.

[michael blunck]

It's not positioned differently; you're just putting a lot of whitespace in front of it so you can use a longer sprite in the buy menu. If you want different texts in the buy menu and the info window, that sounds like a feature request rather than a bug.

IMO, the point is that the specified text is dealt with differently in the buy menu and in the info window. The buy menu doesn´t seem to have means to detect a longer sprite so the supplied text needs some additional whitespace, but the routine in the info window is using the computed length of the vehicle. O/c, text should be placed correctly in both cases, be it by debugging or by a "new feature", I don´t care.

This seems to be a shortened vehicle problem; [...]

Yes, o/c it is.

Personally, I think the "jump" is far more tolerable than the shift in the vehicle window - in fact, as the train has usually just started moving, it's practically unnoticable.

Not in all cases. And if you have noticed it once, you´ll see it everytime.

regards
Michael

[kvtb]

All of a sudden, a train crashed, and then TTD crashed too.
These are the messages that were written to console directly after TTD crashed/

wine: Unhandled page fault on read access to 0x00c1001a at address 0x5744df (thread 000b), starting debugger...
Unhandled exception: page fault on read access to 0x00c1001a in 32-bit code (0x005744df).
Register dump:
CS:0073 SS:007b DS:007b ES:007b FS:0033 GS:003b
EIP:005744df ESP:0033f938 EBP:0043a950 EFLAGS:00010202( - 00 - -RI1)
EAX:00000137 EBX:004e9564 ECX:00560006 EDX:00000246
ESI:00c1001a EDI:00667c1a
Stack dump:
0x0033f938: 00667c1a 0056bd7c 004e9564 004e98ea
0x0033f948: 013701b9 0056bda2 0056b2ad 00590a5d
0x0033f958: 004ab952 00010000 0055a207 0055a091
0x0033f968: 0033fe74 00405a18 7ffdf000 00115d54
0x0033f978: 7b8ad908 00000001 00000000 6940e0d3
0x0033f988: 0000000a 00000000 7bc3c8a2 7ed40000
Backtrace:
=>1 0x005744df in ttdloadw.ovl (+0x1744df) (0x0043a950)
2 0x0057346f in ttdloadw.ovl (+0x17346f) (0x005733ca)
0x005744df: cmpb $0x10,0x0(%esi)
Modules:
Module Address Debug info Name (84 modules)
PE 400000-c00000 Export ttdloadw.ovl
PE 10000000-1000c000 Deferred mpssnd_c
PE 69400000-6940f000 Deferred ttdpatch
PE 6bd00000-6bd0a000 Deferred dxmci
ELF 7b800000-7b926000 Deferred kernel32<elf>
\-PE 7b820000-7b926000 \ kernel32
ELF 7bc00000-7bc97000 Deferred ntdll<elf>
\-PE 7bc10000-7bc97000 \ ntdll
ELF 7bcb6000-7bd36000 Deferred libglu.so.1
ELF 7bd36000-7bdf0000 Deferred wined3d<elf>
\-PE 7bd50000-7bdf0000 \ wined3d
ELF 7bdf0000-7be40000 Deferred ddraw<elf>
\-PE 7be00000-7be40000 \ ddraw
ELF 7be40000-7be99000 Deferred shlwapi<elf>
\-PE 7be50000-7be99000 \ shlwapi
ELF 7be99000-7bf00000 Deferred msvcrt<elf>
\-PE 7beb0000-7bf00000 \ msvcrt
ELF 7bf00000-7bf03000 Deferred <wine-loader>
ELF 7bf3b000-7c000000 Deferred libasound.so.2
ELF 7c1f9000-7c213000 Deferred crtdll<elf>
\-PE 7c200000-7c213000 \ crtdll
ELF 7c213000-7c228000 Deferred midimap<elf>
\-PE 7c220000-7c228000 \ midimap
ELF 7c228000-7c24e000 Deferred msacm32<elf>
\-PE 7c230000-7c24e000 \ msacm32
ELF 7c24e000-7c279000 Deferred winealsa<elf>
\-PE 7c260000-7c279000 \ winealsa
ELF 7d02c000-7d044000 Deferred msacm32<elf>
\-PE 7d030000-7d044000 \ msacm32
ELF 7d046000-7d04b000 Deferred libxfixes.so.3
ELF 7d04b000-7d054000 Deferred libxcursor.so.1
ELF 7d054000-7d071000 Deferred imm32<elf>
\-PE 7d060000-7d071000 \ imm32
ELF 7d071000-7d077000 Deferred libxrandr.so.2
ELF 7d077000-7d07f000 Deferred libxrender.so.1
ELF 7d07f000-7d082000 Deferred libxinerama.so.1
ELF 7dcaa000-7dcac000 Deferred libnvidia-tls.so.1
ELF 7dcac000-7e532000 Deferred libglcore.so.1
ELF 7e532000-7e5be000 Deferred libgl.so.1
ELF 7e5be000-7e5c3000 Deferred libxdmcp.so.6
ELF 7e5c3000-7e5c6000 Deferred libxau.so.6
ELF 7e5c6000-7e6b7000 Deferred libx11.so.6
ELF 7e6b7000-7e6c5000 Deferred libxext.so.6
ELF 7e6c5000-7e6ca000 Deferred libxxf86vm.so.1
ELF 7e6ca000-7e6e2000 Deferred libice.so.6
ELF 7e6e2000-7e6eb000 Deferred libsm.so.6
ELF 7e6eb000-7e779000 Deferred winex11<elf>
\-PE 7e700000-7e779000 \ winex11
ELF 7e825000-7e845000 Deferred libexpat.so.1
ELF 7e845000-7e870000 Deferred libfontconfig.so.1
ELF 7e870000-7e884000 Deferred libz.so.1
ELF 7e884000-7e8ef000 Deferred libfreetype.so.6
ELF 7e8ef000-7e923000 Deferred dplayx<elf>
\-PE 7e900000-7e923000 \ dplayx
ELF 7e923000-7e937000 Deferred dplay<elf>
\-PE 7e930000-7e937000 \ dplay
ELF 7e937000-7e94a000 Deferred libresolv.so.2
ELF 7e94a000-7e968000 Deferred iphlpapi<elf>
\-PE 7e950000-7e968000 \ iphlpapi
ELF 7e968000-7e9bd000 Deferred rpcrt4<elf>
\-PE 7e970000-7e9bd000 \ rpcrt4
ELF 7e9bd000-7ea57000 Deferred ole32<elf>
\-PE 7e9d0000-7ea57000 \ ole32
ELF 7ea57000-7eae6000 Deferred winmm<elf>
\-PE 7ea60000-7eae6000 \ winmm
ELF 7eae6000-7eb2f000 Deferred dsound<elf>
\-PE 7eaf0000-7eb2f000 \ dsound
ELF 7eb2f000-7eb75000 Deferred advapi32<elf>
\-PE 7eb40000-7eb75000 \ advapi32
ELF 7eb75000-7eb81000 Deferred libgcc_s.so.1
ELF 7ec6b000-7ed28000 Deferred gdi32<elf>
\-PE 7ec80000-7ed28000 \ gdi32
ELF 7ed28000-7ee64000 Deferred user32<elf>
\-PE 7ed40000-7ee64000 \ user32
ELF 7ee85000-7ee9c000 Deferred libnsl.so.1
ELF 7ee9c000-7eea5000 Deferred libnss_compat.so.2
ELF 7efc8000-7efef000 Deferred libm.so.6
ELF 7eff5000-7f000000 Deferred libnss_files.so.2
ELF b7cc1000-b7ccb000 Deferred libnss_nis.so.2
ELF b7ccc000-b7cd0000 Deferred libdl.so.2
ELF b7cd0000-b7e11000 Deferred libc.so.6
ELF b7e11000-b7e28000 Deferred libpthread.so.0
ELF b7e39000-b7f4a000 Deferred libwine.so.1
ELF b7f4c000-b7f67000 Deferred ld-linux.so.2
Threads:
process tid prio (all id:s are in hex)
0000000c
0000000e 0
0000000d 0
0000000a (D) Z:\home\kvtb\stuff\Transport Tycoon Deluxe\Install\TTDLOADW.OVL
0000000b 0 <==

No CRASH* files were generated by TTDPatch,

UPDATE: here is a savegame with this strange crash...
It will happen on the 18th of January 2032 near Frankburg station.
Actually, no trains are involved. It seems like an explosion in the streets of Frankburg, near a cinema.

[DaleStan]

Is it possible to follow the OllyDBG instructions found in my .sig? If so, please do.

[Dropzone]

Actually, no trains are involved. It seems like an explosion in the streets of Frankburg, near a cinema.

If you look closely, there is a train involved (at least when I run that savegame). Just before the explosion, a Transrapid engine belonging to one of the AI companies spontaneously appears in an impossible location, and wiggles around a bit. About a second after that, another engine appears right on top of it, and apparently crashes into it - but only one of the engines is destroyed. Clicking on the surviving engine is what crashes the game for me.

[WWTBAM]

Lakie and I have working on the bug list and have gotten it down to 1. Pending the fixing of it, patchman has said he will post a 2.5 stable on the website.