Hi

We noticed a data stage conflict with the explosive rocket prototype. The following was added as new table item for action_delivery. This breaks any setup that expected action_delivery to be single item, which is the default data structure.

      {
        target_effects = {
          effect_id = "mds-map-reveal-small",
          type = "script"
        },
        type = "instant"
      }

Based on the data structure I saw with print, I think you should be able to add the custom script to the original action_delivery item's target_effects, without the need to create a new item for action_delivery. Like this.

table.insert(rocket["action"]["action_delivery"]["target_effects"],  {
          effect_id = "mds-map-reveal-small",
          type = "script"
        })

It's a better way to ensure compatibility of default game entity that other mods may rely on.

Thank you for your insights!

I don't see how does your proposed solution avoid having multiple items in the action delivery. Maybe I don't understand your concern properly. Was there an actual conflict you have encountered with another mod? Perhaps sharing the mod name could help me understand the issue.

However, looking at it from another perspective, the API clearly allow multiple items / array as action_delivery. Assuming a single delivery is simply incorrect and should be fixed where it was wrongly assumed, in the conflicting mod.

EDIT: I guess the conflicting mod is ERM red army. I really should read the subject more carefully next time.

EDIT2: I can see now what you mean. ERM is assuming action delivery is a single item instead of a table and it is refrencing its target_effects without indexing. Your proposed solution is to not add another delivery but add the script effect to the existing delivery's target_effects and see if it works.
I will attempt to try it out and if it does work as expected then I will implement you suggestion.

Thank you for considering it.

The API supports array as action_delivery. It's fine when you are deepcopy the base item out as a new prototype. You can do anything to it without affecting other mods that rely on the same prototype.

When I need to edit base game entity, I try my best not to modify the existing data structure. When the prototype needs data structure changes, I always deepcopy item to a new prototype to minimize the conflicts with other mods.

I can technically fix on my side, but it requires more checks to ensure it's modifying the proper item. I shouldn't need a workaround to deepcopy and make change for a base game item.

I have released 1.2.1 with your suggested change - well., my version of it anyhow. My test indicated that the crash is now gone. Thanks again for the tip! As it turned out it did cause issues with other mods as well besides the ERM - Red Army.