Transport Tycoon Forums

Under certain circumstances, which I have not been able to pin down, TTD seems to get stuck in an infinite loop trying to create a new company.

I have TTD set to "Competitor start time: Immediate".

Symptoms:
- In the first few game days after starting a new game (not affected by Cht:year), TTD quits responding completely, except that the music continues playing.
- TTD is, at this time, using 90+% processor power, for no apparent reason.
- If a "New company launched" news message appears, TTD does not get stuck in this infinite loop.

Here's my ttdpatch.cfg. I've checked experimentalfeatures.cooperative; the infinite loop happens with it both on and off. Since this seems to happen something like half the time, and nobody else has reported it, I think it's a safe assumption that I'm doing something strange. Any ideas where else I should look?

In case it makes any difference, I'm using the Windows version.

I've just tried this, but I couldn't reproduce it. I've started 40 random games with your .cfg file, and while there were a few games where an AI company did not immediately get created, none of them locked up.

Unfortunately, it's very hard to guess what could be causing this. If it happened before the game got started, I would've guessed it's because of invalid house or bridge data, but then you shouldn't even get to see the game at all.

So, unless you have a debugger handy (or want to download ollydbg), I'm afraid you'll have to try and fix this yourself. Perhaps it's a bad .grf file, you could try disabling grf files in newgrfw.cfg until the problem disappears, if it does at all.

If you want to try ollydbg, download and install it. Then run ttdpatch and wait for it to lock up. Now start ollydbg and choose File->Attach, and attach to ttdloadw.ovl. Ignore the warning. After it's done loading, press F7 once and then take a screenshot and send it to me.

Now I can't reproduce it either.

I'll keep Ollydbg around, though.

OK, it's happening again.

I've discovered a new symptom: TTD refuses to release control of the screen until killed. Fortunately taskman can usurp control.
I did figure out how to get around this (if it's minimized, there's no control to release), and here's screenshot from OllyDbg. I wasn't sure if the MMX or 3DNow! registers were relevant, so I included them. (Come to think of it: 3DNow! registers on a P4? Whatever.)

A couple presses of F7 did not get me out of NTDLL, so I hit the "Run until return" button, which brought me here. This is the thread that's eating the CPU. I chopped off the status bar, which reads "Thread 000000F4 terminated, trace stopped"

This hang appears to be associated with having the USSet (v0.85) loaded.

Very odd. The hang is in the calculation of train var. 42 (consist cargo). Apparently there is a consist with no end, i.e. it somehow loops back on itself.

I have no clue how that could happen in a freshly started game :/

This appears to be happening to other people too.
Patchman, is there anything else I can capture/post/&c. that would help you figure out what's causing this?

I wonder if the US Set might (inadvertantly, perhaps) be using var. 42 in the AI selection code (callback 18). That could cause this behaviour.

In that case, it would be necessary to find out which US Set sprite is using that variable. Fortunately, TTDPatch always records the set and sprite it is processing, for use in the crash log. So the easiest way to read that information, is to force a crash.

When this problem happens, repeat the steps you did in OllyDbg, and when you're at the TTDPatch thread (memory range 600000 and up), press "space" to assemble new code, then enter "UD2" and confirm. Then press F9 to return control to TTD. The debugger will then catch the "invalid opcode" exception, but to generate the crash log you have to pass it on to TTD by pressing Shift-F9, maybe several times.

When you have the crash log, the last line will indicate the sprite that was being processed.

Would it be also possible to figure this out by looking in the US set GRF file?

In principle? Yes.

In practice, you're looking at a file of 5800 lines, of which at first glance about 150 make use of these variables. Figuring out which one of these might happen in a callback chain is going to be a lot more work than making the game crash. In addition, if my guess was wrong, making the game crash will still tell you which sprite causes it.

Ah.

I suppose the NFO file would be easier to tell. But I understand about the crash. I personally haven't had this problem, but then I wouldn't, since I don't use the AI and haven't in years.