Transport Tycoon Forums

Posted: **01 Jun 2008 20:30**

I read some complaints about the engine pool, so i decided to think a bit about the problem.

1- Too much items in the list:

My idea:: sorting the items by GRF pack and putting them in separate list that you can select with a dropdown menu, a bit like for the new station GUI.

2- Set incompatibility and bad tast mixing of train sets:

My idea: Make set "strongly" incompatible, I mean making it impossible to mix trains from two sets if the set develloper wants it. If sets develloper don't want to see mis-use of there set (cf: CanSet topic) give them the possibility to restrict the mixing of different GRF sets.

Hope this will help, and sorry for my bad english.

Posted: **01 Jun 2008 20:31**

nautre125 wrote:1- Too much items in the list:

Load fewer sets.

nautre125 wrote:2- Set incompatibility and bad tast mixing of train sets:

Load fewer incompatible sets.

Posted: **01 Jun 2008 20:40**

peter1138 wrote: Load less sets.
Load less incompatible sets.

I don´t think this is an adequate answer to serious questions rised, especially in the cited thread.

regards
Michael

Posted: **01 Jun 2008 20:53**

michael blunck wrote:especially in the cited thread.

What cited thread?

1) Generalised filters are in the pipeline which allow filtering on more than just GRF.

2) There is a flag (hijacked from 'TTDPatchFlags') which would allow this. If the flag is unset, engines will overwrite each other like the good old days (great improvement) and GRM 'works'. More IDs still work, whatever the setting, though. Additional measures could be implemented but I've not heard of any yet.

Posted: **01 Jun 2008 21:09**

What cited thread?

Well, it seems he was refering to this one.

regards
Michael

Posted: **02 Jun 2008 01:19**

I agree with both suggestions.
Sorry to repeat myself, but here is the proper thread to discuss it.

Posted: **02 Jun 2008 05:14**

nautre125 wrote: ... the engine pool ...

First, I'd like to apologise for that DaleStan-style initial comment, it was inappropriate and inadequate.

Let's start again. Thank you for taking the time to think about that problem. Your suggestions are definitely on the right track, but we need far more than that. Here is a list of items that I, as a coder, require to allow a train vehicle set, like the Canadian Trains Set, into the pool.

These items have been on my mind for a long time; back then the issues were discussed with Snail in connection with the French Trains Set.

Credits go to those who have mentioned individual items first; here or somewhere else.

a] Split patchflag 'Enable multiple NewGRF engine sets' into vehicle types (rail, road, ...); very much like 'Disallow trains for competitors' etc. This would be an initial quick fix, to allow road, air and sea sets into the pool, but not train sets. After all these other vehicle types are the ones to gain most from this 'feature'.

b] GRF sets need access to individual flags above; same as variable 85 bit 78.

c] GRF sets need access to variable 9D (used in action-7/9) in var act 2 chains; currently var 1D is considered invalid and contains 0; can of course be any other variable. We must still be able to cater for TTDPatch and OpenTTD variations.

d] Vehicle Set Registration Table (SRT); similar to the Cargo Translation Table. Entries in this table define other friendly sets by GRFID. A set not in the table is considered a foe by the source set. The source set will be in entry 0x00. [more details further down].

e] Vehicle Purchase List to contain only vehicles from ONE vehicle set; plus may be friendly sets listed in SRT. The source grf would make that decision. The 'New Vehicles' tab in the depot window to open a drop down menu, listing all activated vehicle sets of same vehicle type; just like stations do.

f] Facility to prevent vehicles (engines and wagons alike from the source set) to be attachable to lead engines from other vehicle sets; unless listed in the SRT.

g] Facility to prevent vehicles (engines and wagons alike) from other vehicle sets to be attachable to lead engines of the source set. Callback 1D requires access not only to the vehicle ID but also to the vehicle set ID. We must be able to distinguish between friends (listed in SRT) and foes. Foes could be identified as 0xFF; friends by the slot in the SRT.

h] Sets with custom rail track systems; i.e. Narrow gauge, Shinkansen, MagLev, Monorail must be able to use them exclusively.

g] Global Variables; i.e. base costs etc must not interfere with other vehicle sets nor interfered with by other sets.

h] Vehicle Variables (var act-2) that contain vehicle identifiable information; like veh ID in var C6 must contain the vehicle set ID from the SRT or 0xFF for foes. Need to become a DW.

i] Now is the time to mention that expansion of vehicle property 25 and veh var 42 b3 again; this is now an absolute must. We need a double word for both.

Plus anything else I have forgotten ...

An answer this is not possible, too complicated is the wrong one. It is for the Open Devs to find a solution. Until then, coders have every right to keep their sets away from the pools edge.

peter1138 wrote: ... More IDs still work, whatever the setting, though ...

Where is all that documenation ? Where can I find documentation, that says train vehicle sets can use more than 116 veh IDs. Where is explained, how livery overides are affected when vehicles from different sets are in the same train ... and the queries and questions go on and on ...

Thank you for your attention.

Posted: **02 Jun 2008 05:33**

OzTransLtd wrote:c] GRF sets need access to variable 9D (used in action-7/9) in var act 2 chains; currently var 1D is considered invalid and contains 0; can of course be any other variable. We must still be able to cater for TTDPatch and OpenTTD variations.

This can already be done; use action D to set a parameter and check it with action 2 var 7F.

Posted: **02 Jun 2008 07:04**

OzTransLtd wrote:c] GRF sets need access to variable 9D (used in action-7/9) in var act 2 chains; currently var 1D is considered invalid and

... isn't.

NFORenum doesn't like it because it isn't documented. Go document it and NFORenum will probably quit complaining soon after.

Posted: **02 Jun 2008 09:22**

OzTransLtd wrote:...
d] Vehicle Set Registration Table (SRT); similar to the Cargo Translation Table. Entries in this table define other friendly sets by GRFID. A set not in the table is considered a foe by the source set. The source set will be in entry 0x00. [more details further down].

e] Vehicle Purchase List to contain only vehicles from ONE vehicle set; plus may be friendly sets listed in SRT. The source grf would make that decision. The 'New Vehicles' tab in the depot window to open a drop down menu, listing all activated vehicle sets of same vehicle type; just like stations do.

f] Facility to prevent vehicles (engines and wagons alike from the source set) to be attachable to lead engines from other vehicle sets; unless listed in the SRT.

These would be covered by my suggestion of a vehicle class, in exactly the same manner as a newstation class. Sets that use the same class are the equivalent of your "friendly SRT" (d). A flag in the .grf could indicate whether the set is allowed to use vehicles outside of that class (f). The New Vehicles gui would have the same drop down facility as the current newstations. (e)

The advantage of the system I propose is that (d) defines specific sets by GRFID. Over time these GRFIDs will change, and sets will get progressively less supportive of each other. In the class system, the classes would be broader defined; eg. USNA for USA & North America, EURO for European, ASIA for Japan, China, etc. With broader classes, it would be simpler to keep friendly .grfs working together.

Posted: **02 Jun 2008 09:37**

Hmm some other things.. Mainly thinking about multiplayer..

I know that the engine pools was meant to grf coders, who want to add more vehicles in one set, ont for players, who want to use different sets at the same time. BUT currently IMO the different grf sets loadable together is one great bonus too.. Now only problems are sorting the vehicles by sets and economic changes..

For multiplayer, it could be interesting if all companies use different sets. Especially some event multiplayer games like World Wide OpenTTD Game Day or such.. So there could be some way to limit some companies only some sets.. Like one company gets only DB set and other Japanese or sth like that. That could be also done with just sorting the vehicle list, and telling them to use only one set..

: idea.png (12.42 KiB) Viewed 4014 times

And the other is economy, some patch option maybe that if some grf affects base costs, then to use it on that specific GRF only. It would help to keep the prices balanced. Again, I know that the idea of this patch was to help grf makers to get more vehicles in their set, but why be not able to use it in different aspects.

Posted: **02 Jun 2008 10:03**

LordAzamath wrote:I know that the engine pools was meant to grf coders, who want to add more vehicles in one set, ont for players, who want to use different sets at the same time.

Oh no! It was just the other way round. IIRC, nobody did ask "grf coders" beforehand if and how they´d like such a feature.

For multiplayer, it could be interesting if all companies use different sets.

Only if they´d like to experience a biased gameplay. Train sets are too different to allow a well-balanced game with equal chances for every participant.

regards
Michael

Posted: **02 Jun 2008 10:41**

michael blunck wrote:
LordAzamath wrote:I know that the engine pools was meant to grf coders, who want to add more vehicles in one set, ont for players, who want to use different sets at the same time.
Oh no! It was just the other way round. IIRC, nobody did ask "grf coders" beforehand if and how they´d like such a feature.

In that respect the latest posting by OzTransLtd is probably a good starting point as there seems to be the need for some clearification. There may be places (besides the two wikis) which I'm not aware of which summarize grf devs and the source devs needs + plans though. It's quite sad to see that many people put so huge and great efforts in either magnificient grf sets or the game source side but - as it seems - fail to communicate eachothers needs or possibilities sufficiently

. After all it's a commen effort and two sided of a medal to improve this magnificient game(s), isn't it?

michael blunck wrote:
For multiplayer, it could be interesting if all companies use different sets.
Only if they´d like to experience a biased gameplay. Train sets are too different to allow a well-balanced game with equal chances for every participant.

That will be true, on the other hand it may not be an issue, e.g. if plan for a scenario and / or you allow for set-specific adjustment of the base costs. Like LA wrote, scenarios like wwottdgd would IMO greatly profit from a restriction of a set to one or a limited range of the companies which participate in a game - even though companies then may have different capabilities - just as in real life.

Regards,
planetmaker

Posted: **02 Jun 2008 10:55**

Oh no! It was just the other way round. IIRC, nobody did ask "grf coders" beforehand if and how they´d like such a feature.

That is.... interesting... I always had the reverse understanding..

Only if they´d like to experience a biased gameplay. Train sets are too different to allow a well-balanced game with equal chances for every participant.

Do you play TTDP to see how much money you accumulate on 63rd year? Or do you play it because you need to be better than everybody else? I guess neither is true. The #wwottdgd what I was talking about is too, just an event to have fun with lots of clients connected.. And it would be nice imo when you see different trains, which still hold true to their own wagons (not from some other grf) running down the rails.. And even on the same rails, since we have the infrastructure sharing patch.. IMO the multiplayer possibility in OpenTTD isn't so much for competition, but having fun.. And a company with UKRS having lower/higher income than a DB set (just picked two of my favourites

) doesn't take away the fun. Of course, we could use only one train set too, since currently using different train sets together will screw up the costs of vehicles etc.. (similar to LV4 and trams situation), but IMO it would be great if we could use the feature in it's full glory

And btw, MB, you should sometimes play some multiplayer games with OpenTTD.. And not just in some random server and you see what I mean

(I guess you play TTDP mainly, yes?)

Madis

Posted: **02 Jun 2008 11:50**

michael blunck wrote:
LordAzamath wrote:I know that the engine pools was meant to grf coders, who want to add more vehicles in one set, ont for players, who want to use different sets at the same time.
Oh no! It was just the other way round. IIRC, nobody did ask "grf coders" beforehand if and how they´d like such a feature.

I dont think there should be a requirement for the grf coders to be consulted about how OpenTTD development should or should not proceed. That is putting the progress of development of OTTD into the hands of an elite few who (historically) have prioritised support in TTDPatch.

Support for this feature is unlikely to appear in Patch in anywhere like the near future, so it is an OTTD driven feature. Sometimes a decision has to be made "it will be done this way", and if TTDP grf coders want to see their output used in OTTD, then they have to conform - much as OTTD has had to conform to TTDP-centric NFO.

In my view, all that is required is *clear* documentation of the new requirements. It is then up to the grf coders whether they wish to have their .grfs conform or not, bearing in mind that non-conforming .grfs slowly die.

The current facility is a raw beginning; some of the ideas here can give it more polish. Ultimately it comes down to the coder who does the work of coding the changes to decide what and how it works. All others are just, as they say in theatre plays, "Voices Off".

Posted: **02 Jun 2008 13:34**

OzTransLtd wrote:
nautre125 wrote: ... the engine pool ...
First, I'd like to apologise for that DaleStan-style initial comment, it was inappropriate and inadequate.

Let's start again. Thank you for taking the time to think about that problem. Your suggestions are definitely on the right track, but we need far more than that. Here is a list of items that I, as a coder, require to allow a train vehicle set, like the Canadian Trains Set, into the pool.

These items have been on my mind for a long time; back then the issues were discussed with Snail in connection with the French Trains Set.

Credits go to those who have mentioned individual items first; here or somewhere else.

a] Split patchflag 'Enable multiple NewGRF engine sets' into vehicle types (rail, road, ...); very much like 'Disallow trains for competitors' etc. This would be an initial quick fix, to allow road, air and sea sets into the pool, but not train sets. After all these other vehicle types are the ones to gain most from this 'feature'.

b] GRF sets need access to individual flags above; same as variable 85 bit 78.

c] GRF sets need access to variable 9D (used in action-7/9) in var act 2 chains; currently var 1D is considered invalid and contains 0; can of course be any other variable. We must still be able to cater for TTDPatch and OpenTTD variations.

d] Vehicle Set Registration Table (SRT); similar to the Cargo Translation Table. Entries in this table define other friendly sets by GRFID. A set not in the table is considered a foe by the source set. The source set will be in entry 0x00. [more details further down].

e] Vehicle Purchase List to contain only vehicles from ONE vehicle set; plus may be friendly sets listed in SRT. The source grf would make that decision. The 'New Vehicles' tab in the depot window to open a drop down menu, listing all activated vehicle sets of same vehicle type; just like stations do.

I have no idea how you'd define 'source grf'

OzTransLtd wrote:f] Facility to prevent vehicles (engines and wagons alike from the source set) to be attachable to lead engines from other vehicle sets; unless listed in the SRT.

Simple misc flags bit would what, but no doubt probably not flexible enough for you.

OzTransLtd wrote:g] Facility to prevent vehicles (engines and wagons alike) from other vehicle sets to be attachable to lead engines of the source set. Callback 1D requires access not only to the vehicle ID but also to the vehicle set ID. We must be able to distinguish between friends (listed in SRT) and foes. Foes could be identified as 0xFF; friends by the slot in the SRT.

Engine IDs are word values, so 0xFF is a valid ID. 0xFFFF is usable as invalid, though.

OzTransLtd wrote:h] Sets with custom rail track systems; i.e. Narrow gauge, Shinkansen, MagLev, Monorail must be able to use them exclusively.

Rail track systems are a totally separate feature to engines, and will be handled as such (rail type labels, similar to cargo labels, are already planned.)

OzTransLtd wrote:g] Global Variables; i.e. base costs etc must not interfere with other vehicle sets nor interfered with by other sets.

Global variables are global variables. These are also saved in the savegame with inflation added. Not impossible, but adding word or dword values to cost factors my be better. I don't know.

OzTransLtd wrote:h] Vehicle Variables (var act-2) that contain vehicle identifiable information; like veh ID in var C6 must contain the vehicle set ID from the SRT or 0xFF for foes. Need to become a DW.

Only applies to parent scope, I suppose. And if mixing is disabled doesn't really matter. Again 0xFF is a valid ID.

OzTransLtd wrote:i] Now is the time to mention that expansion of vehicle property 25 and veh var 42 b3 again; this is now an absolute must. We need a double word for both.

Easiest bit yet...

OzTransLtd wrote:Plus anything else I have forgotten ...

An answer this is not possible, too complicated is the wrong one. It is for the Open Devs to find a solution. Until then, coders have every right to keep their sets away from the pools edge.

I don't think anybody's denied you that 'right.'

OzTransLtd wrote:
peter1138 wrote: ... More IDs still work, whatever the setting, though ...
Where is all that documenation ? Where can I find documentation, that says train vehicle sets can use more than 116 veh IDs. Where is explained, how livery overides are affected when vehicles from different sets are in the same train ... and the queries and questions go on and on ...

And show me the documentation that says there are only 116 veh IDs to use for rail vehicles. (There is a table but it does not state they are maximum values.) This will be added somewhere at some point, though. Action 0 IDs have been an 'extended byte' for a long time. (Actually it's still a byte in action 3, that needs fixing.) For overrides, they behave as they always have done, but it may be overriding a different ID, in which case it will not be an override (makes sense if described better).

Posted: **02 Jun 2008 18:16**

OzTransLtd wrote:Facility to prevent vehicles (engines and wagons alike) from other vehicle sets to be attachable to lead engines of the source set. Callback 1D requires access not only to the vehicle ID but also to the vehicle set ID. We must be able to distinguish between friends (listed in SRT) and foes. Foes could be identified as 0xFF; friends by the slot in the SRT.

That was what I actually meant with point 2) of the subject. This would prevent TGV to act as freight trains using wagons from other set. (cf CanSet topic).

LordAzamath wrote:idea.png

And this was my point 1), this is exactly what I meant.

Posted: **03 Jun 2008 01:58**

PikkaBird wrote: ... use action D to set a parameter and check it with action 2 var 7F. ...

Yes, I'm aware of that, but it would probably still be better to have a dedicated variable.

1D seems to work in TTDPatch, but is probably not implemented in OpenTTD, it returns 0 in both cases.

rick67 wrote: ... vehicle class vs Set Registration Table of GRFIDs ...

I have no problem with your suggestion as long as other sets (I want to know about) can be identified.

I would like to know (for callback 1D), which is the GRFset that contains the vehicle that wants to be attached to one of my (e.g. CanSet) engines.

LordAzamath wrote: ... implementation of that feature ...

It should have been announced beforehand; we could have had all our say ... eventually it should have been implemented on an opt-in basis for GRFs; unfortunately it was forced upon us coders to deal with the aftermath.

The feature is good; it's how it was implemented that is flawed. With the latest revelations, that all was already possible, that makes it even worse.

I had a clear understanding, that train sets are limited to 116 vehicles by ID in the range of 0x00 .. 0x73 (with all other vehicle types restricted similar). We talked a lot about having more vehicles, we maintained the opinion it is not possible; but no body corrected us that it is already possible. I never tried to define a train vehicle with VehID 0x99 until today. What's the result ? NFORenum doesn't like it and TTDPatch confirms that.

Code: Select all

//!!Error (141): ID 99 out of valid range (00..73).
  882 * 92	 00 00 24 01 99 21 00 05 00 19 00 24 00 ... 

//!!Error (141): ID 99 out of valid range (00..73).
 8369 * 10	 03 00 01 99 01 FF EF 00 DF 00

Just a minor problem.png

Why has Foobar spent so much time in documenting ID allocations/recommendations for road vehicle sets ? Because there are limits in the number of IDs we have available.

Now, where again can I find documentation, that says more than 116 train vehicles by ID are possible, or even more than 255 ? In TTDPatch, it is not possible; in OpenTTD it supposedly is. But that warrants clear documentation.

The wiki says the ID of an action-0 is an extended byte, so that we can have more than 255 sound effects. Doesn't say other IDs are implemented too.

No mention of it in action-3s and action-4s (I'd like to give a name to my new vehicle with the ID 0x2099).

peter1138 wrote: ... definition of source grf ...

I could have said 'CanSet'; or the set a vehicle is defined in [where its action-0/1/2/3 is defined]; e.g. wagon with ID 0x15 from source.grf (S1) wants to be attached to an engine in another set (S2).

... Engine IDs are word values, so 0xFF is a valid ID ...

So, I found out. 0xFF may be valid in Open but not the Patch.

... Rail track systems are a totally separate feature to engines, ...

Naturally, but are important to work with existing sets in that pool.

... global variables ...

Of course they are global and should remain global; but we would need a new system to define cost bases that can be applied to a particular GRF only.

... mixing vehicles from different sets and h] ...

Being able to block mixing such vehicles and/or knowing more than just the VehID is important.

Basically I want to disallow attaching vehicles from other sets and not allowing my vehicles to be attachable to engines of other sets. But, should I wish to allow this, then I need to know more than just the vehicle ID; I need to know what set they are defined in, because we can still have duplicate vehicle IDs.

... livery overrides ...

That would be a nightmare in mixed trains; not allowing mixed trains solves it for now.

... Documentation ...

Yes, it would be really nice to have the variations between OpenTTD and TTDPatch documented. Not just for me, but there are less experienced coders out there who know less than half as much. It surely would help them.

To summarise in layman terms :

The CanSet is the only train vehicle set I'm ever going to be involved with. I simply want to block any vehicle from any other set to show up in 'my' Purchase Window or behind any Canadian engine in the CanSet. Neither do I want to allow any of 'my' vehicles to show up behind any engine from another set. I will be able to do without other friendly sets, because now we know we can have 256 vehicles by ID in a set (not more, because that does not work yet, because there is no action-3 and 4 support). I don't think DanMacK will be able to come up with enough sprites for another 140 vehicles by ID in my lifetime. The CanSet will remain a single GRF set for now.

Then, the purchase and running cost system, as well as the Narrow Gauge Track system must not be interfered with by other sets.

How, that is or can be achieved is up to Open Devs to decide; I don't want to have something implemented in one particular way, just have it available one way or another.

Posted: **03 Jun 2008 02:48**

OzTransLtd, may I point out that the notion of an engine pool patch is not something that happened out of nowhere?
http://www.tt-forums.net/viewtopic.php?f=33&t=35897
As you can see, it has been an active matter.
Even Dalestan and michael blunck were aware of it.

There was even a patch collection containing it : http://www.tt-forums.net/viewtopic.php?f=33&t=36127

Posted: **03 Jun 2008 09:12**

OzTransLtd wrote:The CanSet is the only train vehicle set I'm ever going to be involved with. I simply want to block any vehicle from any other set to show up in 'my' Purchase Window or behind any Canadian engine in the CanSet. Neither do I want to allow any of 'my' vehicles to show up behind any engine from another set.

Or translated: "They are my toys. I made them. I will tell you how to play with them."

Thanks... I know what set to avoid then.

Transport Tycoon Forums

Engine Pool suggestions (making it more useable)

Engine Pool suggestions (making it more useable)

Re: Engine Pool suggestions (makeing it more useable)

Re: Engine Pool suggestions (making it more useable)

Re: Engine Pool suggestions (making it more useable)

Re: Engine Pool suggestions (making it more useable)

Re: Engine Pool suggestions (making it more useable)

Re: Engine Pool suggestions (making it more useable)

Re: Engine Pool suggestions (making it more useable)

Re: Engine Pool suggestions (making it more useable)

Re: Engine Pool suggestions (making it more useable)

Re: Engine Pool suggestions (making it more useable)

Re: Engine Pool suggestions (making it more useable)

Re: Engine Pool suggestions (making it more useable)

Re: Engine Pool suggestions (making it more useable)

Re: Engine Pool suggestions (making it more useable)

Re: Engine Pool suggestions (making it more useable)

Re: Engine Pool suggestions (making it more useable)

Re: Engine Pool suggestions (making it more useable)

Re: Engine Pool suggestions (making it more useable)

Re: Engine Pool suggestions (making it more useable)