Page 1 of 1

Maphack Lump à la EDuke32

Posted: Mon Oct 22, 2018 8:04 pm
by StroggVorbis
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?

Re: Maphack Lump à la EDuke32

Posted: Mon Oct 22, 2018 8:09 pm
by Rachael
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.

Re: Maphack Lump à la EDuke32

Posted: Mon Oct 22, 2018 8:12 pm
by StroggVorbis
Thanks for the thorough explanation, this thread can be closed then :)

Re: Maphack Lump à la EDuke32

Posted: Mon Oct 22, 2018 8:28 pm
by Caligari87
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-)

Re: Maphack Lump à la EDuke32

Posted: Mon Oct 22, 2018 8:53 pm
by Rachael
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. ;)

Re: Maphack Lump à la EDuke32

Posted: Tue Oct 23, 2018 1:15 am
by Graf Zahl
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... ;)