Sign in to follow this  
Followers 0

[Bug] ExtraData doesn't work w/Parameterized Linedefs

In the Eternity wiki, it's stated that parameterized linedefs can be used in place of the dedicated ExtraData control linedef (#270) in Doom format maps:

"Linedef records in ExtraData are associated either with lines which bear the ExtraData Control Line Special (270), or with any linedef in a DOOM-format map which uses a parameterized line special."

Unfortunately, it doesn't seem to work, which appears to be a bug rather than an error in the wad (as far as Essel or I can tell). I've got a line special on a map that tries to use Special #348 (Polyobj_StartLine) to call an ExtraData special, but it fails. Changing the line special to #270 will make it work as intended, but as a result make it not work with the ZDoom setup. :P

I can put up a test wad later if you like. My "test environment" for this involves an experimental build of Hacx 2.0, although I don't suppose it'd hurt to put up a new IWAD build anyhow.

Share this post


Link to post

Sure thing.

I've uploaded a temp. build of the Hacx 2.0 IWAD here, which you'll need for the extradata defs. The actual test wad is here, which is a small test wad featuring a couple of polyobject doors that aren't showing up at present. Everything's set up so they should appear once the bug's fixed, I believe.

Share this post


Link to post

Should be fixed as of r1853. 348 and 349 were ignored because they are static init line types and thus aren't considered parameterized by the E_IsParamSpecial function.

Share this post


Link to post

New build uploaded.

Share this post


Link to post

One thing to watch out for is that most development is currently on edf3-branch, so trunk is actually several months behind at the moment in terms of major features, optimizations, bug fixes, etc.

A few have been done on trunk; IIRC I did this one on trunk.

Share this post


Link to post

Thanks for the fix, Quasar -- it appears to work... almost. Trouble is, it seems that the parameterized linedef special is overriding what's in ExtraData's "special" field. I suppose this is intentional?

This unfortunately bites the intended use in the ass since for ZDoom I had to hijack another line special # for mirrored polyobjects to work right. I used #349 for proximity (and the idea that EE would treat it as parameterized n' look at ExtraData) and I have the tags used mapped in ExtraData to Polyobj_StartLine, but it's still treating it as Polyobj_ExplicitLine and fudging things up. Is there any way to allow ED's "special" field to take precedence? If the aim is to provide a generic set of parameters that can be fed into more than one parameterized linetype, then it seems reasonable to my lazymind to just not include a special in ED.

Sorry for the bother once more. I'm stretching both ends to obscene amounts to make things meet, but I don't think anything's going to budge any further on the ZDoom side. :(

Share this post


Link to post
Xaser said:

Thanks for the fix, Quasar -- it appears to work... almost. Trouble is, it seems that the parameterized linedef special is overriding what's in ExtraData's "special" field. I suppose this is intentional?

This unfortunately bites the intended use in the ass since for ZDoom I had to hijack another line special # for mirrored polyobjects to work right. I used #349 for proximity (and the idea that EE would treat it as parameterized n' look at ExtraData) and I have the tags used mapped in ExtraData to Polyobj_StartLine, but it's still treating it as Polyobj_ExplicitLine and fudging things up. Is there any way to allow ED's "special" field to take precedence? If the aim is to provide a generic set of parameters that can be fed into more than one parameterized linetype, then it seems reasonable to my lazymind to just not include a special in ED.

Sorry for the bother once more. I'm stretching both ends to obscene amounts to make things meet, but I don't think anything's going to budge any further on the ZDoom side. :(


You can't have both an ED special # and a special number on the linedef. If you use one on the linedef other than 270, then the ExtraData record's special will be ignored. What you're trying to do sounds like an abuse of the system for something other than its intent.

So there are two valid possibilities:

  • 270 special in-map, real special in ExtraData
  • real special in the map, args only in ExtraData
Arbitrary remapping of specials isn't meant to be possible using this language. Adding that now would seriously screw with my plans for the upcoming udmf-branch, I am afraid.

Share this post


Link to post

Plus, the whole thing won't be needed once there is UDMF in Eternity, as the Hacx project will then be able to convert.

Share this post


Link to post

So, what needs to be finished first before UDMF is implemented in Eternity, the port of the same author?

Share this post


Link to post

I have determined that creating a completely unified line special system in Eternity like the one that is in ZDoom, where everything is internally represented as Hexen-equivalent linedef types, is pretty much impossible due to an unmanageable amount of compatibility codepath branches that would be required. Some of this code we are speaking of here has problems that are completely hidden until the code is changed.

A couple of examples:

  • When DOOM's vertical doors are reactivated, whether or not they can be reactivated is determined by the special now being triggered, *not* by the one that originally started the door thinker.
  • When DOOM's vertical doors are activated, if the special is not within a certain numeric range, it may be allowed to fall into the default case of a switch statement and start multiple thinker(s) on the same door sector(s).
I could probably list a thousand other such problems which would range from difficult to impossible to maintain through a complete refactoring of the linedef system into a unified one.

Instead I am probably going to break up the various EV_ functions in "codepointers" of a new variety that are referenced from runtime-constructed data into lookup arrays. Different games such as Strife and Hexen will have their own tables and may reference different action codepointers that implement the proper logic without necessarily overlapping.

The thinkers will exist on a separate lower layer and will be largely shared between gamemodes' linedef logic.

Share this post


Link to post
Quasar said:

I have determined that creating a completely unified line special system in Eternity like the one that is in ZDoom, where everything is internally represented as Hexen-equivalent linedef types,

Sounds tough, but does the UDMF standard require that?

Share this post


Link to post
printz said:

Sounds tough, but does the UDMF standard require that?


Not at all. To the contrary, the core UDMF specs require the same specials as the original games -- that's why you have the Doom, Heretic, Hexen and Strife namespaces. The core UDMF specs were written so that they could easily be adopted by any port that wants to.

ZDoom used a translation system before UDMF was dreamed off (and it has had a few errors in it, though I think I discovered all of them; only Strife line 11 remains to be fixed for real).

The advantage of ZDoom's approach is that it makes it simpler to maintain because there's just one set of specials, and you can externalize the translation work. Xlat is a very nifty thing.

Share this post


Link to post
Gez said:

Not at all. To the contrary, the core UDMF specs require the same specials as the original games -- that's why you have the Doom, Heretic, Hexen and Strife namespaces. The core UDMF specs were written so that they could easily be adopted by any port that wants to.

ZDoom used a translation system before UDMF was dreamed off (and it has had a few errors in it, though I think I discovered all of them; only Strife line 11 remains to be fixed for real).

The advantage of ZDoom's approach is that it makes it simpler to maintain because there's just one set of specials, and you can externalize the translation work. Xlat is a very nifty thing.

Yeah. I want to try to find a happy medium where some of the specification can be externalized into an xlat-like EDF facility, and the rest is internal with as much shared as practical, and the game-specific elements isolated out into different modules.

So for example VerticalDoorThinker can easily handle the logic of moving doors in all extant idTech 1 games. However, the logic of DOOM EV_VerticalDoor and EV_DoDoor are not compatible in various ways with Hexen. Mapping compatibility as well as demo compatibility require these bizarre quirks to remain intact, and if I tried to merge the games' logic together, the combination might not only simply not work, but it would be hideous to look at as well.

Share this post


Link to post
Quasar said:

So there are two valid possibilities:

  • 270 special in-map, real special in ExtraData
  • real special in the map, args only in ExtraData

Neither of these will work. I have to use two different line specials in order to assign tags to mirrored polybjects properly via xlat on the ZDoom side, and special #270 can't be one of them since I can't map that in xlat without borking the other specials which use it. :(

Admittedly, none of this will matter when UDMF comes out, but I don't know how long that will be and I'd feel rotten if this falls through since I won't be able to utilize any of the new xlat additions which Randy pretty much added in only for this purpose.

There might be one possibility left, though, that won't require any engine changes. Hopefully I can actually get this one to work. :P

[EDIT] It worked. Hallelujah! Well... no further hacks (or is that 'hacx'? :P ) from me on this front. I'm done trying to tie together features like this. Thanks for the fix n' everything, Quas. :P

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0