Emp eng map model master

From Empires Wiki
Revision as of 06:41, 2 March 2009 by JoeSmuckPermissionsTest (talk | contribs) (New page: == Concept == New entity which allows multiple emp_eng_map_models (or a special entity which is designed to work with this) to be tied together into one buildable with shared health and re...)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search


New entity which allows multiple emp_eng_map_models (or a special entity which is designed to work with this) to be tied together into one buildable with shared health and respawn times, essentially allowing many models to function as one emp_eng_map_model. Handles a bit like env_cubemap.

New KeyValues

  • ModelList
List of entity IDs to tie together into a single object, picked like cubemap faces with env_cubemap.
  • BuildTimeMultiplier
This K/V can be used to scale the build/repair speed in relation to the health of the entity, currently I believe health and build time are directly proportional, however a value of 0.5 for this mutliplier would make the build equal to a model with half as much health, while a multiplier of 2 would make it take twice as long. This could also be hadded to the existing emp_eng_map_model

Inherited properties from emp_eng_map_model

  • Name : Name of the Entity This name will affect the conjoined meta-object in the game world, so changing the health of the object named would change the health of all models connected to the master
  • Pitch Yaw Roll : This entity's orientation in the world. Obviously not needed because the master object does not have an orientation, all models are placed seperately
  • Model : the model to use on this entity. Also obviously unneeded
  • Number of the Parent Capture Point : If this entity is to be enabled/disabled in association with the capture/loss of a capture point, input the associated capture point's number (defined in the capture point's properties) Would function the same way it does currently, tying the unified object to a capture point
  • Initial Owner : This is the team that initially owns the object. This should only be set for objects that are not associated with a control point. As above
  • Changes Ownership : This option affects automatic enabling/disabling from an automated capture point. If no, this object will be disabled when the other team holds the capture point and enable when the initial owner recaptures the point. If yes, this object will change teams as the capture point is captured. As above
  • Raise Object On Build : If yes, this entity will start at only 25% of its final height and will raise up to its full height as it's built. It's a good effect for tall objects like walls. This may be difficult to code, it is not a neccesity because it would probably not be practical to use anyway for complex objects constructed with this entity
  • Solid On Spawn : Does this entity start solid or does it need to be fully built first? As with emp_eng_map_model
  • Visible To Enemy When Not Solid : Can players of the enemy team see this object if it hasn't been fully built yet (if 'Solid On Spawn' is yes [above], then this is ignored). As above
  • Time To Respawn : Time in seconds for the object to respawn and be buildable again after being destroyed. A time of 0 seconds will never respawn until it is disabled and/or changes teams. As above
  • Structure's Initial Health : The initial health of the object on spawn. As above
  • Structure's Max Health : The maximum health of the object and when it becomes fully built after being repaired by an engineer. As above
  • Only Grenadier Can Harm : If yes, then only the grenadier can harm this object, and his rpg does normal damage. Use this for creating obstacles in your map that only grenadiers can get through. If no, then enemy engineers can deconstruct it, and all blast damage does a reduced amount of damage to it. As above, although I can't think of any real practical use for this keyvalue.
  • Solid On Respawn : After this is destroyed and it respawns, does this entity start solid or does it need to be fully built first? As above


Could be the same as emp_eng_map_model as the entity would function the same in the game world.

  • EnableOutputs and DisableOutputs
These enable/disable the outputs. They would likely be needed to prevent the problem of people repeatedly attempting entering/exiting the brush.


Again, the same as emp_eng_map_model, all the usual reports such as:

  • OnKill / OnKillBE/NF
Fires when a (BE/NF) player kills the entity.
  • OnBuild / OnBuildBE/NF
Fires when a (BE/NF) player builds the object.


Made the page, march 2nd. I also wonder whether or not it might be worth having a 'levels' system in this, for example when the structure is fully destroyed, the first level to be built is level 1, then once level 1 is built, level 2 becomes available, it would basically be a self contained entity version of the current method of making multi-level buildables except without all the hacky entity work involved. You could simply make one set of health and modellist K/Vs for each level, so you would have 'Level 1 health: 500, Level 1 models: 140, 135, 132, 124' followed by 'level 2 health: 1200, level 2 models: 240, 236, 235' and so on, as well as a keyvalue along the lines of 'Delevel when damaged?' which, if set to one, has the health of each level be for that level only, and doing that much damage destroys the models of that level only. If set to zero, levels add health to the base structure, and when all health is lost, the whole structure is destroyed simultaneously.

Respawn times could be set per level, or all levels could use the base respawn time, so if one level is destroyed, you have to wait the respawn time to rebuild it. Health can only be removed from the highest level, so shooting the midsection of a multi-level tower does not destroy all levels above it, when a new level is built, the previous level is fully healed, so if the new level is destroyed you don't come back to a damaged level.

Of course this is all up in the air, you could do this but it might not be neccesary, although it would be a lot of work, the base functionality of this object would go a long way towards expanding and streamlining the potential of map buildable objects. -Chris0132