Problem with "Wave defense" scenario

[Pi-C]

I've got a bug report for miniMAXIme when it was used with the "Wave defense" scenario. My mod allows players to change their appearance on the fly by swapping characters. Each player gets a dummy character for storing things like armor and inventory, plus one preview character for each selectable character prototype. Preview and dummy characters are hidden on hidden mini-surfaces (1 tile x 1tile) that are not meant to be used by players.

"Wave defense" has the function create_battle_surface(), which contains the following:

Code: Select all

  for k, surface in pairs (game.surfaces) do
    if surface.name ~= "nauvis" then
      game.delete_surface(surface.name)
    end
  end

I will make sure now to restore my surfaces when they are deleted by some other mod. However, the function destroying the surfaces is called from functions on_player_joined_game, shuffle_button, check_seed_input, infinite_checkbox_input, difficulty_changed, end_round, and restart_round -- so I guess it will be run quite a lot.

I guess there are about 30-40 different characters people can choose from at the moment. If somebody was using all supported character mods, a lot of time will be spent uselessly on deleting surfaces that will be immediately restored (including the dummy and preview characters + rebuilding the players' GUIs). Could you, please, ignore my surfaces when you delete all but nauvis? The name of the surface for storing the dummies is "minime_dummy_dungeon", the names of the preview character surfaces start with "minime_character_previews_".


@Mods: I'm not quite sure this is the correct forum for my post as this is neither a question about how to mod something nor a bug report nor a modding interface request. If you think it would fit in better somewhere else, please move it!

[Klonan]

I looked into it, and unfortunately I don't see a good way to handle this on my side, especially as I don't want to start writing specific mod exclusions in to base game scenarios

My only suggestion would be to only create 1 surface and use position offsets for the characters, which will reduce the number of surfaces you need to make

[Rseding91]

There is a somewhat large overhead to have a surface exist. You really should just use one surface and offsets for each character you support as Klonan said.

[Pi-C]

I looked into it, and unfortunately I don't see a good way to handle this on my side, especially as I don't want to start writing specific mod exclusions in to base game scenarios

Thanks for looking into it! I understand that mod specific exclusions are kind of problematic: make one exceptions and be prepared to make a dozen. But as far as I know, I'm not the only one who makes use of 1x1 surfaces for special purposes. So, perhaps you could check for that in surface.map_gen_settings before deleting it?

My only suggestion would be to only create 1 surface and use position offsets for the characters, which will reduce the number of surfaces you need to make

I already do that: one surface for each character prototype, with one character for each player on it. This way, I can easily add or remove character previews in answer to remote calls from other mods, so I'd rather stick to my current scheme, if possible. (Also, I must admit I'm a bit afraid to break things when I switch to one surface for all preview characters of all players. )

There is a somewhat large overhead to have a surface exist. You really should just use one surface and offsets for each character you support as Klonan said.

Makes sense, perhaps I really should consider this! I bet there's also overhead regarding the size of/number of chunks on the surface, right? I'm asking because it just occurred to me to spread out the characters in a rectangle (lines for prototypes, rows for players), one chunk apart from each other. I need some distance between the characters anyway because their animations can vary considerably in size and I don't want them to overlap in camera view. One chunk per character should be safe enough, but it may be better to narrow the gap a bit.

Still, using just one surface doesn't solve the problem entirely. Sure, if only 1 surface is destroyed instead of 20, this will reduce the number of raised events significantly. But I'd still have to recreate and initialize the preview characters (which won't raise defines.events.script_raised_built, but will raise defines.events.on_player_armor_inventory_changed for all preview characters that belong to a player who is wearing an armor) and update the GUIs. That wouldn't be too bad if it happened only once per session, but I'm afraid surfaces are deleted rather often (see my first posting).

[Pi-C]

But I'd still have to recreate and initialize the preview characters (which won't raise defines.events.script_raised_built, but will raise defines.events.on_player_armor_inventory_changed for all preview characters that belong to a player who is wearing an armor) and update the GUIs.

Looks like I've made a thinko: defines.events.on_player_armor_inventory_changed will be raised when a player's armor is changed, and I respond to that by changing the armor of the preview characters as well. But the previews don't have character.player, so setting their armor won't raise any event.