OpenTTD

Tasklist

FS#4410 - Trains: var4A in purchase list (current railtype)

Attached to Project: OpenTTD
Opened by Michael Blunck (mb) - Saturday, 15 January 2011, 11:57 GMT
Last edited by andythenorth (andythenorth) - Sunday, 03 September 2017, 07:41 GMT
Type Feature Request
Category NewGRF
Status New
Assigned To No-one
Operating System All
Severity Low
Priority Normal
Reported Version trunk
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 0
Private No

Details

It would be nice to get var4A (current rail type for trains) available in the purchase list. I´m using different values for net load depending on rail type, and it would be beneficial for the player to see it in advance in the purchase list.
This task depends upon

Comment by Remko Bijker (Rubidium) - Monday, 17 January 2011, 20:55 GMT
The current railtype would be the railtype of the depot, right? But what when there is no depot, e.g. the available engines list that you can open from the vehicle list's window.

I assume you want to get the railtype's label, right?
Comment by Michael Blunck (mb) - Monday, 17 January 2011, 22:38 GMT
> The current railtype would be the railtype of the depot, right?

In this case, yes. (Because the vehicle is not yet built.)

> But what when there is no depot, e.g. the available engines list that you can open from the vehicle list's window.

Mmh? Ah yes, there´s another scroll down menu ... never realised it. Well, this list seems to include *all* vehicles. So, it lacks the "filter functionality" of a depot, so to say. Well, that´d be OK, as a list of vehicles from every depot type, it´d simply display the max value for a particular vehicle.

> I assume you want to get the railtype's label, right?

Yes: "the lower byte (rr) contains the (translated) rail type the train vehicle is currently driving on."
Comment by frosch (frosch) - Tuesday, 18 January 2011, 20:52 GMT
I guess the variable would need to return some special value like 0xFFFFFFFF for the "available vehicles"-list, autoreplace-gui, newspaper and vehicle-preview.

However, there are way too many places where the depot-railtype would need passing to various callbacks and similiar though. Making it very hard to implement unless maybe using some treacherous global variables set and reset by the purchase list.

Would it be enough, if this was only available for callback 23 (additional text)?
Comment by Michael Blunck (mb) - Tuesday, 18 January 2011, 22:14 GMT
> However, there are way too many places where the depot-railtype would need passing to various > callbacks and similiar though. Making it very hard to implement unless maybe using some
> treacherous global variables set and reset by the purchase list.

I was under the impression that the depot already "knows" about the current railtype (hence its selection of vehicles), and thus it should be "manageable". :)

> Would it be enough, if this was only available for callback 23 (additional text)?

It would be helpful, at least.

Loading...