Pony: buy menu availability cb / var

[andythenorth]

The current model life property is unsatisfactory, the large random factor makes it hard to avoid buy menu spam among other problems.

Proposal:
- new cb for vehicle buy menu availability
- return 00 to hide, 'cb failed' for default behaviour (randomised), any other value to show.
- or use return values similar to climate availability prop, for consistency with that prop.

- new var: check availability of vehicle type by id. Used to enable, e.g. matching train engines and wagons to appear simultaneously. (Needs to not be possible to get into a circular deadlock).

[Toni Babelony]

Very much in favour of this proposal!

Would that mean that the retire_early property in NML will be rendered kind of useless?

[Michi_cc]

Would that mean that the retire_early property in NML will be rendered kind of useless?

Early retirement is about engine reliability, not purchase availability.

-- Michael Lutz

[Eddi]

an alternative would be "make this vehicle available when vehicle Y is available" property, simiar to railtypes.

[michael blunck]

The current model life property is unsatisfactory, the large random factor makes it hard to avoid buy menu spam among other problems.

The random factor in property 04 ("model life") is meant to generate different game behaviour.

In what way does it make it "hard to avoid buy menu spam"? It´s not that engines are showing up in the menu prior or after "real" availability ...

regards
Michael

[FooBar]

In what way does it make it "hard to avoid buy menu spam"? It´s not that engines are showing up in the menu prior or after "real" availability ...

Say I have an engine with matching wagon. Currently, if I want to ensure that the wagon is available when the engine is available, I have to introduce the wagon way earlier than the engine to ensure that the wagon is available with the engine in the very bordercase.

If the proposed feature were to be implemented, I'd use it for the Dutch Trainset for sure.

[Toni Babelony]

Would that mean that the retire_early property in NML will be rendered kind of useless?

Early retirement is about engine reliability, not purchase availability.

Aaah... Then I misinterpreted it from the wiki:

retire_early = Retire the vehicle (make it unavailable in the purchase menu) this many years before reliability starts dropping (...).

Anyway, I'll certainly use this feature if it gets implemented for sure! It'll come in very very handy with my densely packed sets.

[andythenorth]

In what way does it make it "hard to avoid buy menu spam"?

With short class lives (~20 years in HEQS), randomisation can keep an older vehicle type hanging around for around 17 years. Undesirable.

[Eddi]

In my use case, i have difficulties making a vehicle dual-headed, since all my vehicles are already articulated and you can't have both (or nobody implemented it, the specs could be extended). because of this, i have trouble with vehicles of different length. one way could be refitting like in HEQS, but that has its own troubles. the other option would be to offer the vehicle multiple times in the buy menu, which is what i currently do. the problem with that is that you get virtually the same vehicle offered many times as prototype. it would make more sense to have a "master" vehicle that gets offered as prototype, and "slave" vehicles that will never be offered as prototype, but automatically get introduced when the "master" vehicle gets introduced.

it's not the "perfect" solution, but it would definitely improve the situation.

[frosch]

I think this thread mixes too many things: Introduction, model life time and "too many items in purchaselist".

First of all, I do not like an availabilty callback at all. The randomness of introduction and availablity is IMO a core part of vehicle gameplay. [0]

Wrt. introduction and depencies between vehicles: Checking the availability of other vehicles is IMO way too complicated. Instead I propose again what I proposed before:

The randomisation of introduction dates should be changed in a way that it preserves the order of introduction. If two vehicles have the same introduction date in the GRF they are introduced at the same time.

Wrt. making vehicles disappear from the purchase list, to clean it up:
The "retire early" property already solves this half. It can be used to completely cut off the randomisation of phase 3 (which is not very useful anyway). So only the random 15 years of phase 2 remain.

Finally, about the "too many stuff in purchase list"-issue: I think it is fundamentally wrong to try to solve this via NewGRFs. (esp when considering "engines never expire") Instead there should be a feature which allows the player to remove (or readd) engines of his own selection to the purchase list. Further reasons to let the player decide are:
* Remove engines of no use for the player. (bad reliability etc.)
* Keep engines the player likes for whatever reason. (e.g. steam-engines )
* If a player uses multiple engine GRFs, he/she can way better decide which engines are too much, than any GRF could ever.


[0] Just like reliability is also a core part. Sadly too many people play without breakdowns and thus make it totally superfluous to decide between more than maybe 2 engines.

[Eddi]

The randomisation of introduction dates should be changed in a way that it preserves the order of introduction. If two vehicles have the same introduction date in the GRF they are introduced at the same time.

ok, but that is only half the solution of my problem. because it will still ask you about prototype-testing all 4(-ish) versions of the ICE then, each with a different amount of middle wagons.

on a related note: let the newgrf decide whether to throw an introduction news message for a vehicle (e.g. new generation of wagons are currently suppressed by the game). could be a flag of some sort, which defaults to enable for original engines and disable for original wagons.

[PikkaBird]

Officially requested on Frysplay.

Note that I am requesting this primarily for the purpose of allowing different players to have different vehicles in multiplayer. Earlier discussions about random introduction dates or "buy menu spam" are neither here nor there.

[michael blunck]

It would be nice to have a callback to add/remove vehicles from the purchase list [...],
The uses for this callback would include:

a) hiding "confusing" vehicles from an AI player.

There´s already prop18 (AI rank)?

b) hiding "AI Only" vehicles from a human player (for example, street traffic cars).

At least in TTDPatch, you could set the climate bit to "unavailable" (0) for the human player (but not for the AI).

c) giving players exclusive vehicles in multiplayer games (for example, player 1 gets German trains and player 2 gets French trains).

Could be done better by setting a parameter?

d) enabling vehicles as "rewards", in cooperation with a game script.

Shouldn´t something like this be a GS feature rather than a newGRF one?

b) count of vehicle (this/x) (owned by this player/everyone). This would allow authors to limit the number of a particular vehicle, if they wanted to do that for some reason.

An interesting and already discussed feature, but hard to imagine how it should work keeping different map features in mind.

regards
Michael

[PikkaBird]

There´s already prop18 (AI rank)? [...] At least in TTDPatch, you could set the climate bit to "unavailable" (0) for the human player (but not for the AI).

Would be relevant if we were playing TTDPatch, certainly.

Could be done better by setting a parameter?

Sure. Would you like to explain to me how I can use a parameter to give some vehicles to only some players, with no newgrf mechanism to give some vehicles to only some players?

Shouldn´t something like this be a GS feature rather than a newGRF one?

It's somewhere in between, which is why I wrote "in cooperation with a game script".

but hard to imagine how it should work keeping different map features in mind.

I have no idea what that means.

[michael blunck]

There´s already prop18 (AI rank)? [...] At least in TTDPatch, you could set the climate bit to "unavailable" (0) for the human player (but not for the AI).

Would be relevant if we were playing TTDPatch, certainly.

Well, this should work in OTTD as well. The only difference I see is that OTTD uses dedicated AIs, so the question arises how (well) the existing AIs can/are use/using existing specs.


[different vehicles for players]

Could be done better by setting a parameter?

Sure. Would you like to explain to me how I can use a parameter to give some vehicles to only some players, with no newgrf mechanism to give some vehicles to only some players?

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?


[limited number of particular vehicles]

interesting [...] but hard to imagine how it should work keeping different map features in mind.

I have no idea what that means.

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.

regards
Michael

[Hyronymus]

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.

regards
Michael

Only if a GRF author decides to let that number be determined by map size of course. If it's a value set in stone then I don't see a problem and I believe Pikka meant the latter.

[michael blunck]

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.

Only if a GRF author decides to let that number be determined by map size of course. If it's a value set in stone then I don't see a problem and I believe Pikka meant the latter.

Sorry?

regards
Michael

[Eddi]

tbh, i think limiting the engine count should rather be left to a gamescript, e.g. the game script simulates the production capacity of a factory, then if the player tries to build too many engines in a short period of time, the price of new engines will increase (no hard limit). of course a game script cannot be tied to a specific NewGRF (i'm not even sure it can check for presence of NewGRFs), so the system should be generic enough to handle all NewGRFs (potentially with a CB18-ish approach to communicate between Script and NewGRF)

[hargs]

tbh, i think limiting the engine count should rather be left to a gamescript, e.g. the game script simulates the production capacity of a factory, then if the player tries to build too many engines in a short period of time, the price of new engines will increase (no hard limit). of course a game script cannot be tied to a specific NewGRF (i'm not even sure it can check for presence of NewGRFs), so the system should be generic enough to handle all NewGRFs (potentially with a CB18-ish approach to communicate between Script and NewGRF)

If the link is only tenuous between scripts and newgrfs, perhaps it would be better to just allow the newgrf to sort it?

[Eddi]

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.