aRV CB 11 Discussion

[wallyweb]

Somebody has teased us mercilessly by making aRVs available in TTDPatch. Unfortunately it would seem that they forgot to look beyond articulated trams and buses.
Realistically, articulated trucks consist of a tractor (cab) that leads a significantly longer trailer.
Apparently Callback 11 is required to make this work.
It would seem that there are problems centered around CB11. The attached png shows them up graphically (Yes, I removed the tractor's rear wheels and made them a part of the trailer - not so glitchy on slopes that way ). This has raised some questions:
- Currently all fails with values 03, 04 and 05 - Anything 0x03 and above results in flying trucks
- The question whether a CB 11 result of 0x05 or 0x04 is needed to get to 12px (or even less) begs an answer.
- There is a lack of documentation for CB11 for RVs in NewGRF specifications; especially ...
. What is considered full length (7/8 or 8/8) and does not require CB11 ?
. What has to be returned to get to a particular vehicle length?
. What is the minimum allowed vehicle length (at values less than 20px for the tractor, e.g. 12, the trailer floats away and yes, mountains and curves are set to 0) ?
What x-/y- sprite offsets should one use for a given vehicle length?
Also, CB11 is not called inside the depot for the lead part of the truck (horizontal view); but it is called a zillion times outside the depot while the truck is moving.

Any constructive comments would be greatly appreciated and may help some enterprising Patch dev work towards a resolution.
... and no, switching to OTTD is not an acceptable solution. This is a TTDPatch issue and should be resolved therein if at all possible.

[AndersI]

Not really a comment on CB11, but...

Why do you need to make the cab a shorter sprite? Couldn't you just fiddle with the offsets to make the cab end be positioned at the right place relative to the trailer? Like some steamers + tender do.

[wallyweb]

Not really a comment on CB11, but...

Why do you need to make the cab a shorter sprite? Couldn't you just fiddle with the offsets to make the cab end be positioned at the right place relative to the trailer? Like some steamers + tender do.

I'm not sure what you mean. A 12px cab is about proportionally correct for the rig, but CB11 says the cab must be at least 20px long for the trailer not to wander away on its own.

The image below might give a better idea of what I would like to achieve.

Truck.png (2.96 KiB) Viewed 5781 times

[JGR]

On the topic of ARV decoupling I feel the need to link this pic: http://www.tt-forums.net/viewtopic.php?p=694180#p694180, screen 1...

I haven't had the time or energy to try and debug this (for me) persistent problem (and other ARV, and short and/or tram related bugs). So if it turns out to just be GRF related, that would probably make it easier to fix... (I really don't want to have to dig through the movement code).

Anybody else been getting results like the linked screenie? (It's Generic Tram Set v0.4 BTW...)
If it's just me/that/some GRFs, then maybe I've got a duff GRF (I've done bugger all testing so far, major procrastination at work sadly...)

I don't really know much if anything about GRF coding (except what I learnt doing newsignals), so I can't really comment on CB11 itself...

[Lakie]

Probably is an issue with Shortened Articulated Road Vehicles, whilst I don't remember a huge amount of the code, a lot of it was hacks and a lot of guess work as to how it should all operate, I remember I fixed some various issues to try and keep it working but unfortunately I don't know the details of how various aspects like shortened Road Vehicles was implemented.

That said, I think the whole Articulated Road Vehicle system needs a proper rewrite as currently it has a lot of bugs and glitches in it and doesn't 100% work correctly, even with my changes to the system.
I don't have any where near the time to look at it though.

~ Lakie

[wallyweb]

@JGR ... Unfortunately Zephyris is not set up to test under the Patch. I think Dave Worley ran some Patch tests for him but I don't know the results. Does that glitch in your png still happen? Is it random or does it only happen with specific trams? It may be length related, but I don't know if Zephyris had any trams less than 20px long.

@Lakie ... Thanks for posting. I can well understand your hesitation to get into something that could be long and arduous. Hopefully somebody might have a grf work around pending somebody taking on Assembly Language and the Patch.

[AndersI]

I'm not sure what you mean.

Make the sprite 20px even if the interesting part is shorter. Adjust the offsets to make it look right relative the trailer.

[OzTrans]

... Make the sprite 20px even if the interesting part is shorter. Adjust the offsets to make it look right relative the trailer.

That is not a good idea; in fact the sprite of the truck is 12 pixels long, not 16. If you pretend the truck is 20 pixels and adjust the offset of the trailer. Then, your turning axis of both the truck and trailer is too far off-centre. Your vehicles will turn in a funny way (too early or too late), give you graphical glitches and the sprite of the trailer is outside its bounding box.

What needs to be done is fixing CB 11 for articulated road vehicles, that allow (leading) trucks to be 12 pixels long (3/8th), just like rail vehicles.

[wallyweb]

in fact the sprite of the truck is 12 pixels long, not 16.

Oops! Fixed in the post. Thanks for noticing that.

What needs to be done is fixing CB 11 for articulated road vehicles, that allow (leading) trucks to be 12 pixels long (3/8th), just like rail vehicles.

And for that we need a Patch dev comfortable enough with CB11 to work on it, although, from what Lakie said, the problem may not lie with CB 11 itself, but rather how it is implemented in an apparently very messy aRV code.

[JGR]

@Wallyweb (previous post)
I only use two models of tram ATM IIRC, that 3 part tram from the Generic Set (which consistently spreads apart before losing the trailers completely), and a non-articulated unit from the German Tram set which randomly gets "stuck" (ie. become stationary on the tram track tile while reading a non-zero speed, but it seems to be much more frequent at specific points, after corners IIRC, I haven't worked it quite out yet...)
I should probably test other sets out and/or do some debugging/fiddling at some point...

Perhaps if I get stranded anywhere dull without good internet this summer, I'll be motivated into debugging it

[stevenh]

Don't even bother trying... It's been years since I wrote that code and it is nothing but hideous.
The best approach now would be to view the OTTD code and translate to TTDPatch. Sure, it's imitation, but it's the best form of flattery.

I abandoned the aRVs project but didn't have the balls to remove it from TTDP. My code was entirely unfinished when it was released into the Beta/Alpha and you can probably also hold me responsible for halting development on TTDP.

[wallyweb]

... and/or do some debugging/fiddling at some point...

I'm sure you do, but I have to ask ... mountains and curves set to 0?

Perhaps if I get stranded anywhere dull without good internet

They still have those places?

The best approach now would be to view the OTTD code and translate to TTDPatch. Sure, it's imitation, but it's the best form of flattery..

Now there's a thought. In fact, I think that was done to get aRV refitting working properly.

... but didn't have the balls to remove it from TTDP.

Good thing you didn't because some of it works. GRVTS is a fine example.

I abandoned the aRVs project

Would you by any chance be susceptible to any of the following enticements to your return?
- worship and prayer
- begging and pleading
- threats of violence
- outright bribery

[JGR]

I'm sure you do, but I have to ask ... mountains and curves set to 0?

Erm yes. I'm assuming that that's OK. I remember that 3 was Bad™, but didn't Lakie fix that...? Can't remember about 1 and 2.

They still have those places?

They really do...

I abandoned the aRVs project but didn't have the balls to remove it from TTDP. My code was entirely unfinished when it was released into the Beta/Alpha and you can probably also hold me responsible for halting development on TTDP.

It's not like everyone else's code smells of blossom and looks like art in x86 form (quite the opposite from what I can see).
Don't worry about leaving things unfinished, there are plenty of areas which are not entirely complete, and it's better to have something than nothing. As for halting development on TTDP, I call bovine faeces on that one, no one is to blame for anything here.

(I still have to finish newsignals, I got half-way through the next phase before running out of steam...)
(Another off-topic peeve of mine, vehicles in depots who have an order for that same depot just sitting there and depreciating rather than doing something intelligent, another one on the list for of stuff for me to look at sometime. Also, why do trains that have been in depots for a long time emerge with a s*** reliability rating? It makes no sense...)

Sorry if I'm grouchy, I'll go sleep now...

[wallyweb]

I'm sure you do, but I have to ask ... mountains and curves set to 0?

Erm yes. I'm assuming that that's OK. I remember that 3 was Bad™, but didn't Lakie fix that...? Can't remember about 1 and 2.

afaik 3 3 3 0 is still the way to go.

They still have those places?

They really do...

Nirvana ...

[Lakie]

Actually, last I remembered, 3333 worked better for me than 3330, could be wrong though. (And its only curves which effects it, if I remember correctly).

~ Lakie

[wallyweb]

Actually, last I remembered, 3333 worked better for me than 3330, could be wrong though. (And its only curves which effects it, if I remember correctly).

I just tested 3333 for both curves and mountains and it seems to be good. , so if anybody has any problems, time to upgrade their Patch to the latest nightly.

... And now back to our regularly scheduled CB11 discussion ...
Unlike grf coders and devs, I have too much time on my hands, which means I was able to do a little research:
- Vehicles can access callbacks through their respective Action0 properties (1E for trains, 17 for road vehicles)
- Both these properties access the same Wagon length callback (11)
- For trains, if callback 11 fails, property 21 is called.
- For road vehicles, if callback 11 fails, an 8/8 length is used (no property 21 for you)
- The wiki description of callback 11 does not describe any limitations.
- The property 21 does describe limitations:

This property reduces the length of train vehicles, in units of 1/8th (12.5%). The value 00 means the vehicle has the full length, 01 means shorter by 1/8th (12.5%), up to 05=shorter by 5/8ths (62.5%). Larger numbers will not work properly (**), except at the end of the train*. The vehicle length is set whenever it leaves a depot. This property does not work for the first vehicle in a train (i.e. the engine).

* This means that it is only safe to use values larger than 05 in the length callback making sure that they are only returned for the very last vehicle in the train. Otherwise the train will occasionally fall apart, with the wagons after the shortest one stopping to move.

** This restriction has been removed in OpenTTD r15793. Every vehicle can have a length between 1/8 and 8/8 independent of its position in the chain.

The points in bold are exactly what is happening with articulated road vehicles, so perhaps the problem does not lie within the aRV code, but with whatever sets the limitations for property 21. Maybe this is where the devs should be looking for a fix.

Yes, I know ... I don't know what the Heck I'm talking about. but the coincidences are a bit too obvious and ... well ... Where's there's smoke, there's fire.

Any thoughts?

[Patgreg]

This property does not work for the first vehicle in a train (i.e. the engine).

So this means the aRV cab unit can not be shortened in length! Now there's a pity.

[wallyweb]

This property does not work for the first vehicle in a train (i.e. the engine).

So this means the aRV cab unit can not be shortened in length! Now there's a pity.

Actually it can, just not to the extent that would be appropriate.

[Lakie]

Considering no-one actually knows how the shortened RV code works, let alone how it interfaces with aRVs its hard to know if the same limitations apply, although they probably do.
Have you tested all the possible values to see where it does break down (if so is it the same point)?

~ Lakie

[wallyweb]

Considering no-one actually knows how the shortened RV code works, let alone how it interfaces with aRVs its hard to know if the same limitations apply, although they probably do.
Have you tested all the possible values to see where it does break down (if so is it the same point)?

~ Lakie

Hii Lakie,
From the first post:

- Currently all fails with values 03, 04 and 05 - Anything 0x03 and above results in flying trucks

Is this what you were looking for?