Possible to Create TrainStop-type Name Input for Linked-Containers?

[Job]

I recently got my Linked-Chest mod working locally, in part thanks to people answering questions and reading through many old forum posts.

One thing I could not figure out was whether it was possible to add a naming input field similar to those that TrainStops have? To skip ahead, instead of using the checkbox GUI to link containers, players could give names, and the matching names would "link" the containers.

This requires some input field on linked-containers, ideally like TrainStops, but from my reading, I don't think this is acheivable for that prototype. From some older posts, perhaps Frankensteining two prototypes can work? Or perhaps I do not fully understand what is possible with text inputs on GUIs added by mods.

If this ends up not being possible, my mod addresses this in part by creating a whole bunch of color coded linked-chests, but that is not as good as I think I could make it if the above is possible.

To be clear, I'm not requesting someone do this for me; just asking for directions, or confirmation that I am at a dead end.

Thanks in advance for any insights.

[DaveMcW]

Here is a sample of what can be done with a gui. Paste it into the console.

Code: Select all

/c 
function create_gui(player)
  if player.gui.relative.my_frame then 
    player.gui.relative.my_frame.destroy()
  end
  player.gui.relative.add{
    type = "frame",
    name = "my_frame",
    direction = "horizontal",
    anchor = {
      gui = defines.relative_gui_type.linked_container_gui,
      position = defines.relative_gui_position.top,
    }
  }
  player.gui.relative.my_frame.style.width = 1089
  player.gui.relative.my_frame.style.horizontal_align = "center"
  player.gui.relative.my_frame.add{
    type = "textfield",
    name = "my_textfield",
    tooltip = "Link Name",
    text = "",
  }
end

function on_gui_text_changed(event)
  if event.element.name == "my_textfield" then
    local player = game.get_player(event.player_index)
    local entity = player.opened
    entity.surface.create_entity{
      name = "flying-text",
      text = event.text,
      position = entity.position,
    }
  end
end

create_gui(game.player)
script.on_event(defines.events.on_gui_text_changed, on_gui_text_changed)

In a real mod you would call create_gui() from script.on_init and on_player_created.

Some references:
https://lua-api.factorio.com/latest/LuaGuiElement.html
https://lua-api.factorio.com/latest/Con ... #GuiAnchor
https://lua-api.factorio.com/latest/eve ... gui_opened
https://lua-api.factorio.com/latest/eve ... xt_changed

[PFQNiet]

As for "using that name to set the link ID", you could make use of a hashing function. For example, CRC32 would give you a 32-bit number for any given string. The downside is that collisions may occur if two different names happen to yield the same hash.

[Job]

Here is a sample of what can be done with a gui. Paste it into the console.

Thank you @DaveMcW! This has definitely given me some great direction.

I tested your code via the console, and it provided a plain text input field on linked-containers. If you don't mind, I was curious how it worked with linked containers but not anything else that I tested (e.g. other chests); that is the desired outcome, I'm just not understanding what part of the code caused that.

I will try implementing something similar in a script.

Thank you again!

[Job]

As for "using that name to set the link ID", you could make use of a hashing function. For example, CRC32 would give you a 32-bit number for any given string. The downside is that collisions may occur if two different names happen to yield the same hash.

Interesting idea. I was thinking of something along those lines, but had not come up with a specifc (and smart) idea. I will definitely take a look, thank you!

[mrvn]

Here is a sample of what can be done with a gui. Paste it into the console.

Thank you @DaveMcW! This has definitely given me some great direction.

I tested your code via the console, and it provided a plain text input field on linked-containers. If you don't mind, I was curious how it worked with linked containers but not anything else that I tested (e.g. other chests); that is the desired outcome, I'm just not understanding what part of the code caused that.

I will try implementing something similar in a script.

Thank you again!

It's this line:

gui = defines.relative_gui_type.linked_container_gui,

That tells the game that new element is only for the linked container.

Note: The name will appear for all linked containers. It's not specific to a prototype but to the base of the prototype. So another mod has their own modded linked chests then suddenly they have a plain text input field too.

[mrvn]

As for "using that name to set the link ID", you could make use of a hashing function. For example, CRC32 would give you a 32-bit number for any given string. The downside is that collisions may occur if two different names happen to yield the same hash.

Interesting idea. I was thinking of something along those lines, but had not come up with a specifc (and smart) idea. I will definitely take a look, thank you!

Using a hash can be fun and means you don't have to keep track of used IDs. But there is a risk of collision, which can be fun. In ocaml you have variant types, which are kind of a enum. Internaly the name you give for each variant is hashed and that value is used. This leads to:

# type collision = [`Eric_Cooper | `azdwbie];;
Error: Variant tags `azdwbie and `Eric_Cooper have the same hash value.
Change one of them.

A linked chest name "Eric_Cooper" would connect to a linked chest named "azdwbie". You can have fun with that.

You could just maintain a table that maps between names and link IDs. Little effort and no collisions.

[DaveMcW]

Note: The name will appear for all linked containers. It's not specific to a prototype but to the base of the prototype. So another mod has their own modded linked chests then suddenly they have a plain text input field too.

That can be fixed with the anchor property.
https://lua-api.factorio.com/latest/Con ... #GuiAnchor

[Job]

It's this line:

gui = defines.relative_gui_type.linked_container_gui,

That tells the game that new element is only for the linked container.

Note: The name will appear for all linked containers. It's not specific to a prototype but to the base of the prototype. So another mod has their own modded linked chests then suddenly they have a plain text input field too.

Thank you mrvn; not the first time you have shared some valuable insights. A bit sad that I overlooked that line, so extra thanks for clarifying.

[Job]

Using a hash can be fun and means you don't have to keep track of used IDs. But there is a risk of collision, which can be fun. In ocaml you have variant types, which are kind of a enum. Internaly the name you give for each variant is hashed and that value is used. This leads to:

# type collision = [`Eric_Cooper | `azdwbie];;
Error: Variant tags `azdwbie and `Eric_Cooper have the same hash value.
Change one of them.

A linked chest name "Eric_Cooper" would connect to a linked chest named "azdwbie". You can have fun with that.

You could just maintain a table that maps between names and link IDs. Little effort and no collisions.

I will look into this too; thank you!

[Job]

That can be fixed with the anchor property.
https://lua-api.factorio.com/latest/Con ... #GuiAnchor

Great, thank you!