EE update: ExtraData sectors

[Quasar]

Support for sector records in ExtraData is currently being implemented. The current set of fields available includes the following:

damageamount
damagemask
damagemod
floorterrain
floorangle
floorxoffset
flooryoffset
ceilingterrain
ceilingangle
ceilingxoffset
ceilingyoffset
colormap_upper
colormap_middle
colormap_lower

So in short, you can specify custom sector damage, override TerrainTypes for the floor and ceiling, control flat alignment and rotation, and specify sector colormaps without creating a 242 transfer (though the upper and lower maps only apply to sectors with a 242 effect). Ideas for other features are invited.

[Mordeth]

Very nice :) Question:

Quasar said:
specify sector colormaps without creating a 242 transfer (though the upper and lower maps only apply to sectors with a 242 effect)

Is the effect of such a (middle) colormap also seen from non-affected sectors?

[esselfortium]

Awesome. Now we just need some way to edit this from inside a map editor...

[Mordeth]

esselfortium said:
Now we just need some way to edit this from inside a map editor...

You want to edit scripts from within a map editor? Sounds like a feature suggestion for certain editor authors, not for James. And doesn't Deepsea already have that?

[andrewj]

I'd like to propose a set of cross-platform linedef types for doing flat alignment.

Perhaps linetypes in the range 800-8xx (which linetypes does EE use?)

There would need to be three groups: Floor, Ceiling and Floor+Ceiling.

The simplest type would set the rotation based on the direction the linedef is facing, at set the xoffset/yoffset based on the first vertex (i.e. the first vertex becomes (0,0) in the flat coordinate space).

Another type would be the same, but the length of the linedef controls scaling of the flat (e.g. 64 would be normal, 32 to shrink, 128 to enlarge).

These linetypes would affect the sector on the front side, and I guess having anothe group for the back side might be handy too (for teleporters).

Combining all these things into a draft list:

[800] align and rotate front sector's FLOOR
[801] align and rotate back sector's FLOOR
[802] align and rotate front sector's CEILING
[803] align and rotate back sector's CEILING
[804] align and rotate front sector's FLOOR+CEILING
[805] align and rotate back sector's FLOOR+CEILING

[810] align, scale and rotate front sector's FLOOR
[811] align, scale and rotate back sector's FLOOR
[812] align, scale and rotate front sector's CEILING
[813] align, scale and rotate back sector's CEILING
[814] align, scale and rotate front sector's FLOOR+CEILING
[815] align, scale and rotate back sector's FLOOR+CEILING

[Quasar]

I take it these would be for DOOM-format maps. The zdoom-Hexen format has a line special that aligns flats to the linedef as well. If you want to implement these, I see no reason not to go along with it :) EE currently defines linedef numbers up to around 378, and then BOOM generalized specials kick in at 8192 (so 8191 is the highest linedef number we can use; I don't anticipate ever going that high though ;)

However, these still may not end up being compatible unless we have implemented flat rotation the same. I have been told that my current implementation rotates them in the opposite direction that zdoom chooses (which is contrary to what I would logically expect given Doom's coordinate system). It's not too late for me to change it, however, since it's still in the process of implementation.

Also we don't currently support flat scaling. I'm not sure how to do it myself, and the code in zdoom looks Build-derived and uses a lot of Silverman's ASM math routines.

[Quasar]

Mordeth said:

Very nice :) Question:


Is the effect of such a (middle) colormap also seen from non-affected sectors?

The combination of the SMMU change to 242 colormap handling and my recent fix to enable all sectors to store and display their own colormaps means that you can indeed see the colormap of any sector whether or not you're inside it.

However, the results are not like you'd expect from volumetric fog; for example if you have a foggy sector and a sector behind it is normal colormap, the sector behind will seem to "show through" the fog. SoM had a radical and interesting solution to this problem but I believe it has been put off indefinitely at this point, especially while he's working on linked portals. In the meantime it is possible to get an effect somewhat approaching this by applying a translucent colored texture to 2S lines on the boundary of the colormapped sectors. Of course translucency doesn't look too fantastic in 8-bit color.

[esselfortium]

Mordeth said:

You want to edit scripts from within a map editor? Sounds like a feature suggestion for certain editor authors, not for James. And doesn't Deepsea already have that?

No, no, I'm not saying Quasar should do this. I'm just saying it's really a shame that editors aren't yet supporting all this stuff he's implementing, which makes it currently rather inconvenient to use.

EDIT: And if DeepSea has it, this is the first I've heard of it. I've used DeepSea a bit in the past, and its interface is so convoluted that I probably missed quite a bit of what it's capable of, just from not being able to find anything. :p

[sargebaldy]

Nice! Keep up the good work.

[Quasar]

esselfortium said:

No, no, I'm not saying Quasar should do this. I'm just saying it's really a shame that editors aren't yet supporting all this stuff he's implementing, which makes it currently rather inconvenient to use.

EDIT: And if DeepSea has it, this is the first I've heard of it. I've used DeepSea a bit in the past, and its interface is so convoluted that I probably missed quite a bit of what it's capable of, just from not being able to find anything. :p

Actually this is a case of miscommunication. You're saying that editors should support ExtraData natively; that is, for example, you would be able to double click a sector and edit its ExtraData fields in the sector properties dialog as though they were a normal part of the binary map format. Which is what we've been talking about in IRC for a year or three now.

What Mordeth seems to think you were asking for is the ability to simply hand-edit ExtraData scripts from within Doom editors, which is a feature some editors already have, and isn't that useful compared to native editing.

The next release of EE will contain some features that will enable easier editor support of native ExtraData (chiefly the ability to have an ExtraData lump immediately following your map, cutting MapInfo out of the equation entirely (except for backwards comp naturally)).

[esselfortium]

Quasar said:

The next release of EE will contain some features that will enable easier editor support of native ExtraData (chiefly the ability to have an ExtraData lump immediately following your map, cutting MapInfo out of the equation entirely (except for backwards comp naturally)).

Excellent. I really hope to see this in Doom Builder and/or Slade someday.

[Mordeth]

Owwww... that IS awesome ;)