Transport Tycoon Forums

As it stands, only vehicles with a valid cargo and a non-zero capacity can be refitted, even if cargo subtypes are defined. As cargo subtypes are often used for refit tricks like regearing, liveries, changing wagon counts, etc., this means that those things simply can not be done if the vehicle does not carry cargo.

However cargo type and subtype are stored completely independently - the only thing actually preventing a refit of a cargoless vehicle is UI code. So I switched up the UI code. Added some checks, removed some, changed the order of others. Now vehicles with capacities of 0 will allow refitting if and only if they have the cargo suffix callback defined.

At the moment, in the refit window they'll claim to be refitting to "0 passengers" and all the suffixes are preceded by passengers. This is because Passengers and No Cargo are both represented by 0. Of course, if you specify a cargo type with a capacity of 0, you'll get that instead of passengers.

The obvious next-step is to special case the GUI so it doesn't refer to a cargo in this case.

The patch, an example grf and Win32 build are attached.

In addition to the ugly 'Passengers' thing, I'm mostly concerned with not triggering any unintentional side effects with other vehicle sets (Half-implemented features left in, etc.) - ideally every GRF that hasn't been intentionally crafted to take advantage of this should act exactly as they do in trunk. I think multiplayer will be fine, but I didn't check. AIs might be confused by the 0 capacity refits.

Are there any other points of concern?

Strange, I managed to make a vehicle refitable without capacity while experimenting with NML a while ago.

Try this GRF in a regular build of OpenTTD, it has a locomotive in two refittable liveries - the only side effect is that it says "passengers (cargo subtype)" in the refit menu.

The trick that makes that work I think is setting a cargo property and the overriding that in all cases with the cargo capacity callback. Well done!

(note that this nml code uses the old style callbacks, so if you're new to nml then you now know why it's slightly different)

Neat. I think I'm going to have to use that one.

So I guess I should cover both cases with the UI patch, eh?

You may even want to consider making the UI patch a separate patch, since that will then basically be a fix (and may end up in a possible 1.1.4). The other patch which drops the requirements for a capacity in order to be able to refit is more of a new feature (which will have to wait until 1.2.0).