Script development auto reloading on save

[TheLimeGlass]

Description

• Adds structure to denote automatic script reloading per script.
• Adds entryValidator method to set an EntryValidator for a structure.

auto reload:
        # Cancels out permission node. Define the players that will get reload notifications.
	recipients: "LimeGlass" and "Dinnerbone"

	# Players with this permission will receive reload notifications.
	permission: "skript.reloadnotify"

---

Target Minecraft Versions: any
Requirements: none
Related Issues: #4313

[APickledWalrus]

The entry validator is a parameter for registering the structure. Is there a reason you aren't/can't just do that?

[TheLimeGlass]

The entry validator is a parameter for registering the structure. Is there a reason you aren't/can't just do that?

Oh no. Didn't see that. Interesting way of setting the EntryValidator. I still believe this overriding implementation is good so it can be changed dynamically.

[APickledWalrus]

If it needs to be done dynamically (which seems unlikely), I think it would be better for the developer to manage it in init themselves

[TheLimeGlass]

If it needs to be done dynamically (which seems unlikely), I think it would be better for the developer to manage it in init themselves

You'd have to set the EntryValidator by getting the StructureData then the StructureInfo, and that would override the existing EntryValidator if it was also needed because the Structure init is called before the implemented Structure.

[APickledWalrus]

They can simply store the EntryValidator on the class and validate it (receive an entry container) themselves in the overridden init. It does't necessarily have to be the internal one. This is the common approach for addon developers who implement these for Sections.

[Pikachu920]

I'd rather see this as an addon or script personally

[TheLimeGlass]

They can simply store the EntryValidator on the class and validate it (receive an entry container) themselves in the overridden init. It does't necessarily have to be the internal one. This is the common approach for addon developers who implement these for Sections.

Ya that's one way of doing it. It probably should've been an overriding method from the start to avoid storing it in ram, like Njol did with everything. Changers for example.

[ShaneBeee]

I was interested in trying this, but ran into a few minor issues.

[APickledWalrus]

They can simply store the EntryValidator on the class and validate it (receive an entry container) themselves in the overridden init. It does't necessarily have to be the internal one. This is the common approach for addon developers who implement these for Sections.

Ya that's one way of doing it. It probably should've been an overriding method from the start to avoid storing it in ram, like Njol did with everything. Changers for example.

We don't want to be creating an EntryValidator every time the Structure is parsed. I don't think storing it in RAM is anything to be concerned about (or how much memory that might be - it won't be that much). Handling the validation through the syntax info is fine as-is.

[TheLimeGlass]

We don't want to be creating an EntryValidator every time the Structure is parsed. I don't think storing it in RAM is anything to be concerned about (or how much memory that might be - it won't be that much). Handling the validation through the syntax info is fine as-is.

It'll be needed at parse time since that's when the Structure is created and parsed. Once the EntryValidator is used during parsing, it'll be garbage collected.

[TheLimeGlass]

Placing in draft, as the parsing doesn't support String lists.

[Dummybell]

add it