Increase the amount of veh. IDs? (Use mult. vehicle sets)

[kaan]

About one grf modifying another grf... is it possible to have a user select whether a grf should act on the normal, or a previously loaded set?

It is possible, but it would be better if the software just did The Right ThingTM

[Vikthor]

And what about this - Either the grf specifies that it is slotable (and/or) which set it modifies and then it will be asigned to the slot. All other grfs that do not specify that(the old ones), are assigned to the first default slot, where everything works as it is now.

[DaleStan]

As an alternative, what would you think of adding a new Action 0 property which defines the "category" that a particular vehicle goes into? For instance, UKRS vehicles could be put into a "UKRS" category. The original vehicles would be in the "DFLT" category, which would also be the default if no category was specified (i.e. all existing grf sets). The categories could be given a name via action 4 in the same way as stations, so you could switch between them in the build vehicle lists.

So we're adding an extra ~4 bytes per vehicle. Four bytes that are going to be the same for every single vehicle in a set. Plus another four bytes per default vehicle that the set wants to disable?

I guess 14 needs to be changed slightly.
Action 0/3/4s that precede the action 14, if present, always affect the default vehicles. (This way, a GRF file can still make the default vehicles go away.)
After the action 14, actions 0/3/4 affect the specified slot.
Multiple action 14s are still not valid, as that would make the slot specified 14 <grfid> multiply defined.

Note that FF FF FF FF says "any available", not "a new". This way, it is still conforming to load all files into the default space.

About one grf modifying another grf... is it possible to have a user select whether a grf should act on the normal, or a previously loaded set?

It is possible, but

No, it is not. Bad Things will happen if that is allowed.

And what about this - Either the grf specifies that it is slotable (and/or) which set it modifies and then it will be asigned to the slot. All other grfs that do not specify that(the old ones), are assigned to the first default slot, where everything works as it is now.

Isn't that what I just said?

[chrissicom]

Wow, nice such a good discussion started on this topic. I didn't assume it was an easy task but it's definitely a good way to greatly improve the game I have a little different question. The vehicles in each .grf set have IDs. When I use two vehicle sets ID 10 from the set loaded below the first one will replace ID 10 for example. I decoded two vehicle .grf's with the intention to change the vehicle IDs so only the vehicles that I don't need become overwritten. Although I have no idea how to read the .nfo file and how or where the id's are stored in there. I thought that also the prices, running costs and dev year etc. are in there but there's not really anything readable in the .nfo except the vehicle names. Any help on how to edit the file especially how to change vehicle IDs in the .grf would be greatly appreciated

[FooBar]

The NewGRF Specs is what you need. Read the tutorial to find out the structure of the NFO language, then read the specs on Actions 0, 2, 3 and 4. After that, try to find out what every byte in the NFO does, locate the vehicle IDs and change those.

[chrissicom]

Hmmm I just read there is something like http://wiki.ttdpatch.net/tiki-index.php ... eVehicleID this already. Isn't that very useful for combining numerous vehicle sets? The only thing that would be limiting in this case is that the overall limit for available vehicle ids is rather low.

Edit: Ok, this wiki stuff is written in another language for me I really don't get any clue from it.

I have these two trains in the grf set for example:

Code: Select all

4099 * 23	 04 00 03 01 "8BR 112 (Electric)" 00
 4100 * 25	 04 00 04 01 "8BR 112 (Elektrisch)" 00
 4101 * 25	 04 00 08 01 "8BR 112 (Électrique)" 00
 4102 * 24	 04 00 10 01 "8BR 112 (Eléctrica)" 00

and

Code: Select all

 4112 * 21	 04 00 03 01 "TICE1 (Electric)" 00
 4113 * 23	 04 00 04 01 "TICE1 (Elektrisch)" 00
 4114 * 23	 04 00 08 01 "TICE1 (Électrique)" 00
 4115 * 22	 04 00 10 01 "TICE1 (Eléctrica)" 00

Most of the numbers in this line are equal and I doubt that the first byte after the line number is the vehicle id, because why would it change for another language? Isn't there a simple answer out there with a real grf example saying THIS is the vehicle id?

[glx]

These lines are just Action 4, ie string definitions. You should check Action 0 lines.

[Leviath.NL]

http://wiki.ttdpatch.net/tiki-index.php ... on_date_2A_ here you can find an example of an ACtion0 for a trainengine

[DaleStan]

Most of the numbers in this line are equal and I doubt that the first byte after the line number is the vehicle id, because why would it change for another language?

You are correct. Look at the things that are the same between each set of four, different between the two sets, and not obviously displayed to the user. While doing this, look at the documentation; the first byte will tell you which Action* page is significant.

Then look at the documentation for NFORenum's @@BEAUTIFY command, and make use of it.

[FooBar]

These lines are just Action 4, ie string definitions.

Action 4s still include a reference to the Vehicle ID. It's a bit hidden though.

Have a look at this:
"8BR 112 (Electric)"
What's that 8 doing there?

To let you in a little secret: that 8 is the result of some kind of bug in grfcodec. It's actually the vehicle ID, but it ended up decoded in the text string. As DaleStan told you, NFORenum can fix that for you.
If you want to do it manually, you need to convert the 8 back to hex. So 38(h) is your actual vehicle ID. Remove that 8 from the string and put the 38 in front of it.

Same goes for the T in the ICE strings. That's actually Vehicle ID 54.


The other actions are a little easier: the vehicle IDs aren't hidden there. Just follow the spec to find out what byte the vehicle ID is.

[DaleStan]

To let you in a little secret: that 8 is the result of some kind of bug in grfcodec.

Not a bug. A misfeature maybe, but not a bug. Whenever there are more than 4 consecutive printables (2 in actions 7, 8, 9, D, and E.) they are printed as a quoted string, instead of in hex. You may also decode with -t, which will decode everything in hex.

[PikkaBird]

Hmmm I just read there is something like http://wiki.ttdpatch.net/tiki-index.php ... eVehicleID this already. Isn't that very useful for combining numerous vehicle sets?

Not really. It would be very cumbersome or impossible to use for all but the very simplest sets.

[Zephyris]

This has already been suggested and partly implemented, though I cant find the thread but ill do some searching! The way it worked was by creating multiple "slots" of 256 vehicles, each containing the original set of vehicles. Different grfs could then be loaded into each of these slots separately, or be forced to share a slot and act in the legacy manner. It got to the stage where there could be up to 256 slots, each containing the default vehicle set, but loading grfs was not implemented because the coded didnt understand the grf code!

edit: Old threads on this topic here:
http://www.tt-forums.net/viewtopic.php? ... &sk=t&sd=a
http://www.tt-forums.net/viewtopic.php? ... &sk=t&sd=a

[dev|ant]

I don't even remember seeing those topics. Looks like MagicBuzz made a very decent start on the changes necessary. I've got a long weekend so I might take a look at his patch and see what needs to be done next.

[MagicBuzz]

Hello, you're right, I tried to work arround this a few months ago.

But I'm far not enougth skilled in C++ in order to complete the patch, and I got some issues with "altering" sets (sets that alter an existing set).
May be my approach was wrong, but I deducted that the GRF format must contain at least information about the setid it alters, or the offset id it will use (then the offset can't be affected dynamicaly).

Someone suggested using a GUI in the GRF selector, but I wasn't able to find how to had a GUI there.

See attached my patch (I can't remember if it compiles or if it's the last one, as I did some work at home and at my job, using different computers)

[Digitalfox]

Nice MagicBuzz, i didn't know you actually started working on a patch, only thought you talked about it..

So what do dev's and coders say about it? It's a good start?

[MagicBuzz]

So what do dev's and coders say about it? It's a good start?

Honestly, I don't think so

But the positive thing with this, is that it shows it's possible to load more than 256 vehicles at the same time

I found the old topics I participated while designing this patch. You might find a few information about what this patch is supposed to do.
http://www.tt-forums.net/viewtopic.php?f=32&t=33124
http://www.tt-forums.net/viewtopic.php?f=25&t=33146

Doh! And I just rember one of the problems I saw with this patch : it should not be used to load multiple sets. Just because vehicle sets often change some economy rules such as base price multipler or other stuffs. If you load two differents sets that changes the same rule with different values, you'll just get some inconsistant parameters that will make some vehicule unusable (running costs too hight by exemple) or make the game in "god mode" (runing cost far too low by exemple).

In order to fix this, that might requiere a lo of code rewrite in order to apply the rule of the right set, but it's not always possible, as some of these rules are global.

[dev|ant]

Looking at how easily Magic Buzz was able to implement what I was considering the hardest part of the idea (game engine changes) I thought I might as well give it a go myself.

I've just gotten it to the stage where it works and is usable, as you can see from the shot below. PB's Aviators set is loaded in slot 1, leaving the regular TTD engines available in slot 0. But there's still a lot of work to go, eg. base costs are still common between the sets and the NewGRF window needs to have the slot information added.

FWIW, I don't anticipate my implementation of this ever being added to trunk. I wasn't coding to those kind of standards, so it's hackish and ugly in places. It's more a proof of concept, so the core devs can see that it is possible, and one day they might try and implement it themselves.

[Zephyris]

Awesome work! How extensive is the patching required to do this? Bitesize chunks?

[Maedhros]

You know, we already know it's possible. You don't need to make a hackish patch to show us that, but making a non-hackish patch would be much more helpful as then we could actually use it to add the functionality to the game, instead of starting again.