[wheybags]Image codes's length not correctly considered for train station names

[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/

[Oarc]

Ideally, this could work everywhere as well. Including things like server names.
But I understand if there are limitations in certain cases...

[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.

[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]

[wheybags]

We're not savages, we use std::string :p

[TheOnefinn]

We're not savages, we use std::string :p

ahh uncontrolled allocations and heap fragmention it is then!

(I joke, I joke! )

[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

[Beechsack]

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

Code: Select all

[img=item/iron-plate]

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 )

[TheOnefinn]

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)

Code: Select all

[img=item/iron-plate]

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

Code: Select all

[img=1234]

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.

[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.

[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!

[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)

[Iccor56]

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.

[SHiRKiT]

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.