Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Non-random vehicles introduction/withdrawal dates #5086

Closed
DorpsGek opened this issue Mar 1, 2012 · 16 comments
Closed

Non-random vehicles introduction/withdrawal dates #5086

DorpsGek opened this issue Mar 1, 2012 · 16 comments
Labels
component: NewGRF This issue is related to NewGRFs flyspray This issue is imported from FlySpray (https://bugs.openttd.org/)

Comments

@DorpsGek
Copy link
Member

DorpsGek commented Mar 1, 2012

Wowanxm opened the ticket and wrote:

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

Reported version: trunk
Operating system: All


This issue was imported from FlySpray: https://bugs.openttd.org/task/5086
@DorpsGek
Copy link
Member Author

Wowanxm wrote:

"Assigned" status and still no movement for quite a long time. :)


This comment was imported from FlySpray: https://bugs.openttd.org/task/5086#comment11033

@DorpsGek
Copy link
Member Author

dadymax wrote:

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?

Attachments


This comment was imported from FlySpray: https://bugs.openttd.org/task/5086#comment11158

@DorpsGek
Copy link
Member Author

frosch wrote:

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.


This comment was imported from FlySpray: https://bugs.openttd.org/task/5086#comment11162

@DorpsGek
Copy link
Member Author

dadymax wrote:

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.

Attachments


This comment was imported from FlySpray: https://bugs.openttd.org/task/5086#comment11163

@DorpsGek
Copy link
Member Author

DorpsGek commented May 5, 2012

Wowanxm wrote:

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.


This comment was imported from FlySpray: https://bugs.openttd.org/task/5086#comment11186

@DorpsGek
Copy link
Member Author

DorpsGek commented May 5, 2012

Wowanxm wrote:

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.


This comment was imported from FlySpray: https://bugs.openttd.org/task/5086#comment11187

@DorpsGek
Copy link
Member Author

DorpsGek commented Sep 8, 2012

Wowanxm wrote:

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?


This comment was imported from FlySpray: https://bugs.openttd.org/task/5086#comment11501

@DorpsGek
Copy link
Member Author

DorpsGek commented Sep 9, 2012

Alberth wrote:

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.


This comment was imported from FlySpray: https://bugs.openttd.org/task/5086#comment11502

@DorpsGek
Copy link
Member Author

George wrote:

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.


This comment was imported from FlySpray: https://bugs.openttd.org/task/5086#comment11512

@DorpsGek
Copy link
Member Author

Alberth wrote:

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.


This comment was imported from FlySpray: https://bugs.openttd.org/task/5086#comment11513

@DorpsGek
Copy link
Member Author

dadymax wrote:

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?


This comment was imported from FlySpray: https://bugs.openttd.org/task/5086#comment11557

@DorpsGek
Copy link
Member Author

frosch wrote:

For reference: http://webster.openttdcoop.org/index.php?channel=openttd.dev&date=1348531200# 1348598972


This comment was imported from FlySpray: https://bugs.openttd.org/task/5086#comment11558

@DorpsGek
Copy link
Member Author

George wrote:

Can't open the link - time out error


This comment was imported from FlySpray: https://bugs.openttd.org/task/5086#comment11559

@DorpsGek
Copy link
Member Author

planetmaker wrote:

The link will time out on 26th September 1am - 1pm UTC; it's a scheduled downtime to allow some needed server maintenance.


This comment was imported from FlySpray: https://bugs.openttd.org/task/5086#comment11560

@DorpsGek
Copy link
Member Author

TadeuszD wrote:

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.


This comment was imported from FlySpray: https://bugs.openttd.org/task/5086#comment13734

@DorpsGek
Copy link
Member Author

andythenorth closed the ticket.

Reason for closing: Won't implement

Don't depend on other vehicles in this way (see comment from Tadeusz for alternative methods). Vehicle random intro dates is a core OpenTTD mechanic, and changing it is not a current goal. If it was changed, # 5471 would provide a way to achieve it using a more general-purpose callback that would add more value.


This comment was imported from FlySpray: https://bugs.openttd.org/task/5086

@DorpsGek DorpsGek added flyspray This issue is imported from FlySpray (https://bugs.openttd.org/) component: NewGRF This issue is related to NewGRFs enhancement labels Apr 7, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
component: NewGRF This issue is related to NewGRFs flyspray This issue is imported from FlySpray (https://bugs.openttd.org/)
Projects
None yet
Development

No branches or pull requests

1 participant