OpenTTD

Tasklist

FS#5086 - Non-random vehicles introduction/withdrawal dates

Attached to Project: OpenTTD
Opened by Vladimir Guryanov (Wowanxm) - Thursday, 01 March 2012, 01:03 GMT
Last edited by Artem (Osceola) - Sunday, 20 May 2012, 08:02 GMT
Type Feature Request
Category NewGRF
Status New
Assigned To Artem (Osceola)
Operating System All
Severity Medium
Priority Normal
Reported Version trunk
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 9
Private No

Details

Now the game addes a random number of days to the introduction date chosen by a coder. This is quite annoying feature when introducing parts of EMU's and DMU's. That is absolutely essential to offer heads/motor/non-motor units of xMU at the same time, on fixed dates.
And, of course, stable dates of introducing new vehicles and withdrawing old (halting of production) vehicles will give more realism possible for many set developers.
The point is to give a possibility of removing random factor optionally, according to coder's choice.

The idea have been discussed once:
http://www.tt-forums.net/viewtopic.php?f=68&t=57321&hilit=date
This task depends upon

Comment by Vladimir Guryanov (Wowanxm) - Monday, 26 March 2012, 18:22 GMT
"Assigned" status and still no movement for quite a long time. :)
Comment by Max (dadymax) - Saturday, 28 April 2012, 10:12 GMT
Well. As I can see this can be done by adding some kind of flag in NewGRF. This flag can be included in EngineMiscFlags with number 8 for ex. (Then in bitmask this flag can be seen by mask 0x08, even HasBit(EngineMiscFlags, 0x08)). And then
I can do this but I did not work with newgrf's and don't know about it internal structure.
Will adding of such parameter is normal?
Comment by frosch (frosch) - Saturday, 28 April 2012, 10:34 GMT
dadymax: You are misunderstanding the semantics of HasBit(). It takes the bit number, not the bit mask as arguement.

Anyway, IMO this feature hurts gameplay. I welcome that engines appear on different dates every game, so you cannot plan their introduction.
However - somewhat related - somewhen/somewhere I also suggested to change the randomisation of introdates in such a way, that the order of introduction is preserved.
Comment by Max (dadymax) - Saturday, 28 April 2012, 10:41 GMT
wow... my fault... ok :) Delete above file please...

I not a newgrf maker but think that in some cases with complex vehicles this feature is needed.
Comment by Vladimir Guryanov (Wowanxm) - Saturday, 05 May 2012, 19:15 GMT
I don't think many players do really plan introduction of some vehicles in their game strategy. :) What is more important that they cannot buy some xMU until the complete lineup (motor/non-motor unit) is appeared.
Comment by Vladimir Guryanov (Wowanxm) - Saturday, 05 May 2012, 19:18 GMT
What we are asking for - is just a flag for GRF developers. Some may use it, some may not - we don't forbid using grfs with fixed dates or any other. Moreover, there could be a specific parameter "use random/non-random vehicles introduction date" in Advanced Settings menu.
Comment by Vladimir Guryanov (Wowanxm) - Saturday, 08 September 2012, 09:28 GMT
As I understand, thanking to Max, we now have the patch, which is considered as one of the most wanted (8 votes). Why not to include it in trunk?
Comment by Alberth (Alberth) - Sunday, 09 September 2012, 11:17 GMT
The patch looks way too messy for trunk.
Besides that, it reverts the randomness in the introduction date, which is the wrong solution to the problem. Your problem is not random introduction, it is not keeping things properly together.

The right solution is either in the direction of a more careful way of randomzing introduction dates (as suggested by frosch several months ago), or an extension to the newgrfs for saying "these parts belong together".

Then OpenTTD can ensure they are introduced together and/or in the right order.
Comment by George (George) - Saturday, 15 September 2012, 13:33 GMT
> Then OpenTTD can ensure they are introduced together and/or in the right order.
How do you expect to define and provide the right order of vehicles to appear?
IMHO, this would be much harder than defining "exact" dates of introduction.
In case a patch for exact dates is "too messy", how messy would be the patch for "right order"?
IMHO, a much easier solution should be provided first, and only after that a massive complex solution should be provided.
Comment by Alberth (Alberth) - Sunday, 16 September 2012, 09:19 GMT
> > Then OpenTTD can ensure they are introduced together and/or in the right order.
> How do you expect to define and provide the right order of vehicles to appear?
Either by keeping the order of introduction dates, or by keeping stuff marked as "belong together" together, imho. Not sure about feasibility of the latter though.

> IMHO, this would be much harder than defining "exact" dates of introduction.
Perhaps it is harder, but fixed dates kills a feature and it should not do that.
That is, the solution works, but it does so in a too crude way. It should act more subtle, and work together with other existing features instead of bluntly axing them.

> In case a patch for exact dates is "too messy", how messy would be the patch for "right order"?

I meant messy in the sense of being a proposed changeset for trunk. Several changes merged together in one patch instead of being properly split in a patch queue, and changes that are not related to the fix at all.
The change itself is quite trivial and probably correct (but as explained above, wrong in my view).

> IMHO, a much easier solution should be provided first, and only after that a massive complex solution should be provided.

Shifting dates without messing up the order does not strike me as "massive complex".
Easier solutions tend do more harm than they solve. They fail in unexpected new ways, and make the real problem harder to understand and fix.
In this case, the solution is not even a solution, it is an axe chopping away features.
Comment by Max (dadymax) - Tuesday, 25 September 2012, 08:23 GMT
But if parts of EMU that need to introduce together arrive in right order but with halfyear distance one from other it is bad.

Anyway, with advanced trainsets (and carsets) beign created we need such feature. Maybe not in such way but we need it.

Another idea.
Can we add some linked list info in set like:
EMU1 -> EMU2
EMU3
EMU4 -> EMU5

or some kind of dependency between:
EMU1 (EMU2)
EMU3
EMU4 (EMU5)
?
Last is better because we can do multiple depencies:
EMU6 (EMU7,EMU8).

And if EMU1 introducing in game then all depencies also introduced with it.

How do you think about that?
Comment by frosch (frosch) - Tuesday, 25 September 2012, 20:06 GMT Comment by George (George) - Wednesday, 26 September 2012, 06:10 GMT
Can't open the link - time out error
Comment by Ingo von Borstel (planetmaker) - Wednesday, 26 September 2012, 09:00 GMT
The link will time out on 26th September 1am - 1pm UTC; it's a scheduled downtime to allow some needed server maintenance.
Comment by Tadeusz (TadeuszD) - Tuesday, 20 January 2015, 10:55 GMT
Hello, I'm NewGRF coder.
In my opinion it is fundamentally bad idea to introduce parts of DMU/EMU as independent vehicles. Modern NewGRFs define DMU/EMU as a single vehicle with refit option for shorten/extend the consist. Refit_cost callback now supports cargo_subtype and can generate additional costs/incomes when the consist is refitted.
In conclusion, there is no need to add special synchronisation mechanism for vehicle introduction date.

Loading...