Station's name from nearby industry (new version: 1.2.1)

[Roujin]

Yes, I never managed to fix that in my patch either. Might be possible with a new string though. Dalestan pointed something in that direction out to me here, but I was too unknowledgable of the string system in OpenTTD to make anything out of it back then.

Using such a string will only introduce more problems, like what should happen if the industry closes down?

Introduce a routine on industry removal to iterate through stations and change the ones that use the industry's name? IIRC something similar is done for news items concerning an industry that is being removed.

Well, maybe it's a soft limit? Like "We don't want the user to be able to type in anything longer than xy (30?) letters, but names put together by OpenTTD itself and/or newGrfs can actually be up to yx (say 63) letters long without any harm"?
We should get an official word on this (devs) before assuming things

The limit is not about the amount of characters, but about the width (in pixels) of the string. Long labels (so also station names) can cause graphical glitches. I don't know what the exact limit is before glitches can occur, so maybe the current implementation is a bit too strict on the length.

Somewhere in my mind a voice tells me user typed strings had both a "number of characters" and a "pixel length of string" limit..
Anyway, it may well be that both of these limits were choosen low enough so that even with the longest user typable town name it's still possible to attach a station name of x characters (or pixel length y) without glitching, and the standard names exceeding the character (or pixel length) limit of custom strings are not a bug but intentional (since cutting the names off looks not nice).

[Yexo]

Yes, I never managed to fix that in my patch either. Might be possible with a new string though. Dalestan pointed something in that direction out to me here, but I was too unknowledgable of the string system in OpenTTD to make anything out of it back then.

Using such a string will only introduce more problems, like what should happen if the industry closes down?

Introduce a routine on industry removal to iterate through stations and change the ones that use the industry's name? IIRC something similar is done for news items concerning an industry that is being removed.

But then you'll have changes to station names without the user doing anything. (Why was my station renamed?). I'm not saying the current implementation is perfect, it's far from it. Resetting the name for example is not supported (again, I'm curious how TTDPatch handles this).

Well, maybe it's a soft limit? Like "We don't want the user to be able to type in anything longer than xy (30?) letters, but names put together by OpenTTD itself and/or newGrfs can actually be up to yx (say 63) letters long without any harm"?
We should get an official word on this (devs) before assuming things

The limit is not about the amount of characters, but about the width (in pixels) of the string. Long labels (so also station names) can cause graphical glitches. I don't know what the exact limit is before glitches can occur, so maybe the current implementation is a bit too strict on the length.

Somewhere in my mind a voice tells me user typed strings had both a "number of characters" and a "pixel length of string" limit..

Correct.

Anyway, it may well be that both of these limits were choosen low enough so that even with the longest user typable town name it's still possible to attach a station name of x characters (or pixel length y) without glitching, and the standard names exceeding the character (or pixel length) limit of custom strings are not a bug but intentional (since cutting the names off looks not nice).

[/quote]
That's possible, I have no idea.

[DaleStan]

Just for completeness' sake I've tested what I already found by reading your code and indeed the town included in the station's name is the industry's town, not the station's town. Still the question remains what to do here.

This should be the station's town, to keep with current behaviour.

it states that the industry I just queried originates from your NewGrf "station's name from nearby industries". This may be correct from some coding point of view since you probably sort of redefined them or so

This is correct. In order to attach a prop 24 to an industry, you must first replace the industry with a GRF-defined one.

1) Building an industry station in e.g. "Tonningville" -> e.g. "Tonningville Iron Ore Mine", then renaming the town to something else results in the station keeping its name "Tonningville Iron Ore Mine". This is opposed to how the standard station names work.

That one is impossible to fix with the current approach. how does TTDPatch behave in this case?

TTDPatch sets station.name to the a DCxx ID supplied by the GRF. A correct such DCxx text contains exactly one \80, which, in this context, is equivalent to the strgen entity {TOWN}.
IOW: The strings a.locritani has in his GRF are, in OpenTTD terms, "{TOWN} Sawmill", "{TOWN} Factory", "{TOWN} Food Processing Plant", and so forth. These are used as station names in exactly the same way the strings "{TOWN}", "{TOWN} Heights", "{TOWN} Central", &c. are used.

This requires one of two things that may or may not be true in OpenTTD:
1) DCxx texts are accessible even if you do not know what GRF supplied them -- the TextID alone must be sufficient to determine the address of the string. The TextID may associate the information "Read text <SomeID> from grf <GRFID>", or to the information "Read the string from <pointer>", but it MUST NOT -- as TTDPatch does (approximately) for D0xx IDs -- mean "Read text <SelfID> from whatever GRF you you most recently accessed."
-- OR --
2) The information necessary to locate the supplying GRF must be stored alongside the DCxx TextID. This is approximately "Read text <SelfID> from the GRF I just specified", directly preceded by the promised specification.

Peter1138 will likely know if either or both of these are already the case.

Regarding TTDPatch, I'm also curious about that. Could anyone with a copy to hand test this for us and post his results?

Since the \80 gets the town information from the station, it changes as the station's town changes, not as the industry's town changes.

In consider the behavior with default names a bug, instead of what my patch does. It's easy to change it so names are not cut off, but the maximum name length is there for a reason.

The maximum length applies to all custom texts, and only custom texts. Any strings generated programmatically may have any length.

Yes, I never managed to fix that in my patch either. Might be possible with a new string though. Dalestan pointed something in that direction out to me here, but I was too unknowledgable of the string system in OpenTTD to make anything out of it back then.

Using such a string will only introduce more problems, like what should happen if the industry closes down?

As a template for generating a static (no {...} values) custom text, that is just fine, but as an actual station name, that is quite broken. To properly use it as actual station name, a new text would have to be dynamically generated where {INDUSTRY} and {NUMBER} have been substituted, but {TOWN} remains as {TOWN}.

The limit is not about the amount of characters, but about the width (in pixels) of the string.

Not so. See above. The limit is about the number of characters the user may type. If you are modifying a string table that cannot accept user-supplied strings, the limit does not apply. It is also, in OpenTTD, only present for hysterical raisins.

Somewhere in my mind a voice tells me user typed strings had both a "number of characters" and a "pixel length of string" limit.

That is true for randomly generated town names. As far as I know, no other strings have a pixel-length limit.

[Yexo]

Thanks for your answers DaleStan. Apparently Rubidium already had a patch ready for this property that stores the industry type and modifies GetString to return the correct name. That way it'll correctly rename the station when the town is renamed and you'll be able to reset the town name. So although my patch won't make it, the feature will be in openttd soon.

Somewhere in my mind a voice tells me user typed strings had both a "number of characters" and a "pixel length of string" limit.

That is true for randomly generated town names. As far as I know, no other strings have a pixel-length limit.

That is not true for OpenTTD. Most of the strings that are typed by the users (station names, vehicle names, group names, etc.) have both a limit on the number of characters and a limit on the width in pixels.

[Railwaymodeler]

Perhaps as a way of getting around the naming problem, would be to have lengths that are somewhat predictible. For example, in some of the games I get more 'involved' with and micromanage, I will name a coal fired power plant 'Commonwealth Edison', which is a power company in northeast Illinois. Sawmills can be named something like 'Weyerhauser', a lumber company in the USA. Lots of names for factories. You might get the idea...

Such localization would add a bit of a dimension to TTDPatch/OpenTTD (When OpenTTD supports this patch). Of course, I imagine that these custom names would have to be in a GRF (At least for now). There could be industriy names from all over the world, and you could maybe mix/match them with parameters in the GRF?

Just a thought.

[DaleStan]

I like, but it needs a bit more thinking:
Would texts be associated with stations? industries? something else? Two or more of the above?
How would the texts be associated? Statically? Dynamically?
Given the absence of a town name, what happens to the second near-a-power-station station gets built?

[Railwaymodeler]

So far as the industry name, my thinking is that industries can have something, transparent to the game player, that would assign any station within a few tiles of it, say Commonwealth Edison 1, 2, and so on. So similar to town names, there would be 'industry names'.

This then begs another question, now that you mention it, DaleStan: Say a factory AND power plant are overlap the station naming radius, should this GRF then look for the Industrial Stations set, or something like that? So if you built a mineral unloader in that overlap, it gets the power plant's name, but if you built a goods station, it would be named for the factory. Considering that there are a lot of pre-designed stations in the Industrial Stations set, as of (I think is current) 0.7ish (Brain feel fried right now), these could even have something programmed into THEM.

So now, i am thinking, as best as I can right now, that this may be a good component of the Industrial Stations set. I'll try to explain better after I get some sleep.

[a.locritani]

Say a factory AND power plant are overlap the station naming radius, should this GRF then look for the Industrial Stations set, or something like that? So if you built a mineral unloader in that overlap, it gets the power plant's name, but if you built a goods station, it would be named for the factory.

if with "this grf" you are talking about my grf (and i think so) the answer is no. This grf doesn't know anything of Industrial Station set or something similar. It should names the station from nearest industry (I'm quite sure of this but i have no idea about how it works if two industries are at the same exact distance from the station).
I really don't know if your suggestion can be implemented, maybe it's possible, but I'm not so skilled, at the moment...

[michael blunck]

Say a factory AND power plant are overlap the station naming radius, should this GRF then look for the Industrial Stations set, or something like that? So if you built a mineral unloader in that overlap, it gets the power plant's name, but if you built a goods station, it would be named for the factory. Considering that there are a lot of pre-designed stations in the Industrial Stations set, as of (I think is current) 0.7ish (Brain feel fried right now), these could even have something programmed into THEM.

Let´s take a look into the specs:

Default name for nearby station (24)

If non-zero, this text ID specifies an additional name option for stations built near this industry, which will be used before any of the standard TTD names. The text should contain a \80, which will be the name of the nearby town.
If the newly built station cannot use the specified text (because that name has been used for another station in the same town) the default TTD naming system will be used, but without the names "\80 Oilfield" or "\80 Mines".
Setting this to zero disables "\80 Oilfield" and "\80 Mines" without adding any additional station name options.
http://wiki.ttdpatch.net/tiki-index.php ... station_24_

This simply means that an industry gets the additional ability to add a pre-defined text suffix which gets added to the usual town name of a station built in the near vicinity of that industry. So this is a feature of the industry, not a feature of the station, hence it´ll make sense being implemented into an industry set but not into a station set.

regards
Michael

[a.locritani]

yes in the industry set, of course.
The question is if a station can be named in different ways according to the type of station. I don't know if the added text can be related to the station type (farm station, mineral unloader, etc) or better, if you can define more than one property 24 according to your needs.

[michael blunck]

[...]
The question is if a station can be named in different ways according to the type of station. I don't know if the added text can be related to the station type (farm station, mineral unloader, etc) or better, if you can define more than one property 24 according to your needs.

Currently, there is nothing like "station type (farm station, mineral unloader, etc)" in the code. The only thing which could be used for something like this would be the station class ID and the local station ID, and a new property which would link a custom text to a certain ID.

However, apart from the fact that this would need to be implemented in the first place, I don´t think it would be helpful in general. There will be too many problems with automatic station renaming, IMO.

Just do it manually.

regards
Michael

[DaleStan]

I still like the idea of having some of Oz's stations automatically name themselves things like "\80 Grand Central".

On the other hand, "\80 Waypoint", "\80 Waypoint 2", "\80 Waypoint 3", and so on should probably be done in Patch code, and with Patch texts. If that's possible.

[michael blunck]

[...] On the other hand, "\80 Waypoint", "\80 Waypoint 2", "\80 Waypoint 3", and so on should probably be done in Patch code, and with Patch texts. If that's possible.

If "waypoint" == "signal tower", I´d have to disagree on such a simple naming convention.

In Germany, signal tower names aren´t usually counted up from something (they do as well, though ...), but mostly obey quite weird and funny "rules" (e.g., first letter is first letter of main station, second letter (don´t ask me about the third letter) could be anything with regards to service, e.g. "f" (station inspector), "g" (freight station), "r" (commissioning yard), "p" (passenger main station), ..., or geographical (TTD-style!), e.g. "n" (north), "w" (west), ..., or (in former East-Germany) something completely different.

regards
Michael

[DaleStan]

"Waypoint" == "Any station in class 'WAYP'"

[a.locritani]

Edited GRF, since property 24 is implemented starting with r14598

[a.locritani]

SarkoZ signaled me that my grf brakes industry placement constraint - WIP to fix it (now it's very late, for me )

question to expert grf coder: but, if I use property 08 to "copy" (note the quoting) an industry, are special flags (property 1A on action 0 for industries) retrieved? It seems to be that they aren't...

edit: i just realized that position constraint aren't entirely set by prop 1a...trying to understand how to fix it and why are these constraints cleared... any idea?
for ground type (above snowline/desert) i've no problem, i can use callback 28, but for distance from edge (for refinery/oil rigs) what should i use? i can set distance from water (CB 28) but not from edge...

[frosch]

I guess you mean these constrains:
Forest in arctic: Above (summer-)snowline.
Oil refinery: Near edge of map (distance configureable; does not apply in scenario editor)
Oilrig: At sea level and near edge of map (distance configureable; both do not apply in scenario editor)
Farm in arctic. Below (summer-)snowline.
Fruit/rubber plantation: Not in desert
Tropic farm/factory: Not in desert
Water supply/tower: Only in desert
Lumbermill: Only in rain forest
Bubble generator: Only for height <= 4

Note: These are the constrains of OTTD. TTDP's are most likely different.

And yes, they are not copied by property 08, as they could not be disabled by property 1A.
Most of them you can simulate using callbacks, except:
1) Summersnowline: IIRC you can only test for current snowline, but not for the heighest snowline when using variable snowline.
2) Distance from map: You cannot read the advanced setting of the distance, and you cannot check for distance from edge of map [0].

[0] Actually in TTDP you could, but that is not applicable to OTTD's bigger maps, so it is not implemented.

[michael blunck]

[...]
question to expert grf coder: but, if I use property 08 to "copy" (note the quoting) an industry, are special flags (property 1A on action 0 for industries) retrieved? It seems to be that they aren't...

It´s not explicitely mentioned by the Wiki [*]. Since frosch says it isn´t working for OTTD, this may indeed be implementation dependent.

The first assignment of this property copies all properties of the old type to this new type. [emph. mb]

regards
Michael

[frosch]

@michael:
Property 1A is copied. As the wiki says all properties are copied.
But there are no properties for the above restrictions

[michael blunck]

@michael:
Property 1A is copied. As the wiki says all properties are copied.
But there are no properties for the above restrictions

Sorry?

question to expert grf coder: but, if I use property 08 to "copy" (note the quoting) an industry, are special flags (property 1A on action 0 for industries) retrieved? It seems to be that they aren't...

The first assignment of this property copies all properties of the old type to this new type. [emph. mb]

regards
Michael