Getting Localised Names As a String

[coopmaster]

Basically what I am trying to do is filter items by their names based on what someone searches for, so something like

Code: Select all

string.match(localised_name,filter)

When I try to do that with game.get_localised_item_name I get the error that it is a table instead of a string. Is there any way around this? For now I'm just going to have it filter based on the items code-name (so like "iron-plate" instead of iron plate). There was a thread a while ago that people were discussing this, but it didn't go anywhere here. Any help would be great!

[L0771]

Hi, in my opinion, I suggest use {"type.name"} like {"item-name.iron-ore"}
And you can't compare, filter or something.
Maybe you have other way, show more code.

[coopmaster]

Maybe you have other way, show more code.

For instance something like this

Code: Select all

for _, item in pairs(game.item_prototypes) do
 if string.match(game.get_localised_item_name(item.name), "assembling machine") then
  game.player.print(game.get_localised_item_name(item.name))
 end
end

This code doesn't work. Basically, game.get_localised_item_name doesn't return a string, it returns a table. In that table (specifically in the 1 spot, hence localised_name[1]) iron-plate, for example, returns "item-name.iron-plate". I want to be able to get the string "iron plate" from it.

[Rseding91]

There's no way to get the localized string from a item name through script. The reason for that is simple: the localized name is potentially different for every peer playing a given game.

Take this example:

* 2 players
* Player 1 uses the "EN" language (English) - "iron-ore" translates to "Iron Ore"
* Player 2 uses the "FR" language (French) - "iron-ore" translates to "Minerai de fer"

When player 1 searched for "ore" it would bring up "iron-ore". However, on player 2's game it wouldn't since the translation for that is "Minerai de fer" and the 2 game states wouldn't match resulting in a desync.

[coopmaster]

There's no way to get the localized string from a item name through script. The reason for that is simple: the localized name is potentially different for every peer playing a given game.

Take this example:

* 2 players
* Player 1 uses the "EN" language (English) - "iron-ore" translates to "Iron Ore"
* Player 2 uses the "FR" language (French) - "iron-ore" translates to "Minerai de fer"

When player 1 searched for "ore" it would bring up "iron-ore". However, on player 2's game it wouldn't since the translation for that is "Minerai de fer" and the 2 game states wouldn't match resulting in a desync.

The reason I thought it might be possible is because you can do

Code: Select all

game.player.print(game.get_localised_item_name("iron-plate"))

but if you do

Code: Select all

game.player.print(game.get_localised_item_name("iron-plate")[1])

thats where you see what the code sees.

If the devs get the chance to see this, it would be great if there was some way to get the actual localised string like the gui and the print function do now.

[L0771]

Maybe you have other way, show more code.

For instance something like this

Code: Select all

for _, item in pairs(game.item_prototypes) do
 if string.match(game.get_localised_item_name(item.name), "assembling machine") then
  game.player.print(game.get_localised_item_name(item.name))
 end
end

This code doesn't work. Basically, game.get_localised_item_name doesn't return a string, it returns a table. In that table (specifically in the 1 spot, hence localised_name[1]) iron-plate, for example, returns "item-name.iron-plate". I want to be able to get the string "iron plate" from it.

Code: Select all

for _, item in pairs(game.item_prototypes) do 
	if item.place_result ~= nil and item.place_result.type == "assembling-machine" then 
		game.player.print({"entity-name." .. item.place_result.name}) 
	end 
end 

return the names of entities with assembling machine, but you make a condition to print only entities with assembling-machine.

[ratchetfreak]

I think the goal is to create a search bar that allows the user to search with their own locale. So the player doesn't have to know what iron plate is actually iron-plate

It can be solved by a player.locale property that could be passed to the get_localized_item_name. though mismatch of locale files could cause desyncs still

[coopmaster]

I think the goal is to create a search bar that allows the user to search with their own locale. So the player doesn't have to know what iron plate is actually iron-plate

It can be solved by a player.locale property that could be passed to the get_localized_item_name. though mismatch of locale files could cause desyncs still

I think that they can put a little trust in modders to not cause desync. I think that if they put the disclaimer that this function can cause desync if not used properly. I just really want a function like this :\

[ratchetfreak]

I think the goal is to create a search bar that allows the user to search with their own locale. So the player doesn't have to know what iron plate is actually iron-plate

It can be solved by a player.locale property that could be passed to the get_localized_item_name. though mismatch of locale files could cause desyncs still

I think that they can put a little trust in modders to not cause desync. I think that if they put the disclaimer that this function can cause desync if not used properly. I just really want a function like this :\

The solution to the potential desync would be to let the player send the result of the localization to the other clients so they all work with the same data but that would cause lag.

[L0771]

I'm pretty sure here have a item search, maybe can search for help

I'm sure, i've never could compare a localized name.

[coopmaster]

I'm pretty sure here have a item search, maybe can search for help

I'm sure, i've never could compare a localized name.

They do the same thing I'm doing right now with my mod which is just comparing the name that the code sees (so like "iron-plate") instead of the actual localised name. I want to get around that though since it only works with english, doesn't work with some mods since their item names don't always have similar names to their localised names, and doesn't work with multiple words (although I think I know a way around it).

[coopmaster]

I think the goal is to create a search bar that allows the user to search with their own locale. So the player doesn't have to know what iron plate is actually iron-plate

It can be solved by a player.locale property that could be passed to the get_localized_item_name. though mismatch of locale files could cause desyncs still

I think that they can put a little trust in modders to not cause desync. I think that if they put the disclaimer that this function can cause desync if not used properly. I just really want a function like this :\

The solution to the potential desync would be to let the player send the result of the localization to the other clients so they all work with the same data but that would cause lag.

except if its all client side, what I'm suggesting is where it only affects the gui. The way they already do guis is client side (as I already explained above). They already have a way to turn item names into localised names in the engine, I just want access to it.

[ratchetfreak]

except if its all client side, what I'm suggesting is where it only affects the gui. The way they already do guis is client side (as I already explained above). They already have a way to turn item names into localised names in the engine, I just want access to it.

but that access won't be single client

all mod code gets executed on all clients in parallel and must produce the same results on all clients.

[Outsider]

except if its all client side, what I'm suggesting is where it only affects the gui. The way they already do guis is client side (as I already explained above). They already have a way to turn item names into localised names in the engine, I just want access to it.

but that access won't be single client

all mod code gets executed on all clients in parallel and must produce the same results on all clients.

i am really struggling to wrap my head around this bit.. so any mod that has different gui/data for each client can cause desyncs? if not why is this different when it comes to localized names..

[ratchetfreak]

except if its all client side, what I'm suggesting is where it only affects the gui. The way they already do guis is client side (as I already explained above). They already have a way to turn item names into localised names in the engine, I just want access to it.

but that access won't be single client

all mod code gets executed on all clients in parallel and must produce the same results on all clients.

i am really struggling to wrap my head around this bit.. so any mod that has different gui/data for each client can cause desyncs? if not why is this different when it comes to localized names..

Because mod never actually touches the localized strings, that's done by the engine. It translate the strings passed by the mod before displaying it. All the mod sees is a string that the engine uses to search/replace.

The entire vanilla english localization file is ~18 kB so I'm not sure it's a good idea to send it to all connecting clients. Or factorio would need to require matching localization files as well and use a hash to verify.

[Outsider]

I'm aware that the engine only uses the actual translated text when rendering the gui, because i was desperate enough to load all the items localised names in labels in a hidden frame then tried looping through them and getting the caption values, obviously ended up with just references

I know i probably sound stupid at this point but i still don't understand what would be the issue of providing access to the localised strings using an extra index in the get localised names functions, or even a different function entirely?

Is it the fact that all data sent from the engine through the api has to be the same on all clients?

[ratchetfreak]

I'm aware that the engine only uses the actual translated text when rendering the gui, because i was desperate enough to load all the items localised names in labels in a hidden frame then tried looping through them and getting the caption values, obviously ended up with just references

I know i probably sound stupid at this point but i still don't understand what would be the issue of providing access to the localised strings using an extra index in the get localised names functions, or even a different function entirely?

Is it the fact that all data sent from the engine through the api has to be the same on all clients?

There's 2 issues really; one is that there is no way to tell factorio "this call only affects 1 client's gui it's okay to not run it on the other clients"

The other is that localization isn't held to the same "must be equal" standard as the other files (I think). Which means that to let the mod access localization then either the player shouldn't be allowed to connect if the localization he uses doesn't match the ones the other players have or that localization needs to be shared across players. (there's also a similar issue with replays).

[coopmaster]

I'm aware that the engine only uses the actual translated text when rendering the gui, because i was desperate enough to load all the items localised names in labels in a hidden frame then tried looping through them and getting the caption values, obviously ended up with just references

I know i probably sound stupid at this point but i still don't understand what would be the issue of providing access to the localised strings using an extra index in the get localised names functions, or even a different function entirely?

Is it the fact that all data sent from the engine through the api has to be the same on all clients?

There's 2 issues really; one is that there is no way to tell factorio "this call only affects 1 client's gui it's okay to not run it on the other clients"

The other is that localization isn't held to the same "must be equal" standard as the other files (I think). Which means that to let the mod access localization then either the player shouldn't be allowed to connect if the localization he uses doesn't match the ones the other players have or that localization needs to be shared across players. (there's also a similar issue with replays).

After working with multiplayer a bit, I still honestly don't completely understand how it works. If the host does most of the calculations for the clients (like if game.get_player(2).whatever is done by the host) then I can understand why this won't be a thing. If there are some calculations that are done by the client, then I think that it could work since if it is saved as a variable, it would work since it would be saved as a string.

[ratchetfreak]

I'm aware that the engine only uses the actual translated text when rendering the gui, because i was desperate enough to load all the items localised names in labels in a hidden frame then tried looping through them and getting the caption values, obviously ended up with just references

I know i probably sound stupid at this point but i still don't understand what would be the issue of providing access to the localised strings using an extra index in the get localised names functions, or even a different function entirely?

Is it the fact that all data sent from the engine through the api has to be the same on all clients?

There's 2 issues really; one is that there is no way to tell factorio "this call only affects 1 client's gui it's okay to not run it on the other clients"

The other is that localization isn't held to the same "must be equal" standard as the other files (I think). Which means that to let the mod access localization then either the player shouldn't be allowed to connect if the localization he uses doesn't match the ones the other players have or that localization needs to be shared across players. (there's also a similar issue with replays).

After working with multiplayer a bit, I still honestly don't completely understand how it works. If the host does most of the calculations for the clients (like if game.get_player(2).whatever is done by the host) then I can understand why this won't be a thing. If there are some calculations that are done by the client, then I think that it could work since if it is saved as a variable, it would work since it would be saved as a string.

All mod code is executed by all the clients and the host and each time it's executed it must have the exact same effect; otherwise desync.

[coopmaster]

I'm aware that the engine only uses the actual translated text when rendering the gui, because i was desperate enough to load all the items localised names in labels in a hidden frame then tried looping through them and getting the caption values, obviously ended up with just references

I know i probably sound stupid at this point but i still don't understand what would be the issue of providing access to the localised strings using an extra index in the get localised names functions, or even a different function entirely?

Is it the fact that all data sent from the engine through the api has to be the same on all clients?

There's 2 issues really; one is that there is no way to tell factorio "this call only affects 1 client's gui it's okay to not run it on the other clients"

The other is that localization isn't held to the same "must be equal" standard as the other files (I think). Which means that to let the mod access localization then either the player shouldn't be allowed to connect if the localization he uses doesn't match the ones the other players have or that localization needs to be shared across players. (there's also a similar issue with replays).

After working with multiplayer a bit, I still honestly don't completely understand how it works. If the host does most of the calculations for the clients (like if game.get_player(2).whatever is done by the host) then I can understand why this won't be a thing. If there are some calculations that are done by the client, then I think that it could work since if it is saved as a variable, it would work since it would be saved as a string.

All mod code is executed by all the clients and the host and each time it's executed it must have the exact same effect; otherwise desync.

After working with my mod (Galactic Trade) with multiplayer, I was able to get it to where each person could have a different search term that is saved. This is able to be done without desync even though each person has a different search term. I do this by having a table for anything that changes for each player. What I do is have something like this:

Code: Select all

global.gt_current_search_term[event.player_index]

All the clients are able to have their own search terms without causing desync. So lets say that we did have access to the localisation, then it wouldn't really change since the only thing that my mod would be changed by the localisation is the results it shows. What results it shows doesn't affect anyone else, therefore no desync. This is why I'm confused, I don't have to have all the same code run on all the clients from my testing. I don't really know what causes desync since I got desync when they were changing the variable when it wasn't a table. When one client tried to initialize the variable that caused desync and now when I make it a table it doesn't. My guess is that it sends what people type into the textbox to everyone. If that's the case, it can do the same thing for localised text. All it would have to do is send the text to other players to stay synced. I don't know how it works, but my mod somehow works like this and I think that if I am able to have every person have a different search term based on a text box only visible to the client. I think that whatever happens to make this possible, that it could work if they do it for localised strings. I would like to hear how it works though.