New Entity Idea
Some_tall_guy1
Join Date: 2003-05-22 Member: 16601Members
Join Date: 2003-05-22 Member: 16601Members
<div class="IPBDescription">may releive some level over level issues</div> So here I am working on my hiveroom for my map when I realize that this small elevated walkway is going to cause some problems for the commander, as there isn't much room on the sides of it for the comm to peek around to see beneath it.
I came up with the idea of adding an entity that would allow the commander to build on an object as usual, while being able to build underneath AND see whats happening down there too. You have it so if the comm were to simply double-click on it as if it were a button, it would stop drawing for the commander and allow him to see and build underneath it. There will be an icon that would tell the commander he can do this to a certain object, which would also help him find the object for when hes looking to turn it back on (double clicking on the invisible object). As for structures/players already on the object while its invisible, keep drawing them but have buildings and supplies pass down through them to the floor beneath.
I came up with the idea of adding an entity that would allow the commander to build on an object as usual, while being able to build underneath AND see whats happening down there too. You have it so if the comm were to simply double-click on it as if it were a button, it would stop drawing for the commander and allow him to see and build underneath it. There will be an icon that would tell the commander he can do this to a certain object, which would also help him find the object for when hes looking to turn it back on (double clicking on the invisible object). As for structures/players already on the object while its invisible, keep drawing them but have buildings and supplies pass down through them to the floor beneath.
Comments
Then you wouldn't need double-click, which may be harder for Flayra to detect, and you would never have to click on the bridge (to toggle it) so you wouldn't be toggling bridges when dropping several structures fast with keyboard fast keys.
Sounds like a nice idea STG. Could work well in many of the released levels too.
-Tom
-Tom
<!--QuoteBegin--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> </td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->Or perhaps point entities that specify the z level at a particular location and the current commander height interpolates between them. Then the mapper gets to choose an approriate height and the command view goes up and down automatically (easier for commander).<!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd--> That totally defeats the purpose of my idea, the idea is to help lesson the constraints of the level over level dilema, what this suggests doesn't help much even though it is a good idea.
When you answer an alert ("medpack please") then the commander will jump to the lowest level that is still above the marine or structure that called the alert. Then it is up to the mapper to again place the levels at approriate heights for their map.
Then of course we need 3d info_location entities, and we might be able to get level over level play.
-Tom
It also allows the commander to comm without even having to think about cruising height.
Damn we are good STG. Wonder what Flayra will think.
-Tom
The top level could be the "fixed height" like now, and lower levels "swoop" with the terrain, which would be neat. The bottom levels would only go down when there was a vent or tunnel or bridge, and so most of the time they would be at the same height as the upper levels.
All the commander has to think about is "I'm too low, press pgup" or "I need to see under this bridge, press pgdn". As most commanders spend their paniced time bouncing between alerts, which automattically set their height, they would be fine.
-Tom
Otherwise the commander could end up going through the floor and get stuck with a huge HOM.
-Tom
Commander View Changes Height, Mappers able to specify multiple levels
-Tom
-Tom <!--QuoteEnd--> </td></tr></table><span class='postcolor'> <!--QuoteEEnd-->
Not possible. Commanders can't see HOMs unless a mapper specifies it. NS places a black background under the level so that you wont notice the HOM. There is a special ent that has a setting where you can turn this effect off (useful if you found a more efficient way to stop the commander from seeing HOMs).
There are other good reasons you might not want the commander going though the floor, like if they didn't realise why now all they can see is the black background. I can imagine cases where existing maps where the background is disabled getting broken by some commander using this new command and then scrolling sideways out of one room and underneath another.
Some computers crash when they get a large hom.
-Tom
Having zoom being manual would be good, something that I have always wanted. But rarely used in the heat of battle when it causes you to have to scroll up again to follow a marine up a ramp. Something that the commander doesn't have to think about is good. We have way more time to get these entities placed right during map development than a commander who has to get their height correct during the heat of battle.
Once we have this sort of thing working, we can have vents far above and below the level. We can have level-over level play (limited, to keep things simple of course). We could allow the commander to build in weird places in vents and on top of bridges (or under them) where only aliens can build now, because the commander can't see there.
I think that a manual system would be too hard for the commander to control where an automatic (but level based system) would be much easier for us to make fullproof and bulletproof. Would be a pity to be forced to turn on that black background for every map where an alternative allows us to have total control over the commander's movement.
The best part, is that at the end of the day it is the mapper's choice whether to include it, and it would need very little work on the commander's part to make use of it.
-Tom
<!--QuoteBegin--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> </td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->IANAM. I am not a mapper, but I like to think I picked some stuff up.
Regarding multiple-floor maps:
First, remember that the commander is actually (so to speak) flying around when he's commanding. An old bug allowing you to shoot your HMG through ceilings from the commander view makes this quite plausible.
Anyway, if you were looking at a lower level, the thickness of the ceilings/floors would need to be quite extreme to provide the commander their usual field of view without running risks of buggy behavior as the commander's location intersects actual play area.
I was also under the impression that the top-down view was possible because ceilings were (so to speak) textured only on the bottom side. How exactly will a commander manage to see only through the very first thickness unless, again, you have very thick partitions between floors? (So that the 'floor' surface can be opaque, and the ceilings can be transparent, and the commander can fit between)
And as far as I know It's not trivial to simply change the texturing of a whole floor of map to invisible from visible and also having it be a special case for the commander.
One could 'fake it' with some teleporting zones that try to make the transition seamless, but it would cause weird issues where hivesight, motion tracking, and siege range would all still work as a flat model, seriously disrupting the mood.<!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
Don't forget that the commander spends the majority of his time outside the map (ie directly above it, but he's still out there in the middle of the void). When you are out in the void, you aren't in any of the vis leafs, and so the HL engine doesn't know what you can and can't see. Instead of deciding that you can't see any leafs and therefore deciding to draw none of them (and making commanding impossible), it plays it safe and decides to draw ALL of them. The only thing saving the commander from r_speeds into the high 5000's is that he stays fairly close to the map, and anything outside his FOV won't get drawn (ie stuff that isn't on your screen).
This unfortunately means that in any "level over level" sections of your map, all of these sections would be drawn when you are looking at the highest level. You can see this effect in action when playing nomblizkikko (I don't know if the latest version has fixed this yet). The ready room is under the big pit in the middle. So when the commander looks at the closed double doors, the engine is still drawing the pit, the spikes, the water, the ready room, and all the players inside the ready room, giving you r_speeds well over 1000. If the ready room was placed above the commander's height (like the guidelines mention), it would never get drawn, saving the commander from those high r_speeds.
If you think that if now a big corridor might have 400 polys visible, and from above the commander can see 700 (because he can see around more corners etc), then when you have 2 of these corridors going one over the other. Then marine r_speeds stay at 400 because VIS works correctly for them, but the commander suddenly jumps up to around 1400, because the game assumes both rooms are visible to him.
Considering this is effect is outlined in the mapping guidelines originally written by Flayra and currently maintained by Cagey himself, I don't think you need to be so quick to disbelieve me.
However, if the commander height was set so that he was below the ceiling of the upper room, he would be in the upper room's vis leaves and thus would only render that room. In order to maintain the right commander height, the mapper could make the room tall enough to fit the commander inside, and then make a fake ceiling that only the marines would render ( a func_wall ).
Then you can have low ceilings for marines and high ceiling so that the commander can fit inside. As long as the commander is in the room, her computer only renders that room, like a skulk sitting on the ceiling.
By having the commander enter the rooms into which he is observing, the game can reduce r_speeds from phenomina like you described. Because the commander can 'change levels' we don't have to have a single height that takes in the whole map, but several heights each of which takes in part. Thus we save all around by always keeping the commander inside rooms.
I think this would just mean that we would need more careful mapping. Remember that this is all optional, and less advanced mappers can stick with the fixed height stuff.
Another option is to create a "room" that connects together all the rooms the commander can see into so that the commander is never in the void, only in a commander box. You would have several such boxes, for the several levels that the commander could occupy. You could put other useful things in these boxes, like commander only switches and labels for rooms.
To have a roof that the commander could see through (out of the box) you just make the backfaces of the roof textured skip. (I think this would work)
-Tom
I was being sarchastic in saying "r_speeds what are they?". Thought you might of noticed as afterwards as I mentioned them.
too busy getting defensive to notice the humour <!--emo&???--><img src='http://www.unknownworlds.com/forums/html/emoticons/confused.gif' border='0' style='vertical-align:middle' alt='confused.gif'><!--endemo-->
Sorry mate
There. problem solved.
Or maybe not.
Honestly, it would be easier to tell which plan is better after they are impliemented. As I see it, zooming is nice, but especially nice if it is automatic. Perhaps the game could remember in which areas you have zoomed in and remember that when you jump back to that area. This could be kept clientside so that it varies for each commander.
Or perhaps simple is best.
-Parallax.
<!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
Indeed, this is why level over level is not supported for standard NS.
Max