Dev Question
moultano
Creator of ns_shiva. Join Date: 2002-12-14 Member: 10806Members, NS1 Playtester, Contributor, Constellation, NS2 Playtester, Squad Five Blue, Reinforced - Shadow, WC 2013 - Gold, NS2 Community Developer, Pistachionauts
Creator of ns_shiva. Join Date: 2002-12-14 Member: 10806Members, NS1 Playtester, Contributor, Constellation, NS2 Playtester, Squad Five Blue, Reinforced - Shadow, WC 2013 - Gold, NS2 Community Developer, Pistachionauts
<div class="IPBDescription">"Sarts built" flag, restower placement</div> The "starts built" flag on the team_command entity doesn't appear to affect anything currently. Are there plans to implement this in the future? I had hoped to make use of it for an auxiliary command station in ns_shiva. It probably won't be a big problem for balance if infantry portals can be built in the area around the auxiliary, but my preference would be for the marines to have to activate the command station first.
I was also intending on having a section of the map that would contain a double node where one of the two needs to be welded open. From what I can tell however, I think the code for placing resource nozzles checks the current location of the commander's pointer for placement validity rather than the resource node itself where the tower will end up appearing. What this means is if I block off the resource node with a func_door, they cannot place the resource node by putting their pointer directly over it, but they can if they put it off to the side where it isn't blocked and allow the structure to "snap to" the node. This also appears to affect gorges building, although they may just be able to build on it regardless. I haven't verified that behavior. I was wondering if this behavior could be changed/fixed in a future version. It would make my life a lot easier, and I think it makes more sense from a consistency standpoint.
I PMed this to Flayra, does anyone have any further information, or any more detailed knowledge of the the behavior of these entities?
I was also intending on having a section of the map that would contain a double node where one of the two needs to be welded open. From what I can tell however, I think the code for placing resource nozzles checks the current location of the commander's pointer for placement validity rather than the resource node itself where the tower will end up appearing. What this means is if I block off the resource node with a func_door, they cannot place the resource node by putting their pointer directly over it, but they can if they put it off to the side where it isn't blocked and allow the structure to "snap to" the node. This also appears to affect gorges building, although they may just be able to build on it regardless. I haven't verified that behavior. I was wondering if this behavior could be changed/fixed in a future version. It would make my life a lot easier, and I think it makes more sense from a consistency standpoint.
I PMed this to Flayra, does anyone have any further information, or any more detailed knowledge of the the behavior of these entities?
Comments
I've tried that with the nobuild texture and with killing a func_nobuild entity. I'm not even sure that the second approach worked at all, but they were both subject to the same problem. The commander could get around it just by aiming a ways off of the node and letting the tower snap to it.
As for the CC. I remember when I was playing a game of 2.0 and we decided to load up one of my maps and when the map started the CC was not built. So I guess it is something they have recently fixed.
mabye its on by default? And as for the snapping to the res point thing, place a func no build entity right ontop of the nozzle, and make it so when the door opens, the entity slieds away.
Have you found a way to get that to work?
Well, you have the func nobuild that is 1 unit high, and sits inside the nozzle so the comm cant see the brush. Then im pretty sure you'd do something with the Master/Name settings in a func door and somehow link it to the nobuild...
Try covering the node with a NULL texture func_water brush that moves into the floor when the weld is complete to see if that stops the commander from placing the node.
I realize that I'm suggesting hackish workarounds when there should be an elegant solution, and I've added feature requests to the bug DB for both your problems (<a href='http://www.natural-selection.org/bt/bug_view_advanced_page.php?bug_id=0000688' target='_blank'>#688</a>, <a href='http://www.natural-selection.org/bt/bug_view_advanced_page.php?bug_id=0000689' target='_blank'>#689</a>). I'm honestly not sure when Flay's going to let me enhance mapping code -- we're in a bugfix and balance only lockdown at the moment until 3.0 is released. I'd have created that env_model entity people are asking for otherwise.
We love you! <!--emo&:D--><img src='http://www.unknownworlds.com/forums/html//emoticons/biggrin.gif' border='0' style='vertical-align:middle' alt='biggrin.gif' /><!--endemo-->
Is this something that's definately going to be fixed/changed for whatever comes after 3.0? (are there going to be more updates to ns after 3.0?)
What's the use of that entity? Is that only for bringing model to map? I use env_sprite, it can load models too <!--emo&:p--><img src='http://www.unknownworlds.com/forums/html//emoticons/tounge.gif' border='0' style='vertical-align:middle' alt='tounge.gif' /><!--endemo--> (it can crash VHE if you havent edited ns.fgd(should it be actually gdf?))
I have myself made fgd fix to correct this:
What's the use of that entity? Is that only for bringing model to map? I use env_sprite, it can load models too <!--emo&:p--><img src='http://www.unknownworlds.com/forums/html//emoticons/tounge.gif' border='0' style='vertical-align:middle' alt='tounge.gif' /><!--endemo--> (it can crash VHE if you havent edited ns.fgd(should it be actually gdf?))
I have myself made fgd fix to correct this: <!--QuoteEnd--> </td></tr></table><div class='postcolor'> <!--QuoteEEnd-->
The env_model entity would add a model client-side, so that means it would not add to the max entity usage. Also, since it is client side, it would not be solid, so you'd have to encase it in clip brushes if you want it solid (currently cycler makes the models solid automatically).
What's the use of that entity? Is that only for bringing model to map? I use env_sprite, it can load models too <!--emo&:p--><img src='http://www.unknownworlds.com/forums/html//emoticons/tounge.gif' border='0' style='vertical-align:middle' alt='tounge.gif' /><!--endemo--> (it can crash VHE if you havent edited ns.fgd(should it be actually gdf?))
I have myself made fgd fix to correct this: <!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd-->
The env_model entity would add a model client-side, so that means it would not add to the max entity usage. Also, since it is client side, it would not be solid, so you'd have to encase it in clip brushes if you want it solid (currently cycler makes the models solid automatically). <!--QuoteEnd--> </td></tr></table><div class='postcolor'> <!--QuoteEEnd-->
In addition to features like making it optionally invisible to the commander/ visible only to the commander, optionally not drop to the ground, optionally use a custom light value instead of the one on the floor, etc.
env_sprite is pretty limited.