[Added] Don't mandate checksums in LevelCompatibility subclasses

Moderator: GZDoom Developers

Don't mandate checksums in LevelCompatibility subclasses

Postby gramps » Tue Jan 22, 2019 1:12 pm

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.
gramps
 
Joined: 18 Oct 2018

Re: Don't mandate checksums in LevelCompatibility subclasses

Postby _mental_ » Tue Jan 22, 2019 3:11 pm

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 :)
_mental_
 
 
 
Joined: 07 Aug 2011

Re: Don't mandate checksums in LevelCompatibility subclasses

Postby gramps » Tue Jan 22, 2019 3:21 pm

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...
gramps
 
Joined: 18 Oct 2018

Re: Don't mandate checksums in LevelCompatibility subclasses

Postby Graf Zahl » Tue Jan 22, 2019 3:59 pm

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.
User avatar
Graf Zahl
Lead GZDoom Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: Don't mandate checksums in LevelCompatibility subclasses

Postby gramps » Tue Jan 22, 2019 4:18 pm

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.
gramps
 
Joined: 18 Oct 2018

Re: Don't mandate checksums in LevelCompatibility subclasses

Postby Graf Zahl » Tue Jan 22, 2019 4:31 pm

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.
User avatar
Graf Zahl
Lead GZDoom Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: Don't mandate checksums in LevelCompatibility subclasses

Postby gramps » Tue Jan 22, 2019 4:45 pm

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).
gramps
 
Joined: 18 Oct 2018

Re: Don't mandate checksums in LevelCompatibility subclasses

Postby Graf Zahl » Tue Jan 22, 2019 5:04 pm

In the compatibility handler you can only edit the map thing records, not the spawned actors. This gets called before anything is spawned.
User avatar
Graf Zahl
Lead GZDoom Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: Don't mandate checksums in LevelCompatibility subclasses

Postby gramps » Tue Jan 22, 2019 5:11 pm

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.
gramps
 
Joined: 18 Oct 2018

Re: Don't mandate checksums in LevelCompatibility subclasses

Postby Graf Zahl » Thu Jan 24, 2019 7:07 pm

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.
User avatar
Graf Zahl
Lead GZDoom Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: Don't mandate checksums in LevelCompatibility subclasses

Postby gramps » Thu Jan 24, 2019 11:49 pm

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 :)
gramps
 
Joined: 18 Oct 2018

Re: Don't mandate checksums in LevelCompatibility subclasses

Postby Apeirogon » Fri Jan 25, 2019 4:02 am

Graf Zahl wrote: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?
Apeirogon
I have a strange sense of humour
 
Joined: 12 Jun 2017

Re: Don't mandate checksums in LevelCompatibility subclasses

Postby Graf Zahl » Fri Jan 25, 2019 4:07 am

Apeirogon wrote: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.
User avatar
Graf Zahl
Lead GZDoom Developer
 
Joined: 19 Jul 2003
Location: Germany


Return to Closed Feature Suggestions

Who is online

Users browsing this forum: No registered users and 1 guest