UDMF sector sky properties

[Gez]

There were some discussion on that subject recently, so I figured I'd create a thread to keep track of what should be covered by an implementation.

• A [wiki]sky[/wiki] can be a double sky, or an alternate sky in case of [wiki]lightning[/wiki], so there should be properties for both sky1 and sky2.
• Perhaps the sky1 and sky2 properties could be duplicated so as to have separate skies for floors and ceilings.
• A sky can also be a [wiki]skybox[/wiki], so this ought to be able to replace the [wiki=Classes:SkyPicker]SkyPicker[/wiki] thing. Trying to shoehorn skypicker TIDs in a sky texture field would be hacky (what if a sky texture is named simply "1"?) so it may be necessary for robustness to have it as a separate property.

So to recap, we could get something like this:

Code: Select all

ceilingsky1 = "texture name";
ceilingsky2 = "texture name";
ceilingskypicker = <tid>;
floorsky1 = "texturename";
floorsky2 = "texturename";
floorskypicker = <tid>;

Default texture name of an empty string would be to use the sky defined in [wiki]MAPINFO[/wiki] (or through [wiki]Static_Init[/wiki] for this sector). Default tid of 0, likewise (as the skypicker things work).

[Major Cooke]

Agreed. I so need this. Putting things into a sector is good and all, but managing them and finding the things especially if the sector is somewhat large and split up into subsectors can be difficult to find.

[Xaser]

The more we move away from the "place things in a sector" paradigm the better. This suggestion closes one of the biggest gaps, so I'm super-for-it.

[Tormentor667]

The more we move away from the "place things in a sector" paradigm the better.

Absolutely right, I second this

[Major Cooke]

I wonder how hard it would be to make this possible... Hmm, time to investigate my first adventure into UDMF! If someone doesn't beat me to it.

[Graf Zahl]

The biggest fun here will be to manage this in the renderer which (again) suffers from overreliance on global variables for the sky properties.

[Major Cooke]

...Oh. Nevermind then.

[Xaser]

In terms of difficulty, I imagine that we really have two separate things here: adding arbitrary non-skybox skies requires removing some de-hardcoding, but the two skypicker properties ought to be easier since they're already configurable per-sector (in a somewhat roundabout way).

Thinking on it, though, how are Static_Init skies handled? That may be bootstrappable.

I'm educatedly-guessing here, of course.

[Graf Zahl]

Static_Init doesn't do much, it only flags the sector and then lets the renderer pick the sky from the linedef.That code is probably the best guideline to handle per-sector skies.