[Added] Ability for LevelCompatibility to place player starts

Moderator: GZDoom Developers

Ability for LevelCompatibility to place player starts

Postby Kinsie » Sat Oct 05, 2019 6:41 am

...or the ability to place things via their editor number. Or some other way to ignore the lack of a Player 1 starting position, even in a less than graceful way (like just dumping the player at (0,0).)

I'm currently messing with a mod where the player uses deathmatch spawns, but maps refuse to load if they lack a player 1 starting position, even if it's largely irrelevant to the mod at large.

There's been some murmurings in the past about adding more Thing manipulation options to LevelCompatibility, this could be something to add alongside those.
User avatar
Kinsie
Dog Days
 
Joined: 22 Oct 2004
Location: MAP33
Discord: Find Me...
Twitch ID: thekinsie

Re: Ability for LevelCompatibility to place player starts

Postby Graf Zahl » Sat Oct 05, 2019 9:09 am

Even if it's largely irrelevant for the mod, not to have player 1 starts, it is not for the engine. There's a reason this isn't accepted even in deathmatch mode.

As for the request as such, I wish I had more time, but as things are I already have to split it between several projects so some things will simply remain undone unless we find another developer willing work here.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: Ability for LevelCompatibility to place player starts

Postby Rachael » Sat Oct 05, 2019 9:14 am

This would be a lot easier if I knew whether the engine processes player starts before or after the LevelCompatibility handler.

In case anyone is wondering why I ask that - the engine does not handle Player 1 starts the same way it handles things like teleporter destinations or map spots and such. Player starts are simply stuffed into an array somewhere and forgotten about until they're needed. When the map is fully spawned, they do not leave any invisible actors behind like teleporter/map spots do.
User avatar
Rachael
Admin
 
Joined: 13 Jan 2004
Discord: Rachael#3767
Twitch ID: madamerachelle
Github ID: madame-rachelle
Operating System: Debian-like Linux (Debian, Ubuntu, Mint, etc) 64-bit
OS Test Version: No (Using Stable Public Version)
Graphics Processor: nVidia with Vulkan support

Re: Ability for LevelCompatibility to place player starts

Postby _mental_ » Fri Nov 01, 2019 6:58 am

Here is my current developments on generic level post-processor. At the moment, I have no plans to extend it, and so, I decided to make this PR to get some feedback.
_mental_
 
 
 
Joined: 07 Aug 2011

Re: Ability for LevelCompatibility to place player starts

Postby Rachael » Fri Nov 01, 2019 7:08 am

Oh, if the role of the compatibility is being changed to a generic post-processor, then the extensions I had made to it a couple months ago make a LOT more sense.

This is the branch where I had made the extensions necessary in order to flip an entire level. Is there any chance these operations could be integrated into that? They were originally made for my level flipper project - specifically, this branch, but I am sure that some use for them could be found elsewhere.

If you have no issue with the concept of these, I have no issue of doing the work myself to port the changes over to your new branch.
User avatar
Rachael
Admin
 
Joined: 13 Jan 2004
Discord: Rachael#3767
Twitch ID: madamerachelle
Github ID: madame-rachelle
Operating System: Debian-like Linux (Debian, Ubuntu, Mint, etc) 64-bit
OS Test Version: No (Using Stable Public Version)
Graphics Processor: nVidia with Vulkan support

Re: Ability for LevelCompatibility to place player starts

Postby Graf Zahl » Fri Nov 01, 2019 7:12 am

Careful! You cannot rename the class because it was inheritable, so this would break a few mods that use it to apply GZDoom specific changes to maps.
If you want to get rid of the name it has to be done in a way that does not affect mods. This

Code: Select allExpand view

class LevelCompatibility102 : LevelCompatibility
{
   void setcolor(int sector, color colour)
   {
      level.sectors[sector].SetColor(colour);
   }
   
   private void Apply(Name checksum, String mapname)
   {
      int i;
      if (mapname ~== "MAP01")
      {
      }
      else if (mapname ~== "MAP02")
      {
      }
      else if (mapname ~== "MAP03")
      {
      }
   }
}


is very much allowed.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: Ability for LevelCompatibility to place player starts

Postby _mental_ » Fri Nov 01, 2019 8:59 am

I didn't rename LevelCompatibility class. All methods were moved to its new parent.
I extended my test case with the corresponding check, and it outputs the message as expected.
_mental_
 
 
 
Joined: 07 Aug 2011

Re: Ability for LevelCompatibility to place player starts

Postby Graf Zahl » Fri Nov 01, 2019 9:56 am

In that case it should be ok.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: Ability for LevelCompatibility to place player starts

Postby Kinsie » Fri Nov 01, 2019 10:55 pm

Very impressive! I can't wait to see what stuff people smarter than I am can do with this.
User avatar
Kinsie
Dog Days
 
Joined: 22 Oct 2004
Location: MAP33
Discord: Find Me...
Twitch ID: thekinsie

Re: Ability for LevelCompatibility to place player starts

Postby _mental_ » Sat Nov 02, 2019 2:59 am

It's possible to alter things pretty much like in editor: addition of player starts, replacement of things, crap stuff like Doom Extra Hard, whatever.
Ability to query existing things before applying game type and skill filtering is another useful feature.

If there will be no objections, I'll merge these changes, with reduced number of commits.
_mental_
 
 
 
Joined: 07 Aug 2011

Re: Ability for LevelCompatibility to place player starts

Postby Graf Zahl » Sat Nov 02, 2019 3:05 am

Please don't squash this. if then something goes wrong there's no way to bisect to narrow down the thing that caused the problem because it's all one huge blob that's hard to investigate. With complex features I prefer to leave the commit history intact because it makes it a lot easier to analyze the feature. For simple things that got a few cleanup commits squashing is fine.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: Ability for LevelCompatibility to place player starts

Postby _mental_ » Sun Nov 10, 2019 3:43 am

Added in 82c2488 with more features than initially requested.

For new developments, LevelPostProcessor class should be used instead of LevelCompatibility.
It has an ability to do pretty much anything with map things before level is started.
_mental_
 
 
 
Joined: 07 Aug 2011

Re: Ability for LevelCompatibility to place player starts

Postby Kinsie » Mon Nov 11, 2019 3:50 am

Well, I'll be damned. Can't wait for a stable build with this to emerge so I can mess around with it some.

Thanks again, mental!
User avatar
Kinsie
Dog Days
 
Joined: 22 Oct 2004
Location: MAP33
Discord: Find Me...
Twitch ID: thekinsie

Re: Ability for LevelCompatibility to place player starts

Postby Nash » Mon Nov 11, 2019 4:06 am

Interesting! Would the level post processor be capable of adding map geometry (verts, lines/sides, sectors)?
User avatar
Nash
AKA Nash Muhandes! Twitter/Facebook/Youtube: nashmuhandes
 
 
 
Joined: 27 Oct 2003
Location: Kuala Lumpur, Malaysia
Twitch ID: nashmuhandes
Github ID: nashmuhandes

Re: Ability for LevelCompatibility to place player starts

Postby _mental_ » Mon Nov 11, 2019 4:44 am

I doubt so, as adding geometry is much more complicated that adding things.
The mentioned entities are so tightly coupled, and geometry editing would be either very limited or quite hard to use.
If somebody comes up with a good scripting interface for it, this can be reconsidered.
_mental_
 
 
 
Joined: 07 Aug 2011


Return to Closed Feature Suggestions

Who is online

Users browsing this forum: No registered users and 0 guests