2.0.1 alpha / 2.5 beta discussion
Moderator: TTDPatch Moderators
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
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
TTDpatch Developer 2005 - 2010 ~ It all started because of shortened vehicle not loading correctly, now look where I've gone with it!
Grfs coded ~ Finnish Train Set (Teaser) | Bm73 (Release 3) | Emu 680 (Release 3)| Glass Station (Release 1) | UK Roadset (Version 1.1a) | New Water Coasts (Version 7)
Pikka: "Lakie's a good coder, but before he'll add any feature to TTDP you have to convince him that you're not going to use it to destroy the world as we know it."
Grfs coded ~ Finnish Train Set (Teaser) | Bm73 (Release 3) | Emu 680 (Release 3)| Glass Station (Release 1) | UK Roadset (Version 1.1a) | New Water Coasts (Version 7)
Pikka: "Lakie's a good coder, but before he'll add any feature to TTDP you have to convince him that you're not going to use it to destroy the world as we know it."
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...
TTDPatch dev in retirement ... Search a grf, try Grf Crawler 0.9 - now with even faster details view and new features...
TTDPatch2.5 Beta 8
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
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 !
Code: Select all
508 * 14 02 00 00 81 01 00 FF 01 02 80 00 33 01 80
509 * 14 02 00 F8 81 40 08 FF 01 00 00 00 00 00 80
...
3388 * 9 02 00 00 01 01 00 00 01 00
3389 * 9 02 00 01 01 01 02 00 03 00
3390 * 15 02 00 AB 81 7E F8 00 FF 01 01 00 01 01 00 00
-
- Transport Coordinator
- Posts: 307
- Joined: 20 Jul 2005 16:27
- Location: Montreal
There are only two problems with that:CPCNMAN007 wrote:Hi, I full have problem with the TTDXC
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?
Reality is that which, when you stop believing in it, doesn't go away.—Philip K. Dick
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.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.
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]
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]
- Attachments
-
- SCR1.png (210.26 KiB) Viewed 20006 times
-
- TheGames.rar
- (1.03 MiB) Downloaded 471 times
-
- SCR1.png (85.55 KiB) Viewed 19883 times
Wie zich gelukkig voelt met het geluk van anderen, bezit een rijkdom zonder grenzen. (F.Daels)
Still the best OS around
Still the best OS around
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 have again a piece of reserved PBS track that wasn't cleared and it blocks a lot of trains inside a depot this time.
- Attachments
-
- TRP00.SV1
- The game
- (1.45 MiB) Downloaded 477 times
-
- SCR1.png (148.85 KiB) Viewed 19872 times
Wie zich gelukkig voelt met het geluk van anderen, bezit een rijkdom zonder grenzen. (F.Daels)
Still the best OS around
Still the best OS around
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.
Formerly known as r0b0t_b0y2003, robotboy, roboboy and beclawat. The best place to get the most recent nightly builds of TTDPatch is: http://roboboy.users.tt-forums.net/TTDPatch/nightlies/
- stevenh
- TTDPatch Developer
- Posts: 759
- Joined: 24 Jul 2005 05:07
- Location: Canberra, Australia
- Contact:
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.
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.
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.
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.
After loading a game, and after clicking the "Apply" button in the GRF status window.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 ?
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.[...] 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.
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.
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.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.
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).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 ?
Admittedly thats a little more than I wantted, but I'm fairly happy with it.
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: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.
I'm not sure why that happens, possibly a bug.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.
Never had any problems with my test grfs as such though.
Will have to investigate this...
~ Lakie
TTDpatch Developer 2005 - 2010 ~ It all started because of shortened vehicle not loading correctly, now look where I've gone with it!
Grfs coded ~ Finnish Train Set (Teaser) | Bm73 (Release 3) | Emu 680 (Release 3)| Glass Station (Release 1) | UK Roadset (Version 1.1a) | New Water Coasts (Version 7)
Pikka: "Lakie's a good coder, but before he'll add any feature to TTDP you have to convince him that you're not going to use it to destroy the world as we know it."
Grfs coded ~ Finnish Train Set (Teaser) | Bm73 (Release 3) | Emu 680 (Release 3)| Glass Station (Release 1) | UK Roadset (Version 1.1a) | New Water Coasts (Version 7)
Pikka: "Lakie's a good coder, but before he'll add any feature to TTDP you have to convince him that you're not going to use it to destroy the world as we know it."
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.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.
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.... CB 36 for prop 09 (train speed) is called when ...
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.Patchman wrote: ... I don't understand why you make the callback fail at all ...
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.
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.Patchman wrote: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.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.
Thanks for the help.
Who is online
Users browsing this forum: No registered users and 2 guests