Replace the manual isCurrentEvent checks in favor of ERS

[NotroDev]

Problem

The PR introducing the EventRestrictedSyntax interface didn't replace the usages in the legacy classes, so they still used the manual isCurrentEvent checks in their init() methods. While it works pretty much the same, the ERS approach is cleaner and can be used to extract the info about supported events.

Solution

I just went over all the classes where the old approach was still used and replaced it with the ERS implementation.

Testing Completed

I didn't do any manual testing (as that's a technical change) but it compiles and passes the quickTest.

Supporting Information

The ERS interface is pretty straightforward so I could replace only the most basic checks.
For example, the ExprProtocolVersion class checks for the existence of the paper event first:

@Override
public boolean init(Expression<?>[] exprs, int matchedPattern, Kleenean isDelayed, ParseResult parseResult) {
	if (!PAPER_EVENT_EXISTS) {
		Skript.error("The protocol version expression requires Paper 1.12.2 or newer");
		return false;
	} else if (!getParser().isCurrentEvent(PaperServerListPingEvent.class)) {
		Skript.error("The protocol version expression can't be used outside of a server list ping event");
		return false;
	}
	return true;
}

And I don't think I can recreate this behavior properly in ERS without compromising the proper error messages (and I didn't want to expand the ERS logic without discussion)

The only exception is EffHidePlayerFromServerList where I used this approach:

@Override
public Class<? extends Event>[] supportedEvents() {
	if (!PAPER_EVENT_EXISTS) {
		return CollectionUtils.array(ServerListPingEvent.class);
	}
	else {
		return CollectionUtils.array(ServerListPingEvent.class, PaperServerListPingEvent.class);
	}
}

except in that case I believe the PaperServerListPingEvent is redundant anyway (and because it inherits from the ServerListPingEvent, the isCurrentEvent which uses isAssignableFrom under the hood, will pass it anyway)

There are also much more complicated examples in the Skript codebase where the supported events change based on the pattern or other circumstances, so the ERS couldn't be implemented.

PS. I can't guarantee that I've found all the usages that could be replaced :P

---

Completes: none
Related: none
AI assistance: none (i did it fully by hand because I thought there would be far fewer legacy usages...)

[Efnilite]

nice work, one tiny thing

[UnderscoreTud]

And I don't think I can recreate this behavior properly in ERS without compromising the proper error messages (and I didn't want to expand the ERS logic without discussion)

You could add support for this while you're at it, It's pretty simple. Just start a retaining log handler before supportedEvents is called, check if it contains any errors after, and print them if you find any. Then Skript.error should just work with it

[APickledWalrus]

And I don't think I can recreate this behavior properly in ERS without compromising the proper error messages (and I didn't want to expand the ERS logic without discussion)

You could add support for this while you're at it, It's pretty simple. Just start a retaining log handler before supportedEvents is called, check if it contains any errors after, and print them if you find any. Then Skript.error should just work with it

It is worth noting that ERS checks occur before init, so any init-dependent behavior is still unable to be updated. Custom error messages may already work though.

[NotroDev]

You could add support for this while you're at it, It's pretty simple. Just start a retaining log handler before supportedEvents is called, check if it contains any errors after, and print them if you find any. Then Skript.error should just work with it

I'll try to look into it when I have some free time, so I think this PR can stay open for a while

[NotroDev]

Hey, I've gotten some work done.

First, after @Absolutionism's comment, I realized that most of the "paper event exists" checks were redundant. I cleaned them up and added ERS where possible.

The changes in ExprHoverList were bigger because I cut all the fallback logic when HAS_NEW_LISTED_PLAYER_INFO fails. This field was introduced in 1.20.6, which is 23 months old.
If that's not how the Skript support lifetime works, please let me know 😅

next I'll try to expand the ERS usage as discussed above

[Absolutionism]

Just some coding convention touch ups