An Entity I'd Like To See
taleden
Join Date: 2003-04-06 Member: 15252Members, Constellation
Join Date: 2003-04-06 Member: 15252Members, Constellation
<div class="IPBDescription">if such a thing is doable</div> The short version: A "func_container" entity whose sole purpose is to facilitate the relocation of other entities.
The long version: Basically a func_container would work sort of like a func_door, except it would be invisible in the game (like, say, a location entity, or a team_join) and wouldn't have the sounds and other things associated with physical doors. Instead, a func_container's properties would be these:
name : a func_container would have to be named in order to have another entity activate it
master : as usual - if the master is disabled, this entity will never do anything
deltax : linear distance to travel in the X dimension when activated
deltay : " " Y dimension " "
deltaz : " " Z dimension " "
speed : speed of travel
follow : another entity to shadow; explanation below
The basic idea is that when activated, a func_container would move (like a door does when activated), but it would take all entities inside it along with it. This could either be defined as centerpoint containment or by any spacial overlap, but it would allow mappers to draw a func_container around some entities they want to move, which would otherwise be incapable of movement. This would allow for things like moving alien or marine spawn points during gameplay (for example, to let the marines change the spawns used by the "emergency beacon", or something); to allow buttons on elevators that move with the elevator, without using a complicated network of other entities to "simulate" the moving button; a hive room that's on a train - perpetually moving around the map (that could be kinda neat..) and a whole host of other things - I'm sure other mappers can think of creative uses for moving entities.
Naturally some entities would be exempt from movement; we'd have to think long and hard about which entities really shouldn't be moved for various reasons. Relocating hive entities might be a bad thing, unless the hive room names listed for the alien team could be updated; relocating point lights would be silly because the light they cast can't be moved; etc.
Some more details: the interface by which a mapper tells the func_container how to move when activated would be a little tricky to implement. I'm thinking there ought to be two basic modes:
1) Specify another entitiy which the func_container should follow (the 'follow' property). So if you specified a func_door, whenever the func_door moved (on activation, on auto-close, maybe even as a result of another func_container), then this func_container would move in exactly the same way, maintaining the same relative position. This would be ideal for things like buttons on elevators: specify the elevator entity as 'follow', and whenever the elevator goes up or down, the func_container would carry the button with it. It would even allow for multiple stopping points on an elevator or train, whereas the simulated method (putting an invisible button at each possible button location and then enabling the current one) would eat up a LOT of entities handling that case.
2) Specify specific X, Y and Z offsets to apply when the func_container is activated; when activated again, the offsets would be applied in reverse, to create a toggle effect. The speed of movement would be determined as usual by a 'speed' property; there could even be a 'toggle' flag, like in func_doors, that determines whether the func_container can be toggled this way or if it's a one-shot movement. If the 'follow' property was non-empty, then deltax, deltay, deltaz, speed and name would be ignored, since all of these things are only necessary for the externally triggered linear movement method; the follow method requires only the entity to follow.
Anyway, this is a whole lot of detail (in case Flayra has the time, inclination, etc to actually do it), so I apologize for the long windedness. My basic questions now are:
- Mappers, is this something you could make use of? I for one could, that's why I wrote it, but maybe nobody else really sees the need for something like this.
- Coders, is this possible? Can a mod such as NS introduce a fundamentally new kind of entity, like this, or is this something that would have to be added in HL's core engine? Is it even possible at all? I don't know how HL handles entities, maybe moving them after the map loads is just not possible. Would follow mode work? It occurs to me that it might be a severe CPU drain to have to check all the time whether a func_container's master has moved, unless you could set up some linkage so that it knows whether another entity is following a given entity without checking all of them.. anyway, what do you think?
The long version: Basically a func_container would work sort of like a func_door, except it would be invisible in the game (like, say, a location entity, or a team_join) and wouldn't have the sounds and other things associated with physical doors. Instead, a func_container's properties would be these:
name : a func_container would have to be named in order to have another entity activate it
master : as usual - if the master is disabled, this entity will never do anything
deltax : linear distance to travel in the X dimension when activated
deltay : " " Y dimension " "
deltaz : " " Z dimension " "
speed : speed of travel
follow : another entity to shadow; explanation below
The basic idea is that when activated, a func_container would move (like a door does when activated), but it would take all entities inside it along with it. This could either be defined as centerpoint containment or by any spacial overlap, but it would allow mappers to draw a func_container around some entities they want to move, which would otherwise be incapable of movement. This would allow for things like moving alien or marine spawn points during gameplay (for example, to let the marines change the spawns used by the "emergency beacon", or something); to allow buttons on elevators that move with the elevator, without using a complicated network of other entities to "simulate" the moving button; a hive room that's on a train - perpetually moving around the map (that could be kinda neat..) and a whole host of other things - I'm sure other mappers can think of creative uses for moving entities.
Naturally some entities would be exempt from movement; we'd have to think long and hard about which entities really shouldn't be moved for various reasons. Relocating hive entities might be a bad thing, unless the hive room names listed for the alien team could be updated; relocating point lights would be silly because the light they cast can't be moved; etc.
Some more details: the interface by which a mapper tells the func_container how to move when activated would be a little tricky to implement. I'm thinking there ought to be two basic modes:
1) Specify another entitiy which the func_container should follow (the 'follow' property). So if you specified a func_door, whenever the func_door moved (on activation, on auto-close, maybe even as a result of another func_container), then this func_container would move in exactly the same way, maintaining the same relative position. This would be ideal for things like buttons on elevators: specify the elevator entity as 'follow', and whenever the elevator goes up or down, the func_container would carry the button with it. It would even allow for multiple stopping points on an elevator or train, whereas the simulated method (putting an invisible button at each possible button location and then enabling the current one) would eat up a LOT of entities handling that case.
2) Specify specific X, Y and Z offsets to apply when the func_container is activated; when activated again, the offsets would be applied in reverse, to create a toggle effect. The speed of movement would be determined as usual by a 'speed' property; there could even be a 'toggle' flag, like in func_doors, that determines whether the func_container can be toggled this way or if it's a one-shot movement. If the 'follow' property was non-empty, then deltax, deltay, deltaz, speed and name would be ignored, since all of these things are only necessary for the externally triggered linear movement method; the follow method requires only the entity to follow.
Anyway, this is a whole lot of detail (in case Flayra has the time, inclination, etc to actually do it), so I apologize for the long windedness. My basic questions now are:
- Mappers, is this something you could make use of? I for one could, that's why I wrote it, but maybe nobody else really sees the need for something like this.
- Coders, is this possible? Can a mod such as NS introduce a fundamentally new kind of entity, like this, or is this something that would have to be added in HL's core engine? Is it even possible at all? I don't know how HL handles entities, maybe moving them after the map loads is just not possible. Would follow mode work? It occurs to me that it might be a severe CPU drain to have to check all the time whether a func_container's master has moved, unless you could set up some linkage so that it knows whether another entity is following a given entity without checking all of them.. anyway, what do you think?
Comments
/me crawls back into his hole and boots up Hammer
All this has not ben prooven detailed some stuff is tricky, all this WILL cause serveral bugs.
Func_rotate:
When it has a name it can be toggled by the commander, if not the comander can build on it and everything thats build on it (except a CC) will rotate along the xy axis.
The rotating includes the green TF/Turret/siege radius, you can see the TF radius rotating making sieges in range ... out of range ... in range ...) .
A placed CC will stay in the air.
Grouping a hive in the func_rotate will make the hive rotate with it <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo--> (seen in ns_runaround).
Any object blocking the rotation wil make the rotation stop till it dies.
-> this is a nice gag for a static roation.
func_train + func_tracktrain:
When it has a name it can be toggled by the comander, when it has no name the commander can build on it AND you still might use the train like a vehicle.
When the train looks up/down an ip standing on it looks werid.
ANY func_train func_tracktrain moves structures on the bottom around till they get blocked by a player,wall or second structure (seen on ns_cydonia in the hydropinic hive (robot)).
This can be used in many different ways causing many different bugs and exploits.