Transport Tycoon Forums

Yesterday michi_cc submitted a new misc_flag and callback for all vehicle types, the "allow autorefit" flag (nfo, nml) and callback 15E (nfo, nml) which controls refit costs.

The idea is such that a refit between, say, coal and ore doesn't need any work in a depot and refit can be done at the station, just loading the other cargo type (either automatically what is available or explicitly chosen via the order). This becomes possible when both, the misc_flag is set and refit costs are 0 (either via property or callback) or when the refit_cost callback returns a value with bit 14 set which allows refit at a station with arbitrary costs.

The current cargo classes, cargo types and cargo subtypes are accessible by the usual variables, the new cargo classess (cccc), cargo subtype (ss) and cargo type (tt) are available via extra_callback_info1 (var 0x10) in the form of ccccsstt.

As such vehicle set authors probably want to update their sets and make use of this new misc_flag and the related callback.

Example code from OpenGFX+Trains looks like this:

That's cool! That means when I unload some cargo and load it another supported cargo near by and deliver it to the start location, it compensate going back empty to destination where I came from?!?! More cargo means more profit!

will this finally make "multi-cargo" trains more viable (aka auto-adjust to available supply or do i misunderstand now)

ZxBiohazardZx wrote:will this finally make "multi-cargo" trains more viable (aka auto-adjust to available supply or do i misunderstand now)

Yes. Exactly that works when the NewGRF (or rather the wagons) support automatic refit. You could give it a shot jointly with the upcoming nightlies of both OpenTTD and OpenGFX+Trains.

This sounds great, but for autorefit to become the norm (a la locomotion) we'll also need a way to specify which cargo a train should pick up (a la locomotion). Otherwise my petrol tankers are going to get filled randomly with plastic, and my lumber trains with goods.

I will incorporate this onto my sets, but will make auto a refittable option rather than the default for now, I think.

PikkaBird wrote:This sounds great, but for autorefit to become the norm (a la locomotion) we'll also need a way to specify which cargo a train should pick up (a la locomotion).

Thankfully, you can specify either a fixed cargo type or what is available for each order.

-- Michael Lutz

PikkaBird wrote:I will incorporate this onto my sets, but will make auto a refittable option rather than the default for now, I think.

Why that? The player has to select autorefit explicitly via the order anyway...?

Thank you for the nice explanation, this will make implementing this in OpenGFX+ Road Vehicles simpler

Thanks Michael, i hadnt tried it yet so I did not realise you had already modified the orders system too. This will be fantastic!

PikkaBird wrote:Thanks Michael, i hadnt tried it yet so I did not realise you had already modified the orders system too. This will be fantastic!

Yes. Yes it will.

planetmaker wrote:

ZxBiohazardZx wrote:will this finally make "multi-cargo" trains more viable (aka auto-adjust to available supply or do i misunderstand now)

Yes. Exactly that works when the NewGRF (or rather the wagons) support automatic refit. You could give it a shot jointly with the upcoming nightlies of both OpenTTD and OpenGFX+Trains.

then maybe we can implement the "repair" stations as well now? (the other depot feature other then refit) (to me that addition sounds similar in approach )

I've just tried out this new feature, and it's awesome. But there is one thing bugging me: I tried to autorefit a flatbed wagon from lumber to engineering supplies, but it didn't work (the train didn't refit) because the cargos aren't "compatible" with each other. However, the option to refit to that cargo is still there. In addition, when I had first built the train, it was refitted to Goods by default, and it can't autorefit from goods to lumber or engineering supplies, so it was stuck at the station. (I had assumed it would autorefit from Goods to Lumber). It's also hard to determine which cargos are actually compatible with each other, as you have to go to the train's depot refit window and see which cargos cost to refit to, or something like that.

I imagine this would be very disorientating and confusing for a novice player, and will result in a lot of questions, reports and complaints such as "why isn't my train autorefitting?" etc...

Another thing: When a certain order is set to auto-refit, it should be removable in the same way as a load/unload order, ie the autorefit button should be depressed if autorefit is active, and one click resets it. It is currently difficult to remove autorefit from an order (one must select "no loading" in order to remove it.)

Emperor Jake wrote:I've just tried out this new feature, and it's awesome. But there is one thing bugging me: I tried to autorefit a flatbed wagon from lumber to engineering supplies, but it didn't work (the train didn't refit) because the cargos aren't "compatible" with each other. However, the option to refit to that cargo is still there.

Yes, that's is definitely not a good UI, but unfortunately not really avoidable as OpenTTD only knows the cargo type the vehicles have right now, while for auto-refitting the cargo type the vehicle will have in the future upon arriving at the destination is the deciding one. Predicting the future is... problematic.

Emperor Jake wrote:Another thing: When a certain order is set to auto-refit, it should be removable in the same way as a load/unload order, ie the autorefit button should be depressed if autorefit is active, and one click resets it. It is currently difficult to remove autorefit from an order (one must select "no loading" in order to remove it.)

The auto-refit order is removed exactly like the existing depot refit order which is by Ctrl-Click as the tooltip will tell you.

-- Michael Lutz

Sorry for the double post.

From OpenTTD r23124 on the value returned in bits 0-13 is now treated as a signed integer to allow refit income (for example if refit is used to change the number of articulated parts). As I don't think any of the few already changed NewGRFs returns a refit cost factor >= 8192, no action is needed for the existing NewGRFs.

-- Michael Lutz

Michi_cc wrote: The auto-refit order is removed exactly like the existing depot refit order which is by Ctrl-Click as the tooltip will tell you.

-- Michael Lutz

Actually, that scrolls to the destination as it does with any other order. Or are you referring to clicking somewhere else?

Also, if you remove the wagons of a train that has autorefit orders and replace them with non-auto-refittable wagons (or simply copy orders from a train that has autorefit) then it is also impossible to remove the autorefit orders because the button is greyed out. In fact they shouldn't be there if the wagons don't support it - either automatically removed or the order copy refused.

Emperor Jake wrote: Actually, that scrolls to the destination as it does with any other order. Or are you referring to clicking somewhere else?
<snip snip> ... either automatically removed or the order copy refused.

I'm referring to Ctrl-clicking the refit button. This is exactly the same behaviour as for the pre-existing depot refit orders, which aren't removed either on copying orders as far as I remember.

-- Michael Lutz

Very interesting feature!

I'd like to talk a little bit about refitting to different subtypes of the same cargo.
Right now, if I refit from cargo type A to cargo type B, and cargo type B has subtypes X and Y with different refitting costs, refitting to cargo B (subtype X) will have a different cost than refitting to cargo B (subtype Y).
OTOH, it seems that if I refit to another subtype of the same current cargo, the refitting costs are always 0, no matter how much I set the costs for each single subtype.

Is this intended?

I can see a couple of drawbacks here. First of all, let's say cargo B's subtype X has higher refitting costs than subtype Y. So:

* if I refit from cargo A to cargo B (subtype X) it will cost a certain amount;
* if I refit from cargo A to cargo B (subtype Y), and then to cargo B (subtype X), it will cost less (and the final effect will be the same!).

Also, in my set, I'm creating passenger classes as subtypes of PASS. My original idea was to have the passenger wagons to show up as 2nd class by default, and then have a certain refit cost (> 0) if I refitted from "passengers (2nd class)" to "passengers (1st class)". Why this? Well, because refurbishing a 2nd class coach to a 1st class coach costs money, due to labor and the more luxurious interiors. OTOH, refitting back from 1st class to 2nd class would cost something as well, but less (just the labor needed to refurbish the wagon using cheaper interiors).

For this reasons, I set up refit_costs to a certain amount for passengers (2nd class), and to a higher amount for passengers (1st class).
However, since refitting to a different subtype of the same cargo costs nothing, this has no effect.

I could also code different classes' wagons as separate IDs, but I'd prefer to do it the way I just described, to save IDs and to make the set leaner.

Perhaps we could add a feature that can make the refit costs > 0 when switching between subtypes of the same cargo, if needed?

Snail wrote: [refitting to different subtypes of the same cargo]

Right now, if I refit from cargo type A to cargo type B, and cargo type B has subtypes X and Y with different refitting costs, refitting to cargo B (subtype X) will have a different cost than refitting to cargo B (subtype Y).
OTOH, it seems that if I refit to another subtype of the same current cargo, the refitting costs are always 0, no matter how much I set the costs for each single subtype.

Is this intended?

In general, there´s no refitting cost incurred for refitting to the same cargo, even if a refitting cost value specified in the vehicle´s action0.

OTOH, the documentation of CB15E (refit cost factor) explicitly mentions "cargo subtype" being part of variable 10, which might be checked when in that callback.

So, it´s either a bug or a misleading documentation, and word from a developer would be indeed helpful, IMO.

[edit]thanks[/edit]

regards
Michael

michael blunck wrote:So, it´s either a bug or a misleading documentation, and word from a developer would be indeed helpful, IMO.

It's a bug that was just fixed in r23518.

By default, refitting only the subtype was always free so the cost callback was skipped. I've changed it now that a subtype-only refit is still free by default, but the refit cost callback can override it now.

-- Michael Lutz

Thanks! Now it works great!