ExtraData sectors - Doomworld Forums

Doomworld Forums : Powered by vBulletin version 2.2.5

Doomworld Forums > Special Interest > Eternity > ExtraData sectors

Author

All times are GMT. The time now is 09:10.

printz
CRAZY DUMB ZEALOT

Posts: 8151
Registered: 06-06

I saw in the source code that you added ExtraData support for sectors. Their section looks extraordinarily thick compared to their linedef and mapthing counterparts, which is good:

code:
// sector fields:
#define FIELD_SECTOR_NUM            "recordnum"
#define FIELD_SECTOR_SPECIAL        "special"
#define FIELD_SECTOR_TAG            "tag"
#define FIELD_SECTOR_FLAGS          "flags"
#define FIELD_SECTOR_DAMAGE         "damage"
#define FIELD_SECTOR_DAMAGEMASK     "damagemask"
#define FIELD_SECTOR_DAMAGEMOD      "damagemod"
#define FIELD_SECTOR_DAMAGEFLAGS    "damageflags"
#define FIELD_SECTOR_FLOORTERRAIN   "floorterrain"
#define FIELD_SECTOR_FLOORANGLE     "floorangle"
#define FIELD_SECTOR_FLOOROFFSETX   "flooroffsetx"
#define FIELD_SECTOR_FLOOROFFSETY   "flooroffsety"
#define FIELD_SECTOR_CEILINGTERRAIN "ceilingterrain"
#define FIELD_SECTOR_CEILINGANGLE   "ceilingangle"
#define FIELD_SECTOR_CEILINGOFFSETX "ceilingoffsetx"
#define FIELD_SECTOR_CEILINGOFFSETY "ceilingoffsety"
#define FIELD_SECTOR_TOPMAP         "colormaptop"
#define FIELD_SECTOR_MIDMAP         "colormapmid"
#define FIELD_SECTOR_BOTTOMMAP      "colormapbottom"

I'm wondering how you set up in the map that a sector is defined by its ExtraData record. What setting do you give a sector to tell the map that it's an Extradata sector?

Also, interestingly, the light level and floor/ceiling heights are missing here, but not the tag and special (well, now I'm guessing why). I'm gonna ask for some specs on some of these properties:
- Does the special field use keywords? There are all those generalized Boom specials with huge numbers.
- flags. What flags, exactly? :)
- Do damage and damagemask work the same as EDF thingtype's topdamage counterparts, except that these DON'T hurt monsters (IMO neither topdamage should, it debalances gameplay)? What about radiation suit level of protection?
- damagemod. It sets up the death obituary? Does it use its own keywords?
- damageflags. Another newie.
- floorterrain. I guess that it uses a terrain type mnemonic, correct?
- floorangle, flooroffsetx, flooroffsety (and ceiling* counterparts). Great. Doom always needed these. I'm not being sarcastic.
- ceilingterrain. Huh? Perhaps the terraintype EDF type has been expanded as well with stuff that would make this worthy.
- colormap*. Do I use a lump name, which by itself has to be located between C_START and C_END in order to work, or do I have to use EDF to declare a mnemonic?

I saw further in the code some "@" keywords as well.

__________________
Available for download: Automatic Wolfen s tein - Wolfenstein 3D bot
MBF configuration for WHackEd2

Last edited by printz on 02-05-10 at 12:39

02-05-10 12:33 #

Profile || Blog || PM || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

Quasar
Moderator

Posts: 5158
Registered: 08-00

You can't yet because it's not finished -_- I've been heavily indecisive about how ExtraData could attach the properties to the sectors in question, as sectors don't have a good field to use like linedefs did. Also with UDMF right around the corner, this is a lot less important than it used to be.

02-05-10 20:15 #

Profile || Blog || PM || Email || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

esselfortium
Cumulonimbus Antagonistic Posting

Posts: 5978
Registered: 01-02

Could it be implemented as a new sector special, assuming there are still some free? Then the sector tag could be the extradata entry number, and the actual tag if needed could be specified in extradata. A bit icky, but no moreso than what's already done for extradata linedefs, and it'd allow these features to finally be exposed for use.

Alternately, I suppose it could be done like attached surfaces or portal linetype 385, where a tagged linedef's front side points to the sector to be affected. That way, the sector's tag and everything could still be set directly in the sector.

__________________
essel.spork-chan.net - doom stuff, artwork, and music by esselfortium

02-05-10 20:18 #

Profile || Blog || PM || Email || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

printz
CRAZY DUMB ZEALOT

Posts: 8151
Registered: 06-06

Well, it's OK by me if there's little priority for it, though it won't be bad if this same form will be used for sectors in UDMF. My particular worry is that it may dissociate the terrain types from their designated flats, or that the author may have to manually set them for every liquid floor, unless it defaults. Maybe it'll have to be streamlined when ported to UDMF.

02-05-10 20:35 #

Profile || Blog || PM || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

esselfortium
Cumulonimbus Antagonistic Posting

Posts: 5978
Registered: 01-02

If terrain types are set on a flat, they'll still always work on that flat by default. Setting them per-sector like this is just an optional override for greater control if it's needed.

__________________
essel.spork-chan.net - doom stuff, artwork, and music by esselfortium

02-05-10 21:02 #

Profile || Blog || PM || Email || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

Gez
Why don't I have a custom title by now?!

Posts: 9160
Registered: 07-07

Quasar said:
Also with UDMF right around the corner, this is a lot less important than it used to be.

Exactly. The whole ExtraData business makes sense if you want to remain within the limits of the binary map formats; but everything that could be typed in an external supplementary text lump can be put directly within the normal text lump instead.

Speaking of this, is linetype 270 going to be invalidated in UDMF-Eternity; just like linetype 121 is invalidated in UDMF-ZDoom?

Or kept just in case people write a map converter for Eternity and they don't make it able to parse EMAPINFO and ExtraData lumps to properly translate 270 into whatever it really is?

esselfortium said:
Alternately, I suppose it could be done like attached surfaces or portal linetype 385, where a tagged linedef's front side points to the sector to be affected. That way, the sector's tag and everything could still be set directly in the sector.

That would probably be better. Cleaner at least.

02-05-10 21:06 #

Profile || Blog || PM || Search || Add Buddy

IP || Edit/Delete || Quote

Quasar
Moderator

Posts: 5158
Registered: 08-00

Gez said:

Exactly. The whole ExtraData business makes sense if you want to remain within the limits of the binary map formats; but everything that could be typed in an external supplementary text lump can be put directly within the normal text lump instead.

Speaking of this, is linetype 270 going to be invalidated in UDMF-Eternity; just like linetype 121 is invalidated in UDMF-ZDoom?

Or kept just in case people write a map converter for Eternity and they don't make it able to parse EMAPINFO and ExtraData lumps to properly translate 270 into whatever it really is?

That would probably be better. Cleaner at least.

Eternity will not support a hybrid namespace under UDMF; that is, there not be a UDMF-Doom-EE namespace. Instead the UDMF Eternity namespace will be as compatible to the ZDoom/Hexen spec as is possible, with Eternity additions hopefully placed in an area where they will not cause conflicts during future development (Graf and I have talked in the past about making this happen and for my part, I am committed to it).

I will be coding a utility that will take an existing EE-Doom + ExtraData map and will spit out the corresponding map in pure UDMF format. What this means for line type 270 is that no analog of it will exist in that namespace, unless some purpose is found for ExtraData within the scope of UDMF - for example it could contain some types of data that UDMF cannot specify - but this would be disadvantageous at best, since UDMF was designed to largely negate the need for ExtraData.

The utility is a given because it is already needed by essel's vaporware project, which plans to convert all of its maps over to UDMF as soon as EE supports it.

02-05-10 23:53 #

Profile || Blog || PM || Email || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

Graf Zahl
Why don't I have a custom title by now?!

Posts: 7451
Registered: 01-03

Quasar said:

(Graf and I have talked in the past about making this happen and for my part, I am committed to it).

Me, too.

Seeing printz's list I noticed one potential problem situation and that's the colormaps. I can remember that their use was different in old Eternity version as opposed to Boom. (I noticed this discrepancy way back when DSV4 was released.) In Boom they affect the entire view based on the viewpoint's sector and in the old Eternity version it only affected the sector it was placed in. Is that still the case?

Oh, and btw, terrain per sector is a neat idea. I think I'll implement this in ZDoom, too. ;) But what does 'ceilingterrain' do?

02-06-10 08:19 #

Profile || Blog || PM || Email || Search || Add Buddy

IP || Edit/Delete || Quote

printz
CRAZY DUMB ZEALOT

Posts: 8151
Registered: 06-06

Why exactly go for ZDoom compatibility (regarding UDMF fields)? They're different ports, with slightly different aims. The most likely reason I can think of is if a player can't run a port on their system, but can do another.

02-06-10 12:38 #

Profile || Blog || PM || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

Gez
Why don't I have a custom title by now?!

Posts: 9160
Registered: 07-07

printz said:
Why exactly go for ZDoom compatibility (regarding UDMF fields)? They're different ports, with slightly different aims.

See "slightly".

The more compatible they are, the more common features they have, the highest the appeal for making multi-port map sets. "Boom-compatible" is still a bit limited; and since both Eternity and the ZDoom family are the ports that are interested in bringing new features, it would make sense that when possible, they do so in a non-conflicting way.

Note that Vavoom is ZDoom/GZDoom compatible as well. (Mostly. Don't expect post-ZDoom-2.2.0 features in it.) So that's three ports that could have something in common.

I've been able to play this, Ogro Power Facility and De Kerker in GZDoom thanks to xlat (and some DECORATE work for De Kerker). It would be nice to slap an EMAPINFO and EDF lump addon in kdizd.pk3 and play it in Eternity some day. ;)

02-06-10 13:02 #

Profile || Blog || PM || Search || Add Buddy

IP || Edit/Delete || Quote

Graf Zahl
Why don't I have a custom title by now?!

Posts: 7451
Registered: 01-03

printz said:
Why exactly go for ZDoom compatibility (regarding UDMF fields)? They're different ports, with slightly different aims. The most likely reason I can think of is if a player can't run a port on their system, but can do another.

That's incredibly shortsighted. In general I think that if 2 ports implement the same feature they should at least try to keep it compatible.

If you have followed my work on ZDoom you might have noticed a certain pattern that I tended to add alternative definition methods for existing features from other ports (like Vavoom's slope definition stuff, Eternity's linked sectors (a.k.a. attached surfaces.) and the portal linedef definitions. The question is, why not? All the underlying logic was already there in all these cases so all that needed to be done was exposing it in a way that's compatible to these other ports.

Same when I implemented 3DMIDTEX. Why do it differently? It was easy enough to keep the feature fully compatible and yet do some expanding by making use of Hexen format's linedef args.

02-06-10 13:38 #

Profile || Blog || PM || Email || Search || Add Buddy

IP || Edit/Delete || Quote

printz
CRAZY DUMB ZEALOT

Posts: 8151
Registered: 06-06

Your arguments made it clear why, now. I was worried that this criterion would go too far, slowing down the adding of port-unique content, but the teams are already working on revolutionary stuff (DoomScript I think I read there, and linked portals here).

02-06-10 15:55 #

Profile || Blog || PM || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

Quasar
Moderator

Posts: 5158
Registered: 08-00

Graf Zahl said:
Oh, and btw, terrain per sector is a neat idea. I think I'll implement this in ZDoom, too. ;) But what does 'ceilingterrain' do?

EE's terrain types affect the ceiling as well as the floor, however the only feature that currently responds to the terrain type of the ceiling are particle bullet puffs, which change to the terrain-specified colors and change their motion to more closely resemble a fluid impact than a puff of smoke.

printz said:
Your arguments made it clear why, now. I was worried that this criterion would go too far, slowing down the adding of port-unique content, but the teams are already working on revolutionary stuff (DoomScript I think I read there, and linked portals here).

It's more the idea that editing for the two ports can have knowledge which is directly transferable, rather than the idea that EE is someday going to be able to load and play ZDoom maps - aside from ones that stick strictly to Hexen features, it's unlikely that'll happen, and thus it's not my real goal here.

02-06-10 18:07 #

Profile || Blog || PM || Email || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

All times are GMT. The time now is 09:10.

Doomworld Forums > Special Interest > Eternity > ExtraData sectors

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 >