Somethings not (or hidden) in doc but you need to know

[eradicator]

here I can protect moda against by clicking on modb cancel button, but I can't protect modb to be triggered wjen clicking on moda cancel button

Preventing existing bugs in other mods from being discovered is not part of my coding strategy. Let it explode in their face so they can fix it is (and yes, that means if you find a bug in my mods please make it explode so i can fix it).

For gui management i have since moved to a very different paradigm, which is using the LuaGuiElement.index (or alternatively a direct reference to the element) to handle everything. This way the actual name of the gui element is no longer needed for anything. As this requires storing data about each active gui button it's not a method suited for beginning modders, or very large guis, but is quite flexible as you can directly pass arguments to the target function on gui creation.

Code: Select all

--warning: untested pseudocode

local element_handlers = {}

function element_handlers .button_handler(event,argumment1,argument2)
  --dostuff
  end

local function setup_gui() --whereever you create your gui
  global.my_elements =  {} --overwriting all the old data because it is no longer relevant
  local new_button = player.gui.center.add{type="button"}  
  global.my_elements[new_button.index] = {'button_handler',{'argument1','argument2'}}
  end
  
script.on_event(defines.events.on_gui_click,function(event)
  local this = global.my_elements[event.element.index]
  if this then
    element_handlers[this[1]](event,unpack(this[2]))
    end
  end)

[Klonan]

here I can protect moda against by clicking on modb cancel button, but I can't protect modb to be triggered wjen clicking on moda cancel button

Preventing existing bugs in other mods from being discovered is not part of my coding strategy. Let it explode in their face so they can fix it is (and yes, that means if you find a bug in my mods please make it explode so i can fix it).

For gui management i have since moved to a very different paradigm, which is using the LuaGuiElement.index (or alternatively a direct reference to the element) to handle everything. This way the actual name of the gui element is no longer needed for anything. As this requires storing data about each active gui button it's not a method suited for beginning modders, or very large guis, but is quite flexible as you can directly pass arguments to the target function on gui creation.

Code: Select all

--warning: untested pseudocode

local element_handlers = {}

function element_handlers .button_handler(event,argumment1,argument2)
  --dostuff
  end

local function setup_gui() --whereever you create your gui
  global.my_elements =  {} --overwriting all the old data because it is no longer relevant
  local new_button = player.gui.center.add{type="button"}  
  global.my_elements[new_button.index] = {'button_handler',{'argument1','argument2'}}
  end
  
script.on_event(defines.events.on_gui_click,function(event)
  local this = global.my_elements[event.element.index]
  if this then
    element_handlers[this[1]](event,unpack(this[2]))
    end
  end)

I also use a method similar to this for handling GUI events, such as in the Wave defense and PvP base game scenarios.

[jamiechi1]

In the first section of this document, https://lua-api.factorio.com/latest/Data-Lifecycle.html, last sentence.
There is a reference to "mod-settings.json" file. It should be "mod-settings.dat".
Should this be reported as a bug somewhere?

[Bilka]

In the first section of this document, https://lua-api.factorio.com/latest/Data-Lifecycle.html, last sentence.
There is a reference to "mod-settings.json" file. It should be "mod-settings.dat".
Should this be reported as a bug somewhere?

Fixed for the next version. Note that this thread is rather outdated, while most tips aren't wrong, a lot of them are now in the docs.