Hi! I've been made aware of your mod by a bug report. It seems there are compatibility issues with some of my mods.

miniMAXIme allows players to switch characters on the fly. They can also select a character to leave god mode or editor mode, and admins may (depending on a global setting) also use their GUI to enter god mode or editor mode. I raise a custom event whenever a player switches characters or changes between character, god, and editor mode. You could get the event ID using

if remote.interfaces.minime and remote.interfaces.minime.get_minime_event_ids then 
    local id = remote.call("minime", "minime_exchanged_characters")["minime_exchanged_characters"]
    script.on_event(id, your_function)
end

I'll raise the event with the following arguments:

script.raise_event(event_id, {
  player_index = player.index,  -- uint
  old_character = old_char,     -- LuaEntity or nil
  new_character = new_char,     -- LuaEntity or nil
  old_unit_number = old_id,     -- uint or nil
  new_unit_number = new_id,     -- uint or nil
  god_mode = data.god_mode,     -- true or nil
  editor_mode = data.editor_mode    -- true or nil
})

For compatibility with Jetpack and Bob's classes, I've already a remote function in place that you could call whenever a player has entered or left sandbox mode:

if remote.interfaces.minime and remote.interfaces.minime.on_character_swapped then 
    remote.call("minime", "on_character_swapped", arguments)            
end

These are the arguments my remote function expects:

-- Event data used by Jetpack:
-- {new_unit_number = uint, old_unit_number = uint,
--  new_character = luaEntity, old_character = luaEntity}
--
-- Additional (optional) event data used by Bob's classes:
-- player_index = uint,
-- editor_mode = boolean, god_mode = boolean

Would you mind cooperating on making our mods work together?

(EDIT: Removed second part because I realized that my request wasn't really necessary.)

Hello! It's possible to work together, but I want us both to understand a bit more before doing anything. You may not already know, so I'll explain a bit about this mod's principles.

• Entering a Sandbox must always swap to the God Controller
• Exiting a Sandbox should always try to return to whatever "state" the player was originally in (quite complicated, exceptions apply)
• The Sandbox's inventory must appear real and persistent
• Potentially implied by the first bullet: while in a Sandbox, the player should always feel at least like that God Controller does

That second bullet is the hardest part of all of this. There are situations where we basically cannot return to that original state, and in that case our last-resort is to prevent entering the Sandbox if we cannot gracefully return out of it. For example, a player on a normal character who has already changed to another controller type for some other reason - we may only know this state to revert back to, but that may lose the original/home state and "disembody" the player.

I think the implications of the above are:

• Don't allow character switching within Sandboxes
• Do allow God/Editor Controller swapping within the Sandboxes

I can think of further points than that, but I want to pause and see what you think an integration means.

Hello! It's possible to work together, but I want us both to understand a bit more before doing anything.

Thanks for the reply! Glad you're looking into this.

You may not already know, so I'll explain a bit about this mod's principles.

• Entering a Sandbox must always swap to the God Controller

Entering a sandbox happens on your end. I just need to know that you will switch to the god controller BEFORE you actually do that, so that I can update my data and the player's GUI.

• Exiting a Sandbox should always try to return to whatever "state" the player was originally in (quite complicated, exceptions apply)

My mod only deals with character, editor, and god controller. Before leaving character mode for editor or god mode, I back up the player's character, so I can reattach it when the player returns to character mode. This should work even if the player decides to return to character mode by selecting a different character (first step is reattaching the old character, second step is replacing it with the new one).

• The Sandbox's inventory must appear real and persistent

Your job! I only care about the inventories of characters; these are distinct from the editor/god mode inventories.

• Potentially implied by the first bullet: while in a Sandbox, the player should always feel at least like that God Controller does

Sorry, I really don't understand what you mean here.

That second bullet is the hardest part of all of this. There are situations where we basically cannot return to that original state, and in that case our last-resort is to prevent entering the Sandbox if we cannot gracefully return out of it. For example, a player on a normal character who has already changed to another controller type for some other reason - we may only know this state to revert back to, but that may lose the original/home state and "disembody" the player.

Did you try out miniMAXIme yet? If not, download it together with a couple of character mods (see the optional dependencies). Make sure you have a character, don an armor and put some stuff into your inventory. Switch to god mode, then to editor mode, then back to a character. Check your inventory -- it should have the same contents as it had before you turned on god mode, even if you have switched to a different character.

By the way: My mod supports the Lua API global Variable Viewer (gvv), so if you're using that, you can follow what's going on in my global table. It also has a startup setting for activating detailed logging (off by default), showing what functions get called with what arguments etc.

I think the implications of the above are:

• Don't allow character switching within Sandboxes
• Do allow God/Editor Controller swapping within the Sandboxes

My GUI will always show the character buttons, only the buttons for god/editor mode are optional (locked behind a map-setting, and only usable by admins, which includes the player in single-player mode). Hiding the character buttons while keeping those for god/editor mode seems like more trouble than it's worth, given the alternatives:

• Space Exploration has a kind of remote view (called "Satellite Navigation Something-or-other") which actually is god mode. If a player has this mode enabled and uses my GUI to switch to character mode, I call a remote function of SE to stop its remote view. If you had such a function, I could request a stop of sandbox mode as well.
• Alternatively, I could hide the GUI of players who have entered sandbox mode until they leave it again. This requires that you announce the mode change -- either by raising a custom event, or by calling a remote function provided by my mod.

I can think of further points than that,

Sure, go on! :-)

but I want to pause and see what you think an integration means.

Basically, my mod can only work correctly if a player's controller type is in sync with what the mod thinks this player's controller type is. That's no problem where editor mode is concerned (we can listen to defines.events.on_player_toggled_map_editor and defines.events.on_pre_player_toggled_map_editor), but there are no vanilla events for god/character mode or for when a player's character is exchanged.

Suppose a player had a character and used my GUI to change to god mode, then some other mod was stopping god mode by creating a new character and assigning it to the player. If the other mod doesn't announce the mode switch, I can't remove the player's old character, and the surface will eventually be spammed with unused characters.

If there's anything that you need done on my end, just say so and I'll try to provide it. :-)

It seems like most of what I tried to communicate was not received as intended, and I'm not sure if I should clarify all of it again, or frame it in a different context and hope it clicks on a re-read. There was one hit among all of that, and I'll point it out next. Before that, you seemed to think that I was telling you what to do, or that some of the responsibilities that I described this mod as already having would be something that your mod would somehow take over or do - that's clearly not a good idea and I don't think that I worded my reply in a way that would entirely reverse its meaning. I don't want to hit all of those points again, and I hope that maybe after more communication that you could re-read it and understand what I originally meant (if it matters).

Alternatively, I could hide the GUI of players who have entered sandbox mode until they leave it again. This requires that you announce the mode change -- either by raising a custom event, or by calling a remote function provided by my mod.

This is almost exactly the solution that I pitched. It seems that a broadcast from this mod is the better solution, since there's unnecessary coupling otherwise, especially if that coupling doesn't enhance the experience (as in your previous example of limiting specific options based on the current state). I can imagine reasons why other mods would care about the dramatic plane-shift between the "real" and the "sandbox," but it's hard to justify this mod caring about the details of other mod's handling of characters (unless the solution is cross-cutting, instead of for-each mod).

Basically, my mod can only work correctly if a player's controller type is in sync with what the mod thinks this player's controller type is...

We share this exact problem, and this is where I was going with further integration points. Before those, I'll summarize what I think our current situation is. This mod doesn't care at all about characters - that's an implementation detail that we are forced to implement by the nature of the game's systems. On the other hand, your mod's primary concern is about characters: if they weren't a concept, it couldn't exist. I am not motivated to solve character-related issues or compatibilities, in the same way that you are not motivated to solve sandbox-related issues or incompatibilities.

With that in mind, the solution I called out above is a bit unfair, but it resolves the immediate problems (I think, again, I'm not exactly sure what the bug/issue is). I can broadcast information that would be helpful to your mod (and probably a few others), and you can react to that information to prevent the issues from occurring; the same goes for a method of requesting an exit, which might be equally acceptable, and it comes down to what we both want the interaction to be like.

I was trying to imagine more symbiotic scenarios, but of course this would be focused from my POV, not yours, and it doesn't sound like you have any more needs that I could solve. Given that the characters are a point of pain for this mod - and the primary topic of yours - I was wondering if leveraging your mod to achieve my goals would be desirable (for the same reasons one delegates to an existing library). Or, similarly, if there was any initiative on a standard/framework/library to help solve this exact problem more generally instead of in bespoke ways.