Livery preview

[merni]

Currently, when refitting a vehicle (particularly talking about livery), you cannot see what the livery looks like until you apply it. Could a "preview" be added where the train sprite in the refit window changes when you choose a particular refit option, but before applying it?

Granted, the new variants feature is better and you can see liveries in the purchase menu, but most existing grfs still use the refit system for liveries. So this feature can still be useful.

[peter1138]

Not really possible. Refit options do not exist until the vehicle is purchased.

[Eddi]

that's part of the reason why variants was introduced, because the refit system cannot solve these problems.

[LaChupacabra]

Not really possible. Refit options do not exist until the vehicle is purchased.

You got it wrong. The point is that currently to see what a livery looks like you have to rebuild the vehicle, but this will cause the refit window to close automatically and you'll have to reopen it to see what you've selected. When you change the livery again, the window will close again. And so every time. This behavior makes sense when selecting a cargo type, but is a burdensome when selecting a livery where you want to see what you've selected. So it would be good to see the liveries/variants (subvariant) before making a choice.

This is how choosing of livery looks like now

[+] Spoiler

Choice of livery - current.gif (685.93 KiB) Viewed 2328 times

This is what it could look like
Variant 1: Click once to see the livery / variant, double click or on the bottom to select and close the window

[+] Spoiler

Choice of livery - upgrade v1.gif (31.89 KiB) Viewed 2328 times

Variant 2: Show all liveries / variants - it's easier to see the interesting option, but the window will be slightly larger

[+] Spoiler

Choice of livery - upgrade v2.png (25.44 KiB) Viewed 2328 times

that's part of the reason why variants was introduced, because the refit system cannot solve these problems.

Variants is a good feature, but they won't be a solution to the lack of previews for existing add-ons. In addition, the variant may specify, for example, the engine version, the number of sections in the case of EMU and DMU trains, or the aircraft version where, for example, Boeing 737 had probably 12 of them. Then the preview in the refit options will still be useful.

[andythenorth]

Lol no, update the grfs.

[Eddi]

which part of "this is impossible(*)" was so hard to understand?

(*) from an engineering standpoint, "impossible" means it takes a really long time

[LaChupacabra]

which part of "this is impossible(*)" was so hard to understand?
(*) from an engineering standpoint, "impossible" means it takes a really long time

Is it impossible(*) for you to make a single click on a variant show the image assigned to that variant? I don't know the intricacies of the code, but superficially it doesn't seem very complicated.

[Eddi]

Is it impossible(*) for you to make a single click on a variant show the image assigned to that variant?

correct.

the data you want to have shown only exists AFTER the modification was made.

effectively, you have to make a clone of the vehicle, apply the refit, show the data, and when you submit you have to apply the refit again to the original vehicle and destroy the clone

and during the time the clone exists, it must be hidden from all the other vehicle lists. so the clone has to both exist and not exist at the same time.

and thus it is impossible(*)

[OzTrans]

Is it impossible(*) for you to make a single click on a variant show the image assigned to that variant? I don't know the intricacies of the code, but superficially it doesn't seem very complicated.

No it is not impossible; it should be quite easy to implement ...

Naturally, you have to buy the vehicle first.

If it is refitable, to other cargo types and/or liveries, the refit window has to be constructed. During that process cargo types, cargo subtypes, capacities and refit costs have to be collected for all possible options. All data is provided by the GRF. Now, just one more step would be necessary; i.e. collecting the sprite number for each refit option.

Then, when the player selects a refit option, just display the sprite relevant to the refit option at the top of the refit window.

To start with the current livery is shown already.

Aircraft Refit.png (8.11 KiB) Viewed 2209 times

I find this actually a good idea ... may be JGR can help us here, if the Gods will not ...

[Argus]

It doesn't really seem impossible, but maybe it's running into problems in the old core of this game. It doesn't seem like Schrödinger's cat to me.

[peter1138]

Ok, my original answer was from the purchase list point of view, rather than the cargo refit window.

But still, the problem is that, unlike getting just the subtype strings, to show the changed graphics requires the refit to actually happen, and that requires backup and restore of a fair amount of game state (for example refitting will drop cargo (which includes source & destination information) if the capacity is not enough), and making sure nothing goes wrong in between.

And that needs to happen every time you want to draw a potential refit option.

OR

We created variants for a reason.

[odisseus]

...the problem is that, unlike getting just the subtype strings, to show the changed graphics requires the refit to actually happen, and that requires backup and restore of a fair amount of game state...

Why is it perfectly possible to calculate in advance what the capacity, speed, power etc. are going to be after the refit, but mocking up a graphical representation is suddenly a problem?

[peter1138]

I don't know why you think all those things work.

Only capacity is available, and that's done by running refit command in test mode which is able to return a single capacity value for the refitted cargo type. And even that can be incorrect in some circumstances.

[OzTrans]

... unlike getting just the subtype strings, to show the changed graphics requires the refit to actually happen, ...

Really, I don't get that ...

Below is my code of the Airbus A380.

In order to be able to construct that Refit Window ... things go through the display chain first; i.e. 1117 (CB 19) >> 0xD5 to get the cargo subtypes via var 0xF2; so 1116 gives you all the cargo sub-types one by one. Obviously the game keeps a list of these.

Then, if the vehicle has been refitted previously, the sprite is resolved, via display chain; i.e. 1117 >> 0x40, 1109 >> var 10 [0x11] refit GUI >> 0x00, 1103, again 0xF2 [known from previous refit] gives you the sprite (sprite number) to be displayed.

Now, what is so difficult to get those sprite numbers in the same way as the cargo subtypes are collected. Keep them together with the text IDs of the cargo subtypes in a list alongside.

Then, when the player (or a previously refitted livery) highlights an option to also go and displays the livery. This already works for previous refitted option (the one in white in my image above). 0xF2 is there for a reason and works perfectly well. Miraculously, the correct livery is displayed, when a previously refitted vehicle is displayed again in a refit window.

If that feature would require proper handling (like I have done below) so be it ...

Code: Select all

// ** --------------------------
// ** Aircraft - Airbus A380-800
// ** --------------------------

// BLDSPRBLK TYPE(Airbus A380-800) FEATURE(*VEH_AIRCRAFT) ;
//           SPRITE_IDS(10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D)
  829 * 4        01 03 1E 08
// SPRITEBLK *START
 [sprites]
// SPRITEBLK *END
 1070 * 9        02 03 10 01 01 00 00 00 00
 1071 * 9        02 03 11 01 01 01 00 01 00
 1072 * 9        02 03 12 01 01 02 00 02 00
 1073 * 9        02 03 13 01 01 03 00 03 00
 1074 * 9        02 03 14 01 01 04 00 04 00
 1075 * 9        02 03 15 01 01 05 00 05 00
 1076 * 9        02 03 16 01 01 06 00 06 00
 1077 * 9        02 03 17 01 01 07 00 07 00
 1078 * 9        02 03 18 01 01 08 00 08 00
 1079 * 9        02 03 19 01 01 09 00 09 00
 1080 * 9        02 03 1A 01 01 0A 00 0A 00
 1081 * 9        02 03 1B 01 01 0B 00 0B 00
 1082 * 9        02 03 1C 01 01 0C 00 0C 00
 1083 * 9        02 03 1D 01 01 0D 00 0D 00
 1084 * 9        02 03 1E 01 01 0E 00 0E 00
 1085 * 9        02 03 1F 01 01 0F 00 0F 00
 1086 * 9        02 03 20 01 01 10 00 10 00
 1087 * 9        02 03 21 01 01 11 00 11 00
 1088 * 9        02 03 22 01 01 12 00 12 00
 1089 * 9        02 03 23 01 01 13 00 13 00
 1090 * 9        02 03 24 01 01 14 00 14 00
 1091 * 9        02 03 25 01 01 15 00 15 00
 1092 * 9        02 03 26 01 01 16 00 16 00
 1093 * 9        02 03 27 01 01 17 00 17 00
 1094 * 9        02 03 28 01 01 18 00 18 00
 1095 * 9        02 03 29 01 01 19 00 19 00
 1096 * 9        02 03 2A 01 01 1A 00 1A 00
 1097 * 9        02 03 2B 01 01 1B 00 1B 00
 1098 * 9        02 03 2C 01 01 1C 00 1C 00
 1099 * 9        02 03 2D 01 01 1D 00 1D 00

// BLDSPRBLK TYPE(Airbus A380-800) FEATURE(*VEH_AIRCRAFT) ;
//           SPRITE_IDS(30)
 1100 * 4        01 03 01 01
// SPRITEBLK *START
 1101 SPR_CTP/CanAir292300.png  8bpp  658 1672   68   21  -34  -10 normal chunked
// SPRITEBLK *END
 1102 * 9        02 03 30 01 01 00 00 00 00

// BLDA02NFO FEATURE(*VEH_AIRCRAFT) TEST(*LIV_REFIT) ACTION_2_ID(40) TYPE(*SET_ALLOC) NUM_LIV(6) ;
//           SPRIDS(10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D)
 1103 * 34       02 03 00 81 F2 00 FF 06 10 00 00 00 11 00 01 01 12 00 02 02 13 00 03 03 14 00 04 04 15 00 05 05 FF 00
 1104 * 34       02 03 01 81 F2 00 FF 06 16 00 00 00 17 00 01 01 18 00 02 02 19 00 03 03 1A 00 04 04 1B 00 05 05 FF 00
 1105 * 34       02 03 02 81 F2 00 FF 06 1C 00 00 00 1D 00 01 01 1E 00 02 02 1F 00 03 03 20 00 04 04 21 00 05 05 FF 00
 1106 * 34       02 03 03 81 F2 00 FF 06 22 00 00 00 23 00 01 01 24 00 02 02 25 00 03 03 26 00 04 04 27 00 05 05 FF 00
 1107 * 34       02 03 04 81 F2 00 FF 06 28 00 00 00 29 00 01 01 2A 00 02 02 2B 00 03 03 2C 00 04 04 2D 00 05 05 FF 00
 1108 * 26       02 03 40 81 E2 00 FF 04 02 00 0F 0F 00 00 12 12 03 00 15 15 04 00 16 16 01 00
 1109 * 14       02 03 40 81 10 00 33 01 00 00 11 12 40 00

// BLDA02NFO FEATURE(*VEH_AIRCRAFT) CALLBACK(*CB36_PRO_MOD) ACTION_2_ID(D8) ;
//           AIR_RUN_COST(445000) AIR_SPEED(1016 425 475 450 250 102)
 1110 * 30       02 03 03 81 E2 00 FF 05 4F 80 12 12 21 80 0D 0D 25 80 0F 0F 23 80 10 14 14 80 15 16 08 80
 1111 * 30       02 03 02 81 E2 00 FF 05 B9 80 12 12 5D 80 00 0C E8 80 0D 0F 8B 80 10 14 A7 80 15 16 3D 80
 1112 * 17       02 03 01 85 4C 00 FF FF 01 00 80 00 00 00 00 02 00
 1113 * 18       02 03 00 81 10 00 FF 02 03 00 0C 0C 01 00 0E 0E FF 00
 1114 * 14       02 03 D8 81 40 00 FF 01 00 00 00 00 FF 00

// CRTVEHCDE VEHNAME(Airbus A380-800) VEHID(00) FEATURE(*VEH_AIRCRAFT) ;
//    SPRITEID(40) ;
//    CALLBACKS((*CALLBACK36 *OTHER)) ;
//    NUMSPRITESETS((0 1) *1 30)
 1115 * 14       02 03 D3 81 47 00 FF 01 84 82 00 00 82 80
 1116 * 34       02 03 D5 81 F2 00 FF 06 56 80 00 00 59 80 01 01 63 80 02 02 62 80 03 03 64 80 04 04 66 80 05 05 00 84
 1117 * 29       02 03 DF 85 0C 00 FF FF 03 D3 00 15 00 15 00 D5 00 19 00 19 00 D8 00 36 00 36 00 40 00
 1118 * 17       02 03 EF 85 0C 00 FF FF 01 74 80 23 00 23 00 30 00
 1119 * 10       03 03 01 00 01 FF EF 00 DF 00

[peter1138]

Yes, it's probably not so complicated for an airplane made of just one sprite (shadow isn't drawn in the UI).

* Sprite stacks exist, although in most cases these aren't used, but to draw correctly requires keeping the complete sprite stack data.
* Trains and road vehicles which consist of multiple different vehicle parts, so you need to keep image data for each part.
* Across a vehicle chain, string IDs don't necessarily correlate with the same cargo subtype number.
* For trains and RVs, vehicle length callback result could change depending on cargo type/subtype, so length information needs to be captured. (HEQS does this, it's not hypothetical)
* Custom colour callback result could change depending on cargo type/subtype, so palette information needs to be captured.
* Non-front parts can depend on the values (not just cargo type/subtype) of prior parts, so the whole consist needs to be to done together. (This is common for train engine tenders, it's not hypothetical)
* Refits could be temporal. After data is collected, it may no longer be valid for the next game tick. (This is true for the string information already maintained)

Doing all this means duplicating most of the refit routines (without actually applying new capacity limits) and capturing all possible data required, while making sure that all game-state is properly reverted (including NewGRF caches)

OR

We created variants for a reason.

[OzTrans]

... Doing all this means duplicating most of the refit routines (without actually applying new capacity limits) and capturing all possible data required, while making sure that all game-state is properly reverted (including NewGRF caches) ...

I suspect the current implementation of refitting vehicles is pretty messy; may be a complete overhaul and re-write is a very good option. I believe the above can easily be implemented, if you disconnect the entire process completely from the game and only update the vehicle/train in question when the player commits the refit. The following process could work :

a) Use a new callback to collect all the data from the GRF. Some data you already know from the properties of the vehicle/train in question.
b) Present the refit window to the player.
c) Display relevant data/image when the player makes a selection.
d) When the player commits to a preselected option; either update the current vehicle/train or update the virtual one with orders, age, profit etc then delete the current one and clone your virtual vehicle/train, creating a brand-new one while retaining vehicle number. This can all be done with existing functionality; i.e. cloning orders, cloning entire trains etc.

I'll leave that in your capable hands now, may be one day it will see the light of day.

We created variants for a reason.

You keep saying that, but I will not use this feature for livery refits. It makes things more than complicated in my world. I don't want to put players in a hopeless position to having to scan through countless liveries, that require a individual vehicle ID. Especially those players, that are not familiar with Canadian Roads [rail companies].

For example in 1978, Canadian Pacific [CPR] and Canadian National [CNR] passenger trains transition to VIA. This would mean players will have to set up Autoreplace for every passenger train to get those wagons replaced with a vehicle of a different ID and knowing what to choose. That would be a hard day in the office for any player.

It isn't even possible to just display only relevant liveries for a particular train. You need to scan through the lot, there could be a few hundred to choose from ... and callback 0x1D would have a field day and frustrate players with the message : "Sorry, you cannot attach that one either, keep trying !!".

Players would need expert knowledge of Canadian Railways; I'd rather do that work for them and give them just what is relevant to choose from.

Have a look at the chart of the Lightweight Passenger Coach with its multitude of liveries. It's only v2.0, I haven't done v3.0 yet, which will have many more liveries added. You want me to code these with individual vehicle IDs and still retaining the automatic way of livery changes when trains go for servicing, you must be kidding ...





BTW, I have given this Master/Slave feature a go, not just with liveries, but with different configurations. I would never do it just for liveries. Still not quite happy with it ...

Ontario Rapid Transit.png (65.99 KiB) Viewed 1915 times

[Eddi]

I suspect the current implementation of refitting vehicles is pretty messy; may be a complete overhaul and re-write is a very good option

we did a complete redesign of the whole system. it's called variants.

also, we can't remove (or significantly change) the old system, because old GRFs are meant to continue to work.

[LaChupacabra]

...

Maybe you're right in the end, maybe it's too complicated, I can't rule it out, but I just can't believe there isn't a sensible way to make it possible without such twisted methods. Too many times I heard "it's impossible(*)" only to find out later that it wasn't.

...to show the changed graphics requires the refit to actually happen

So maybe make it to show the graphic without needing a refit?

Let the graphics shown in the window always refer to the virtual vehicle

Yes, I'm a bit like the blind trying to show you the way.