ZDoom

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.

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.

...Oh. Nevermind then.

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

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. :P

[quote="Xaser"]The more we move away from the "place things in a sector" paradigm the better.[/quote]
Absolutely right, I second this

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.

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.

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

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.

[list][*]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.[/list]

So to recap, we could get something like this:
[code]ceilingsky1 = "texture name";
ceilingsky2 = "texture name";
ceilingskypicker = <tid>;
floorsky1 = "texturename";
floorsky2 = "texturename";
floorskypicker = <tid>;
[/code]
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).