/*
	
	Tricks of the trade -- compiled by ChebMaster so that more people could create skyboxes as awesome as I made for chebskies-EDAY
	
	(also see _wiki_is_a_crapshot.txt)
	
	First and foremost, we are talking Zandronum. Forget GZDoom. GZDoom seems advanced but its multiplayer model is hopelesly outdated, with its need for all players to gather and connect beforehand and the session falling apart if it desyncs.
	
	Zandronum is Skulltag. Zandronum does real client-server multiplayer where new players can join mid-game as they see fit. Chebskies-EDAY supports up to 8 coop players (which is a terminal overkill: such a crowd of respawning immortal yahoos flattens everything like a stampede of bulls in a china shop). Zandronum itself supports up to *64* players - say, on a deathmatch server.
	
	Zo what could Zandronum *do* ?
	
	Use UDMF. There is no reason not to. I have converted *all* the EDAY maps to this format, eliminates the need for a new TEXTURES entry every time you need to use a scaled texture.
	
	Just be aware that Zandronum only supports a *limited* set of UDMF features. Some things the editor (Ultimate Doom Builder, no real alternatives) tells you are possible are really not.
	
	Sector light color and fog color? Yes. Textures scaling? Yes.
	
	Multiple tags per sector ? No. Use extra tags and extra driving linedefs where two skybridges cross. Setting slope directly ? No. Use the old tricks with set slope ceiling, set slope floor, transfer slope and that vertex height setting thingy, forgot its doomed number.
	
	(also be aware that Zandronum considers some ACS functions like SetFogDensity() to be designed to setup the map at the map start - so it executes them exactly one time per map, ignores the consecutive calls and ignores the sector tag passed to this function, setting the fog really for the entire map)
	
	
	A VERY IMPORTANT LIMITATION not documented and not mentioned anywhere: you have a very limited canvas. The editor shows you a canvas that goes from -32768 to 32767 on x and y axes. 
	
	Forget about it. You can *only* use the central square - one fourth of it - to place anything important. You are constrained to the -16384..16383 range. No one would tell you this. You would get no warnings, no error messages - your controlling structures would simply GLITCH due to suffering 16-bit integer overflow somewhere in their calculations under the hood. Portals would flicker unstably or shift by a huge offset showing the other end of the map instead. Torches would ignore the Z you set for them and fall through 3d bridges. Disregard this UNDOCUMENTED rule and you are in a debugging HELL.
	
	Your sky portal areas *can* extend well past this border, *but* their anchor linedefs *have* to fit inside. Yet another mental equilibristics required, what a pain. Open any complex map like eday27 or eday28 and observe how the controlling linedefs are placed.
	
	So, a sky portal. Pretty simple. (I use the term "top layer" instead of "skybox" here because I most often than not layer a real 3d skybox on top of that! Counterintuitively, such multi-layered sandwich runs well on potatoes. FYI, I work and playtest on laptops with especially weak Intel integrated graphics.)
	
	Mind that portals in Zandronum are purely visual. Nothing can pass through them. Zandronum does *not* support real portals -- believe me I tried. No way.
	
	Give all your sectors, which receive the sky portal, a specific tag. Now create the top layer area. Now create a couple controlling linedefs with special 57 Sector Set Portal, set portal type to "Link to portal with the same tag" and Plane to "Ceiling" (unless you are doing something real tricky). Now set Misc to 1 for the linedef of the top layer and to 0 for the linedef in the receiving area.
	
	I, personally, like to use some wall of some building that is present in both layers.
	
		(see _tricks_of_the_trade_pic_01.png)
		
	Now, what about sectors with a *different* tag -- you cannot avoid using such, for 3d floors and other purposes. Of course you need a dummy copy portal linedef for each such tag! Note that secors with a different tag surrounded by the portal sky of the main tag used (say, tag 97) don't need treatment, Zandronum propagates the sky portal across them automatically - I am simply being over-cautious by creating that dummy linedef for them anyway.
	
	It looks weird and counter-intuitive at first until you realize the sky *propagates* from a solid wall that serves as the sky boundary and towards the camera. You will see strips of the wrong sky running from such walls up into infinity if you get things wrong -- and you WILL get them wrong, this stuff is too complex to get right without tons of debugging and playtesting. The pitfall is, *if* both your top layer and your map use the same sky/skybox (most likely), such errors are unnoticeable until they create sky-filled holes in your top layer but THEY ARE MURDER ON THE FRAMERATE. I strongly suggest, for testing purposes, replacing the sky of your top layer with something contrast -- like a bright blue texture -- until you catch all instances of different-tagged secors not being assisted with copy portal, or some tiny sector on the fringe you forgot to set the sky portal tag for, that bringa the framerate to its knees.
	
	Now, create a looong dummy sector somewhere. Create a looong linedef inside it. Assign special 57 Sector Set Portal. Set the tag to the tag of the sector you copy the portal *to*. Set portal type to "Copy portal from the second tag". Set Plane to the same as the main controlling linedefs (99.9% you'll use "Ceiling"). Set Misc to the tag of the main tag of the sky portal you chose before (97, in our case). Now, every time you need to copy that portal to a new sector tag, you just split that linedef and only set Misc of the newly created chunk. Minimum work. (see _tricks_of_the_trade_pic_02.png)
	
	Before you get your hopes up, though, let's talk about aprons. Aprons are SUPER important. You see, the portals sure seem like magic but they *aren't*. The game engine just creates a second camera to render the space beyond the portal, shifted relative to your camera by the amount your top layer is shifted (the distance between the controlling linedefs, really) while the z is always the same. This is fraught with that second camera getting somewhere it was not supposed to go and getting its view obscured with random crap or, worse, falling out into the void, with the entire map potentially visible and MURDERING your framerate. Also, don't forget the fun with recursive portals that can see themselves (hint: framerate dies, then game crashes)
	
	How do you *avoid* that horror? Simple, by using aprons.
	
	(see _tricks_of_the_trade_pic_03.png)
	






*/