Requested Fgd/mapping Fixes For Next Version Of Ns
BreadMan
Join Date: 2002-12-15 Member: 10854Members, Retired Developer
Join Date: 2002-12-15 Member: 10854Members, Retired Developer
<div class="IPBDescription">Post em here</div> Ok, I know I don't have any authority here or anything, but I wanted to get a topic like this started.
My 2 big things:
- Put gamestartedstatus back in
- Put in-game particle editing back in
That is all. It would be great to see an official post of planned fixes sometime, if possible.
My 2 big things:
- Put gamestartedstatus back in
- Put in-game particle editing back in
That is all. It would be great to see an official post of planned fixes sometime, if possible.
Comments
Could a mod please sticky this thread. This is a fantastic post idea. This will be useful to Flayra (and mappers), and will help NS become a more stable MOD to map for.
Also people, please make sure your suggestions are reasonable and sane. Stupid suggestions will be deleted (I'll make sure of that). Having said that, if your post is deleted and you don't know why, just assume that it was a bad idea, or not worth the effort of implementation.
If you are reporting a bug, PLEASE elaborate and include any extra information you can (see below for an example). For instance, don't do what tommyd did. Say what the problem is, state any experiments you've done and the results, whatever. Anything you think is useful, but use your head when explaining. Also, do not assume that Flayra knows everything about mapping. If background information for a problem is needed, GIVE IT, or if you can't think of a way to explain, then at least post a link to the relevant information on <a href='http://www.valve-erc.com' target='_blank'>http://www.valve-erc.com</a>. I assume all mappers know their way around this site already.
Anyway, here is my bug:
Currently, multisources do not recognise when they are being targetted by func_weldables. As it is, to target a multisource with a weld (which is vital to 'lock' doors), you must have it target a trigger_relay which in turn targets the muiltisource. This uses up an extra entity, and as we all know, entity usage is a big concern with mapping so the less entities the better.
The problem is that the multisource does not recognise that the func_weldable is targetting it (at all times, not just when it is triggered). Multisources must be able to tell what is targetting it because of the way it works. If more than one entity is targetting a multisource, then ALL those entities must be triggering it at once for it to 'switch' from one state to another. If it doesn't recognise that anything is targetting it then it assumes that nothing WILL target it, and so is useless.
[edit] And another: func_seethroughs with a ground-player render amount under 255 are not shootable. Also, when the same render amount is set to 0, the brush appears solid. The entity seems to work fine in commander mode. [/edit]
Now, what would I like to see... Render mode on func_seethroughs.
Something to improve PS editing, as I haven't been able to do that, no matter how many NSTR's I have.
Thats all I can think of now.
gamestartedstatus, According to the official guidelines NS is supposed to fire this trigger at the start and end of a round. The NSTR used to do this. NS Doesn't.
Team_hive ('target on spawn' property)
In theory you can toggle the status of an entity using this property of a hive. However if a hive that is active when the map is loaded is the first hive of the game the entity gets toggled twice (once when the map is loaded and once when the game starts).
Func_Resource ('target on build' property)
You can toggle the status of an entity using this property of a resource node. This fires once when the node is built and again about second later, just before it starts animating. So even though a resource node is built on my trigger is in the off state.
I have a test map to demonstrate all of the above if you want it.
Trigger_presence
When using it to create automatic doors (two momentary_doors moving in oposite directions), one door moved normally the other moved instantly.
For additonal entities i'd like to request pre-configured particle systems for things like fog(brush), a jet of steam(point entity targeting another point entity for the direction) and rain(brush). I'm too lazy for my own good <!--emo&;)--><img src='http://www.unknownworlds.com/forums/html/emoticons/wink.gif' border='0' valign='absmiddle' alt='wink.gif'><!--endemo-->
Fix trigger_camera and trigger_gravity.
Invisible from commander view func_wall and func_illusion.
Thats all I can think of at the moment.
[EDIT] Oh yes, and the 'invisible from top down' property isn't enough sometimes. I've encountered a roadblock on two occasions because func_seethrough has no render properties. So please either add render properties to func_seethrough, or commander visiblity properties to func_wall and func_illusionary. It would rule if that were implemented!
i havent yet used the particle system, but ive heard thats very buggy also.
if i come across another oddity ill be sure to post.
nope, it is in WC/hammer, not the fgd. that is why it has not been fixed yet.
fgd is easy to fix, the WC/hammer editor can only be fixed by the authors - valve employees who are busy at other PAYING duties, instead of programming a non paying map editor.... <!--emo&:p--><img src='http://www.unknownworlds.com/forums/html/emoticons/tounge.gif' border='0' valign='absmiddle' alt='tounge.gif'><!--endemo-->
i think if you use QUARK or some other editor, you no longer have that problem - but then you have to learn a new editor......
<!--emo&::asrifle::--><img src='http://www.unknownworlds.com/forums/html/emoticons/asrifle.gif' border='0' valign='absmiddle' alt='asrifle.gif'><!--endemo-->
also what would be cool, since the new team size restrictions have been put in some kind of enity (func) that could be used in the ready room to restrict players from entering the team sides, i.e a func_door that closes when the marine team is full etc.
A window, with a sky bg outside it. Run away from the window, the sky image gets bigger (looks closer). Run towards the window the image gets smalelr (loosk further away). I wanted to know if this is a general mapping problem? If not it can be fixed. (I used the 'mars' sky image when i found this)
Well..yeah, the background image stays the same and the rest changes perceived size. I don't see the problem myself?, maybe I'm missing something, but that background image you speak of <i>is</i> just a background image. It doesn't, and can't, and shouldn't, shrink, or get bigger, or do anything..
What you speak of sounds to me exactly like what the background is supposed to do in Half-Life <!--emo&???--><img src='http://www.unknownworlds.com/forums/html/emoticons/confused.gif' border='0' valign='absmiddle' alt='confused.gif'><!--endemo-->
CLIP can't be climbed by skulks, and func_wall adds to the entity count and doesn't remove any extra collision hulls that it might cover (because its an entity). This is a problem.
There are two solutions I'd suggest, the simplest being to make it so Skulks can climb CLIP brushes. The other solution would be to include a new special texture, such as HULL or WALL or something, that might allow bullets to pass through like CLIP, but allows the skulks to walk on it and causes any extraneous collision hulls to be compiled out. I dunno how this latter suggestion might be achieved... it might require a compiler modification as opposed to a change in the mod code. Although, I'm all for an NS-specific map compiler... it would allow the inclusion of many more advanced mapping features!
Anyways, I would be very glad to see this problem fixed, for the sake of Skulks and Mappers everywhere!
maybe on these entities there would be a "rescuable" flag on it, so that when a marine goes near it the marine team would own it. it would open up LOTS of possablilites such as a "rescue the base" mission.
Long before you came around, this was heavily discussed and attempted. Both Flayra and Merl (of Merl's custom ZHLT build fame) tried to find a solution that could be made with a new compile parameter or function, or a solution that could be made with a small alteration in the NS code. Short answer, impossible without a complete rewrite of the wallclimbing code. And the time and effort associated with that greatly outweighs the benefits. <!--emo&???--><img src='http://www.unknownworlds.com/forums/html/emoticons/confused.gif' border='0' valign='absmiddle' alt='confused.gif'><!--endemo-->
Maveric: There may be support for that in the future (any tutorial level would kinda suck if there weren't already pre-built bases to destroy and stuff).
*notices for the first time that Greedo's avatar blinks several different colors after a while*
Ooh, cool.
ive placed about 50 of these in a map, just a real basic map
and no matter how many res points you build on your resource points still go up 1 at a time, it doesn't accumulate more at all <!--emo&:angry:--><img src='http://www.unknownworlds.com/forums/html/emoticons/mad.gif' border='0' valign='absmiddle' alt='mad.gif'><!--endemo-->
Skulks dont need to climb ladders as they can climb any surface (Apart from the clip node). Really its lerk that has a problem. especially on the ventilation hive in ns_caged.
ive placed about 50 of these in a map, just a real basic map
and no matter how many res points you build on your resource points still go up 1 at a time, it doesn't accumulate more at all <!--emo&:angry:--><img src='http://www.unknownworlds.com/forums/html/emoticons/mad.gif' border='0' valign='absmiddle' alt='mad.gif'><!--endemo--><!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
because to test your map you are using cheats mode - and it will not let you have more than one res pnt at a time.
if you really want to test the resourcers, you are gonna have to get bots and play a game without the cheat mode on. or get some friends into a lan game.
There's a flag on func_illusionary to toggle whether the commander can see it or not (and the other way around for commander view only illusionarys)... is there a specific reason why you'd want to have a func_wall that the commander can't see? It would still register as a surface for building, so I'm not sure this is what you want. If you do actually want an invisible build platform that ground troops can see, you can combine a func_illusionary with invis to commander checked (to get it to look right) and a null-textured or alpha level 0 rendered func_wall (invisible to all, physical properties of a func_wall).
---------------------
The quick fix I'd really, really like added to the func_wall spec is a <a href='http://www.unknownworlds.com/forums/index.php?act=ST&f=5&t=15545&hl=func_wall' target='_blank'>nobuild flag</a> -- if checked, the func_wall acts as a visible func_nobuild. This would reduce the number of ents required to make a wide railing, for instance, nobuild for the marines.
While I'm on the subject of enancing the fgd to lower map complexity, I have another more long term enhancement request that would require client side changes: attachment of models to moving ents like doors and trains(quake 3 allows this). Basically, in addition to the brushwork you want to use, you specify a .mdl file, origin brush, and start orientation (yaw pitch roll), and the model moves/rotates with the brush ent in the game--useful for adding complex shapes like door knobs (which are specifically less applicable in this game universe, but bear with me) without needing to do detailed brushwork that eats up map resources (MAX_MAP_PLANES, etc). Having an offset (x y z) for the model from the origin of the item would also be nice for items like func_trains which have another use for the origin brush. If you use custom animation to move the model along the path of the object on trigger, you can sort of fake this now, but it's pretty resource intensive (in terms of both creation time and game resources for scripting).
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?
I can see why it won't work on its own, but why not in combination with an invisible func_seethrough?
POST FUNC_SEETHOUGH PLAYER ALPHA BUGFIX: Use player and commander alphas of 0 on the seethrough, check no commander view on the illusionary, set the illusionary render to solid with fx amount 255, and you're set--once the player alpha seethrough bug is fixed. The invisible func_seethrough provides the physics, and the func_illusionary provides the graphics.
PRE FUNC_SEETHROUGH PLAYER ALPHA BUGFIX: Change the func_seethrough to a player alpha of 255 (keep commander at 0 so the ent is never considered for comm render) and use null texture on the entire entity, effectively making it invisible.
If you want to block the commander from building under the grate, sub a func_nobuild for the func_seethrough.
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.