After a month of thought, here's my wish list (in addition to fixes mentioned above):
EDIT: telegraphic grammar fix.
<span style='color:white'>Summary:</span><ul> <li>standardized naming conventions (may be too late for this, but it's worth mentioning) <li>target_tooltip <li>target_mdl / trigger_script enhancements <li>appearflags for comm vis, ground vis, team based vis, spec vis, and autohelp sensitive vis <li>enhanced event triggering <li>hook for per-map entity code (unlikely to be used much, but the single most powerful enhancement any mod could make) </ul><span style='color:white'>Naming conventions:</span> func_* = Solid brush entities only, e.g. func_wall info_* = Settings and placement markers only, e.g. info_mapinfo, team_* = Placement markers for buildings target_* = Resource file placement into map (like the mp3 ent) env_* = Point entities
Standardize event names (at fgd level if not at the code level): hive - TriggerOnSpawn, TriggerOnDeath comm chair - TriggerOnUse, TriggerOnLogout
------------------------------------------------
<span style='color:white'>target_tooltip:</span> Ability to add custom tooltips to a map (targetable point entity, target_tooltip) with a master field to override when it can be triggered--should be useful for telling players about broken doors, tasks to get to a new destination, etc. Should use the appearflags mentioned below.
------------------------------------------------
<span style='color:white'>target_mdl:</span> Addition of a q3 misc_model styled model display that has some enhancements specific to the HL engine
Properties - not affected by gravity, no direct reaction to player or gameplay elements (trigger_script handles any events), no clip hull, can set render light amount directly using a key instead of using floor brightness, can set skin number using a key, can set render properties like other model based entities
Pair with an enhanced scripting ability (trigger_script): toggle submodel visibility (one submodel at a time) change texture (skin) change light amount change visibility flags (see next item) change render properties
Would allow integration of mdl files with maps without restrictions of env_cycler or monster_furnature-- could be used for furnishings, light bulbs, screens, etc.
(I may code this up myself as a proof-of-concept... it would easily be among the most powerful mapper's entities in the game in terms of flexibility vs. impact on game speed when paired with the appearflags below, on par with the particle system IMHO)
------------------------------------------------
<span style='color:white'>appearflag changes:</span> Modification of AppearFlags (high value flags standard on many entities (e.g. "not in deathmatch") for use in determining visibility to comm/ground -- if all rendered entities (mdl, point and brush) have the ability to be invisible to either, mappers can be less concerned with the commander's view when placing items like sprites, particle systems, and mdl entities...
It would also be nice to have team-based vis flags (check to make invisible to team1/team2) for providing in-game feedback to people, an autohelp vis flag (new player hint like a floor scroll that appears to show which way to go at map start, off for people who don't want autohelp), and an invisible to spectators vis flag (so that the code doesn't have to assume presense/absense based on team flag status).
If the above appearflags are implemented, having the ability to change them using an enhanced env_render would be great.
------------------------------------------------
<span style='color:white'>Enhanced event triggering</span> (where the rubber meets the road for map interactivity with game state):
Flesh out event model to allow mappers to add additional triggered events in 2 modes: toggle on leading edge of state change / on when a building is in a given state, off otherwise. Redundancy between the modes allows removal of extra entities required to track states. The overhead required to process this information would be two possible trigger calls per state change on major entities, which shouldn't happen that frequently.
Coupled with the target_mdl entity above, the possibilities are really exciting.
Uses for example: A set of custom target_mdl tenticles could be added to a hive room, looking like extensions of the hive--the tenticles could be scripted to react to whatever was happening to the hive--jerking when it's hurt, shriveling while it's dead. Subtle lighting changes that take effect when the hive is dead -- room coloration turns sickly instead of vibrant.
Uses for example: A set of controls in marine comm room that flicker when the chair is being damaged and go offline when the chair is destroyed. When the chair is being welded, lights in the room pulse slightly brighter. Indicator lights around the map that show when someone is in the chair. Warning claxon when the chair is being damaged.
Uses for example: Indicator lights showing when node is active. Infestation grows around node when aliens are building or using it.
Also use generic event-based trigger name hooks. Preface trigger names with a special character to indicate that they are NS state triggers (!)? sample triggers: (toggles - marine) - !building_started_marine, !building_finished_marine, !building_destroyed_marine (toggles - alien) - !building_started_alien, !building_finished_alien, !building_destroyed_alien (toggles - either) - !building_started_*, !building_started_first_*, !building_finished_*, !building_finished_first_*, !building_destroyed_*, !building_destroyed_final_* (states) - !building_active_*
* = entity name for building, trigger is named according to type of building that event corresponds to.
Example uses for triggers: Finishing building of a new comm chair after old one is destroyed brings some items online (on when !building_active_<command chair ent name>)
Simple automated defenses (e.g. electrical barriers) activate while an observatory is present (on when !building_finished_first_<observatory ent name>, off when !building_destroyed_final_<observatory ent name> *or* !building_active_<observatory ent name> could be used)
Map infestation grows after N alien buildings have been constructed (using counter and !building_finished_alien)
The started first and finished first triggers allow mappers to generate new sub-objectives on a per-map basis. If combined with an entity to end the round, you'd have an optional new victory condition that could be specified by the mapper. This would be even more powerful if a brush entity could be used to define areas where the trigger applied.
<span style='color:white'>Hook for per-map entity code</span> Least likely to be used, but still on the list: a DLL hook for per-map entities. If the map worldspawn specifies a DLL field, that DLL is dynamically loaded into the system for processing entities while the map is running--if the DLL is absent, the system sends a debug message and proceeds without the custom entity code. The map DLL wouldn't override the main code, but would be called to allocate and dispose of entity types that the main code didn't recognize.
For the 1% of mappers who are programmers (like myself), it would allow specification of interactive map elements with complex behaviors that aren't necessarily worth putting into the main codebase (one-shot interactive set pieces without the limitations of the primative movement and reaction types available in the canonical entity set). If this is a possibility, I'll define a linking API for connecting map DLLs to the server.
How about a flag for all entities that defines whether a Commander can directly select the entity or not? If the flag is on, the Commander cannot click on the entity with the cursor to activate it directly. This would prevent the Commander from activating entities that should only be activated from buttons/triggers/sequences under specific situations.
Example: I make an airlock that opens and sucks everyone out into space. I have a multimanager activate the door and suction effect, and a button activates the multimanager. Instead the Commander clicks on the door directly, which opens it, but there's no suction effect. So players can just walk in and out at will.
I would just love to see the gravity trigger fixed, thats my only request now..... <!--emo&???--><img src='http://www.unknownworlds.com/forums/html/emoticons/confused.gif' border='0' style='vertical-align:middle' alt='confused.gif'><!--endemo-->
Here are a few requests, let me know/flame me if they are already possible. They are for a map idea I have (I'm working on a different map right now, but maybe I would do this one in a million years or so).
- A trigger that makes skulks 'lose their grip'. Stopping them from climbing to certain places.
- Env_fade is useful for voids/pits of death. However, I am not sure how env_fade can be made to work for one client (not the whole server). If there is currently no way of doing this, make it possible (me suspects there already is).
-Specify custom model, render properties etc for res nodes. I don't care of this goes against the theme (who says this map does <!--emo&;)--><img src='http://www.unknownworlds.com/forums/html/emoticons/wink.gif' border='0' style='vertical-align:middle' alt='wink.gif'><!--endemo--> ).
A trigger_endgame type thing that can be set for specific team. And when that team wins activates the trigger. Or something along those lines. This could do two things:
1) ready room bonuses for the winning team! 2) change the dynamics of the following game! Say if the aliens win, some vents could be closed off. If the marines win, more vents could be opened and halls blocked off. Stuff like that.
<!--QuoteBegin--Yamazaki+Mar 12 2003, 01:39 PM--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (Yamazaki @ Mar 12 2003, 01:39 PM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin--> How about a flag for all entities that defines whether a Commander can directly select the entity or not? If the flag is on, the Commander cannot click on the entity with the cursor to activate it directly. This would prevent the Commander from activating entities that should only be activated from buttons/triggers/sequences under specific situations.
Example: I make an airlock that opens and sucks everyone out into space. I have a multimanager activate the door and suction effect, and a button activates the multimanager. Instead the Commander clicks on the door directly, which opens it, but there's no suction effect. So players can just walk in and out at will. <!--QuoteEnd--> </td></tr></table><span class='postcolor'> <!--QuoteEEnd--> In addition to adding the ability to make an entity unresponsive to hacker mode, it would be great if we could specify a substitute trigger name (hackerModeTarget? commanderClickTarget?) to fire instead of the object when the commander clicks on it. In your example, this field would point to the multimanager, skipping the button -- the commander could then click on the door and the entire effect, including the suction, would execute properly.
It would still be nice to be able to turn off hacker mode entirely, but I think that having a substitute trigger should be flexible enough to allow any commander interaction that the mapper didn't want to explicitly prohibit.
<i>Hook for per-map entity code If the map worldspawn specifies a DLL field, that DLL is dynamically loaded into the system for processing entities while the map is running</i>
I'm not a programmer, but that sounds like a huge safety liability. dll's can do anything, right? For quake III they use a specific file format, .qvm, which only allows safe commands to be executed. Something similar would seem necessery for NS, and sounds like a <i>lot</i> of work. An easier implementation would probably be to hardcode the .dll files to be loaded, so that only official maps can use this feature.
<!--QuoteBegin--Wolv+Mar 27 2003, 06:44 AM--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (Wolv @ Mar 27 2003, 06:44 AM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin--> I'm not a programmer, but that sounds like a huge safety liability. dll's can do anything, right? For quake III they use a specific file format, .qvm, which only allows safe commands to be executed. Something similar would seem necessery for NS, and sounds like a <i>lot</i> of work. An easier implementation would probably be to hardcode the .dll files to be loaded, so that only official maps can use this feature. <!--QuoteEnd--> </td></tr></table><span class='postcolor'> <!--QuoteEEnd--> This is pretty much the same issue as releasing a Half-Life mod dll or (in a closer analogy) a metamod dll--it's just for a more specific application. I'm assuming that half-life checks the client dll against the server's copy as one step in cheat prevention... perhaps the same mechanism could be extended for use here. That combined with source code review and certification by a central board ought to be pretty secure. For more information on this concept, you can check out NetTrek and its use of <a href='http://www.inl.org/netrek/netrekFAQ.html#10' target='_blank'>blessed binaries</a>.
When Quake 2 came out with dll based game code, many people were worried about the transition from QuakeC to a full featured dll, and some community mechanisms were proposed to establish a way to know if a dll was safe. Quake 3 switched back to a safe format because of the community concerns. Half-Life, on the other hand, is still using DLLs <!--emo&;)--><img src='http://www.unknownworlds.com/forums/html/emoticons/wink.gif' border='0' style='vertical-align:middle' alt='wink.gif'><!--endemo-->. I don't have any links to this information offhand, but it should be archived somewhere.
Of course, it all comes down to trust. When I released the map planes fix, nobody around here knew me and some people assumed that I was either joking around or doing something malicious. In fact, the first few pages of the original thread about its release weren't pretty. It took some testimonials that the optimizer worked as advertised before more people became comfortable with trying it out. We trust the NS dev team to release code that won't hurt our machines or our data -- it's that same trust that would need to be extended to map dll writers (or the people doing certification of map dlls if a blessed binary scheme is used).
Like I said in the original proposal, this isn't likely to be implemented, but it would be the single most powerful mapping extension a mod could have--it's basically adding metamod style support for mappers directly into NS.
Right now I want to be able to make a floor that opens up when a player press a button but wont open when the commander presses the floor, its so annoying.
Make a flag in func_door "Commander cant activate".
Back to the dll-idea... would it be possible to check the dll for unwanted api calls, like disk writes, etc. as a first step of prevention? If a dll was checked to import no other libraries at all... that wouldn't hurt either, right? Entities don't need disk access or registry or create new windows and such. <!--emo&;)--><img src='http://www.unknownworlds.com/forums/html/emoticons/wink.gif' border='0' style='vertical-align:middle' alt='wink.gif'><!--endemo--> Hey! That's it! Isn't my idea great, huh? No, don't tell me... it's ok. I know it is great.
one thing i want is to be able to place buildings and weapons not just hives and ccs. Have it so it can start unbuilt or built and if built be able to set its health.
I'm with Yamazaki, I also have a need for a "Comm cannot trigger" flag. I'm running into a problem with my doors where comms can open things I'd rather make the marines do. While a redirect like Cagey is talking about would be really cool and useful, my specific need is to deny the operation of a triggerable entity altogether. I can see this being aplied to doors, plats, triggers, ect.
I'd like to see the following changes: -The entities that name locations in the map (forgot the name) can either define an area by coordinates and by a specified brush -You can decide which hive is the starting hive
Hi Guys! Im working at a new kind of NS-funmap because I dont like ANY funmap that had been released. In my opinion funmap-"mappers" are the lazy part of the NS community. Funmaps are supposed to look cool and should be a great fun to play because they are crafted well. My worst nightmares went true with ns_siege005. Everyone knows it... even the HL tutorial map (remember: one room and a kind of storage area) looked better <!--emo&???--><img src='http://www.unknownworlds.com/forums/html/emoticons/confused.gif' border='0' style='vertical-align:middle' alt='confused.gif'><!--endemo--> Mapping for ns is quite *giggles* different. But I got in rage when I realized the entities. Cuz ALL the teamspecific modifications/flags for common triggers like func_door, trigger_hurt (!!!), etc. were missing! Since DOD I thought its standart for hl-mods. BTW the angle problem withhin func_playerstart, func_teamhive and other important entities is a problem known since dod. I ignore this error. My map has 24 of this <!--emo&:p--><img src='http://www.unknownworlds.com/forums/html/emoticons/tounge.gif' border='0' style='vertical-align:middle' alt='tounge.gif'><!--endemo-->
What Im really missing:
- all func and trigger with teamspecific flags. U cannot make a hive jetpack-rush-secure if the trigger hurts aliens as well. - point two of that: the trigger hurt should be connected with the specific soundfile know since halflife. When I first get killed by a trigger_hurt I kno how unrealistic it seems suddenly getting killed. - there are some trigger missing from halflife. Dont know exactly which ones but I realized it working on my map. - add all marine weapons and items to place separetely with the options "respawn:1-<!--emo&???--><img src='http://www.unknownworlds.com/forums/html/emoticons/confused.gif' border='0' style='vertical-align:middle' alt='confused.gif'><!--endemo-->/infinite; respawntime" btw the hl jumppack is functional in ns <!--emo&:D--><img src='http://www.unknownworlds.com/forums/html/emoticons/biggrin.gif' border='0' style='vertical-align:middle' alt='biggrin.gif'><!--endemo--> Also add unbuild buildings like instarcraft. You first have to find them. Than you can build them like other buildings. - Anyone should think about gamelimitations like weaponlimitation at dod, where u simply can modify a config to fit the game to your map, not the other way round. - there was an error in ambience_generic not looping custom soundfiles ingame
One other problem I came over: Aliensize and the movement restrictions. How are u supposed to build a genious gameplay map for ns when there are too few restrictions for the player? Onos shouldnt be able to use ladders and they need wider areas to move. This would make the layout of maps more interesting when you first have to think about which path are you planning to go, then evolve. Or make the onos smaller. This size would be great: <!--emo&::onos::--><img src='http://www.unknownworlds.com/forums/html/emoticons/tiny.gif' border='0' style='vertical-align:middle' alt='tiny.gif'><!--endemo-->
Think the env_fog works... but... the wrong way! Only entities get fogged, the worldbrushes stay as they are. This is an effect know since DOD but there the entities stayed "unfogged". Whats worse? <!--emo&???--><img src='http://www.unknownworlds.com/forums/html/emoticons/confused.gif' border='0' style='vertical-align:middle' alt='confused.gif'><!--endemo-->
As far as I've noticed the commander can only click on doors which only are targeted by a button. there may be other instances, but these are all I've seen. If you've got a door/elevator that you don't want the commander to mess around with, target it with a trigger_relay that's targeted by the button. It'll work just the same but the commander can't h4x it.
1. func_forcefield -the field has a health life, so aliens could destroy it -only penetrable by marines and certain weapons -only alien weapon to get through is lerk gas/possible lerk primal scream -mappers can make the force field any color
2.func_webwall -the field has a health life, so marines could destroy it -still indestructable to siege cannons, and not targeted by turrets -penetrable by aliens and certain weapons -has the appearance of certain wad files such as the gestation embryo wad. -has the appearance of a normal force field, as if aliens penetrated into a secure area through the vents, and have access through it
also a great idea would be func_spores so marines are not able to access so areas, if they are to slow to pass the "spored" area (no jetpack). but I never will get over this: Heavy Armor marines take damage by spores. why? the model has a separated airsupply unit. was just what I thought...
Here's an actual fix that I need done. On rotating or moving doors, fans, etc, I notice that the commander's viewpoint if over them will rotate along with them. whoa. On some fans that I have spinning at 60 RPM you get over these things and you can't slide your view off, you have to use the minimap, AND you get sick while your screen is spinning in circles. Sure, I can fix it by putting an invisible block over it, but that's an extra entity, and won't always work when I need marines and players to be able to move through (up and down) the fan (if they get lucky and don't get chopped up, or if the fan has stopped)
just an idea: env_freespace or env_vacuum. you can alter the damage done to the player and how the surrounding sounds are affected. 100% would mean that all sounds are completely not hearable. add lower gravity (hihi) and you have the perfect "**** I forgot my airtank!"-feeling at your own home <!--emo&:D--><img src='http://www.unknownworlds.com/forums/html/emoticons/biggrin.gif' border='0' style='vertical-align:middle' alt='biggrin.gif'><!--endemo-->
Not sure if these have been said before, but I feel these are VERY important.
1. Everything not pertaining to NS needs to be removed i.e. monster_headcrab and weapon_9mmAR yeah um why are those still there?
2. Allow us to specify custom door sounds in some field in the func_door. I know you can do it manually (ambience_generics etc.) but I'd rather have it like spirit.
3. Some spirit of half-life functions, not all just a few.
to allowcustom sounds with doors would be cool but I think there is not a singel mod out there where you simply can define them. I think the ns team wont change that. I wwould be glad to see a list or a tutorial map for the door and train/elevator sounds because they had all been changed, some of them doesnt work (means that they left some hl soundfiles out). hard to decide which soundfile fits perfectly.. the ns team dindt changed the names of the sounds in the entity properties. this is bad! so you have to guess... *annoyed*
<!--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-->not a singel mod out there where you simply can define them<!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
Spirit of half-life has stuff like that and the purpose of spirit is to give mod makers extreemly awesome code to make their mods better. I wish NS could get some of those features.
also:
3. Make an option for buttons to not be able to be triggered by aliens and likewise for marines
4. Weldables should have an option to be able weld multiple (if not infinite) times.
you all know that the playersizes arent too different. the crouching marine is a high as an skulk, what makes some things impossible to do. so there should be an entity that lets only some classes pass. so you can create an "onos stunning" area or such stuff. best thing: jp cant lame the hive. anything in that direction...
i wud like the commander cannot trigger thing (coz i got a train on my map) and i wud like move with function coz there is source code for ti sumwhere so i can have moving lights and windows and buttons with my trains and doors etc
I dont think this will be possible in the near future. hl entities can only have ONE defined class ability. moving lights would be a func train combined with light. exspecially the light thing is a difficult thing because there are only few realtime render effects (strobe, fastflicker...)
although I remember that one of the last dod fgd had the option to create moving ladders...
<!--QuoteBegin--Lt.Gravity+Jun 7 2003, 07:30 PM--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (Lt.Gravity @ Jun 7 2003, 07:30 PM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin--> I dont think this will be possible in the near future. hl entities can only have ONE defined class ability. moving lights would be a func train combined with light. <!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd--> Sorry, but this is not true, it would be easy to have a light attached to a train - the question is just how to implement it (i.e. do you specify co-ordinates relative to an origin brush?, etc.)
The main fixes I'm waiting for are the build triggers and the ability to specify starting resource nodes (desperate for this one <!--emo&:(--><img src='http://www.unknownworlds.com/forums/html/emoticons/sad.gif' border='0' style='vertical-align:middle' alt='sad.gif'><!--endemo-->!)
After this would have to be Spirit styled move-with properties.
with "not possible" I mean "not necessary in the eyes of the ns team" do I? <!--emo&:D--><img src='http://www.unknownworlds.com/forums/html/emoticons/biggrin.gif' border='0' style='vertical-align:middle' alt='biggrin.gif'><!--endemo--> the question is if the team seriously thinks about some ideas that mapper wrote down. it would make our live much easier when some of the things get real. and I forgot one entity connection seen in global warfare: func_train + func_tank so you were able to shot out of a MOVING helicopter. so it cant be to difficult to create some more entity connections. a moving hive would be cool XD why not? hive at a giant trainlike construction. if this hive reaches a specific point in the map marines lose the match.
Comments
EDIT: telegraphic grammar fix.
<span style='color:white'>Summary:</span><ul>
<li>standardized naming conventions (may be too late for this, but it's worth mentioning)
<li>target_tooltip
<li>target_mdl / trigger_script enhancements
<li>appearflags for comm vis, ground vis, team based vis, spec vis, and autohelp sensitive vis
<li>enhanced event triggering
<li>hook for per-map entity code (unlikely to be used much, but the single most powerful enhancement any mod could make)
</ul><span style='color:white'>Naming conventions:</span>
func_* = Solid brush entities only, e.g. func_wall
info_* = Settings and placement markers only, e.g. info_mapinfo,
team_* = Placement markers for buildings
target_* = Resource file placement into map (like the mp3 ent)
env_* = Point entities
Examples:
info_join_team -> trigger_join_team
func_resource -> team_resource
Standardize event names (at fgd level if not at the code level):
hive - TriggerOnSpawn, TriggerOnDeath
comm chair - TriggerOnUse, TriggerOnLogout
------------------------------------------------
<span style='color:white'>target_tooltip:</span>
Ability to add custom tooltips to a map (targetable point entity, target_tooltip) with a master field to override when it can be triggered--should be useful for telling players about broken doors, tasks to get to a new destination, etc. Should use the appearflags mentioned below.
------------------------------------------------
<span style='color:white'>target_mdl:</span>
Addition of a q3 misc_model styled model display that has some enhancements specific to the HL engine
Properties - not affected by gravity, no direct reaction to player or gameplay elements (trigger_script handles any events), no clip hull, can set render light
amount directly using a key instead of using floor brightness, can set skin number using a key, can set render properties like other model based entities
Pair with an enhanced scripting ability (trigger_script):
toggle submodel visibility (one submodel at a time)
change texture (skin)
change light amount
change visibility flags (see next item)
change render properties
Would allow integration of mdl files with maps without restrictions of env_cycler or monster_furnature-- could be used for furnishings, light bulbs, screens, etc.
(I may code this up myself as a proof-of-concept... it would easily be among the most powerful mapper's entities in the game in terms of flexibility vs. impact
on game speed when paired with the appearflags below, on par with the particle system IMHO)
------------------------------------------------
<span style='color:white'>appearflag changes:</span>
Modification of AppearFlags (high value flags standard on many entities (e.g. "not in deathmatch") for use in determining visibility to comm/ground -- if all rendered entities (mdl, point and brush) have the ability to be invisible to either, mappers can be less concerned with the commander's view when placing items like sprites, particle systems, and mdl entities...
It would also be nice to have team-based vis flags (check to make invisible to team1/team2) for providing in-game feedback to people, an autohelp vis flag (new player hint like a floor scroll that appears to show which way to go at map start, off for people who don't want autohelp), and an invisible to spectators vis flag (so that the code doesn't have to assume presense/absense based on team flag status).
If the above appearflags are implemented, having the ability to change them using an enhanced env_render would be great.
------------------------------------------------
<span style='color:white'>Enhanced event triggering</span>
(where the rubber meets the road for map interactivity with game state):
Flesh out event model to allow mappers to add additional triggered events in 2 modes: toggle on leading edge of state change / on when a building is in a given state, off otherwise. Redundancy between the modes allows removal of extra entities required to track states. The overhead required to process this information would be two possible trigger calls per state change on major entities, which shouldn't happen that frequently.
Coupled with the target_mdl entity above, the possibilities are really exciting.
----
Example: team_hive
(toggles) TriggerOnSpawn, TriggerOnDeath, TriggerOnFinishBuild, TriggerOnDamage, TriggerOnHeal
(states) TriggerWhileDead, TriggerWhileBuilding, TriggerWhileActive, TriggerWhileTakingDamage, TriggerWhileHealing
Uses for example:
A set of custom target_mdl tenticles could be added to a hive room, looking like extensions of the hive--the tenticles could be scripted to react to whatever was happening to the hive--jerking when it's hurt, shriveling while it's dead. Subtle lighting changes that take effect when the hive is dead -- room coloration turns sickly instead of vibrant.
----
Example: team_command
(toggles) TriggerOnSpawn, TriggerOnDeath, TriggerOnDamage, TriggerOnHeal (weld), TriggerOnUse, TriggerOnLogout
(states) TriggerWhileActive, TriggerWhileInUse, TriggerWhileTakingDamage, TriggerWhileHealing (weld)
Uses for example:
A set of controls in marine comm room that flicker when the chair is being damaged and go offline when the chair is destroyed. When the chair is being welded, lights in the room pulse slightly brighter. Indicator lights around the map that show when someone is in the chair. Warning claxon when the chair is being damaged.
----
Example: func_resource
(toggles - marine interaction) TriggerOnMarineBuildStart, TriggerOnMarineBuildFinish, TriggerOnMarineDamaged, TriggerOnMarineHealed (welded), TriggerOnMarineDestroyed, TriggerOnMarineRecycled
(toggles - alien interaction) TriggerOnAlienBuildStart, TriggerOnAlienBuildFinish, TriggerOnAlienDamaged, TriggerOnAlienHealed, TriggerOnAlienDestroyed
(states - generic) TriggerWhileDead, TriggerWhileBuilding, TriggerWhileActive, TriggerWhileTakingDamage, TriggerWhileHealing, TriggerWhileRecycling
(states - marine) TriggerWhileMarineBuilding, TriggerWhileMarineActive, TriggerWhileMarineTakingDamage, TriggerWhileMarineHealing
(states - alien) TriggerWhileAlienBuilding, TriggerWhileAlienActive, TriggerWhileAlienTakingDamage, TriggerWhileAlienHealing
Uses for example:
Indicator lights showing when node is active. Infestation grows around node when aliens are building or using it.
Also use generic event-based trigger name hooks. Preface trigger names with a special character to indicate that they are NS state triggers (!)?
sample triggers:
(toggles - marine) - !building_started_marine, !building_finished_marine, !building_destroyed_marine
(toggles - alien) - !building_started_alien, !building_finished_alien, !building_destroyed_alien
(toggles - either) - !building_started_*, !building_started_first_*, !building_finished_*, !building_finished_first_*, !building_destroyed_*, !building_destroyed_final_*
(states) - !building_active_*
* = entity name for building, trigger is named according to type of building that event corresponds to.
Example uses for triggers:
Finishing building of a new comm chair after old one is destroyed brings some items online (on when !building_active_<command chair ent name>)
Simple automated defenses (e.g. electrical barriers) activate while an observatory is present (on when !building_finished_first_<observatory ent name>, off when !building_destroyed_final_<observatory ent name> *or* !building_active_<observatory ent name> could be used)
Map infestation grows after N alien buildings have been constructed (using counter and !building_finished_alien)
The started first and finished first triggers allow mappers to generate new sub-objectives on a per-map basis. If combined with an entity to end the round, you'd have an optional new victory condition that could be specified by the mapper. This would be even more powerful if a brush entity could be used to define areas where the trigger applied.
-------------------------------------------------------------------------------
<span style='color:white'>Hook for per-map entity code</span>
Least likely to be used, but still on the list: a DLL hook for per-map entities. If the map worldspawn specifies a DLL field, that DLL is dynamically loaded into the system for processing entities while the map is running--if the DLL is absent, the system sends a debug message and proceeds without the custom entity code. The map DLL wouldn't override the main code, but would be called to allocate and dispose of entity types that the main code didn't recognize.
For the 1% of mappers who are programmers (like myself), it would allow specification of interactive map elements with complex behaviors that aren't necessarily worth putting into the main codebase (one-shot interactive set pieces without the limitations of the primative movement and reaction types available in the canonical entity set). If this is a possibility, I'll define a linking API for connecting map DLLs to the server.
Example: I make an airlock that opens and sucks everyone out into space. I have a multimanager activate the door and suction effect, and a button activates the multimanager. Instead the Commander clicks on the door directly, which opens it, but there's no suction effect. So players can just walk in and out at will.
- A trigger that makes skulks 'lose their grip'. Stopping them from climbing to certain places.
- Env_fade is useful for voids/pits of death. However, I am not sure how env_fade can be made to work for one client (not the whole server). If there is currently no way of doing this, make it possible (me suspects there already is).
-Specify custom model, render properties etc for res nodes. I don't care of this goes against the theme (who says this map does <!--emo&;)--><img src='http://www.unknownworlds.com/forums/html/emoticons/wink.gif' border='0' style='vertical-align:middle' alt='wink.gif'><!--endemo--> ).
1) ready room bonuses for the winning team!
2) change the dynamics of the following game! Say if the aliens win, some vents could be closed off. If the marines win, more vents could be opened and halls blocked off. Stuff like that.
Example: I make an airlock that opens and sucks everyone out into space. I have a multimanager activate the door and suction effect, and a button activates the multimanager. Instead the Commander clicks on the door directly, which opens it, but there's no suction effect. So players can just walk in and out at will. <!--QuoteEnd--> </td></tr></table><span class='postcolor'> <!--QuoteEEnd-->
In addition to adding the ability to make an entity unresponsive to hacker mode, it would be great if we could specify a substitute trigger name (hackerModeTarget? commanderClickTarget?) to fire instead of the object when the commander clicks on it. In your example, this field would point to the multimanager, skipping the button -- the commander could then click on the door and the entire effect, including the suction, would execute properly.
It would still be nice to be able to turn off hacker mode entirely, but I think that having a substitute trigger should be flexible enough to allow any commander interaction that the mapper didn't want to explicitly prohibit.
If the map worldspawn specifies a DLL field, that DLL is dynamically loaded into the system for processing entities while the map is running</i>
I'm not a programmer, but that sounds like a huge safety liability. dll's can do anything, right? For quake III they use a specific file format, .qvm, which only allows safe commands to be executed. Something similar would seem necessery for NS, and sounds like a <i>lot</i> of work.
An easier implementation would probably be to hardcode the .dll files to be loaded, so that only official maps can use this feature.
An easier implementation would probably be to hardcode the .dll files to be loaded, so that only official maps can use this feature. <!--QuoteEnd--> </td></tr></table><span class='postcolor'> <!--QuoteEEnd-->
This is pretty much the same issue as releasing a Half-Life mod dll or (in a closer analogy) a metamod dll--it's just for a more specific application. I'm assuming that half-life checks the client dll against the server's copy as one step in cheat prevention... perhaps the same mechanism could be extended for use here. That combined with source code review and certification by a central board ought to be pretty secure. For more information on this concept, you can check out NetTrek and its use of <a href='http://www.inl.org/netrek/netrekFAQ.html#10' target='_blank'>blessed binaries</a>.
When Quake 2 came out with dll based game code, many people were worried about the transition from QuakeC to a full featured dll, and some community mechanisms were proposed to establish a way to know if a dll was safe. Quake 3 switched back to a safe format because of the community concerns. Half-Life, on the other hand, is still using DLLs <!--emo&;)--><img src='http://www.unknownworlds.com/forums/html/emoticons/wink.gif' border='0' style='vertical-align:middle' alt='wink.gif'><!--endemo-->. I don't have any links to this information offhand, but it should be archived somewhere.
Of course, it all comes down to trust. When I released the map planes fix, nobody around here knew me and some people assumed that I was either joking around or doing something malicious. In fact, the first few pages of the original thread about its release weren't pretty. It took some testimonials that the optimizer worked as advertised before more people became comfortable with trying it out. We trust the NS dev team to release code that won't hurt our machines or our data -- it's that same trust that would need to be extended to map dll writers (or the people doing certification of map dlls if a blessed binary scheme is used).
Like I said in the original proposal, this isn't likely to be implemented, but it would be the single most powerful mapping extension a mod could have--it's basically adding metamod style support for mappers directly into NS.
Right now I want to be able to make a floor that opens up when a player press a button but wont open when the commander presses the floor, its so annoying.
Make a flag in func_door "Commander cant activate".
You just have to include this!
%"#%"#¤
>:(
Hey! That's it! Isn't my idea great, huh? No, don't tell me... it's ok. I know it is great.
Have it so it can start unbuilt or built and if built be able to set its health.
Thanks guys,
GSH
-The entities that name locations in the map (forgot the name) can either define an area by coordinates and by a specified brush
-You can decide which hive is the starting hive
Im working at a new kind of NS-funmap because I dont like ANY funmap that had been released. In my opinion funmap-"mappers" are the lazy part of the NS community.
Funmaps are supposed to look cool and should be a great fun to play because they are crafted well. My worst nightmares went true with ns_siege005. Everyone knows it... even the HL tutorial map (remember: one room and a kind of storage area) looked better <!--emo&???--><img src='http://www.unknownworlds.com/forums/html/emoticons/confused.gif' border='0' style='vertical-align:middle' alt='confused.gif'><!--endemo-->
Mapping for ns is quite *giggles* different.
But I got in rage when I realized the entities. Cuz ALL the teamspecific modifications/flags for common triggers like func_door, trigger_hurt (!!!), etc. were missing! Since DOD I thought its standart for hl-mods. BTW the angle problem withhin func_playerstart, func_teamhive and other important entities is a problem known since dod. I ignore this error. My map has 24 of this <!--emo&:p--><img src='http://www.unknownworlds.com/forums/html/emoticons/tounge.gif' border='0' style='vertical-align:middle' alt='tounge.gif'><!--endemo-->
What Im really missing:
- all func and trigger with teamspecific flags. U cannot make a hive jetpack-rush-secure if the trigger hurts aliens as well.
- point two of that: the trigger hurt should be connected with the specific soundfile know since halflife. When I first get killed by a trigger_hurt I kno how unrealistic it seems suddenly getting killed.
- there are some trigger missing from halflife. Dont know exactly which ones but I realized it working on my map.
- add all marine weapons and items to place separetely with the options "respawn:1-<!--emo&???--><img src='http://www.unknownworlds.com/forums/html/emoticons/confused.gif' border='0' style='vertical-align:middle' alt='confused.gif'><!--endemo-->/infinite; respawntime" btw the hl jumppack is functional in ns <!--emo&:D--><img src='http://www.unknownworlds.com/forums/html/emoticons/biggrin.gif' border='0' style='vertical-align:middle' alt='biggrin.gif'><!--endemo--> Also add unbuild buildings like instarcraft. You first have to find them. Than you can build them like other buildings.
- Anyone should think about gamelimitations like weaponlimitation at dod, where u simply can modify a config to fit the game to your map, not the other way round.
- there was an error in ambience_generic not looping custom soundfiles ingame
One other problem I came over: Aliensize and the movement restrictions. How are u supposed to build a genious gameplay map for ns when there are too few restrictions for the player? Onos shouldnt be able to use ladders and they need wider areas to move. This would make the layout of maps more interesting when you first have to think about which path are you planning to go, then evolve. Or make the onos smaller. This size would be great:
<!--emo&::onos::--><img src='http://www.unknownworlds.com/forums/html/emoticons/tiny.gif' border='0' style='vertical-align:middle' alt='tiny.gif'><!--endemo-->
<!--emo&:D--><img src='http://www.unknownworlds.com/forums/html/emoticons/biggrin.gif' border='0' style='vertical-align:middle' alt='biggrin.gif'><!--endemo-->
If you've got a door/elevator that you don't want the commander to mess around with, target it with a trigger_relay that's targeted by the button. It'll work just the same but the commander can't h4x it.
1. func_forcefield
-the field has a health life, so aliens could destroy it
-only penetrable by marines and certain weapons
-only alien weapon to get through is lerk gas/possible lerk primal scream
-mappers can make the force field any color
2.func_webwall
-the field has a health life, so marines could destroy it
-still indestructable to siege cannons, and not targeted by turrets
-penetrable by aliens and certain weapons
-has the appearance of certain wad files such as the gestation embryo wad.
-has the appearance of a normal force field, as if aliens penetrated into a secure area through the vents, and have access through it
but I never will get over this: Heavy Armor marines take damage by spores. why? the model has a separated airsupply unit. was just what I thought...
On rotating or moving doors, fans, etc, I notice that the commander's viewpoint if over them will rotate along with them.
whoa.
On some fans that I have spinning at 60 RPM you get over these things and you can't slide your view off, you have to use the minimap, AND you get sick while your screen is spinning in circles.
Sure, I can fix it by putting an invisible block over it, but that's an extra entity, and won't always work when I need marines and players to be able to move through (up and down) the fan (if they get lucky and don't get chopped up, or if the fan has stopped)
env_freespace or env_vacuum. you can alter the damage done to the player and how the surrounding sounds are affected. 100% would mean that all sounds are completely not hearable.
add lower gravity (hihi) and you have the perfect "**** I forgot my airtank!"-feeling at your own home <!--emo&:D--><img src='http://www.unknownworlds.com/forums/html/emoticons/biggrin.gif' border='0' style='vertical-align:middle' alt='biggrin.gif'><!--endemo-->
1. Everything not pertaining to NS needs to be removed i.e. monster_headcrab and weapon_9mmAR yeah um why are those still there?
2. Allow us to specify custom door sounds in some field in the func_door. I know you can do it manually (ambience_generics etc.) but I'd rather have it like spirit.
3. Some spirit of half-life functions, not all just a few.
I wwould be glad to see a list or a tutorial map for the door and train/elevator sounds because they had all been changed, some of them doesnt work (means that they left some hl soundfiles out). hard to decide which soundfile fits perfectly.. the ns team dindt changed the names of the sounds in the entity properties. this is bad! so you have to guess... *annoyed*
Spirit of half-life has stuff like that and the purpose of spirit is to give mod makers extreemly awesome code to make their mods better. I wish NS could get some of those features.
also:
3. Make an option for buttons to not be able to be triggered by aliens and likewise for marines
4. Weldables should have an option to be able weld multiple (if not infinite) times.
although I remember that one of the last dod fgd had the option to create moving ladders...
Sorry, but this is not true, it would be easy to have a light attached to a train - the question is just how to implement it (i.e. do you specify co-ordinates relative to an origin brush?, etc.)
The main fixes I'm waiting for are the build triggers and the ability to specify starting resource nodes (desperate for this one <!--emo&:(--><img src='http://www.unknownworlds.com/forums/html/emoticons/sad.gif' border='0' style='vertical-align:middle' alt='sad.gif'><!--endemo-->!)
After this would have to be Spirit styled move-with properties.
the question is if the team seriously thinks about some ideas that mapper wrote down. it would make our live much easier when some of the things get real. and I forgot one entity connection seen in global warfare: func_train + func_tank so you were able to shot out of a MOVING helicopter. so it cant be to difficult to create some more entity connections. a moving hive would be cool XD why not? hive at a giant trainlike construction. if this hive reaches a specific point in the map marines lose the match.