Transport Tycoon Forums

I'm sure I've muttered about this before, but now I can't find it. Anyway, I'm going to make this suggestion official:

I think it would be useful to have callbacks for station naming, called on both the station and the closest industry (only if the closest industry is in the catchment area? Possibly all industries in catchment area, closest first?).
The return value would be either the number of a D0xx text, a magic number that maps to one of textIDs 300F..302F, or a magic number that means "revert to default naming".

It might also be useful to have a generic version of this callback, to be called if the station-specific and industry callbacks both fail. The main reason for this is to enable GRF-supplied strings for non rail-stations, but those probably belong in their own feature, so this may not be feasible.

Information that seems useful in this callback includes:
- Number of times this callback has been called, in case there are multiple GRF-supplied names.
- (industries, generic) Which station part is being built
- ΔX/ΔY from the station to the center of the nearest town (signed byte should be sufficient here; if it's more than 127 squares to the nearest town, the scenario creator should be shot.)
- ΔX/ΔY from the station to the nearest industry?
- (station, generic) type of nearest industry?

With this callback, Oz's megastations could name themselves appropriately, eg "\80 Grand Central", and MB's waypoints could name themselves "\80 Waypoint", &c.

The industry version of this callback would be useful for avoiding this type of illogicality:
and for eg naming bouys near fishing grounds to "\80 Fishing Grounds".

I like this idea however I do have a question: Would the ability for a player to rename a station be preserved?

Of course. The callback should only be called when the station is first built; after that, the station would behave just like any other station.

This could also reduce the frequency of the "Too many stations/loading areas in this town" messages. I'm not sure if that's really a selling point, though; I've seen that message once.

Actually, this would allow something like a "more station names" set, that does nothing but add more predefined station names, that could be quite nice.

For that to work, it would need to be a generic stations callback, though, i.e. not one called for the specific station type that's being built.

A definite selling point in a low number of towns scenario with many stations per town. Besides rail stations and waypoints, I often have several bus/lorry stations, remote airports, ports (docks) and now with Oskar's one way roads, on/off ramps for multilane highways, all in one town. Currently the only way around this is to rename stations which is fine. Your concept should ease this need significantly.

Another scenario: I build industrial parks containing several different industries serviced by one station. Retaining the ability to rename "Footown Steel Mill" to "Footown Industrial Park" would be a definite advantage for me.

I was hoping for both a station-specific and a generic callback, so that some strings could be applied only to certain stations, while other strings could be applied to any station.
The correct order to call the callbacks would probably be specific station, industry, generic station.

That is, ask the station if it has a specific name it wants, then ask the industry if nearby stations should have a specific name, then ask the generic handler for new station names.


Under no circumstances should the presence of these callbacks disable station renaming. Even if I wanted to be able to disable station renaming, I seriously doubt that any patchteam member would code it.

I'm not quite sure how the call-count variable would work for the generic handler, assuming that they're chained. For the specific handlers, 02 04/0A 00 81 10 00 FF 02 00 FF 00 00 01 FF 01 01 FF FF will work just fine (assuming that the low byte of 10 contains the call count and FF is the return value for "fail") but for the generic handler, either even more Patch magic is required to set the counter correctly for each handler[0], or GRF magic is required to deal with an essentially random initial value for var 10.

It might also be useful to know:
- TextID (or at least the low byte thereof) to be used if the callback fails, or FF if no available string, so standard functionality can be preserved when desired.
Example: The first airport in a town is gets the default "\80 Airport", and the second gets "\80 International Airport"
- Town zone that the station is in (as for house var 42), so, eg "\80 Suburbs", doesn't appear smack in the middle of downtown.
- Some of the town variables (Population, mainly, but all would probably be easiest, with type 82/86/8A var 2s.)

The stationpart information should also include the airport type, and probably bus station vs. bus stop.

Whether the industry callback should be called with the industry's variables or the station's variables (assuming any of them are valid) is not clear to me.

[0] Possibly simpler: just call one handler until it fails, then reset and continue to the next one?

OK, I looked into this in a bit more detail now.

At the moment, TTD does something like the following ("try" means check if not used yet, if so use it and skip the remaining checks):

if (specialtype)   // buoy, docks, heliport, airport, oil field
    try corresponding name;
if (has mines nearby)    // coal, iron ore, copper ore, gold or diamond mine
    try "<townname> Mines";
if (less than 8 tiles from town center)
    try "<townname>", then "<townname> central"
if (close to water tile but not map edge)
    try "Lakeside";
if (close to trees or forest industry)
    try "Woods" ("Forest" in arctic climate);
if (station altitude below town center)
    try "Valley"
if (station altitude above town center)
    try "Heights";
if (station to the north, south, east or west of town center)
    try "North", "South", "East" or "West", respectively
try all remaining generic station names ("Transfer", "Halt", "Exchange", etc.)

So, the industries don't really play too much of a role here, except for the specific ones (mines or forests). I suppose I could look for nearby industries anyway, and call the callback for each of them still, but I'm not sure if that's really useful. Btw, the station part being built is probably not useful, since the naming only happens for the very first part built anyway, no matter how the player later arranges the station.

For the station callback, I could look at all nearby industry tiles, and create a bitmask of all industries present, that might be more useful. I'm not sure if any of the other properties are useful for this, like "is close to water", "is north/south/east/west", "is above/below town center" etc.

For the chained handler, all handlers in the chain would be called once for the first name, then for the second name, etc. until one doesn't fail. There's no problem with the callback count that way.

What I'm not sure about is what kind of text ID we should use here. If the callback handlers are to return a D0xx ID, I must allocate a custom text in TTD, of which there may be 512 I think. This would be one custom text for each station so named, not per type of station name.

Alternatively, it could be a DCxx ID, of which the grf would define one per type of station name. That's probably the better solution, but if the .grf is unloaded, the station would show "Text not available". Personally, I'd prefer this one I think.

By "station part" I meant Airport/Heliport/RVbay/&c., so the generic callback could return "International Airport" only for large airports.


Personally, I don't use custom texts very often, but I unload GRF files even less often. DCxx seems like a reasonable ID-space to use, although it does make the saves slightly less portable.

*bump*



At the moment, all newindustries seem to be "Mines".

Perhaps a new property could be added for industries; string to use for station names?

No, for example the fishing grounds don't. Since the search goes by industry tiles though, not actual industries (which don't really exist in the map), if a new industry overrides any mine tiles, it'll be considered a mine by this algorithm.



Which of the two types I suggested would you prefer?

Ah, whoops, thanks, fixed! (in that order)

I guess then the new property would have to be for industry tiles, rather than industries?



Hmm... well the DCxx would seem to make most sense. Any game that was started with a newindustries grf which is no longer loaded is probably going to be unplayable anyway.

In about 5 minutes, industries can specify a string to be used for nearby stations instead of "<townname> Mines"/"<townname> Oilfield", or just that those strings not be used.

Getting the callbacks working will be much more interesting, though.


So far, I have this proposed spec, with almost zero clue on how to implement it.

Callback 14D
Called for Stations, Stations (generic)

During this callback, variable 10 is ??hhYYXX, and variable 18 is ????ppcc. The bytes are as follows:
YYXX: Signed ΔX and ΔY from the station to the center of the nearest town. If negative, the station is north of the town.
hh: Signed Δheight from the station to the center of the nearest town. If negative, the station is lower than the town.
pp: The station part being built. Low two bits 0..3 for feature. For features 0..2, bit 2 indicates:
0: WAYP vs anything else
1: trucks vs buses
2: dock vs bouy
For feature 3, remaining bits indicate airport type: 00..02 for small/large/heliport. Other values as Open sees fit; all bits set means "supplied by a newgrf".
cc: Call count. Each different call count should return a different result.

It might be possible to supply random bits somewhere, if necessary. Likely no station variables will be accessible; town variables may be accessible.

The return values are as follows:
00..FF Try the corresponding DCxx text for the station name.
100..120 Try the corresponding 300F..302F text for the station name.
121 For the station-specific callback, try the industry property/ies and then the generic callbacks.
121 For the generic callback, return to TTD's default station naming.
Here, as above, "try" means check if not used yet, if so use and skip remaining.

How would it look for unowned station at fishing ground for example?

The code or the result?
Since I modified the fishing grounds for my test anyway:

  -1 * 16    04 0A FF 01 80 DC 80 " Fishery" 00
<...>
  -1 * 88    00 0A 1A 01 1D 08 05 0B 02 0C 32 48 0D 35 48 0E 39 48 0F FF 10 04 0C 11 0C FF FF
           FF 12 00 13 00 14 05 15 04 34 39 44 48 16 FF FF FF 17 07 18 03 19 C0 1A 04 80 00 00 1B
           2D 48 1C 00 00 00 00 1D 00 00 00 00 1E 00 00 00 00 1F 75 DC 20 FF FF FF BF 21 BC 22 01
           24 80 DC

These are, like all property texts, DCxx or TTD texts, and not D0xx texts.

And what should happen if there are two industries nearby?

The exact same thing as if there are two oil rigs in the same town. Second one gets "North", "Valley", "Transfer", &c.. Whichever seems good to the TTD naming engine.