Needing some help in coding of articulated trains...

[Regiovogel]

Hi Guys,

this is my first post to the forums, so I'd like to start with some thanking - I've been addicted to TTD for a while now and would like to make some graphics as my "private extension" to the fantastic DB Set.

Coding "normal" vehicles seems to be no real problem, after reading the grf tutorial and descriptions for several hours I finally worked out how to get it to life. At the moment, I'm working on a BR 628 DMU, but until now, I had no luck with implementing it as articulated vehicle.

Finally, I managed to get *something* into TTD, but it isn't really the way it should be.
As you can see in the attached picture, the rear part of the train is twice there:

something must have gone wrong here ;)

BR628.png (15.78 KiB) Viewed 6098 times

I don't know what could be wrong... as there is no tutorial for articulated vehicles, it's not easy to understand what parts of code are really needed for this feature. Even decoding other grfs and searching the forums (yeah, I tried that ) could not help me.

Here's what my nfo looks like, there are some comments in my file, but since most people here will not be able to understand them, I removed them...

Code: Select all

// Automatically generated by GRFCODEC. Do not modify!
// (Info version 7)
// Format: spritenum pcxfile xpos ypos compression ysize xsize xrel yrel
    0 * 4	 1A 00 00 00
    1 * 8	 08 06 "SS" 04 00 00 00
    2 * 42	 00 00 0F 01 69
  00 BA 66
  06 03
  05 00
  09 78 00
  0B 93 02
  12 FD
  1E 10
  14 48
  15 00
  16 27
  19 08
  1D 00 00 00 00
  21 00
  22 22
  1B 00 00
    3 * 4	 01 00 02 08
[...2 sets of realsprites...]
   20 * 9	 02 00 00 01 01 00 00 00 00
   21 * 9	 02 00 01 01 01 01 00 01 00
   22 * 14	 04 00 04 01 69 "BR 628.4" 00
   23 * 14	 02 00
  02
  81 10
  00 FF
  01
  04 FF
  01 01
  FF FF
   24 * 14	 02 00
  03
  81 0C
  00 FF
  01
  02 00
  16 16
  01 00
   25 * 7	 03 00 01 69 00 03 00
   26 * 7	 03 00 81 04 00 01 00

Furthermore, the train is displayed in the purchase window with a capacity of 144 passengers which changes to 72 when bought...
Apart from these difficulties, there are some more things which I couldn't achieve until now. How can I get different weight and capacity for the two wagons?

Some help would be greatly appreciated!

Greetings from Nürnberg,
Regiovogel

[Regiovogel]

...well, now I have to answer myself. Sorry for that. I fixed the graphics problem. I simply used the wrong Cargo ID for the first part. I thought I had fixed that already...

Now there's only the problem left that there is no weight added by the cab car and the capacity is not right. Any hints for that...?

[DaleStan]

Now there's only the problem left that there is no weight added by the cab car and the capacity is not right. Any hints for that...?

The first is as defined. If you use powered wagons, you can make the cab car have weight, or you can just pack all the weight into the lead vehicle.
The second is a bug in TTDPatch, I believe.

[Regiovogel]

Thanks DaleStan, I put the weight in the first vehicle now. I also solved the capacity problem (next time I will have to read the wiki even more closely...).

Now there's another problem with the cargo types. If I set property 1D (refittable cargo types) to 00 00 00 00 (which I think would stand for "no refitting possible"), the vehicle is refittable for everything except oil and the additional types introduced by new industry grfs. If it is set to 01 00 00 00, what should be "only refittable to passengers", it says "refittable" in the purchase window and there is a refitting option - the only cargo type shown there is passengers. Well... What have I done wrong again? I just don't get it...

[michael blunck]

[...] What have I done wrong again?

Nothing. It´s a peculiarity of the more recent versions of TTDPatch.

Either live with it, or specify more refitting options (e.g., MAIL, VALU, TOUR, ...), or discard property 1D altogether (if at all possible, depending on the veh-ID of the "overridden" vehicle).

regards
Michael

[Regiovogel]

Ah, thanks. Glad to know I understood how it should work and it was not my fault. I've chosen the possibility of taking mail as second cargo type for it now... looks a bit similar to the DB Set, doesn't it

I finally got everything working as I wanted. You can buy the whole DMU as one vehicle and it changes its livery to traffic red in 1997.
But I wouldn't be telling you all that if there was no problem left at all
After getting the more complex code for the livery choosing in, there happen some strange things to the capacity. In the purchase window, it is shown as 146 passengers what it should be. When bought, this changes to 186 passengers now. If I remove all my newly introduced VarAction2s, it behaves as it should be. It was working normally before and I didn't touch the Action0.

I suppose that I really made a mistake this time...?

[michael blunck]

In the purchase window, it is shown as 146 passengers what it should be. When bought, this changes to 186 passengers now.

Well, just a wild guess without taking a look into your .grf: did you include CB16 for the purchase menu as well (c-ID FF in action3)?

regards
Michael

[Regiovogel]

In the Action3 I'm calling a VarAction2 when the c-ID is FF. This VarAction2 decides whether the mint-green or the traffic red graphic should be used there. Before the traffic red livery was in there, this was just the direct call of the BasicAction2 of the graphic that I want to be displayed in the purchase window.

The thing that's confusing me is that the capacity is displayed right in the purchase window and magically changes when the train is bought. It makes absolutely no sense where the additional 40 passengers are coming from...


I've attached my nfo, perhaps someone is able to find the mistake(s). And if some of my comments don't say what the bytes really mean, just tell me...

[michael blunck]

OK, I´ve checked the .nfo and made a couple of changes. Some with regards to bugs and some with regards to the structure, for a better understanding.

First of all, you mixed graphics and callbacks. You´ll have to keep them in two separate chains. Consequently, in CB16 you´ll have to use the veh-ID (69) of your DMU, not the c-ID (was 09 in your file).

In addition, you had no mechanism for distinguishing between the first (VT) and the second (VS) vehicle, with regards to graphics.

And if this will be used without additional middle coaches, you don´t need the override in your second action03.

Last thing is as expected: you´ll have to include CB16 as well in the chain for the purchase menu ("Kaufansicht") because otherwise the capacities cannot be evaluated properly.

regards
Michael

Code: Select all

    2 * 62	 00 00 19 01 69 [...]

//------------------------------------------------------------------
// Triebzug
//------------------------------------------------------------------

// VT (vorwärts)
   53 * 9	 02 00 00 01 01 00 00 00 00 // mint
   54 * 9	 02 00 01 01 01 01 00 01 00 // rot

// VT: mint oder rot?
   55 * 14	02 00 02 81 C4 00 FF 01
                              00 00 48 4C  // 1992 - 1996
                              01 00        // 1997-

// VS (rückwärts)
   56 * 9	 02 00 03 01 01 02 00 02 00 // mint
   57 * 9	 02 00 04 01 01 03 00 03 00 // rot

// VS: mint oder rot?
   58 * 14	02 00 05 81 C4 00 FF 01
                              03 00 48 4C  // 1992 - 1996
                              04 00        // 1997-

// Grafik: VT oder VS?
   59 * 16 02 00 06 81 40 80 FF 00 02 01 // MOD 2 wg. evtl Vielfachsteuerung (?)
                              05 00 01 01  // VS
                              02 00        // VT

// CB: articulated -> (69) - 69
   60 * 14	02 00 07 81 10 00 FF 01
                              69 FF 01 01  // VS (hinten)
                              FF FF        // das war´s

// CB oder Grafik?
   61 * 14	02 00 08 81 0C 00 FF 01
                              07 00 16 16 // articulated
                              06 00       // Grafik

//------------------------------------------------------------------
// Kaufansicht
//------------------------------------------------------------------

   62 * 9	 02 00 00 01 01 04 00 04 00 // mint 
   63 * 9	 02 00 01 01 01 05 00 05 00 // rot

// mint oder rot?
   64 * 14	02 00 02 81 01 00 FF 01
                              00 00 48 4C  // 1992 - 1996
                              01 00        // 1997-

// CB oder Grafik?
   65 * 14	02 00 03 81 0C 00 FF 01
                              07 00 16 16 // articulated (wg. Kapazitätsberechnung!)
                              02 00       // Grafik

   66 * 10	03 00 01 69 01 FF 03 00 08 00

[Regiovogel]

Thank you very much, Michael. I just noticed that I hadn't seen that the cab car was added as seperate vehicle with a capacity of 40 passengers... If I had looked more closely at it, I wouldn't have had to be so confused about that

I think I don't exactly understand the VarAction2 (06) you have made to decide if VT or VS. Why is it needed to make the mod 2 calculation? (perhaps I simply had luck, but it worked perfectly for me the way I did it)
I'm not going to put a middle coach into it, but what would have to be done to expand it to one additional coach? Simply replace the mod 2 with a mod 3 and check for 01 and 02?

I'll try it now with your code. If I run into some new problems, I will post it here...

[Regiovogel]

OK, here we go. It works very well now. The only thing is that the capacity is doubled now, but that won't be a big problem with the 628

Regarding the possibility to make complete MUs as an articulated vehicle - is it possible to vary the capacity (and perhaps also the cargo type) of some vehicles in the consist? Thinking of train sets like the ICE2 or something...

[michael blunck]

I think I don't exactly understand the VarAction2 (06) you have made to decide if VT or VS. Why is it needed to make the mod 2 calculation?

Well, it´s not needed, only when going to allow multi-control for that DMU. Otherwise, it´d be sufficient to check if the vehicle in question would be number 0 (VT) or number 1 (VS) in the consist:

VT VS
00 01

By including a <varadjust> containing a modulo value (see http://wiki.ttdpatch.net/tiki-index.php ... nalAction2 ) you may allow easily for multi-control:

VT VS VT VS VT VS
00 01 00 01 00 01

O/c then, you´d like to apply additional means to limit the total number of vehicles among checking for other sublties. Something like this:

Code: Select all

// make callback for engine attach: only 4 * BR612, not more
   -1 * 14      02 00 04 82 40 10 FF 01
                        FE FF 00 06
                        23 FF           // "falsche Anzahl von Wagen" 

// type of alien wagon/coach?
   -1 * 14      02 00 05 81 42 00 FF 01
                        21 FF 00 03     // "Reisezugwagen kann nicht angehängt werden"
                        20 FF           // "Güterwagen kann nicht angehängt werden"

// make callback for engine attach: only BR612 itself, nothing else
// check prop25
   -1 * 14      02 00 06 81 42 18 FF 01
                        04 00 20 20     // OK
                        05 00           // alien wagon/coach
 

HTH

regards
Michael

[Regiovogel]

Yes, the explanation of the modulo helped a lot. Should be clear now...

Also, the limiting code for the attaching of vehicles seems to be very useful. I'd like to use something like that, but I'm afraid I don't understand it once again

Let's start at the bottom. You check prop25 of the vehicle. If I'm reading the wiki correctly ("User-defined bit mask to set when checking veh. var. 42"), you have to set this property in the Action0 to an useful value? Is this 20 in this case?

The Action2 above that (typo of alien wagon) is also not clear to me... Am I right that you check the "tt" part of var. 42, so if the cargo type is passengers or mail, the first range is used? What does the "21 FF" and "20 FF" mean then?

And finally the first one... you are checking the "nn" part of var. 40 of the existing train, right? What does the ""FE FF" and "23 FF" call here?

Well, that were a lot of questions... hoping you're not bored by it, but it's not easy for a nfo beginner...
(I suppose you didn't see my last post before?)

Greetings,
Regiovogel

[michael blunck]

The only thing is that the capacity is doubled now, but that won't be a big problem with the 628

Well, you´ll have to fiddle a bit with the capacities for the constituent vehicles, i.e., in their action0s.

Regarding the possibility to make complete MUs as an articulated vehicle - is it possible to vary the capacity (and perhaps also the cargo type) of some vehicles in the consist?

In principle, yes. But for an articulated consist this would be quite limited, rather than with adding single passenger coaches or mail vans. E.g., for 3-part MUs it´d be useful to design a refittable coach acting as middle part of a MU. But o/c, the general problem with refitting of articulated vehicles remains: you can´t remove any part of them for explicitly refit.

Also, the limiting code for the attaching of vehicles seems to be very useful. I'd like to use something like that, but I'm afraid I don't understand it once again

Well, this would be based on CB 1D ("wagon attach").

Let's start at the bottom. You check prop25 of the vehicle. If I'm reading the wiki correctly ("User-defined bit mask to set when checking veh. var. 42"), you have to set this property in the Action0 to an useful value? Is this 20 in this case?

Ah yes. I simply copied that code snippet from the v0.9 source of the DBXL, but it´s not much useful as a standalone example.

In the DBXL, I´m using different methods to allow/disallow linking of engines/coaches/vans, depending on the actual situation. In this case, I´m checking prop25´s bit mask, but in other situations (like e.g. yours), it´d be more useful to do something like this to disallow linking of any other material to the 628:

Code: Select all

// attach: only veh-ID "69" allowed
   -1 * 14      02 00 04 81 C6 00 FF 01
                        02 00 69 69     // OK
                        24 FF           // "falscher Wagentyp"

O/c, in your simple example, you could use prop25 as well, but only in the more complex context of the DBXL, using prop25 makes better sense in a couple of situations.

The Action2 above that (typo of alien wagon) is also not clear to me... Am I right that you check the "tt" part of var. 42, so if the cargo type is passengers or mail, the first range is used? What does the "21 FF" and "20 FF" mean then?

Yes. "21 FF" and "20 FF" are callback results, refering to error messages. See http://wiki.ttdpatch.net/tiki-index.php ... ttached_1D_

And finally the first one... you are checking the "nn" part of var. 40 of the existing train, right? What does the ""FE FF" and "23 FF" call here?

Same as above. These are all in a "CB 1D" chain and "FE FF" simply allows attaching.

[edit: I removed a bug in the code change above. In the "Kaufansicht" part it must read:

Code: Select all

// mint oder rot?
   64 * 14   02 00 02 81 01 00 FF 01
                              00 00 48 4C  // 1992 - 1996
                              01 00        // 1997-

instead of "02 00 02 81 C4 00 FF 01" because you´ll have to check the actual year, but not the age of the vehicle.

regards
Michael

[DaleStan]

Code: Select all

 // Grafik: VT oder VS?
   59 * 16 02 00 06 81 40 80 FF 00 02 01 // MOD 2 wg. evtl Vielfachsteuerung (?)
                              05 00 01 01  // VS
                              02 00        // VT

I have a very strong preference for doing <and-mask> = 01 and no add/div/mod block. div and mod are expensive operations; 02 00 06 81 40 00 01 01 / 05 00 01 01 / 02 00 does the same task without the expensive div.

Of course, this doesn't work for non-power-of-two modulos.

[Regiovogel]

Just seen that - in sprite 60, there is the VS added. The ID used there is "69 FF". Why is the "FF" needed here and what's the difference to "69 00" at this point? I couldn't find a real explanation in the wiki for that:

For each of the ranges to check, you give the set-id as a WORD value (i.e. with a 00 following, e.g. set-id 5 becomes 05 00), followed by the low and high limits of this range.

This seems to me as if it doesn't matter if I put 00 or FF there...?

I suppose, attaching vehicles with different capacity can be achieved by replacing the 69 here with another vehicle ID? Hiding this vehicle from the purchase list could be done with "moving" it to another climate?

I think that this should've been enough explanation of CB 1D now... I'll try it, thank you

I removed a bug in the code change above.

Ah, well, yes... hadn't seen that either.

@DaleStan: Thanks, I'll try that. Sounds reasonable

[michael blunck]

I have a very strong preference for doing <and-mask> = 01 and no add/div/mod block. div and mod are expensive operations [...]

Good point. Has this been profiled sometime?

Of course, this doesn't work for non-power-of-two modulos.

AFAIR, most MU´s in the new set are 3-part. However, I could change that for all the steamers.

Just seen that - in sprite 60, there is the VS added. The ID used there is "69 FF". Why is the "FF" needed here and what's the difference to "69 00" at this point?

"69 FF" (or "69 80", you need only to set the high bit) is a callback result (which you´ll need here), but "69 00" is not.

I suppose, attaching vehicles with different capacity can be achieved by replacing the 69 here with another vehicle ID? Hiding this vehicle from the purchase list could be done with "moving" it to another climate?

Yes, e.g., "69 + 1B" or something like that. And yes, you may hide it like we do it with tenders or use one of the existing coaches/vans.

regards
Michael

[Regiovogel]

"69 FF" is a callback result (which you´ll need here), but "69 00" is not.

Ah, ok. No more guessing needed about FF or 00 in the future

OK, so I think all my questions should be answered (at least for some time...).
Thank you for your help!

[DaleStan]

I have a very strong preference for doing <and-mask> = 01 and no add/div/mod block. div and mod are expensive operations [...]

Good point. Has this been profiled sometime?

Not to my knowledge. At one point I tried to profile TTDPatch, but it just doesn't lend itself well to profiling, and it is, of course, completely impossible to do static analysis. If memory serves, TTD's sprite drawing functions were the biggest CPU load, at 20-40% of the total processor time; nothing else even came close. It could be, however, that the sprite selection is a larger code block than the drawing and it drew less notice because the load was spread over a larger block of code. It could be the other way too, that sprite selection is a smaller code block, and the fact that it drew no notice means that it really isn't a significant load at all.

My recollection is that VTune did something to the effect of breaking the execution every few ms, grabbing EIP, and drawing a histogram to show which addresses were most commonly executed.

[Regiovogel]

[...] so I think all my questions should be answered [...]

Well, I just hoped that... I gave the solution with different vehicle IDs a try. The capacities were set to different values. Now there is no weight added by the second car (don't think that this was different before?), the capacity in the purchase window is 2 times the capacity of the first part - thus wrong. When the vehicle is bought, the capacity is right again
Something coded wrong again or simply not possible to display this in the right way?