The decision need not be random. It could be done with parameters, like you suggested. If the vehicle counting var were implemented, one could even have the player select French or German trains by building their first locomotive.michael blunck wrote: I think it´ll be better to let the players decide which "group" of vehicles they´re going to use (French ones, or German ones), rather than make that decision by random (?). And then, why shouldn´t they use different sets at all?
Functionally, of course, this can already be done. I can already give different players different vehicle sprites, so for example I could show "French" locomotives to the "German" player greyed out with a slash through them. I can also control whether or not a train can leave the depot, so I could make it impossible for the "German" player to start a "French" train. This additional callback would simply make things easier for players, by allowing me to clear their purchase menu of vehicles they're not allowed (because they have chosen not to be allowed) to use.
This seems to be a variant on Lakie's old argument-against-everything: "if xyz feature is implemented, newgrf authors will use it to do horrible things to the player and TTD will be ruined forever!". Firstly, no we won't, we're smarter than that. Secondly, even if we do, the worst we can do is produce an unplayable GRF that no-one will use. I'm just asking for a tool; if I misuse it it's no skin off anyone's nose but my own.W/o having detailed information about the actual map (size, mountainousness(?), distribution and sizes of towns, types and numbers of industries, ...) it´d be hard to impossible for a newGRF to decide about the number of particular engines to be allocated to the player.
"It should be done in GS" is the new bane of every NewGRF feature discussion, and I'm sorry I even mentioned GS in the feature request. No, it - for almost any value of it - should not be done in GS, for the following two reasons;Eddi wrote:tbh, i think limiting the engine count should rather be left to a gamescript [...] We already have this problem with Industry NewGRFs, where the NewGRF itself has really heavy control mechanism and nobody can build properly balanced economy mechanisms on top of that.
One, you can only have one GS running at a time. GS are specifically for "setting conditions, goals, achievements and quests". Any kind of "mechanism" more specific than that - production by individual industries, availability of individual vehicles - is the province of NewGRF.
Two, as you so rightly pointed out, a GS cannot be linked to a specific NewGRF. So to transfer some of my NewGRF's functionality to a GS means I need to write a script generic enough to function with any, or no, NewGRFs. This would be, at best, nearly impossible to achieve.
Now, if these two obstacles were removed - if the GS could detect and interact with the GRF, and if loading any number of "mechanic" GSes didn't preclude players from also loading a proper "goal" GS - then yes, this could be done in GS. But what would be the point? All you would have achieved is making the player find, install and configure two files instead of one to use this train or industry or house set. Where's the sense in that?
