Can LevelCompatibility be used to give a line an ID in a UDMF map?
Line_SetIdentification and other line specials that would set an ID in other formats don't work in UDMF, as described on wiki. Is there another way?
I'd like to auto-generate IDs for some lines, so they don't need to be defined on the map. But right now each ID needs to be specified twice on each line in the map, once as an actual id and once as a UDMF user field, since IDs can't be read by LevelCompatibility.
If IDs can't be written in UDMF format by LevelCompatibility, it looks like the only way to generate them will be to switch to Doom or Hexen format, which seems backwards. Would also have to hack another UDMF user field in as something else, like an unused special arg, and throw it out later in LevelCompatibility.
Assign line ID using LevelCompatibility in UDMF?
Moderator: GZDoom Developers
- Graf Zahl
- Lead GZDoom+Raze Developer
- Posts: 49056
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: Assign line ID using LevelCompatibility in UDMF?
Internally there is such a function that returns a line's first ID but it was never needed on the script side so far.
The main problem you are facing is simply that the compatibility handler only got functions added on an as-needed basis. So far there haven't been maps that needed line ID manipulation to fix problems so there are no functions for it.
Since you are basically the first person to use this feature for programmatic map manipulation your only choice is to make feature requests to get the needed features in.
The main problem you are facing is simply that the compatibility handler only got functions added on an as-needed basis. So far there haven't been maps that needed line ID manipulation to fix problems so there are no functions for it.
Since you are basically the first person to use this feature for programmatic map manipulation your only choice is to make feature requests to get the needed features in.
Re: Assign line ID using LevelCompatibility in UDMF?
Got it. I guess this can go in feature suggestions as-is; requested a move.
- Graf Zahl
- Lead GZDoom+Raze Developer
- Posts: 49056
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: Assign line ID using LevelCompatibility in UDMF?
For that, please report it. I cannot do it.
Re: Assign line ID using LevelCompatibility in UDMF?
Saw this in https://github.com/coelckers/gzdoom/commit/3df112a7
Really nice, this completely removes the need for tedious ID assignment when cut-n-pasting my "zones."
OT: finally got these static portals working. LevelCompatibility is very powerful.
Really nice, this completely removes the need for tedious ID assignment when cut-n-pasting my "zones."
OT: finally got these static portals working. LevelCompatibility is very powerful.
Re: Assign line ID using LevelCompatibility in UDMF?
At this point I wonder what really separates compatibility scripting (as in, fixing glitchy, previously-working maps) from "powerful level altering scripting made for modern mods"...
- Graf Zahl
- Lead GZDoom+Raze Developer
- Posts: 49056
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: Assign line ID using LevelCompatibility in UDMF?
At the moment: The feature set. You still need a working level in which you can change stuff, but not add or remove.
If you look at some of the compatibility code you'll see that for some maps it's not just filling in some blanks but heavily restructuring of certain areas that were made with hacky constructs. Especially the fixes for Kama Sutra MAP01 and Alien Vendetta MAP01 are quite complex.
If you look at some of the compatibility code you'll see that for some maps it's not just filling in some blanks but heavily restructuring of certain areas that were made with hacky constructs. Especially the fixes for Kama Sutra MAP01 and Alien Vendetta MAP01 are quite complex.
Re: Assign line ID using LevelCompatibility in UDMF?
I guess the conversation to have is whether it makes sense to rework the API a bit so this all works through the event handlers, say in a LevelLoaded event, with LevelCompatibility passed in as a param.[1]
If so, what should the actual scope of it be... should it be able to add and remove stuff?
[1] - Just to make it a normal feature, not undocumented, and not feel too much like subverting an unrelated feature. Also because an EventHandler is likely sort of the "main class" in a mod, and this would avoid the need for a thinker singleton to get stuff back and forth between your LevelCompatibility and your EventHandler.
If so, what should the actual scope of it be... should it be able to add and remove stuff?
[1] - Just to make it a normal feature, not undocumented, and not feel too much like subverting an unrelated feature. Also because an EventHandler is likely sort of the "main class" in a mod, and this would avoid the need for a thinker singleton to get stuff back and forth between your LevelCompatibility and your EventHandler.