Transport Tycoon Forums

I guess it's due to DirectX being differrent and incompatible with it.
It gives me an error about DPLAY.dll not existing, so I can only guess.
I believe Oskar may know more than me about this though.

~ Lakie

Yes that can be true, the support for very old stuff like DirectX 3 & 5 is in Windows 2003 Server and Vista non existent. What you can do is: Get an dplay from a winxp maschine and put it under your game folder. I guess it will need some other dlls aswell...

I tried this one but found two problems and went back to Beta 7.
Problem 1 was fishing stopped working
Problem 2 was all stations generate traffic as soon as they are built

Mervyn

What is wrong with sprite 3390 ? tested with 2.5 beta 7 and 8; NfoRenum likes it !

Hi, I full have problem with the TTDXC

CPCNMAN007 wrote:Hi, I full have problem with the TTDXC

There are only two problems with that:

1: You posted this in the wrong topic. This topic is about TTDPatch; TTDXC is a different program, written by a different person. You will have more luck in the [TTDX Configurator news topic]. I know the title is misleading, but everyone seems to post their problems there.

2: You didn't say what your problem was. Even if this was the right topic, we couldn't help without knowing what your problem is. Imagine that you're going to your doctor and say "It hurts". Do you think the doctor could cure you with this, without knowing what hurts exactly, how bad the pain is, etc?

OzTransLtd wrote:What is wrong with sprite 3390 ? tested with 2.5 beta 7 and 8; NfoRenum likes it !

May be a bug in the procedure call code, probably the error message is wrong. Please send me the grf file for debugging.

Patchman wrote:May be a bug in the procedure call code, probably the error message is wrong. Please send me the grf file for debugging.

The .grf is too big, but here is a cut down version, containing 1 engine with 4 calls to the same procedure, but a different procedure than above, all triggering an invalid sprite message.

Thanks, I've fixed the bug. This code is different in the nightlies so you can't test it right away but it'll work in beta 9.

Another strange thingy discoverd with PBS.
In the picture you can see a train (inside the circle) waiting before a PBS juntion just before three tunnels.
Somehow the left tunnel is blocked, PBS wise, because the train won't enter that tunnel anymore.

I have a save before and after it happend, configs the same as a few posts up.
This happens rather regulary and not only with tunnels but also with other junctions.
But at least with the junctions you can see the reserved piece of track.

The tunnel is empty, at least forcing the train through doesn't result in a crash.

[edit] I dynamyted the tunnel and rebuild it, and it hasn't happend since, which is about 2 game years. [/edit]

[edit2]Ooh crap, don't bother downloading this game because it didn't catch that bug after all, there was another reason that train didn't enter the tunnel : it doesn't lead to it's destination. The bug however is/was valid, I just have to catch it. [/edit2]

[edit3]In the last picture are the ghost PBS reservations I was talking about, only catching it before it happens is somewhat impossible. [/edit3]

I know it won't help, but I'll post this anyhow, you never know after all it might help anyway.
I have again a piece of reserved PBS track that wasn't cleared and it blocks a lot of trains inside a depot this time.

I don't quite understand the current position of the patch. Although I'm having a lot of fun with the latest nightlies, those are alphas for 2.6. But 2.5 is still in beta stage, isn't it? Does that mean some of the improvements that are in the current nightly builds will still go into 2.5? Or is beta 8 of version 2.5 the final version?

the betas are only for bugfixing. fixes go into the nightlies, then get aded to the betas. Thats what i understand.

The Beta is for the final 2.5 release... minimal 'new features' are to go into it... just bug fixes...

We started the 2.6 a0 stream (nightlies) so that idiots like me could have a base to start working on other features (that wont be complete for ages).
These features are all going to introduce bugs/issues and so will never get merged into 2.5 and will be in 2.6 (?).

So, even though most of the patch developers are coding new features into the nightlies, the main focus should be to repair the issues in the 2.5 betas and get 2.5 out so everyone can focus on 2.6.

Thanks, stevenh, that enlightens me (us?).

Problems with CB 36, prop 09 (train speed) ...

The use of CB36 does give me problems.

First, I'd like to know, when exactly is CB36 for property 09 (train speed) called ? I know, it is called whenever a vehicle is attached or removed to/from a train and when the train leaves the depot. What are the other occasions ?

With a rather complex speed determination, it would be prefereable to limit the number of times the speed is determined. I only want to set the speed when the train is constructed or altered; i.e. the train is stopped in a depot. For all other occasions, I let CB36 fail. But failing CB36, results in the original speed (action-0 prop-09) to be applied again; I would like that the current speed (which has already been set) be retained when CB36 fails. I could return a speed of 32767 (FFFFh) to indicate to do nothing or the callback could simply do nothing when it fails.

Further to that, when in callback 36 incorrect train/vehicle information is retrieved. When constructing the very first train (#1), there are no problems, everything works as expected.

But whenever further trains are constructed, vehicle variable 42 (tt of 42) and/or 60 (vehicle count) [the ones I use] return information from train #1 or some other source. e.g. if train #1 is a freight train, when buying the loco for train #x, it already knows it is a freight train, but there are no wagons attached yet and the loco has no cargo. Also the initial speed is taken from train #1 (regardless whether train #x uses the same or another loco), this however could be because of an incorrect vehicle count (variable 60); i.e. wagons in train #1 are counted. Attaching wagons to train #x will fix those problems sometimes.

Note : TTDPatch 2.5 beta 8 for WIN being used.

OzTransLtd wrote:First, I'd like to know, when exactly is CB36 for property 09 (train speed) called ? I know, it is called whenever a vehicle is attached or removed to/from a train and when the train leaves the depot. What are the other occasions ?

After loading a game, and after clicking the "Apply" button in the GRF status window.

[...] For all other occasions, I let CB36 fail. But failing CB36, results in the original speed (action-0 prop-09) to be applied again; I would like that the current speed (which has already been set) be retained when CB36 fails.

It is not possible to determine whether the top speed comes from the callback, from a change in the grf, or something else, so after loading a game and resetting the graphics, the callback has to be called to check this. It must not fail outside of the depot.

However, I don't understand why you make the callback fail at all. It is called very rarely anyway (precisely for this reason), so it should not make a significant difference if it is expensive to compute.

Further to that, when in callback 36 incorrect train/vehicle information is retrieved. When constructing the very first train (#1), there are no problems, everything works as expected.

This might be a bug. It is possible that the variables are not initialized correctly when the loco is bought, and only when a wagon is attached. I'll probably need a grf exhibiting the problem to test this though.

OzTransLtd wrote:First, I'd like to know, when exactly is CB36 for property 09 (train speed) called ? I know, it is called whenever a vehicle is attached or removed to/from a train and when the train leaves the depot. What are the other occasions ?

Well, it's called in the buy window, leaving the depot, applying new grf settings and when a train leaves a station. (Also when loading a saved game).
Admittedly thats a little more than I wantted, but I'm fairly happy with it.

OzTransLtd wrote:With a rather complex speed determination, it would be prefereable to limit the number of times the speed is determined. I only want to set the speed when the train is constructed or altered; i.e. the train is stopped in a depot. For all other occasions, I let CB36 fail. But failing CB36, results in the original speed (action-0 prop-09) to be applied again; I would like that the current speed (which has already been set) be retained when CB36 fails. I could return a speed of 32767 (FFFFh) to indicate to do nothing or the callback could simply do nothing when it fails.

Why do you make it fail, it's called like all other callbacks to get a new value, if it fails it uses the default value for the train. (Which was how it was decided to work).

OzTransLtd wrote:Further to that, when in callback 36 incorrect train/vehicle information is retrieved. When constructing the very first train (#1), there are no problems, everything works as expected.

I'm not sure why that happens, possibly a bug.
Never had any problems with my test grfs as such though.
Will have to investigate this...

~ Lakie

OzTransLtd wrote:But whenever further trains are constructed, vehicle variable 42 (tt of 42) and/or 60 (vehicle count) [the ones I use] return information from train #1 or some other source.

This should be fixed in the next nightly/beta. I haven't been able to reproduce it because I don't have your grf file, but the problem apparently was that the speed is computed before these variables are initialized. However, I'm not sure how var.60 could misbehave, so if that still doesn't work I'll need a test grf that exhibits the problem.

... CB 36 for prop 09 (train speed) is called when ...

As long as it is only called in the depot, leaving the depot, loading a saved game and applying the .grf (the latter 2, I didn't think of) then I have no problems with that and I can live with leaving a station as well.

Patchman wrote: ... I don't understand why you make the callback fail at all ...

The rationale was, not to go through the speed determination, unless the train was stopped (manually), which it is when it is in the depot and being constructed or altered. I have no problems to remove the 'is it stopped' check and return a callback result at all times; this I have done now.

The speed determination can be rather lengthy, using veh var 60 (veh count), which is a computable one; it checks whether a wagon of a lower speed than the engine is present in a train; the faster the engine is the more wagons need to be processed (wagons that are faster or have the same speed as the engine are ignored). After the lowest speed has been found, the speed is set to this, unless it is a freight train, which involves a few other checks. ATM, I'm still in the process to consolidate the number of sprites (currently 528) used.

Patchman wrote:

OzTransLtd wrote:But whenever further trains are constructed, vehicle variable 42 (tt of 42) and/or 60 (vehicle count) [the ones I use] return information from train #1 or some other source.

This should be fixed in the next nightly/beta. I haven't been able to reproduce it because I don't have your grf file, but the problem apparently was that the speed is computed before these variables are initialized. However, I'm not sure how var.60 could misbehave, so if that still doesn't work I'll need a test grf that exhibits the problem.

That's ok. I'm not sure myself, whether it was just 42 or 60 as well. I'll check it again, when beta 9 is out. I'm also going to recode it. If I have further problems, I'll let you know.

Thanks for the help.