Factorio Forums

L0771 wrote: Maybe you have other way, show more code.

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

Rseding91 wrote: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.

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

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

coopmaster wrote:

L0771 wrote: 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.

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 

ratchetfreak wrote: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 wrote:

ratchetfreak wrote: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 :\

L0771 wrote: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.

ratchetfreak wrote:

coopmaster wrote:

ratchetfreak wrote: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.

coopmaster wrote:
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 wrote:

coopmaster wrote:
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 wrote:

ratchetfreak wrote:

coopmaster wrote:
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..

Outsider wrote: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 wrote:

Outsider wrote: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 wrote:

ratchetfreak wrote:

Outsider wrote: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 wrote:

coopmaster wrote:

ratchetfreak wrote:

Outsider wrote: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.

global.gt_current_search_term[event.player_index]