Call backs tutorials or any help at all!

[Ronnie Clark]

I've tried going through the latest newgrf.txt, but still can't really
fathom out this "call backs" mallarchy.

Are there any tutorials out there? Or an explanatory file to go with
"callbacks.grf"?

If anyone out there can help with this simple (I hope) call back query, is
it possible for a wagon to have a default appearance UNLESS it appears as
the first wagon after the engine? If so, could anyone "give" me the code for
this situation:

Actions 1 and 2 have already created cargo-ids 00 and 01, where 00 is the
default appearance and 01 is its appearance after the engine. They are to be
tied to veh-id 0B when the train engine is veh-id 0A.

What other actions 0 and 2 are needed to do this?

Ronnie
--
Volunteer guard on the Great Central Railway, Loughborough, Leicestershire
Visit the world's only double track preserved steam railway!
http://www.gcrailway.co.uk

[michael blunck]

Ronnie Clark wrote:

Are there any tutorials out there?

Hi Ronnie,

Yes. You may check the ttdpatch wiki pages. AFAIR those tutorials and also the
callback descriptions there
http://wiki.ttdpatch.net/tiki-index.php ... ion0Trains
are somewhat more detailed than in the newgrf.txt file.

Or an explanatory file to go with "callbacks.grf"?

I could sent you commented excerpts from the DB set implementation, just tell me
what kind of callbacks you would like to take a closer look onto.

If anyone out there can help with this simple (I hope) call back
query, is it possible for a wagon to have a default appearance
UNLESS it appears as the first wagon after the engine?

That´s possible, however you wouldn´t need a callback for that.

If so, could
anyone "give" me the code for this situation:

Actions 1 and 2 have already created cargo-ids 00 and 01, where 00
is the default appearance and 01 is its appearance after the
engine. They are to be tied to veh-id 0B when the train engine is
veh-id 0A.

What you´ll need is another action 2 which would check var "40" (consist
position and length) and decides if your waggon for position "1" (i.e. after the
engine). According to newgrf.txt:

"returns dword 00nnbbff, where ff is the number of vehicle
within consist counted from engine (front), e.g. engine=0,
1st wagon/mail comp.=1, 2nd wagon/rotor=2, 3rd wagon=3 etc.,
bb is the number counted from end, e.g. last wagon=0,
next-to-last wagon=1 etc., and nn is the total number of
vehicles in the consist."

i.e. your additional action 02 would be:

-1 * 14 02 00 xx 81 40 00 FF 01 (01 00) 01 01 (00 00)

You can then use c-id "xx" for further processing or for an action 03.

HTH

regards
Michael
PS: don´t send a "multipart" mesage in case you´d like to contact me in pm ...

[Ronnie Clark]

Thanks Michael...

I only just managed to learn the basic style of GRF coding, and now I come
back 6 months later it's even more complicated!

One thing I was wondering is is it now possible (using callbacks or
otherwise) to differentiate between graphics that appear in windows in the
game and those actually on the track? One thing that I've always found
annoying is that the trains never actually appear to run on the tracks, but
instead sort of ride next to them. I've just designed a new carriage, with
offsets to put it on the tracks, and also full length so that in the
horizontal view the corridor connections of adjacent carriages join up.

The problem is, in all the windows, the coaches appear about three pixels
too high, and in the depot window, they're about 2 pixels too long.

Is they're any way around this, or is it a case of that if you want the
on-track graphics to work, you have to put up with the rest?

Ronnie
--
Volunteer guard on the Great Central Railway, Loughborough, Leicestershire
Visit the world's only double track preserved steam railway!
http://www.gcrailway.co.uk

[michael blunck]

Ronnie Clark wrote:

One thing I was wondering is is it now possible (using callbacks or
otherwise) to differentiate between graphics that appear in windows
in the game and those actually on the track?

I´m not really shure what you´re talking of, but I´d say "no" in general ... but
"yes" in that special case to follow.

[shifting vehicles vertically]

The problem is, in all the windows, the coaches appear about three
pixels too high, and in the depot window, they're about 2 pixels
too long.

Is they're any way around this, or is it a case of that if you want
the on-track graphics to work, you have to put up with the rest?

There´s a (relatively) new feature of the patch which deals exactly with that
problem. In fact it has been developed by Josef for the DB set XL which
implemented "driving on tracks" for the first time.

Only thing you´d have to do would be to include the special patch command:

-1 * 9 0D 8E 00 FF FF 02 00 00 00

before your vehicles´ definitions. This will result in shifting vehicles up two
pixels in train windows.

This is essentially an "action 0D" (set parameter value) which sets the special
variable "8E" (how many pixels to displace sprites in train windows) to "2". See
"action 07/09" and "action 0D" for details.

BTW, there´s another useful thing to do, namely to reset the ordering scheme of
vehicles which could have been possibly changed by a prior .grf file:

-1 * 6 00 00 01 00 00 1A

resets the ordering scheme for vehicles to the default (0 ... FF). This command
should be also issued before all vehicle specific actions.

regards
Michael

[Ronnie Clark]

-1 * 9 0D 8E 00 FF FF 02 00 00 00

-1 * 6 00 00 01 00 00 1A

These both sound very handy! Thanks!

That just leaves the in-depot problem. As I'm sure you know, when consists
are displayed in a depot window, the horizontal spacing between vehicles is
reduced.

The problem I'm facing with that is that graphics are being produced that
when the trains are out of the depot, in the horizontal view, they take up
the full width, and buffers/corridor connections between vehicles join up.

Sadly, when viewing graphics drawn like this in the depot, the reduced
spacing leads to graphics over-lapping.

http://www.blugman.freeserve.co.uk/scr4.gif shows what I mean.

Ronnie
--
Volunteer guard on the Great Central Railway, Loughborough, Leicestershire
Visit the world's only double track preserved steam railway!
http://www.gcrailway.co.uk

[michael blunck]

Ronnie Clark wrote:

[...]

That just leaves the in-depot problem. As I'm sure you know, when
consists are displayed in a depot window, the horizontal spacing
between vehicles is reduced.

Yes, I´m aware of this.

The problem I'm facing with that is that graphics are being
produced that when the trains are out of the depot, in the
horizontal view, they take up the full width, and buffers/corridor
connections between vehicles join up.

Sadly, when viewing graphics drawn like this in the depot, the
reduced spacing leads to graphics over-lapping.

http://www.blugman.freeserve.co.uk/scr4.gif shows what I mean.

Well, ATM there´s no cure for that overlapping problem. There´s only help for
the vertical alignment issue.

I have the same problem with the horizontal depot view, but I really don´t care
anymore ... :/

Apropos, another hint.

It *may* be that your engines resp. wagons are shifted horizontally accidentally
(unintentionally) because you modified their x/y-offsets during the process of
aligning them properly on-track. I.e. their alignment *looks* correct but
they´re *shifted* in one direction, nevertheless. If that´ll be the case,
they´ll be also misaligned in the depot window (there´s a "special" overlapping
between engine and first wagon in your picture).

A good method to test proper offset alignment is to stop a (preferably
symmetrically built, i..e. engine-waggon-waggon-engine) train and flip its
direction. If the train´s vehicles are well aligned the train wouldn´t "jump".
O/c this has to be tested in all four main directions ( / - \ | ), beginning
with the single engines ...

I found these "false" offsets also an additional contribution to the general
depot misalignment.

regards
Michael