Sign in to follow this  
Followers 0

ExtraData sectors

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:

// 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.

Share this post


Link to post

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.

Share this post


Link to post

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.

Share this post


Link to post

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.

Share this post


Link to post

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.

Share this post


Link to post
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.

Share this post


Link to post
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.

Share this post


Link to post
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?

Share this post


Link to post

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.

Share this post


Link to post
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. ;)

Share this post


Link to post
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.

Share this post


Link to post

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).

Share this post


Link to post
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.

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