Entity Changes to Make a Mapper's Life Easier

moultanomoultano 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">If these features will even be in ns2 that is</div>I wrote this a while back about potential entity changes for ns:source, and now that you guys are doing a full fledged new game some of this might no longer be applicable, but I thought I'd post it again in case some of the features of ns2 will be similar.

I thought I’d throw in my two cents on <i>existing</i> entities that if they will appear in ns2, could be slightly reworked to make things easier for mappers. Once people start making maps it's too late, so I want to get this out there now.

<b>Weldables shouldn’t collide with players. They would be easier to use just as brush based triggers.</b>
Right now the func_weldable has a physical presence. Players collide with them. The original intent of the func_weldable was for it to be the actual physical obstruction to the vent, and welding it would either make it appear or disappear. However, the pause that players experienced when crossing weldables in early versions, and the lack of realism in a wall appearing out of thin air led map designers to use the func_weldable for no more than its triggering abilities. Most mappers hack around it to make the func_weldable invisible, and just have it trigger the desired effect. Given that the range of special effects possible in Source is well beyond what Half-Life can deliver, I doubt we will see any mappers using the func_weldable for its appearing/disappearing properties. In NS2, I suggest making the brush associated with a func_weldable solely define the area you have to point at to weld, and not have any collision detection or other things associated with it. The effects can be done much more effectively with triggered entities than by any default behavior you would pick to assign to the func_weldable, and this would only require a small update for those maps that do use the original functionality.

<b>Func_nobuilds shouldn’t collide with players. Just make them define the area of effect.</b>
Right now this entity is solid. At the moment it is a bit of a pain to use, and it It will be even more of a pain if maps in NS:Source attempt to portray a wider variety of environments. Imagine that you are making a small outdoor area in your map. Players can get there, but the commander shouldn't be able to build there (according to backstory) because the nanogrid doesn't extend beyond the base. In order to accomplish this, you would have to make a thin sliver of func_nobuild over every brush in the area. It should be easy to see why this is a pain. The easiest way is just to copy all the geometry, and move it vertically by one unit, then texture it all with null. Then if you want to change anything about the area, you have to redo this. I propose making the func_nobuild simply define an area in which buildings cannot be placed, rather than colliding with anything. For instance, to prevent building in a section of the map, you would just enclose the entire area in a single brush marked with the entity. There are also a lot of other reasons for wanting to designate areas as unbuildable other than compliance with the backstory. Elevators, irregular geometry, and all sorts of other factors make it desirable to restrict where the commander can build. (Afterall, most commanders would be much happier having a structure refuse to be placed on a spot, then to place it and have it sink under the map.) If we could simply enclose areas in a func_nobuild and still allow players through, it would make our lives much easier.

<b>Give us direct control over command chairs, res nodes, and possibly other structures pre-placed in the map.</b>
Mappers like to play with the game mechanics a bit to mix things up, and right now they have to go through all sorts of nasty hacks to disable a resource node (for instance,) and the result ends up being less intuitive for the players. Give every placeable structure a setting in which they would start out as a lump of coal (effectively) until triggered. This would make it a lot easier to incorporate the TSA technology into the maps, and ultimately make for a more cohesive and atmospheric experience.

<b>Make the seethrough texture actually seethrough for the commander.</b>
Quite frankly, I’ve never found a good use for the seethrough texture on anything, because the commanders can’t see through it. It just allows structures to be placed through it. Make it invisible like the null texture by default and you’ll have a real winner.

Much <!--coloro:red--><span style="color:red"><!--/coloro--><b><3</b><!--colorc--></span><!--/colorc--> to the devs for all their hard work, and for giving us mappers an outlet for all of our creativity, freetime, sweat, blood, and tears, and an occasional replacement for our social lives. <img src="style_emoticons/<#EMO_DIR#>/smile-fix.gif" style="vertical-align:middle" emoid=":)" border="0" alt="smile-fix.gif" /> I hope this is helpful.

Comments

  • HyperionHyperion Hyperion2010 Join Date: 2003-10-06 Member: 21477Members
    Dont forget that we can be given new clip textures such as "clip_skulk" with the new materials system <img src="style_emoticons/<#EMO_DIR#>/wink-fix.gif" style="vertical-align:middle" emoid=";)" border="0" alt="wink-fix.gif" /> And func_comm, like func_detail except that it wont render for the commander (may not be needed depending on how things are ultimately implemented).
Sign In or Register to comment.