[Added] Don't mandate checksums in LevelCompatibility subclasses

[gramps]

The way LevelCompatibility subclasses work right now, some kind of black magic / static analysis is performed where it won't be applied if the current map's checksum doesn't appear in single quotes in a valid statement in the Apply method (at least that's sufficient to get it to run, haven't found an easier way).

Can that behavior be done away with for subclasses of LevelCompatibility? The problem here is that LevelCompatibility changes other people's maps, while its user-created subclasses likely (or at least potentially) change maps distributed along with them. This really slows down mapping, since the checksum needs to be updated every time you want to test a map.

[_mental_]

The first thing we need to do is to rename that class to something like LevelProcessor before speedy modders don’t release their works with it

[gramps]

I'm still thinking it would eventually be good to have LevelCompatibility passed into some EventHandler method, instead of extending it, and just make everything on it public. If that sounds reasonable, it might make sense for the new name for it to agree with whatever that handler method would be named.

EventHandler.LevelProcessed does sound pretty decent...

[Graf Zahl]

What's the obsession with event handlers? I wish I had never accepted them as a feature, they are probably the biggest feature blocker in the entire engine - they have been added everywhere because it was convenient for the moment.

[gramps]

Imagine you want to move some vertices and some things... the vertices need to be moved in LevelCompatibility, and the things (as far as I can tell) need to be moved in an event handler. In order to coordinate between these two, you need a third piece, like a thinker singleton. I don't really care about having it in EventHandler in particular, it's just that some of the behavior already has to be done there, and moving the LevelCompatibility stuff there would mean you could (for example) move some vertices and some things by defining one class instead of three.

It's not a huge deal if that's a lot of trouble, though, it's just a minor convenience thing.

[Graf Zahl]

I already told you last time, if you find that the compatibility stuff is missing features, make a request for them.

BTW, you can move things around with the compatibility handler, the one thing that'S missing is setting the angle.

[gramps]

Sorry, I should have been more clear... you can move things, but I was under the impression that it would be impossible to iterate them yet, like with ThinkerIterator. But I may be wrong about that, I didn't actually try it... just felt safer to do this in WorldLoaded (plus, I did need to rotate them).

I'm hesitant to make too many feature suggestions regarding LevelCompatibility because I'm not entirely sure whether things like this are even possible, since the level's not fully set up yet. But I'll take this into account going forward.

Just to be specific, what I need to do is iterate all things, check their position, check whether they are lights (because of special angle handling for lights), then set a new position and new angle. If that could all happen in LevelCompatibility, I think that would remove the need to bridge my LevelCompatibility and EventHandler with some other class (for now at least).

[Graf Zahl]

In the compatibility handler you can only edit the map thing records, not the spawned actors. This gets called before anything is spawned.

[gramps]

Right, so I guess the feature I'd want to suggest for that would look something like this in LevelLocals:

native Array<@Thing> Things;

...and we could just iterate over that and manipulate its fields directly, like with Lines or Sectors; or there could be methods provided for that if needed, like SetVertex.

Again, though, it's not a big deal to just do this in WorldLoaded, I don't want to create unnecessary dev work.

[Graf Zahl]

Done. It will no longer skip this if there's no checksum and it will pass the map name as a second string parameter. I guess for user mods that makes a lot more sense.

[gramps]

Great, thank you! That'll be a huge productivity boost. Hopefully this is the last thing I'll need to bother you guys about for a while

[Apeirogon]

What's the obsession with event handlers? I wish I had never accepted them as a feature, they are probably the biggest feature blocker in the entire engine - they have been added everywhere because it was convenient for the moment.

Huh? Event handlers is a powerful instrument. in right hands.
Or you complain not about event handlers as idea, but about a way it was implemented in gzdoom?

[Graf Zahl]

Huh? Event handlers is a powerful instrument. in right hands.

Emphasis highlighted.
That's precisely the problem. They are extremely powerful. They can do a lot of stuff. They also require a lot of discipline to not screw up things.
In clear English this means, that in the wrong hands they can become a maintenance nightmare for us engine developers.