Here is another mapping related bug submission: <a href='http://www.unknownworlds.com/forums/index.php?act=ST&f=26&t=18981&hl=func_breakable' target='_blank'>func_breakable's trigger only flag ignored</a>
Another behavioral change that probably requires a client update -- add a flag to info_location that performs a second, finer level of collision detection after determining if a player is inside the info_location's bounding box. The check would take the dot product of the normal of each info_location face with the player's location minus any point along the face--if any result is greater than zero then the player is outside the bounds of the info_location assuming that the info_location has a convex shape. This is a fast, efficient way to do volumetric bounds checking.
The additional test would only be performed if the mapper explicitly checked the flag, allowing backward compatability and speeding up the common case of axis aligned info_locations. The calculation could stop with the first negative (player out of bounds) result for each info_location, and would never execute for more than 2-3 info_locations whose bounding boxes happen to overlap. This adjustment would allow for adjacent rooms without axial walls to be labeled using a single entity instead of staggering multiple info_locations to follow each of the two walls (picture below illustrates this case):
There's a thread about adding map detection of buildings <a href='http://www.unknownworlds.com/forums/index.php?act=ST&f=4&t=20874' target='_blank'>here</a>. I personally like the idea of extending the trigger_presense entity for this purpose.
Imatarget was wondering if func_weldables could be made for aliens. Unfortunately I check out VHE and it appears not. So i was wondering, make func_weldable accessable for aliens? Maybe give gorge the ability to do something funky instead of babblers or even add it on to another aliens weapon selection. This would obviously need extra animations etc, personally i recommend if it was made that func_weldable worked for marines and kharaa that the marines should have a door_h-b texture and the aliens an infested texture which has partial transparecys through to the other side of the vent. Also i suggest that both of these are BREAKABLE but at a high damage amount, this way people don't complain about the fact you cant get back into welded vents.
func_weldable enabled for a gorges spit. Maybe takes 150% (1.5x) more time to "weld".
Something for mappers to deside what techs are already researched. (It might not get used a lot, but I would find it useful.)
Something for func_weldable to deside if it can be welded and unwelded (or vise versa) a # of times. (Desided by the mapper.)
Moving func_tanklaser (is this possible?). (I would like this for my walking mechs [the mechs are not mine, but someone put them on the really old forums for download, but I am the one who made them "walk"] that I put in my map.)
<!--QuoteBegin--Unknown+Jan 26 2003, 01:28 AM--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (Unknown @ Jan 26 2003, 01:28 AM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->func_weldable enabled for a gorges spit.<!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd--> I'd definately like to see some sort of gorge interaction with the map, but I'd like to have some flexibility with it -- perhaps make a func_gorgespit or use 2 flags (-allowgorge and -ignoremarines) so that we can decide when gorges can close something off and use different brushes/triggered reactions to a gorge finish event than a marine finish event -- essentially, have infestation grow across it instead of having a gorge spit up a steel plate <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' valign='absmiddle' alt='smile.gif'><!--endemo-->.
<!--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-->Something for func_weldable to deside if it can be welded and unwelded (or vise versa) a # of times. (Desided by the mapper.)<!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
Seconded <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' valign='absmiddle' alt='smile.gif'><!--endemo--> I'd also like to see the ability to have it cycle infinite times (specified by -1 in # field?).
<!--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-->Moving func_tanklaser (is this possible?). (I would like this for my walking mechs [the mechs are not mine, but someone put them on the really old forums for download, but I am the one who made them "walk"] that I put in my map.)<!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
It's possible, but it's also an extremely complex item to code for a very specialized case. If this were generalized so that any entity could be attached to move relative to any other entity (like attaching a func_door to a func_train, or a func_wall to a func_platrot) using an "info_relative_movement" point entity, it would be much, much more powerful and would probably give you the functionality you're looking for.
Spec: key value "base" "<name of entity to move/rotate with>" "<name of ent to control>" "<null>" "<name of ent to control>" "<null>" "<name of ent to control>" "<null>" "<name of ent to control>" "<null>" "<name of ent to control>" "<null>"
etc.
Whenever the base ent moves or rotates, rotate or translate all other entites whose names match the key fields by the same amount. Rotation would be about the origin of the base entity (the base entity would require an origin brush and would therefore need to be brush based). The entities being moved/rotated could be point or brush based (think about moving ent_sparks along with a func_train based elevator, for instance). I think spirit of half-life has something like doors that move with trains, but I haven't investigated how it's implemented or how general a solution is provided.
If you had the relative movement described above, you could attach an env_laser to your mech and have it move when the mech does.
<!--QuoteBegin--CrAcKbRoCk+Jan 22 2003, 08:21 PM--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (CrAcKbRoCk @ Jan 22 2003, 08:21 PM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->... in some places if you build a turret factory in a corner it allows you to build turrets in a completely diffrent area of a map that would normally take a little while to get there(where the turrets were built) on foot.<!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd--> I've been thinking this problem over in my head, and I think the best solution (if Flayra agrees that having the tf activate turrets in spacially close but logically remote rooms is a problem) would actually be at the source code level rather than mapper controlled.
In situations like the one you describe (rooms are close enough for tf range, but not connected in a way that lets you walk there quickly), it's likely that the vis information for those two rooms already contains what you need to know -- the two rooms are not reachable from each other without taking a convoluted path. For vis, that means that the engine won't draw one room when a soldier is in the other, but it could also be used to determine placement of dependant items like turrets and infantry portals (dependant on cc). If a room isn't in the potentially visible set from the factory's (or chair's) position, don't allow building the dependant item. Vis determination would allow more flexibility than direct line-of-sight while still restricting the worst cases.
I believe that this would require far less effort on the mapper's part, and wouldn't be prone to oversight on the mapper's part (after all, it's very difficult to accurately predict all of the consequences of a given layout without extensive playtesting).
The problem that I see this having, however, stems from the fact that the placement area highlight is a circular sprite instead of being tied to level geometry -- the commander sees a green circle no matter where he's trying to place the turret, and it may be counterintuitive for him to realize that he can't place the turret in a logically remote room if it's still within the circle. In fact, vis range is often unpredictable since it's based on which way the map is chopped up by the compiler.
While I can see why putting a turret farm in a remote room from its tf could be abused by sneaky commanders, I worry about the effect on playability if an attempt to limit the problem is made (for the reasons stated above).
<!--QuoteBegin--XP-Cagey+Jan 20 2003, 07:25 PM--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (XP-Cagey @ Jan 20 2003, 07:25 PM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->I'd also love to be able to use a master for a func_weldable -- the obvious application is welding a door shut: close the door, THEN weld it shut. Welding would have no effect if the door was open, but would work normally if it was closed... once the weld is finished, slap a brush across the door crack to indicate a finished weld and deactivate the door itself. Turn off the cl_autohelp icon when the master is disabled so that newbs know when they can weld. Using the standard master mechanism already in place for other entities would be the best implementation, IMO.
Add a 'reweldable' flag to func_weldable: after aliens break a low-health weld, the marines can attempt to weld it closed again. Default to false=no reweld for backward compatability. This allows welds to be low strength (100s of HP instead of invincible) without making them useless and turns them into a possible stalling tactic instead of always being used to change connectivity outright.<!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd--> I second that request.
I also have an addition to it. Create a new entity called FUNC_HSPRAY.
Func_HSpray would work exactly the same as a weld except with the gorges healing spray.
This combine with the previous request would allow gorges to "Grow" bacteria on an item or button to disable it. It could then be welded or shot open by a marine. The marine could also weld a button locked and a gorge could spray it to have the bacteria get inside the lock and unlock it.
I want func_button to have the flags "only team one" "only team 2" -> just aliens or marines can press one button. This buttons could cause the same mayor action (open the same door) but just another deelay.
Trigger_presence needs to differenciate between aliens and marines. Triggeer presence should react on build structures, too.
On ressource nodes "trigger on build" needs a differentiation flag between "build by marines" and "build by gorge".
- - trigger presence needs a counter -> that it just reacts if "n" players are inside.
Well I posted about this along time ago but nobody replied, target_mp3audio does not seem to work on my maps or any maps, I dunno if this is a real bug, intentionally disabled or just not working for me:
FreestylerThe First NS FanJoin Date: 2002-01-24Member: 20Members
The Zoner compile tools have the bailitie to make entities like func_wall cast a shadow. Flags to have this enabled or not should be added to the NS FGC like they are in other FGD's (DoD I know has it, CS I think has it...).
I want func_button to have the flags "only team one" "only team 2" -> just aliens or marines can press one button. This buttons could cause the same mayor action (open the same door) but just another deelay. <!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd--> I would also like to see this aplied to trigger_hurt, so that enviormental factors could be setup which could hurt one team but not another.
The_Real_QuasarHas the I.Q. of 12,000 P.E. TeachersJoin Date: 2002-11-26Member: 9998Members
<!--QuoteBegin--Gun_Sgt_Hartman+Feb 7 2003, 06:30 PM--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (Gun_Sgt_Hartman @ Feb 7 2003, 06:30 PM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin--> I would also like to see this aplied to trigger_hurt, so that enviormental factors could be setup which could hurt one team but not another.
GSH <!--QuoteEnd--> </td></tr></table><span class='postcolor'> <!--QuoteEEnd--> I like that idea, would allow "decontamination" and hive slime that kills marines and not aliens. How about making the resource point particles semi customizable, with colour selection (like light entities) and style selection (steam, electricity, sparks, etc). Would allow for some nice effects, and would default to white steam for compatibility with old maps.
Cagey that thing you were talking about has already been implemented in the "Spirit of Half-life" mod/code resource - most entities have a "movewith" field in which you can enter the name of another entity. When the other entity moves, the first is translated by the same amount. This is useful for having ladders, sprites, etcetera on trains.
<!--QuoteBegin--[watch.me.die]+Feb 8 2003, 03:42 PM--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> ([watch.me.die] @ Feb 8 2003, 03:42 PM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin--> Cagey that thing you were talking about has already been implemented in the "Spirit of Half-life" mod/code resource - most entities have a "movewith" field in which you can enter the name of another entity. When the other entity moves, the first is translated by the same amount. This is useful for having ladders, sprites, etcetera on trains. <!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd--> Yeah, I think I plugged Spirit in my post--just didn't know how it was being done <!--emo&:D--><img src='http://www.unknownworlds.com/forums/html/emoticons/biggrin.gif' border='0' style='vertical-align:middle' alt='biggrin.gif'><!--endemo-->. I wonder if Laurie implemented the movement on a per-entity basis or as an attribute overlay... If he did the latter, it's exactly what I'm thinking of (any item moves with any item without having to code that for individual item types). The end effect is the same either way <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo-->.
<!--QuoteBegin--XP-Cagey+Feb 8 2003, 06:51 PM--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (XP-Cagey @ Feb 8 2003, 06:51 PM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin--> <!--QuoteBegin--[watch.me.die]+Feb 8 2003, 03:42 PM--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> ([watch.me.die] @ Feb 8 2003, 03:42 PM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin--> Cagey that thing you were talking about has already been implemented in the "Spirit of Half-life" mod/code resource - most entities have a "movewith" field in which you can enter the name of another entity. When the other entity moves, the first is translated by the same amount. This is useful for having ladders, sprites, etcetera on trains. <!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd--> Yeah, I think I plugged Spirit in my post--just didn't know how it was being done <!--emo&:D--><img src='http://www.unknownworlds.com/forums/html/emoticons/biggrin.gif' border='0' style='vertical-align:middle' alt='biggrin.gif'><!--endemo-->. I wonder if Laurie implemented the movement on a per-entity basis or as an attribute overlay... If he did the latter, it's exactly what I'm thinking of (any item moves with any item without having to code that for individual item types). The end effect is the same either way <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo-->. <!--QuoteEnd--> </td></tr></table><span class='postcolor'> <!--QuoteEEnd--> Yes, but with one less entity <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo--> - which is always a good thing.
<!--QuoteBegin--evoL:ving:eviL+Jan 19 2003, 01:36 PM--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (evoL:ving:eviL @ Jan 19 2003, 01:36 PM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin--> Commander-invisible brushes are still a problem in some cases, and I have an example of where this applies:
I wanted a grating (with a "}" texture) that people could walk over and under, but I wanted it so the comm couldn't see the grating or build on it. It seemed like a simple idea, but its not possible (and func_illusionary WON'T WORK, for several obvious reasons), because func_seethrough can only set player and commander opacity, not player and commander RENDER MODES. A player RENDER MODE and FX AMOUNT property, at least, if not commander rendering properties also, would be immensely helpful... I suppose the opacity setting will have to stay for backwards-compatibility, but it could be disabled by setting FX AMOUNT to something > 0 .
So... can it be done? <!--QuoteEnd--> </td></tr></table><span class='postcolor'> <!--QuoteEEnd--> I used a func_illusionary with a clip brush over it... as it's for a grating there should be no problems with skulks climbing it.
speaking of spirit, it'd be wonderful to incorporate some of spirit into ns. granted that's a big request, but even if it was just a few small things, like adding in the watcher entity or some of the new env entities, would make me very happy.
It occured to me that we're all standin around like a bunch of kids at the candy store asking for goodies, and I personally don't even know what's behind the counter.
What can you do with an FGD? I know what I do with it, I make maps. But what can YOU (the coding GODS) do with it?
Some of the stuff I've asked for seems like it would take a little more work than just tweaking the FGD. If I knew a little more about what you CAN do, I could offer better suggestions.
<!--QuoteBegin--Gun_Sgt_Hartman+Feb 10 2003, 04:23 PM--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (Gun_Sgt_Hartman @ Feb 10 2003, 04:23 PM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin--> What can you do with an FGD? I know what I do with it, I make maps. But what can YOU (the coding GODS) do with it? <!--QuoteEnd--> </td></tr></table><span class='postcolor'> <!--QuoteEEnd--> Pretty much every suggestion I've seen here (except the unused angles key thing and the mention of Zoner's enhancements being migrated to the NS FGD) would require a change to the NS source... the thread has kinda drifted off course (partially--mostly? <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo-->--my fault)--FGD tweaks won't enhance an object's actual capabilities, since the scope of the FGD is entirely inside WC's interface.
The FGD serves two purposes: populating the Smart Edit feature of WC's entity dialog, and warning the mapper when it looks like an entity has an unused key. It's possible to create a map entirely without an FGD by hand editing the key/value pairs (with Smart Edit turned off)... it's just a major pain. The FGD exposes an easier/faster interface to existing resources (just as WC exposes an easier/faster interface than text editing .map files in NotePad <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo--> ), which is a Good Thing . If there is a key that is missing from the Smart Edit, an FGD tweak could add it--the request to add Zoner's entity shadow flags are an example of this.
What this thread has become is a sort of mapper's entity enhancement wish list--modifying the FGD to get these additions is the simple part of filling the order. I think the tangent started with asking to add fields to items such as master to func_welder (a new capability requiring a source change), then it shifted to adding entire new entity types...
I think it would be nice if the mapper's had the ability to specify the resource node that the marines start with instead of just the closest one to the CC. Actually I do not think this is with the FGD itself but with the coding. Either that or it is set up to default like that if I don't specify which resource node.
In the map I'm making I put the marine start in the middle and I want a RT that is about 128 units from the back of the CC. (Not near it in walking distance of course, it just ends up closer with my map's layout) It is quite large, so I have to cram things in to fit where I want them.
Also if this is possible already and I couldn't figure it out don't be to harsh <!--emo&:p--><img src='http://www.unknownworlds.com/forums/html/emoticons/tounge.gif' border='0' style='vertical-align:middle' alt='tounge.gif'><!--endemo--> (If it is a command you put in as a keyvalue, or Im using an old FGD or something.)
Also, would it be possible to make an entity that makes it so the seige can not see past it? Example- how you can siege most of the Engine Room Hive (The RT but not the actual hive) in Bast from the marine start.
And haveing flags to alow a sound to only be played to the commander.
I realize these would require more than messing with the FGD
<!--QuoteBegin--Jobabob+Feb 24 2003, 08:48 AM--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (Jobabob @ Feb 24 2003, 08:48 AM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin--> I wish people would stop saying 'Id like to see a clean up of the FGD', I already did it, and then did it again. Too bad the search function doesnt work, or else i'd quote the post here.[/URL] <!--QuoteEnd--> </td></tr></table><span class='postcolor'> <!--QuoteEEnd--> Here's the link to You and Eld's respective FGD's and a link in there to your original posting of your FGD:
<!--QuoteBegin--Ollj+Feb 3 2003, 11:29 PM--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (Ollj @ Feb 3 2003, 11:29 PM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin--> Trigger_presence needs to differenciate between aliens and marines. <!--QuoteEnd--> </td></tr></table><span class='postcolor'> <!--QuoteEEnd--> Last time I checked trigger_presence had team one only, and team two only flags under the flags section in VHE.
<!--QuoteBegin--Revenant+Mar 3 2003, 11:00 AM--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (Revenant @ Mar 3 2003, 11:00 AM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin--> What does info_bigmomma do? If it does nothing of importance leave it out <!--QuoteEnd--> </td></tr></table><span class='postcolor'> <!--QuoteEEnd--> Its left over from vanilla half-life, where it allows you to set up AI paths for a monster_bigmomma:
It would be very usefull if info_location could set the dynamic sound effects in the same way an env_sound does. This would save lots of env_sound entities being used for hallways.
Comments
The additional test would only be performed if the mapper explicitly checked the flag, allowing backward compatability and speeding up the common case of axis aligned info_locations. The calculation could stop with the first negative (player out of bounds) result for each info_location, and would never execute for more than 2-3 info_locations whose bounding boxes happen to overlap. This adjustment would allow for adjacent rooms without axial walls to be labeled using a single entity instead of staggering multiple info_locations to follow each of the two walls (picture below illustrates this case):
<img src='http://www.xp-cagey.com/info_location_demo.gif' border='0' alt='user posted image'>
The cost of taking N dot products where N is under 10 (sides of the bounding box) is very small, and this would make life much easier.
Something for mappers to deside what techs are already researched. (It might not get used a lot, but I would find it useful.)
Something for func_weldable to deside if it can be welded and unwelded (or vise versa) a # of times. (Desided by the mapper.)
Moving func_tanklaser (is this possible?). (I would like this for my walking mechs [the mechs are not mine, but someone put them on the really old forums for download, but I am the one who made them "walk"] that I put in my map.)
I'd definately like to see some sort of gorge interaction with the map, but I'd like to have some flexibility with it -- perhaps make a func_gorgespit or use 2 flags (-allowgorge and -ignoremarines) so that we can decide when gorges can close something off and use different brushes/triggered reactions to a gorge finish event than a marine finish event -- essentially, have infestation grow across it instead of having a gorge spit up a steel plate <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' valign='absmiddle' alt='smile.gif'><!--endemo-->.
<!--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-->Something for func_weldable to deside if it can be welded and unwelded (or vise versa) a # of times. (Desided by the mapper.)<!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
Seconded <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' valign='absmiddle' alt='smile.gif'><!--endemo--> I'd also like to see the ability to have it cycle infinite times (specified by -1 in # field?).
<!--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-->Moving func_tanklaser (is this possible?). (I would like this for my walking mechs [the mechs are not mine, but someone put them on the really old forums for download, but I am the one who made them "walk"] that I put in my map.)<!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
It's possible, but it's also an extremely complex item to code for a very specialized case. If this were generalized so that any entity could be attached to move relative to any other entity (like attaching a func_door to a func_train, or a func_wall to a func_platrot) using an "info_relative_movement" point entity, it would be much, much more powerful and would probably give you the functionality you're looking for.
Spec:
key value
"base" "<name of entity to move/rotate with>"
"<name of ent to control>" "<null>"
"<name of ent to control>" "<null>"
"<name of ent to control>" "<null>"
"<name of ent to control>" "<null>"
"<name of ent to control>" "<null>"
etc.
Whenever the base ent moves or rotates, rotate or translate all other entites whose names match the key fields by the same amount. Rotation would be about the origin of the base entity (the base entity would require an origin brush and would therefore need to be brush based). The entities being moved/rotated could be point or brush based (think about moving ent_sparks along with a func_train based elevator, for instance). I think spirit of half-life has something like doors that move with trains, but I haven't investigated how it's implemented or how general a solution is provided.
If you had the relative movement described above, you could attach an env_laser to your mech and have it move when the mech does.
I've been thinking this problem over in my head, and I think the best solution (if Flayra agrees that having the tf activate turrets in spacially close but logically remote rooms is a problem) would actually be at the source code level rather than mapper controlled.
In situations like the one you describe (rooms are close enough for tf range, but not connected in a way that lets you walk there quickly), it's likely that the vis information for those two rooms already contains what you need to know -- the two rooms are not reachable from each other without taking a convoluted path. For vis, that means that the engine won't draw one room when a soldier is in the other, but it could also be used to determine placement of dependant items like turrets and infantry portals (dependant on cc). If a room isn't in the potentially visible set from the factory's (or chair's) position, don't allow building the dependant item. Vis determination would allow more flexibility than direct line-of-sight while still restricting the worst cases.
I believe that this would require far less effort on the mapper's part, and wouldn't be prone to oversight on the mapper's part (after all, it's very difficult to accurately predict all of the consequences of a given layout without extensive playtesting).
The problem that I see this having, however, stems from the fact that the placement area highlight is a circular sprite instead of being tied to level geometry -- the commander sees a green circle no matter where he's trying to place the turret, and it may be counterintuitive for him to realize that he can't place the turret in a logically remote room if it's still within the circle. In fact, vis range is often unpredictable since it's based on which way the map is chopped up by the compiler.
While I can see why putting a turret farm in a remote room from its tf could be abused by sneaky commanders, I worry about the effect on playability if an attempt to limit the problem is made (for the reasons stated above).
Add a 'reweldable' flag to func_weldable: after aliens break a low-health weld, the marines can attempt to weld it closed again. Default to false=no reweld for backward compatability. This allows welds to be low strength (100s of HP instead of invincible) without making them useless and turns them into a possible stalling tactic instead of always being used to change connectivity outright.<!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
I second that request.
I also have an addition to it. Create a new entity called FUNC_HSPRAY.
Func_HSpray would work exactly the same as a weld except with the gorges healing spray.
This combine with the previous request would allow gorges to "Grow" bacteria on an item or button to disable it. It could then be welded or shot open by a marine. The marine could also weld a button locked and a gorge could spray it to have the bacteria get inside the lock and unlock it.
Thanks for the great Mod guys!
GSH
I want func_button to have the flags "only team one" "only team 2" -> just aliens or marines can press one button.
This buttons could cause the same mayor action (open the same door) but just another deelay.
Trigger_presence needs to differenciate between aliens and marines.
Triggeer presence should react on build structures, too.
On ressource nodes "trigger on build" needs a differentiation flag between "build by marines" and "build by gorge".
-
-
trigger presence needs a counter -> that it just reacts if "n" players are inside.
<a href='http://www.unknownworlds.com/forums/index.php?act=ST&f=4&t=18927&hl=target' target='_blank'>http://www.unknownworlds.com/forums/in...18927&hl=target</a>
I want func_button to have the flags "only team one" "only team 2" -> just aliens or marines can press one button.
This buttons could cause the same mayor action (open the same door) but just another deelay.
<!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
I would also like to see this aplied to trigger_hurt, so that enviormental factors could be setup which could hurt one team but not another.
GSH
I would also like to see this aplied to trigger_hurt, so that enviormental factors could be setup which could hurt one team but not another.
GSH <!--QuoteEnd--> </td></tr></table><span class='postcolor'> <!--QuoteEEnd-->
I like that idea, would allow "decontamination" and hive slime that kills marines and not aliens.
How about making the resource point particles semi customizable, with colour selection (like light entities) and style selection (steam, electricity, sparks, etc). Would allow for some nice effects, and would default to white steam for compatibility with old maps.
Yeah, I think I plugged Spirit in my post--just didn't know how it was being done <!--emo&:D--><img src='http://www.unknownworlds.com/forums/html/emoticons/biggrin.gif' border='0' style='vertical-align:middle' alt='biggrin.gif'><!--endemo-->. I wonder if Laurie implemented the movement on a per-entity basis or as an attribute overlay... If he did the latter, it's exactly what I'm thinking of (any item moves with any item without having to code that for individual item types). The end effect is the same either way <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo-->.
Yeah, I think I plugged Spirit in my post--just didn't know how it was being done <!--emo&:D--><img src='http://www.unknownworlds.com/forums/html/emoticons/biggrin.gif' border='0' style='vertical-align:middle' alt='biggrin.gif'><!--endemo-->. I wonder if Laurie implemented the movement on a per-entity basis or as an attribute overlay... If he did the latter, it's exactly what I'm thinking of (any item moves with any item without having to code that for individual item types). The end effect is the same either way <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo-->. <!--QuoteEnd--> </td></tr></table><span class='postcolor'> <!--QuoteEEnd-->
Yes, but with one less entity <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo--> - which is always a good thing.
I wanted a grating (with a "}" texture) that people could walk over and under, but I wanted it so the comm couldn't see the grating or build on it. It seemed like a simple idea, but its not possible (and func_illusionary WON'T WORK, for several obvious reasons), because func_seethrough can only set player and commander opacity, not player and commander RENDER MODES. A player RENDER MODE and FX AMOUNT property, at least, if not commander rendering properties also, would be immensely helpful... I suppose the opacity setting will have to stay for backwards-compatibility, but it could be disabled by setting FX AMOUNT to something > 0 .
So... can it be done? <!--QuoteEnd--> </td></tr></table><span class='postcolor'> <!--QuoteEEnd-->
I used a func_illusionary with a clip brush over it... as it's for a grating there should be no problems with skulks climbing it.
It occured to me that we're all standin around like a bunch of kids at the candy store asking for goodies, and I personally don't even know what's behind the counter.
What can you do with an FGD? I know what I do with it, I make maps. But what can YOU (the coding GODS) do with it?
Some of the stuff I've asked for seems like it would take a little more work than just tweaking the FGD. If I knew a little more about what you CAN do, I could offer better suggestions.
Thanks,
GSH
Pretty much every suggestion I've seen here (except the unused angles key thing and the mention of Zoner's enhancements being migrated to the NS FGD) would require a change to the NS source... the thread has kinda drifted off course (partially--mostly? <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo-->--my fault)--FGD tweaks won't enhance an object's actual capabilities, since the scope of the FGD is entirely inside WC's interface.
The FGD serves two purposes: populating the Smart Edit feature of WC's entity dialog, and warning the mapper when it looks like an entity has an unused key. It's possible to create a map entirely without an FGD by hand editing the key/value pairs (with Smart Edit turned off)... it's just a major pain. The FGD exposes an easier/faster interface to existing resources (just as WC exposes an easier/faster interface than text editing .map files in NotePad <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo--> ), which is a Good Thing . If there is a key that is missing from the Smart Edit, an FGD tweak could add it--the request to add Zoner's entity shadow flags are an example of this.
What this thread has become is a sort of mapper's entity enhancement wish list--modifying the FGD to get these additions is the simple part of filling the order. I think the tangent started with asking to add fields to items such as master to func_welder (a new capability requiring a source change), then it shifted to adding entire new entity types...
Actually I do not think this is with the FGD itself but with the coding. Either that or it is set up to default like that if I don't specify which resource node.
In the map I'm making I put the marine start in the middle and I want a RT that is about 128 units from the back of the CC. (Not near it in walking distance of course, it just ends up closer with my map's layout) It is quite large, so I have to cram things in to fit where I want them.
Also if this is possible already and I couldn't figure it out don't be to harsh <!--emo&:p--><img src='http://www.unknownworlds.com/forums/html/emoticons/tounge.gif' border='0' style='vertical-align:middle' alt='tounge.gif'><!--endemo--> (If it is a command you put in as a keyvalue, or Im using an old FGD or something.)
Example- how you can siege most of the Engine Room Hive (The RT but not the actual hive) in Bast from the marine start.
And haveing flags to alow a sound to only be played to the commander.
I realize these would require more than messing with the FGD
Here's the link to You and Eld's respective FGD's and a link in there to your original posting of your FGD:
<a href='http://www.unknownworlds.com/forums/index.php?act=ST&f=4&t=24963&hl=' target='_blank'>http://www.unknownworlds.com/forums/in...f=4&t=24963&hl=</a>
<!--QuoteEnd--> </td></tr></table><span class='postcolor'> <!--QuoteEEnd-->
Last time I checked trigger_presence had team one only, and team two only flags under the flags section in VHE.
Its left over from vanilla half-life, where it allows you to set up AI paths for a monster_bigmomma:
<a href='http://valve-erc.com/entities/?entity=info_bigmomma' target='_blank'>http://valve-erc.com/entities/?entity=info_bigmomma</a>
It'd be nice to exclude all of the vanilla half-life ents that are no longer needed/supported from the fgd in the future.