Fix hunter background action names

[scamille]

Stumbled upon this when fixing compiler warnings. The fix is based on my understanding of how the get_background_action functionality is supposed to work.

Should be reviewed by some actual hunters though ;)

[Pewtro]

Don't think we've had any issues with the background actions, what is this meant to fix?
And looks like it's breaking CI

[scamille]

The idea of the get_background_actions - as far as I understand it - is that you only have a single instance per player, based on the action name.

The issue here is that the background actions aren't created with the correct name - thus they are recreated each time get_background_action is called.

In the end this is mostly a object optimization.

[scamille]

In the end the question is whether most of these background actions - let's pick serpent_sting_explosive_venom should actually be separate from their base actions like serpent_sting or whether they should share the name, e.g. for expressions.

If the actions should be truly separate, then constructing them with a correct name is indeed required.

[Pewtro]

They should not be separate, they should share name

[Pewtro]

This can be merged once the CI passes, it's currently causing either dot.serpent_sting or action.serpent_sting to fail

[scamille]

They should not be separate, they should share name

Ok thanks. So if they indeed should share the name, but ideally still be a single global action unique to the player, this just needs something different than get_background_action that does lookup based on a unique name.

[Jayezi]

think it just needs to make sure any of the actions that got looked up with get_background_action before gets background set to true in case it was relying on the lookup to do that before, I see a few at glance that would need it

[nuoHep]

The idea was (as implemented in 4cb5c7c; the implementation did not change afaict, notwithstanding changes outside of the class module itself):

• background action objects have name in the constructor and always pass it through to the base object constructor (up to action_t ctor)
• get_background_action() gets called with a name "unique" for this background action, the constructed action gets constructed with this name so it can be looked up later

This is mostly a memory optimization (has negligible positive impact on perf) to share these "background" actions between different instances of the main action because of the way apl & stuff is handled in simc (each action line in the apl results in an action object).

I don't know why the actions used with get_background_action() don't propagate their names now, but "by design" (of get_background_action()) they should.

[Jayezi]

Main culprit that comes to mind is explosive shot, there's like a dozen different ways it shows up with different qualities (salvo needs to be set to 2 targets, etc) but that all share the dot, so without other handling, in some cases propagating a name unique to whatever implementation is looked up, like "explosive_shot_salvo", all the way to base actions would result in the wrong dot being looked up, when they all need to hook up to the same "explosive_shot". So volley and multishot both look up "explosive_shot_salvo" and then end up with an implementation of explosive shot with targets set to 2, but based on a action still named "explosive_shot" pulling up the "explosive_shot" dot it shares with every other implementation.

I think I always kinda glossed over it assuming it looked more like a map of name to action and was pulling up the same action in a case like that.