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

[chrissicom]

I'd like to know if it's possible to increase the amount of vehicle IDs e.g. for trains. This would be required when I want to use two train .grf sets.

Another good thing would be when a player can e.g. choose from the trainset he wants to use in a game like it is with stations where I can choose wheich station style I want to build. This way it would even be possible to add 5 different train .grfs and then 5 players use each one set in multiplayer to get truly different companies

[kaan]

Not that i have looked at the code for this, but i think that a good approach would be to virtualize the vehicle id for each set loaded so that the newgrfs will think they have the id of their choice, but in reality they are allocated in some form of dynamic array side by side without causing conflicts. This will probably not be an easy task because of callbacks and the like

[FooBar]

If that ID virtualization turns out to be possible, why not also increase the amount of vehicles of each type to 256?

That way we can have more vehicles per set AND the possibility to use more sets at the same time.

One minor issue: We'll probably end up with way too much vehicles in the buy menu. Maybe not technically, but practically. That could be solved with some sort of category system.

One major issue: It's a **** of a lot of work to create such a new system, probably something close to completely rewriting OTTD.

[SyncViews]

It is worth doing though in the long run. And i'm sure if someone took the task on they would get plenty of support.

[Digitalfox]

One major issue: It's a **** of a lot of work to create such a new system, probably something close to completely rewriting OTTD.

Bigger maps was also a **** of a lot of work, so why not more vehicle ID's??

Newhouses also allows more houses..

Newindustries also allows more industries..

I believe it's the next step, since it will allow a new kind of game, where you can have lot's of choice with vehicles

I know we can have like 20 buses, 20 trucks and 20 trams ( or something like that ), but the truth is that you don't really have a lot of variety, imagine having 20 mercedes trucks from 1920 to 2007, 20 volvo trucks from 1920 to 2007 etc.. Or even having other kind of vehicles from before 1900, who knows if with more slot's there some crazy guy who adds lot's of historical vehicles..

Because now, what happens for example for a train set, is you chose to create a set based on old trains, or present trains or future trains, and when a mix happens it feels a lot of trains are missing..

Just IMHO

[Wolf01]

or even load a trainset for each climate without every time you want to change the climate to unload the ukrs and load the tropic set (is an example, i never tried if they are compatible) or have both trams and long vehicles loaded

[Digitalfox]

I would like to hear from a open developer what do they think..

Is it almost impossible without rewriting almost all openttd source code?

Can be made without breaking compability with old versions, by using some kind of dynamic slot attribution?

Would be something the developers would like to see in trunk?

Has ever any open dev active or retired discussed this increase in slot's?

[richk67]

I would like to hear from a open developer what do they think..

I'll throw in my thoughts... argue if you like whether Im a developer or a part-time developer

Is it almost impossible without rewriting almost all openttd source code?

Shouldnt be, as the vehicle ID is stored in the OpenTTD data structures, which we can modify. The difficulty is that some sets are designed to be used with the basic set, and just to assign some new values/graphics to certain vehicles. Other sets are effectively complete replacements.

Can be made without breaking compability with old versions, by using some kind of dynamic slot attribution?

Doing this automatically may be the killer. Sometimes a set may need loading as core, sometimes as a separate set.

I would imagine that the best way is to create a set relocater, that makes a copy of the "normal" vehicle space, and then applies the NewGRF modifications to this copy (and perhaps removes the unmodified duplicates). The vehicle ID would need expanding in some way - perhaps combining with a set ID - to get it to point to the correct vehicle in different sets, when the vehicle ID is the same.

Would be something the developers would like to see in trunk?

Personally... ooooohhh yeaaaaaaahhh!!!

Has ever any open dev active or retired discussed this increase in slot's?

Yup, couple of times Ive discussed it with other devs, and Im sure its been discussed other times as well. As always, the key is to find devs who have the time, interest, and motivation to make this work.

[DaleStan]

I would imagine that the best way is to create a set relocater, that makes a copy of the "normal" vehicle space, and then applies the NewGRF modifications to this copy

Except that that fails mightily when fed a GRF like the dbxl_ecs, which is designed to modify a the vehicles loaded by a previous GRF, not the default vehicles.

[richk67]

I would imagine that the best way is to create a set relocater, that makes a copy of the "normal" vehicle space, and then applies the NewGRF modifications to this copy

Except that that fails mightily when fed a GRF like the dbxl_ecs, which is designed to modify a the vehicles loaded by a previous GRF, not the default vehicles.

Yup, one of the known limitations of the method. Its only throwing an idea around... dealing with the problems may mean... shock, horror... that some GRFs may have to change.

For set-modifiers, it may be necessary to introduce a "this set modifies Set X" attribute into the newgrf... not too great a hardship I would have thought.

[DaleStan]

dealing with the problems may mean... shock, horror... that some GRFs may have to change.

NAK. The invalidation of any previously-valid GRF file is, at best, a bug.

Adding new things is OK, but changing the behaviour of something that doesn't use (or at least acknowledge the presence of, as with GRF v6 versus GRF v7) said new thing is not.

[Bjarni]

If we forget about grf files that modifies vehicles from other grf files then the issues would be like:
-Right now some parts of the code presumes vehicle type based on EngineID. We would have to make this dynamic (and slower). It would be nice to be able to replace say all aircraft with trains if you disable aircraft anyway.
-There is a limit of 256 different engines in the game. Long ago we started to allocate 16 bits to store engine types, but if we should allow more engines then we will have to be sure that we use 16 bits everywhere.
-somehow to store any number of engines instead of a fixed size. An easy (but still good) solution would be to replace the array with a vector.
-make it possible to fill more engines into the engine array.

This should be enough to get the game core to accept this (unless I forgot something). The first two is a great deal of work to ensure that no place is missed (that's also a boring task) and the last one... well I don't even know where to begin on that one.


So will it happen? Personally I hope so. Will we see it soon? no

One minor issue: We'll probably end up with way too much vehicles in the buy menu. Maybe not technically, but practically. That could be solved with some sort of category system.

I think I limited the list size row count to a single unsigned byte... I think human readability is gone before we make an overflow. Besides it's fairly easy to change this into two bytes so an overflow here is not the issue.

[richk67]

dealing with the problems may mean... shock, horror... that some GRFs may have to change.

NAK. The invalidation of any previously-valid GRF file is, at best, a bug.

In my view, nothing need be invalidated, and indeed that should try to be avoided. But old GRFs that arent modified will only be able to work in the old ways.

I would expect it would be added as a new entry of some form, probably an action. Since it is probably a file-level association, there is no need to embed it as a vehicle change property - just create a new action. Existing software that cant handle it ignores it.

For existing files where the author is no longer around, such a mod could be added with ease using grfcodec/nfo.

I would also expect to see a manual option of "this set replaces core vehicle set", and to keep the core available, it would need a way to replicate the core to a relocatable set if needs be. Thus, a set+modifier that requires the bottom group would be catered for - but would need manual intervention. Clearly, the restriction would be that you could only have one set+modifier in that situation.

Its the nature of advance... you can aim for as much backwards compatibility, but sometimes you just have to accept that old things can only work old ways.

BTW this is just throwing the ideas around... dont take it that this is all fully fleshed out, and your thing wont be handled. Think on the ideas a bit less argumentatively. If this were "THIS IS HOW IT WILL BE", then yeah, get stroppy. But its just a general discussion, in the earlyish stages of an idea.

(BTW what does NAK mean? To think you whine about ppl using shrthnd wdz. )

[Digitalfox]

richk67, sometimes i can only decode what somepeople say, by looking here http://en.wikipedia.org/wiki/Nvm#N

But in this case not even wiki, can help..

[dev|ant]

In my view, nothing need be invalidated, and indeed that should try to be avoided. But old GRFs that arent modified will only be able to work in the old ways.

I would expect it would be added as a new entry of some form, probably an action. Since it is probably a file-level association, there is no need to embed it as a vehicle change property - just create a new action. Existing software that cant handle it ignores it.

For existing files where the author is no longer around, such a mod could be added with ease using grfcodec/nfo.

I would also expect to see a manual option of "this set replaces core vehicle set", and to keep the core available, it would need a way to replicate the core to a relocatable set if needs be. Thus, a set+modifier that requires the bottom group would be catered for - but would need manual intervention. Clearly, the restriction would be that you could only have one set+modifier in that situation.

Its the nature of advance... you can aim for as much backwards compatibility, but sometimes you just have to accept that old things can only work old ways.

BTW this is just throwing the ideas around... dont take it that this is all fully fleshed out, and your thing wont be handled. Think on the ideas a bit less argumentatively. If this were "THIS IS HOW IT WILL BE", then yeah, get stroppy. But its just a general discussion, in the earlyish stages of an idea.

Great thinking on all of those ideas. And as a last resort, if the new virtual vehicle IDs came in and old GRFs were still in use, you could warn the user about old GRFs in use, and either switch back to standard IDs, or maybe even allow the user to select which ID instance to put the incompatible GRF in.

(BTW what does NAK mean? To think you whine about ppl using shrthnd wdz. )

NAK means not acknowledged, it is used in some systems to report an invalid or misunderstood message.

DaleStan, here's your chance to make amends for throwing up road blocks where they don't exist. If we wanted to extend the NewGRF specification to include the "this GRF extends the GRF with ID ...." option, how would you suggest it be implemented?

[DaleStan]

Existing software that cant handle it ignores it.

And NAK again. If the GRF file says to do something that you don't know how to do, under no circumstances fall back to the default. If the default were correct, the GRF file wouldn't be trying to change it.

(BTW what does NAK mean? To think you whine about ppl using shrthnd wdz. )

ASCII 0x15, apparently. Anything in TNHD (and obscure references thereunto) is fair game. (EBG: uggc://jjj.wnetba.bet/)
It's what you say when someone suggests re-implementing OpenTTD in COBOL. Or GWBASIC.

DaleStan, here's your chance to make amends for throwing up road blocks where they don't exist. If we wanted to extend the NewGRF specification to include the "this GRF extends the GRF with ID ...." option, how would you suggest it be implemented?

New action, just like Rich said. 5 bytes, in one of three forms:
14 00 00 00 00: "Modify the default ID space." This is also the behaviour when no action 14 is present.
14 FF FF FF FF: "Modify any available ID space."
14 <grfid>. "Modify same ID space as the grf with ID <grfid>". Causes the containing GRF file to be disabled if the GRF file with the specified grfid is not found or has not been loaded.
The presence of multiple action 14s in a single file is an error, and causes the file to be disabled. An action 14 may be deemed invalid in certain locations, but all valid locations must be equivalent.

[Maedhros]

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.

[DJ Nekkid]

something like this?

then question then comes:

what about the wagons, should it be possible to use wagons from different sets? (a DBXL-engine with NARS wagon?)

[Youri219]

something like this?

then question then comes:

what about the wagons, should it be possible to use wagons from different sets? (a DBXL-engine with NARS wagon?)

Some sets only allow specific wagons to be put behind some locomotives, I think combining that could lead to some nasty side effects.

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?

[Maedhros]

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?

I shouldn't have thought so - it'll be up to the grf author to decide, as otherwise things could end up breaking in all sorts of weird and wonderful ways.