TargetSpy: Replaceable getters/viewers/finders/filters

[MajorCooke]

Project
TargetSpy

Is your feature request related to a problem? Please describe.
Right now there is no easy way to simply replace one of the four special class types.

Describe the solution you'd like

Since they're actors, they're subject to CheckReplacement (near the bottom), which is called whenever GetReplacement is called.

Here's what I suggest...

• The mod will set up as normal and initialize everything, and then it will call GetReplacement().
• If the replacement has a suitable function to it, it'll simply use that actor's functions instead and is affected by the CVar associated with the original, so people don't have to fiddle around with disabling/enabling as much on a per-mod basis.
• Name tags that match the replacement's name will be used if found in LANGUAGE, otherwise it sticks to the original.

If this is doable, it'll solve all my problems. Modders would only need to set up replacements on their end via event handlers.

This example will be perfect because it's not mod dependent thanks to Names.

class EV : StaticEventHandler
{
	override void CheckReplacement(ReplaceEvent e)
	{
		Name rpe = e.Replacee.GetClassName();
		
		Switch (rpe)
		{
			Case 'tsGetter_Health':
				e.Replacement = 'tsGetter_SLN_Health';	break;
			Case 'tsGetter_HealthBar':
				e.Replacement = 'tsGetter_SLN_HealthBar';	break;
		}
	}
}

[mmaulwurff]

Added in 67a0a52. Example here.

Replacing the replaced class name kind of works: the mod that replaces an extension class can either replace its language string or not.

Does it work for you?

[MajorCooke]

I'm having trouble getting it to work. Does it require both CheckReplacement and CheckReplacee?

[mmaulwurff]

Should work with just CheckReplacement.

Does this example work on your side? It should replace tag getter with a modified one, that adds " - name test" to the enemy tag.
TargetSpyTest.zip

[MajorCooke]

I tried doing this (you'll need to make a mapinfo for SEvent handler) but it keeps compounding getters instead of replacing them.

What I expect is for the original ones being replaced to never display but they do, and they show up in the getters menu too. That's not supposed to happen.

[MajorCooke]

And yes, I tried changing tsGetter to just ts, but they still fail to replace the originals.

[MajorCooke]

Your example doesn't replace the names, it only compounds.

[mmaulwurff]

Well, that's embarrassing, and I'm dumb. CheckReplacement could not work because it is called on spawn, and TargetSpy never spawns extension classes. I checked one with replace syntax and called it a day.

Anyway, replacing feature is moved to Configuration. In addition to on, off, and user, you can now specify the extension class. Example, build.

[MajorCooke]

That's what Actor.GetReplacement() is for, it's static clearscope too.

[MajorCooke]

Also I'm not entirely sure what it means by "a second configuration is needed". Can you explain?

[mmaulwurff]

That's what Actor.GetReplacement() is for, it's static clearscope too.

The version that tried to use EventHandler.CheckReplacement did use Actor.GetReplacement(), as you can see here. It didn't work, because Actor.GetReplacement() bypasses EventHandler.CheckReplacement.

---

Also I'm not entirely sure what it means by "a second configuration is needed". Can you explain?

Say, you want to replace tsGetter_Tag with your own, and you also want it to be always enabled and excluded from user menus. You cannot just write it in a single ts_config.json:

{
  "tsGetter_Tag": "tsGetter_MyTag",
  "tsGetter_Tag": "on"
}

because that would be duplicate JSON keys and one would override another. So you have to make two separate configs:
ts_config.1.json:

{
  "tsGetter_Tag": "tsGetter_MyTag"
}

ts_config.2.json:

{
  "tsGetter_Tag": "on"
}

[MajorCooke]

The version that tried to use EventHandler.CheckReplacement did use Actor.GetReplacement(), as you can see here. It didn't work, because Actor.GetReplacement() bypasses EventHandler.CheckReplacement.

That seems like a bug with UZDoom. I'll work on reporting that.

Say, you want to replace tsGetter_Tag with your own, and you also want it to be always enabled and excluded from user menus.

So to be clear, the second tsGetter_Tag definition in the second config refers to tsGetter_MyTag then, or is it still referring to the original?