Same underlying shot but requires different (but dependent) behavior across multiple modes (with different priorities)

[bernarma]

To set some context, I have 7 unique shots that are defined in a base/global mode that run throughout the game.

Base/Global Mode:

shots:
  sh_shot1:
    switch: s_switch1
  sh_shot2:
    switch: s_switch2

I have another mode that runs alongside this base/global mode that defines its own set of shots (ultimately still the same 7 unique shots from the base) configured using the hit_event property of the corresponding shot from the base/global mode.

Mode 1 Shots

shots:
  sh_mode1_shot1:
    hit_events: sh_shot1
    enable_events: enable_shot1
    disable_events: disable_shot1
    profile: custom_profile1
  sh_mode1_shot2:
    hit_events: sh_shot2
    enable_events: enable_shot2
    disable_events: disable_shot2
    profile: custom_profile1

What I would like to do is have a new mode start, that for any shot that the other mode has not "enabled" (i.e. lit up), to be actively lit in this new mode so I can tie some logic to it (keeping in mind that the other mode that is running has the potential to change its active/enabled shots at any time and this mode must respect that).

Mode 2 Shots

shots:
  sh_mode2_shot1:
    hit_events: sh_shot1
    profile: custom_profile2
  sh_mode2_shot2:
    hit_events: sh_shot2
    profile: custom_profile2

I am unsure after reading through the documentation on how to approach this. I have read about shot profiles and the block property but haven't been able to work it out. I was hoping someone would have some suggestions on how to tackle this problem.

[avanwinkle]

Shot states are stored as player variables, so you can check the state of the shot by checking the variable shot_<shot_name>. That works for profile state, if you want to check the enabled/disabled state then you'll want to make sure the shot has persist_enable: true and then it will save the player variable shot_<shot_name>_enabled.

[bernarma]

I managed to get it working with out of the box functionality and some behind the scenes python code. I will provide a more definitive answer later on so that it can help others in the future. I would like to eventually get some patterns published to help others. The framework is very powerful but I think where it is exceptionally good is its ability to extend using Python.

A few things I have learnt since I posted this was the priority system and how it can be manipulated independently of shots and the shot_profile shows. Funny thing, to get this working I had to refactor all the major modes to the new style but I got rid of so much duplicate yaml scripts so it was for the greater good anyhow.

Regarding the persist_enable functionality, it didn't behave as I would have expected. I'd have expected that if you configured persist_enable to false (which isn't the default), that the state wouldn't be saved but unfortunately the state is saved for the shot and I would have to reset the state regardless of the setting. Is this intended behavour?