LuaPlayer.translate( LocalisedString ), LuaPlayer.locale

[aubergine18]

Reason: I need to sort a table by item names, to do that I need translated locale text.

The issue with getting localised text has always been that it is player specific. Hence, have a translate method on LuaPlayer; the player, and thus their locale, is known.

For performance, while the GUI is active, I can manually keep a cache of the translated text, in a simple dictionary table indexed by item name - so use of the player.translate() method will be minimised at the expense of some short-term memory consumption.

The cache longevity could be increased, and duplicate caches (of same locale) avoided, if there was also a LuaPlayer.locale (returns 2 char locale code, eg. "en"). Obviously, only where the locale objects don't have parameters, but I'll know that in advance.

Summary:

* LuaPlayer.translate( LocalisedString ) :: string
* LuaPlayer.locale :: string [R]

Alternative: The translate() method could accept a second param for locale, and be located elsewhere, for example:

script.translate( LocalisedString, locale ) :: string

[Rseding91]

You don't seem to understand how locale works with mods.

You can simply set your GUI text to the localized string and it shows that string runtime for the person looking at it translated for what ever language they're using:

Code: Select all

element.text = {"my-gui-key"}

Will translate using the key "my-gui-key" and show what ever that translates too.

If you want the locale for any item you just use:

Code: Select all

game.item_prototypes["item-name"].localised_name

[aubergine18]

Ok, so... I put the LocalisedString object in the element caption and the game shows the translated text on-screen to the user.

Now, in my table of such elements... The user sees all the text in their language on-screen. My mod only sees LocalisedString objects...

I want to sort the table alphabetically... But all I have are the LocalisedString objects. I don't know what text the user is actually seeing. So I can't sort alphabetically based on what user sees, only the raw locale keys from the LocalisedString objects.

That's why I need some way to get, in my mod code, the actual text that the user is seeing on those elements.

.localised_name returns a LocalisedString: http://lua-api.factorio.com/latest/LuaE ... lised_name

...not the actual translated text from the .cfg file

Unless I'm doing something wrong?

[Nexela]

Unless I'm doing something wrong?

You are correct.
I also had a situation where having access the translated text would have been nice but I worked around it. In my case I wanted to display the item-name if a locale key didn't exist.

Your best bet would be to just sort on the items .name

[aubergine18]

Your best bet would be to just sort on the items .name

But that's not sorting: from user perspective, it's more like 'grouping in to some mystical order'.

[Oxyd]

You can't get the translated text because that would be non-deterministic. Each user may be using different locale, so the translated result could be different for each player. The only way we could provide these functions would be by making multiplayer require that all players use the same locale – which is just undesirable.

This is the entire point of having a LocalisedString in the first place – you only ever see the key from your mod, and it renders as something different for each user. The actual rendered strings aren't a part of the game state, but the keys are.

[aubergine18]

Hrm, ok... Well, in that case, the only possible way to sort tables alphabetically is if the API provides table sorting: viewtopic.php?p=206039#p206039

Otherwise, at best, we can only provide mystical 'unfathomable group' sorting to our tables.

[Klonan]

Hrm, ok... Well, in that case, the only possible way to sort tables alphabetically is if the API provides table sorting: viewtopic.php?p=206039#p206039

Otherwise, at best, we can only provide mystical 'unfathomable group' sorting to our tables.

Even sorting the tables in different orders could cause desyncs, if for two users some list is sorted in a different way, and then you do almost anything to that list it would desync.

For now since most players play the game in English, just sort the items with their item.name, and don't worry about all the locale stuff

[Zeblote]

You can't get the translated text because that would be non-deterministic. Each user may be using different locale, so the translated result could be different for each player. The only way we could provide these functions would be by making multiplayer require that all players use the same locale – which is just undesirable.

Nonsense, all you need to know is 1) which locale the player is using and 2) what the localized texts in this locale are.

As every client has the entire mod, it also has the strings in every locale, so it should be able to load the chinese ones for sorting if another client has their game in chinese.





(I still don't get why you thought having the gui part of the game state is a good idea)

[Rseding91]

(I still don't get why you thought having the gui part of the game state is a good idea)

The base game ones aren't.

Modded ones are because we have to persist those between save and load. If they weren't part of the game state you couldn't read any data about them in mods and you would have to re-create them every time the game was loaded.

[aubergine18]

Feels

I'll list not being able to sort tables as a feature.

[Zeblote]

(I still don't get why you thought having the gui part of the game state is a good idea)

you would have to re-create them every time the game was loaded.

You also have to recreate the base game ones, right? I don't see any problem here, as long as an on_load callback is available.

[aubergine18]

You also have to recreate the base game ones, right? I don't see any problem here, as long as an on_load callback is available.

I'm in two minds about this. When I started trying to refactor EvoGUI, I was seriously considering recommending the GUI not persist the save/load cycle. But now I'm not so sure. There are pros and cons to it that I'm still pondering, though I'm currently leaning towards the GUI persistence being more of a good thing than a bad thing. My views on that might change substantially when it comes to dealing with changed config though...

[Zeblote]

You're right, if the gui isn't part of the game state then your open gui is lost when loading a save from someone else on the server. I guess it depends on the mod how severe that problem is.

Instead of blindly synchronizing everything, maybe there could be an api for creating variables that are saved in the game state? (Wait, don't we already have these?) Just have major gui actions such as changing pages send an event to all players to set a global var and in on_load create the proper page. It'll work in most cases, not all, but it's good enough.

[Mooncat]

I am not sure whether the original problem really related to the problem of GUI being saved in game state. And I think desyncs can be avoided with proper implementation: each player has an individual list according to his/her locale.
But then, there may be another problem about memory usage.
Also, we may need a way to detect change on player locale, or simply re-order the list on load (in this case, we don't even need to store the lists in global. Just store the list in local!)

You can't get the translated text because that would be non-deterministic. Each user may be using different locale, so the translated result could be different for each player.

I think it is what aubergine looking for.
Get the translated text according to the player's locale, so he can make a alphabetically sorted item list for that particular player.



Regarding the GUI being saved in game state, I am happy with the current approach of Factorio.
I have done some modding in Minecraft a few years ago. Their GUI code was separated into 2 parts, one for client UI and one for server UI.
The client UI is for graphical representation, like image paths and positions to draw the images.
The server UI is for data that is saved and shared across players, like inventory data, progress bar data. (I can't remember the details.)
You can say it is well optimized, as only necessary data are stored in game state.
But it is not easy to learn. It took me a few days to understand how it works and made a proper GUI.
In Factorio, it just took me a few minutes to learn. (Although creating GUI elements is another story, let's see how 0.15 will go. )
So, I would say, if it ain't broke, don't fix it.

[aubergine18]

Also, we may need a way to detect change on player locale, or simply re-order the list on load (in this case, we don't even need to store the lists in global. Just store the list in local!)

You can't get the translated text because that would be non-deterministic. Each user may be using different locale, so the translated result could be different for each player.

I think it is what aubergine looking for.
Get the translated text according to the player's locale, so he can make a alphabetically sorted item list for that particular player.

Mooncat is 100% correct.

BTW, good point about needing to know when player changes locale (it wouldn't result in desyncs if the mod didn't know, it would just confuse the player why their list sorting looks weird).

[mknejp]

As nice as persisting the GUI is, it can also lead to problems, especially if game state changes due to game/mod updates where your option is to either update your GUI or recreate it from scratch. I am definitely in the "recreate it on load" camp, because if you are starting with a clean slate on every load you know what you have or don't have and you know that certain things (like the locale) cannot change once the GUI is created. As to the topic of losing a mod's GUI state: just do it like any other software does it and store the minimal GUI configuration that you need to recreate the state. That includes window positions, hidden/visible, filter strings, selected options, anything that is not dictated by game state, and those configs can be part of the game state (even though they really are purely client-side settings). Or be lazy and don't

[Rseding91]

As nice as persisting the GUI is, it can also lead to problems, especially if game state changes due to game/mod updates where your option is to either update your GUI or recreate it from scratch. I am definitely in the "recreate it on load" camp, because if you are starting with a clean slate on every load you know what you have or don't have and you know that certain things (like the locale) cannot change once the GUI is created. As to the topic of losing a mod's GUI state: just do it like any other software does it and store the minimal GUI configuration that you need to recreate the state. That includes window positions, hidden/visible, filter strings, selected options, anything that is not dictated by game state, and those configs can be part of the game state (even though they really are purely client-side settings). Or be lazy and don't

That's how it works now... We store the minimal information needed to recreate the mod GUIs so we can:

1. Re-create the GUI on load
2. Allow adjusting the values on different peers (dedicated server) where the GUI element doesn't actually exist (the GUI only exists physically on the local instance).
3. Allow reading the values back to the game state when the GUI doesn't actually exist (same as #2)

[Zeblote]

Anyways, this topic was about accessing the localized text in mods.

Where exactly is the problem with determinism, assuming we have the following:

- player variable that has the locale he is using
- method to get localized text given a specific string and locale
- event that runs when a player changes locale

[aubergine18]

So, I just tried to implement a 'filter results' search text box. Guess what problem I instantly ran in to?