Roujin wrote: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.
Roujin wrote: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.
Yexo wrote: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.
Roujin wrote: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.
Yexo wrote:Roujin wrote: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}.
Yexo wrote: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.
Roujin wrote: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.