Page 1 of 1
[wheybags]Image codes's length not correctly considered for train station names
Posted: Thu Mar 21, 2019 12:04 pm
by SHiRKiT
As pointed out by reddit user leixiaotie, Station names have a hard cap of 100 characters.
But Image Codes themselves are rendered as 2-3 characters wide, the way to write them is actually quite large, so complex station names can't be done
Image codes should be parsed as what their rendered version occupies, instead of what's the length of the string.
More info here:
https://www.reddit.com/r/factorio/comme ... r_smaller/
Re: Image codes's length not correctly considered for train station names
Posted: Thu Mar 21, 2019 12:44 pm
by Oarc
Ideally, this could work everywhere as well. Including things like server names.
But I understand if there are limitations in certain cases...
Re: [wheybags]Image codes's length not correctly considered for train station names
Posted: Thu Mar 21, 2019 1:21 pm
by wheybags
It's not really a bug, and the character count for each image tag is not likely to change, but we will probably bump the limit to account for this.
Re: [wheybags]Image codes's length not correctly considered for train station names
Posted: Thu Mar 21, 2019 2:05 pm
by TheOnefinn
It's not really a bug, and the character count for each image tag is not likely to change, but we will probably bump the limit to account for this.
Ideally the intuitive behaviour would be for the limit to apply to the rendered characters (ie icons) rather than the source "script" since any alternative is going to allow either ridiculously long text only names or far shorter icon names, but the realist in me says the code is probably doing char StationName[CHARACTER_LIMIT + 1]
Re: [wheybags]Image codes's length not correctly considered for train station names
Posted: Thu Mar 21, 2019 2:17 pm
by wheybags
We're not savages, we use std::string :p
Re: [wheybags]Image codes's length not correctly considered for train station names
Posted: Thu Mar 21, 2019 2:29 pm
by TheOnefinn
wheybags wrote: ↑Thu Mar 21, 2019 2:17 pm
We're not savages, we use std::string :p
ahh uncontrolled allocations and heap fragmention it is then!
(I joke, I joke!
)
Re: [wheybags]Image codes's length not correctly considered for train station names
Posted: Fri Mar 22, 2019 10:49 am
by Stringweasel
Ideally the intuitive behaviour would be for the limit to apply to the rendered characters (ie icons) rather than the source "script" since any alternative is going to allow either ridiculously long text only names or far shorter icon names, but the realist in me says the code is probably doing char StationName[CHARACTER_LIMIT + 1]
I think the reason they will only bump it up a little is due to the internal storage of the station names (which uses the item codes), and not because they want you to have short train station names
Re: [wheybags]Image codes's length not correctly considered for train station names
Posted: Fri Mar 22, 2019 12:23 pm
by Beechsack
TheOnefinn wrote: ↑Thu Mar 21, 2019 2:05 pm
It's not really a bug, and the character count for each image tag is not likely to change, but we will probably bump the limit to account for this.
Ideally the intuitive behaviour would be for the limit to apply to the rendered characters (ie icons) rather than the source "script" since any alternative is going to allow either ridiculously long text only names or far shorter icon names, but the realist in me says the code is probably doing char StationName[CHARACTER_LIMIT + 1]
It's not doing source "script".
They added rich text formatting in 0.17, so what is being displayed on screen is simply the RTF parse of the text field. Someone
could have named a station
in previous versions, it would have just displayed onscreen exactly that way, not like the iron plate image it does in 0.17.
I'm sure they chose 100 chars as the limit for the station name field for a reason. If they can bump it up a little without smoking performance, that would be prob be fine for most people. But an overhaul on how train names are stored prob fails the cost benefit test pretty quickly.
wheybags, what about an addition to the train station entity so that someone could set image icons on it like in a combinator? ( OR maybe that's mod territory, I dunno.. :p )
Re: [wheybags]Image codes's length not correctly considered for train station names
Posted: Mon Mar 25, 2019 12:08 pm
by TheOnefinn
Beechsack wrote: ↑Fri Mar 22, 2019 12:23 pm
It's not doing source "script".
Its a markup
language, referring to the markup source as script is correct usage of the word, its not a full programming language but it still uses text based (ie script) markup to convey additional information (I want an icon printed, not the text itself)
Treating the length of that string as 21 characters is unintuitive to the end user, the actual "thing being rendered" is visually not 21 characters long, its 2-3 characters long, the actual size of the source is irrelevant to the length of the string drawn on screen, it could have been something like
if they had decided to use an ID based markup. The point is that to the end user the actual contents/length of this string is irrelevant, its just some "magic letters" (ie script) they type in (or copy and paste) to get the iron plate icon to appear, the only width that is meaningful to the end user (and is not purely an implementation convenience for the code) is the actual visual width of the screen as its drawn.
Imagine if they made the "text edit box" RTF aware, instead of typing in the markup you simply clicked a button and chose the icon from a menu which was rendered in the box. In such a case the end-user wouldn't even be aware of how the actual markup "string" worked and how long internally each "icon" happened to be. It would be completely unintuitive to them to find out there was an internal limit which meant that icons were far "wider" than they appeared to be and in fact were varying in length based on how long the item name happened to be in code!
Why can I make a station with more "coal" icons than I can "personal-laser-defense-equipment" icons? Its not intuitive to the end user.
Re: [wheybags]Image codes's length not correctly considered for train station names
Posted: Mon Mar 25, 2019 4:07 pm
by coderpatsy
To be fair, a lot of apps like forums count each character in the pre-render markup. This is at least partly because in many of those setups markups can be stacked even though they don't have any visual effect (like 500 underline tags on the same text, for an extreme example) and you still have to store all that data.
Re: [wheybags]Image codes's length not correctly considered for train station names
Posted: Tue Apr 30, 2019 9:36 am
by wheybags
Ok, this is fixed for the next release by bumping the limit up to 1024 bytes. The gui has also been adjusted to account for longer names by truncating where appropriate.
Thanks for the report!
Re: [wheybags]Image codes's length not correctly considered for train station names
Posted: Thu May 02, 2019 8:33 pm
by kleopi
Imagine if they made the "text edit box" RTF aware, instead of typing in the markup you simply clicked a button and chose the icon from a menu which was rendered in the box. In such a case the end-user wouldn't even be aware of how the actual markup "string" worked and how long internally each "icon" happened to be. It would be completely unintuitive to them to find out there was an internal limit which meant that icons were far "wider" than they appeared to be and in fact were varying in length based on how long the item name happened to be in code!
I second this, typing or copynpasting that is a bit weird, should use a simple picker GUI maybe activated by a letter (like many text chats use ":" to trigger emoji selection)
Re: [wheybags]Image codes's length not correctly considered for train station names
Posted: Fri May 03, 2019 11:49 pm
by Iccor56
SHiRKiT wrote: ↑Thu Mar 21, 2019 12:04 pm
Image codes should be parsed as what their rendered version occupies, instead of what's the length of the string.
that is not how codes and strings work.
Re: [wheybags]Image codes's length not correctly considered for train station names
Posted: Wed Nov 27, 2019 9:21 pm
by SHiRKiT
Iccor56 wrote: ↑Fri May 03, 2019 11:49 pm
SHiRKiT wrote: ↑Thu Mar 21, 2019 12:04 pm
Image codes should be parsed as what their rendered version occupies, instead of what's the length of the string.
that is not how codes and strings work.
I know, I wrote this quick just to illustrate the problem and a possible solution. How the team implements it's up to them.I'm just glad it works.