Raising number of available engine types to 8192 per type

[Bilbo]

I thought about a way to allow more engine types loaded via NewGRF's at once

Since GRF specs have engine ID as extended byte, theoretically nothing would limit having as much as 65536 engines of each type (road vehicle, aircraft, ...)

Problem is, there are only 255 usable slots, in them there are four ranges (116 trains, 88 road vehicles, 11 ships and 41 aircrafts)

Basically, you can only replace vehicles in these ranges and you cannot have more of them than is size of the range. You can't replace "empty slots" with some vehicle.

I thought of converting the common pool of 255 engines to separate dynamic pools, each of them would be preallocated to its 'default' size (116 items for trains, ....) and reallocated as necessary, having maximum of 8192 items in it.

Any vehicle could replace the empty slot with some vehicle (of course all of its properties hagve to be defined for the vehicle to be usable)

I set the new implementation limit to 8192 engine types per class (8192 road veh types, 8192 train types, ....), as this is quite enough (raising current limit almost 80 times for trains, even more for other vehicle types) and raising the limit further will make some things somewhat more complicated.

Advantages:
* Old GRF's will still work as usual.
* Old GRF's that can take advantage of variable vehicle ID's can work as usual, but it could be remapped from replacing default vehicles to replacing "empty slots", thus allowing combining vehicles in that GRF with other grf's vehicles or with default vehicles.
* New code fully aware of this change can use all the slots. 300 engine types in single GRF? no problem :)

(Variable vehicle ID's are described at http://wiki.ttdpatch.net/tiki-index.php ... eVehicleID )

Disadvantages:
* new code using this feature to the fullest extent (specifying too many engines) won't work currently in ttdpatch. Could be "solved" by detecting for ttdpatch or older openttd version and switching off the extra engines if this feature is not supported. That way GRF will still load, though only with subset of all its engines.
* The changes required for this to fully work are rather complex.

I decided to split the work into two phases:
Phase 1: replace the common static pool with 4 static pools of some "reasonably small size" (currently 512 vehicles)
Phase 2: make the pools really dynamic (upping the limit to 8192 engines)

I am attaching some preview of this patch (currently halfway to phase 1). In current state it is not even compilable, as in many places the old common pool is still used. But you can see the way in which the changes are to be taken.

I want some feedback from the people, especially from devs:
Would this feature be useful?
Would this be a good way to solve that limitation?

[peter1138]

Sorry, but all the work to turn engines into a dynamic pool has already been carried out.

[DaleStan]

*blink*

[michael blunck]

Yes, I saw it in the other thread:



Problem is how to configure such a feature. Just (mis-)using it to load multiple vehicle sets in parallel wouldn´t be a good thing, IMO [*]. O/c, the audience will just demand it for that purpose - as usual.

[*] I´ll elaborate on this if/when needed.

regards
Michael

[DJ Nekkid]

as earlier proposed, it should be devided into sections/tabs ... "DFLT" - "DBXL" - "UKRS" - "NARS" or something, but that _might_ need some kind of NEW action 4 property or something...

[Bilbo]

Sorry, but all the work to turn engines into a dynamic pool has already been carried out.

What? Where, in one of the branches?

[peter1138]

Problem is how to configure such a feature. Just (mis-)using it to load multiple vehicle sets in parallel wouldn´t be a good thing, IMO [*]. O/c, the audience will just demand it for that purpose - as usual.

Correct. The screenshot was just to show what is possible.

One of the main advantages is being able to have more earlier and later vehicles, as well as the much forgotten limit on the number of seafaring vehicles...

However, if you would like to elaborate on your own concerns and perhaps suggest a possible solution, let me know.

as earlier proposed, it should be devided into sections/tabs ...

Or just don't load so many contrasting sets. With a well design set of sets (as it were) it shouldn't be necessary.

What? Where, in one of the branches?

In a local patch (distributed to some testers on IRC) that I updated from a patch that I originally made in June 2006.

[Bilbo]

One of the main advantages is being able to have more earlier and later vehicles, as well as the much forgotten limit on the number of seafaring vehicles...

11 ships is way too small amount .... while ships in general are not very good, having only 11 of them won't help that either.

Or just don't load so many contrasting sets. With a well design set of sets (as it were) it shouldn't be necessary.

Some way to filter out the engines displayed could be done relatively easily later. Some way is already done now: http://tt-forums.net/viewtopic.php?f=33&t=35805 (build and refit patch able to filter out the vehicle list)

If you combine some reasonable sets (like UK, DB XL and CSD sets for europe scenarios), you could have well-looking railway scenario ... best would be to filter by sets, but that would probably require enhancing newgrf specs to support this.

What? Where, in one of the branches?

In a local patch (distributed to some testers on IRC) that I updated from a patch that I originally made in June 2006.

Is that patch available somewhere?

Maybe it would be good to improve it so it would end up in trunk .. perhaps I can help with that :)

[Kumagoro]

Any progres going on? That would be a nice feature neer-to-be-seen in TTDpatch

[peter1138]

Any progres going on?

It is being kept up-to-date.

[chrissicom]

Do your efforts also take into account that the Japan set for example has a special track for the Shinkansen? Does it work to use the DB XL and Japan Set for example so the modified Shinkansen tracks are actually added as a new track instead or replacing an old one and thus making lots of the DB XL trains unusable due to track limitations.

[peter1138]

No. That is a totally separate feature and concept to just adding more engine types.

And yes, I do have some plans for that...

[MagicBuzz]

No. That is a totally separate feature and concept to just adding more engine types.

And yes, I do have some plans for that...

Hello,

I bump this thread as I don't know which "dynamic engine pool" is used in the Gonozal pack.
But I found a quite anoying bug in this , and another one that I think is related with.
- When you start using different vehicles of different sets, the "autoreplace" window is completely stuck. It looks like it recognize your vehicles only based on the firt (or last) GRF loaded. So you see trains you never built and you can't find the trains you actually uses. This make the feature totally useless.

- The other bug is about the "vehicle enters in depot". I'm not sure it's related, I can't find exactely which bug produce this. But it looks like it's a side effect of this patch. When a vehicle enters a depot for autorenew/autoreplace, if you have a window opened on the vehicle, then the game crash with a problem in the string.cpp file. It looks like it can't find the string to display. The bug doesn't happen if you close the vehicle window before it replaces itself.

[peter1138]

I don't experience those problems with just the engine pool patch applied. It could however be just a combination of vehicles which causes issues.

[Bilbo]

I bump this thread as I don't know which "dynamic engine pool" is used in the Gonozal pack.

Surely not my code from this thread, as it is not even compilable. Unless he managed to finish it. I looked at the http://fuzzle.org/o/ from where the enginepool code for gonozal pack was taken ans that is not my code (or if it ever was, it was changed beyond any recognition :)

[MagicBuzz]

I don't experience those problems with just the engine pool patch applied. It could however be just a combination of vehicles which causes issues.

Is "http://fuzzle.org/o/" your patch ?

I experience the problem with UKRS + Add-on 4 and DBXL together.

I'll do some deeper tests and give you the exact configuration I use to reproduce the problem.

[MagicBuzz]

Hmmm, quite strange...

I tried to reproduce the problem, but i'm unable to reproduce it again.
And the savegame where I found the problem... just work fine now !

Looks like the game got stuck after a moment, and repaired itself when reloading the game...
I hope it's just something wrong with my version, or the bug will be hard to find

[MagicBuzz]

It happens again on my favorite saved game :/

Here is a detailed post about the problem with a savegame, a screenshot, GRF settings and comments
http://www.tt-forums.net/viewtopic.php?p=672207#p672207

[Wolf01]

another post in a row and you win a teddy bear :/


I have one little question: I think not all sets will be compatible, at least with the 'only' three available track types, I know the Japan set uses the maglev tracks for the Shinkansen, so the sets may look weird... how do you plan to handle this?

[MagicBuzz]

chrissicom already asked this (8 posts ago) and peter answered "And yes, I do have some plans for that...".

ps: and if you take a look at my posts, you'll see, there is an interval of more than 12 hours between the 2 first, and more than 24 hours with the next one. do you really think i should have a chance to get read if i edited posts 36 hours later ?