[Already In] Maphack Lump à la EDuke32

Moderator: Developers

Maphack Lump à la EDuke32

Postby DabbingSquidward » Mon Oct 22, 2018 9:04 pm

Taking inspiration from the Duke Nukem 3D source port of choice is the proposal of adding something akin to the Maphack Language, plaintext files to fix map bugs in case where distributing a modified version would be on shaky legal ground. For anyone interested, here's the source material:

https://wiki.eduke32.com/wiki/Maphack_Language

In a nutshell, this allows one to:

-change the position of entities in a given map (out of a wall or bounds)
-apply rotation, pitch and roll to an object (if you replace sprites with models or voxels and don't want all of them to face the same direction) and in addition offset the centerpoint of a model's axes
-add spotlights

To go a step further, I suggest expanding on this formular and add stuff like applying texture orientation correction or replacement to squash halls of mirrors.

As a starting point Brad Harding's Doom Retro source port has over thousand individual fixes for every official Doom IWAD, however I think they are compiled into the executable and applied in real time on map load if r_fixmaperrors is set to true. One could ask him for permission to use the corresponding source code on his GitHub as a base to create a GZDoom-specific MAPHACK.lmp or maybe extend this information to the MAPINFO lump. If desired, other engines like Eternity or EDGE could follow suit. Since the UDMF format was the result of such a collaboration, why not let them benefit from this too?
User avatar
DabbingSquidward
 
Joined: 08 Nov 2017
Location: Germany

Re: Maphack Lump à la EDuke32

Postby Rachael » Mon Oct 22, 2018 9:09 pm

GZDoom already does this through its compatibility systems. One of the most notable ones you'll see is MAP21 (Nirvana) of Doom 2, the room with the rising stair platforms and the rocket launcher. In the Doom 2 version, there are holes in the ceiling due to the addition and deletion of sectors with how Petersen initially designed the map and the associated DoomEd bugs. GZDoom repairs the damage (transparently, as far as the user is concerned) by fixing the ceiling and making the individual sectors all the same level, and makes it look completely solid. There are many MANY more examples of this happening, but this happens to be one of the most obvious ones.

If there are any wads (even non-official ones, but not likely to be fixed by the original author themselves) that need such fixes, put it in here.

Adding newer features to maps is also possible through ZScript and comparing the map's MD5 sum against an internal list, and adding objects as necessary.
User avatar
Rachael
QZDoom + Webmaster
 
Joined: 13 Jan 2004

Re: Maphack Lump à la EDuke32

Postby DabbingSquidward » Mon Oct 22, 2018 9:12 pm

Thanks for the thorough explanation, this thread can be closed then :)
User avatar
DabbingSquidward
 
Joined: 08 Nov 2017
Location: Germany

Re: Maphack Lump à la EDuke32

Postby Caligari87 » Mon Oct 22, 2018 9:28 pm

As a coat-tail request, can the map compatibility system be opened up for modding use? I know there's several people who would appreciate the ability to dynamically add deep-water sectors or 3D floors to maps, for example, and I don't think this can be accomplished with ZScript since it requires adding more sectors to the map.

8-)
User avatar
Caligari87
I'm just here for the community
User Accounts Assistant
 
Joined: 26 Feb 2004
Location: Salt Lake City, Utah, USA
Discord: Caligari87#3089

Re: Maphack Lump à la EDuke32

Postby Rachael » Mon Oct 22, 2018 9:53 pm

The compatibility system can't add sectors to the map, as far as I know. If I am wrong, and it can, then it would be more appropriate to open a new thread for this. ;)
User avatar
Rachael
QZDoom + Webmaster
 
Joined: 13 Jan 2004

Re: Maphack Lump à la EDuke32

Postby Graf Zahl » Tue Oct 23, 2018 2:15 am

Technically this can all be implemented. All the compatibility layer does is manipulate the actual map data before the internal data structures are being created. This of course also means that the features it can access are currently limited to the few things actual compatibility related changes need to do.

Of course to make it work externally there needs to be some means to override the class from which the setter method gets taken - or make this a configurable list. Currently it is hard coded to the internal one.

Now all this needs is someone to implement it... ;)
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 2 guests