Cacodemon
Register | User Profile | Member List | F.A.Q | Privacy Policy | New Blog | Search Forums | Forums Home
Doomworld Forums : Powered by vBulletin version 2.2.5 Doomworld Forums > Special Interest > Eternity > [Bug] ExtraData doesn't work w/Parameterized Linedefs
 
Author
All times are GMT. The time now is 17:39. Post New Thread    Post A Reply
Xaser
Forum Staple


Posts: 2140
Registered: 07-03
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.
Old Post 01-23-12 07:25 #
Xaser is offline Profile || Blog || PM || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
Quasar
Moderator


Posts: 5240
Registered: 08-00
Will need the test wad.
Old Post 01-23-12 20:28 #
Quasar is offline Profile || Blog || PM || Email || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
Xaser
Forum Staple


Posts: 2140
Registered: 07-03
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.
Old Post 01-24-12 04:17 #
Xaser is offline Profile || Blog || PM || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
Quasar
Moderator


Posts: 5240
Registered: 08-00
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.
Old Post 01-31-12 00:05 #
Quasar is offline Profile || Blog || PM || Email || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
Mordeth
Administrator


Posts: 1937
Registered: 05-00
Speaking of new builds... where can you get them from these days? It seems the drdteam build site stopped updating a few months ago.
Old Post 01-31-12 18:50 #
Mordeth is offline Profile || Blog || PM || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
Gez
Why don't I have a custom title by now?!


Posts: 9283
Registered: 07-07
New build uploaded.
Old Post 01-31-12 20:22 #
Gez is offline Profile || Blog || PM || Search || Add Buddy IP || Edit/Delete || Quote
entryway
Forum Staple


Posts: 2675
Registered: 01-04
Gez said:
New build uploaded.

Slade_ME!!1
Old Post 02-01-12 04:13 #
entryway is online now Profile || Blog || PM || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
Quasar
Moderator


Posts: 5240
Registered: 08-00
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.
Old Post 02-01-12 04:14 #
Quasar is offline Profile || Blog || PM || Email || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
Xaser
Forum Staple


Posts: 2140
Registered: 07-03
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. :(
Old Post 02-15-12 04:38 #
Xaser is offline Profile || Blog || PM || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
Quasar
Moderator


Posts: 5240
Registered: 08-00
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.
Old Post 02-15-12 12:16 #
Quasar is offline Profile || Blog || PM || Email || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
Gez
Why don't I have a custom title by now?!


Posts: 9283
Registered: 07-07
Plus, the whole thing won't be needed once there is UDMF in Eternity, as the Hacx project will then be able to convert.
Old Post 02-15-12 12:33 #
Gez is offline Profile || Blog || PM || Search || Add Buddy IP || Edit/Delete || Quote
printz
CRAZY DUMB ZEALOT


Posts: 8193
Registered: 06-06
So, what needs to be finished first before UDMF is implemented in Eternity, the port of the same author?
Old Post 02-15-12 13:00 #
printz is offline Profile || Blog || PM || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
Quasar
Moderator


Posts: 5240
Registered: 08-00
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.
Old Post 02-15-12 17:27 #
Quasar is offline Profile || Blog || PM || Email || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
printz
CRAZY DUMB ZEALOT


Posts: 8193
Registered: 06-06
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?
Old Post 02-15-12 19:18 #
printz is offline Profile || Blog || PM || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
Gez
Why don't I have a custom title by now?!


Posts: 9283
Registered: 07-07
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.
Old Post 02-15-12 20:10 #
Gez is offline Profile || Blog || PM || Search || Add Buddy IP || Edit/Delete || Quote
Quasar
Moderator


Posts: 5240
Registered: 08-00
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.
Old Post 02-16-12 02:27 #
Quasar is offline Profile || Blog || PM || Email || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
Xaser
Forum Staple


Posts: 2140
Registered: 07-03
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

Last edited by Xaser on 02-18-12 at 20:43
Old Post 02-18-12 20:06 #
Xaser is offline Profile || Blog || PM || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
All times are GMT. The time now is 17:39. Post New Thread    Post A Reply
 
Doomworld Forums : Powered by vBulletin version 2.2.5 Doomworld Forums > Special Interest > Eternity > [Bug] ExtraData doesn't work w/Parameterized Linedefs

Show Printable Version | Email this Page | Subscribe to this Thread

 

Forum Rules:
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts 		HTML code is OFF
vB code is ON
Smilies are OFF
[IMG] code is ON
 

< Contact Us - Doomworld >

Powered by: vBulletin Version 2.2.5
Copyright ©2000, 2001, Jelsoft Enterprises Limited.

Message Board Statistics