When both my Inserters mod and Logistics mod are installed, I want to draw part of the Inserters mod GUI inside the Logistics mod GUI when you open it.
The ideal solution would be if there was a "Gui_Opened" event. That way, every time you open the logistics GUI, the inserters mod can add to it.
Other than copying large portions of code from my inserters mod into my logistics mod, with an "if this mod exists" check in there somewhere, is there an easier way to do it?
GUI scripting stuff from 2 mods.
- bobingabout
- Smart Inserter
- Posts: 7352
- Joined: Fri May 09, 2014 1:01 pm
- Contact:
Re: GUI scripting stuff from 2 mods.
doing a simple on gui click event should work
logistics
creates button ->
inserters
on_gui_click - > my_button_name_from_logistics.
destroy() uneeded logistic gui parts, add() inserter parts
logistics
creates button ->
inserters
on_gui_click - > my_button_name_from_logistics.
destroy() uneeded logistic gui parts, add() inserter parts
- aubergine18
- Smart Inserter
- Posts: 1264
- Joined: Fri Jul 22, 2016 8:51 pm
- Contact:
Re: GUI scripting stuff from 2 mods.
You can create your own events...
In mod 1:
Then in mod 2, which should be marked dependent on mod 1:
In mod 1:
Code: Select all
local gui_event = script.generate_event_name()
remote.add_interface( "mod1_name", {
get_event_id = function()
return gui_event
end
} )
-- when you open your mod 1 gui, trigger the event
function opens_gui()
-- ... gui code ...
game.raise_event( gui_event, { element = some_gui_element } )
end
Code: Select all
local gui_event = remote.call( "mod1_name", "get_event_id" )
script.on_event( gui_event, function( event )
local element = event.element
-- then add stuff to the gui element...
end )
Better forum search for modders: Enclose your search term in quotes, eg. "font_color" or "custom-input" - it prevents the forum search from splitting on hypens and underscores, resulting in much more accurate results.
- bobingabout
- Smart Inserter
- Posts: 7352
- Joined: Fri May 09, 2014 1:01 pm
- Contact:
Re: GUI scripting stuff from 2 mods.
Yeah, I did think about that. Both of them looking for the same on_gui_click event. The issue is, which is run first?
The first one, Logistics, will create the GUI from the ground up when it opens, and outright delete it when you click it again to close it.
The Inserters mod purely wants to add stuff to the end of the GUI. and possibly even edit one of the variables in the Inserters global.
This means that one of three things could happen:
1. The Logistics script runs first, the GUI is drawn, then the inserters mod scripts add to it. outcome as intended.
2. The Inserters script runs first, the GUI that already exists from last time is edited, then the Logistics mod deletes it.
3. Given some multithreading scenario, they're both run at around the same time, and unpredictable events happen, such as the GUI being drawn in strange orders.
Given the fact that you can't guarantee that the logistics mod will always run it's script first in every possible situation, you can't guarantee what the GUI will look like when it opens.
So although this is an option, is there a better solution?
EDIT:
The creating your own events thing does look like a better solution.
I don't actually want them dependant on each other, but I can possibly do a mod version check on mod 2 to see if mod 1 exists before trying to use the remote.call from it.
Or perhaps a better solution would be to make the GUI drawing parts of the inserters mods available in a remote call, then if they exist the inserters mod can just call it to draw them directly.
The first one, Logistics, will create the GUI from the ground up when it opens, and outright delete it when you click it again to close it.
The Inserters mod purely wants to add stuff to the end of the GUI. and possibly even edit one of the variables in the Inserters global.
This means that one of three things could happen:
1. The Logistics script runs first, the GUI is drawn, then the inserters mod scripts add to it. outcome as intended.
2. The Inserters script runs first, the GUI that already exists from last time is edited, then the Logistics mod deletes it.
3. Given some multithreading scenario, they're both run at around the same time, and unpredictable events happen, such as the GUI being drawn in strange orders.
Given the fact that you can't guarantee that the logistics mod will always run it's script first in every possible situation, you can't guarantee what the GUI will look like when it opens.
So although this is an option, is there a better solution?
EDIT:
The creating your own events thing does look like a better solution.
I don't actually want them dependant on each other, but I can possibly do a mod version check on mod 2 to see if mod 1 exists before trying to use the remote.call from it.
Or perhaps a better solution would be to make the GUI drawing parts of the inserters mods available in a remote call, then if they exist the inserters mod can just call it to draw them directly.
- aubergine18
- Smart Inserter
- Posts: 1264
- Joined: Fri Jul 22, 2016 8:51 pm
- Contact:
Re: GUI scripting stuff from 2 mods.
IIRC, mod dependencies would solve that issue - Mod 2 depends on Mod 1, so Mod 1 is loaded first, registers its events first, so they get called first, before Mod 2's events.
Also, this discussion seems relevant, particularly with respect to mod naming potentially having an effect on load order: viewtopic.php?f=34&t=34427
Also, this discussion seems relevant, particularly with respect to mod naming potentially having an effect on load order: viewtopic.php?f=34&t=34427
Better forum search for modders: Enclose your search term in quotes, eg. "font_color" or "custom-input" - it prevents the forum search from splitting on hypens and underscores, resulting in much more accurate results.
Re: GUI scripting stuff from 2 mods.
bobingabout wrote: I don't actually want them dependant on each other, but I can possibly do a mod version check on mod 2 to see if mod 1 exists before trying to use the remote.call from it.
Or perhaps a better solution would be to make the GUI drawing parts of the inserters mods available in a remote call, then if they exist the inserters mod can just call it to draw them directly.
I do like the sounds of option B
- bobingabout
- Smart Inserter
- Posts: 7352
- Joined: Fri May 09, 2014 1:01 pm
- Contact:
Re: GUI scripting stuff from 2 mods.
in the topic you linked.aubergine18 wrote:IIRC, mod dependencies would solve that issue - Mod 2 depends on Mod 1, so Mod 1 is loaded first, registers its events first, so they get called first, before Mod 2's events.
Also, this discussion seems relevant, particularly with respect to mod naming potentially having an effect on load order: viewtopic.php?f=34&t=34427
So, dependencies do nothing.Rseding91 wrote:Events are fired in order by mod name.
When I look into programming this, I'll go for the remote call options. Have the Logistics mod check if a remote call to functions in the Inserters mod exists, and if they do, use them to draw part of the inserters GUI in the Logistics GUI.
Though, I'll probably have to re-write most of the functionality of the inserters mod in the logistics mod, because although I want to use the same GUI drawing routines, the inserts mod doesn't account for what I want to do in the Logistics mod anyway.
(The inserters GUI updates the inserter as you press a button. The Logistics GUI needs to store which buttons have been pressed even after the GUI has been deleted, and then every time you place an inserter, change the positions. Inserters also only does the exact position you clicked, the logistics mod needs to take rotation into account too.)
Re: GUI scripting stuff from 2 mods.
Looking into it, there's no reason to not fire events by mod dependency order so I'll change it to do that for 0.15.
For 0.15 it will be:
1. Level (scenario script)
2. All other mods listening sorted by dependency order (same order they're loaded in)
For 0.15 it will be:
1. Level (scenario script)
2. All other mods listening sorted by dependency order (same order they're loaded in)
If you want to get ahold of me I'm almost always on Discord.