Topic [Guide] Actor Types
Vindicator #468
Vindicator
Edited by Vindicator on 10/17/12 8:54 PM (PDT)
Below I've listed all the actor types and briefly described what most do to the best of my knowledge. If you know an explanation for any remaining types, please post below. If I get a good enough understanding of most of them I'll make a video tutorial explaining them all in as much detail as I can. Also, if you have a good grasp of what actors actually are, that might help clear up general confusion regarding the actor tab in the data editor, as it isn't very intuitive to what their general purpose is other than they are a necessary component for many things, such as units, to work. Thanks!

UPDATE: Only need some site operation specifics to make this a complete actor type reference!

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Actor Types- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
  • Action: Manages the many different aspects of a combat action, like launch squibs, hitting target attach volumes, spawning physics, dealing with units attacking from bunkers, etc. There are *many* different options on this actor.
  • Actor List: Stores a list of actors, so that data can send a message to an arbitrary set of them at once.
  • Arc: Arcs for abilities are what define the radius which abilities can be targeted from without a unit needing to turn, so perhaps actor arcs are preset arc values. (guess)
  • Banker (Unit): Banks a unit when it turns similar to a phoenix or viking (guess)
  • Beam (Simple):Draws beams between two actor hosts, which actually gets the job done in a 95% of the cases we have currently.
  • Beam (Standard):Standard beams have a synchronous component are part of a broader infrastructure that we haven’t had a chance to really bulk out yet. The plan is to make beams much more interesting and capable in the future, on both the sync and async sides.
  • Billboard: Used to make sure the actor always facing the camera. You can fix its distance towards the camera or make it so it can't be obstructed. This actor type doesn't have model property itself, it applies these properties to what it is associated with.
  • Camera: Actors for non-gameplay view cameras such as cutscenes and unit preview views such as in the help menu. (Guess)
  • Creep: Actor used by creep to be used in-game. (Guess)
  • Curve Set: Enables various actor properties, like TintColor, to be animated via splines.
  • Doodad: References model and sound data allowing them to show up in the terrain editor for placement.
  • Doodad Effect Spawner: When a burnable doodad is hit by a nuke or firebat fire for example, this is what creates the fire effect on the foliage and doodads.
  • Doodad Preserver: Used to make doodads appear to still exist even though they’ve been killed by enemy creep that hasn’t been revealed b/c of the FoW (Guess)
  • Editor Camera: Allows cameras in terrain editor to be displayed as interactable entities.
  • Editor Point: Allows terrain editor points to be displayed as interactable entities in the terrain module. This includes different point types such as 3d, regular, sound emitters, and pathing blocker points.
  • Event Macro: Packages a set of messages so that can be shared across actors with a single line of data, rather than copying and pasting the same set of messages everywhere. Can also be used to remove sets of messages. Very useful.

      10/17/2012 07:44 AMPosted by Deletarius
      I'd like to reiterate how useful Event Macros are - an example is, say you want to have one set of actor events that will be applied in multiple places throughout data, and on different units, without having to create those events again and again. This is when you would create a new event macro and apply that macro to a unit. The added bonus is that instead of having to modify every instance that would use the "child" events, you can modify the Event Set and anything that references that set will in-turn have their events updated.

  • Global Configuration: Stores global configuration data that has no business being replicated across multiple actor types. So, for instance, we store the custom death priority list here, b/c we should only store this in one place for the entire actor system.
  • Impulses: Impulses are more or less gone now and have been replaced with forces. They enable modders to apply physics forces to models with physics bodies in them, such as ragdoll deaths. Lots of fun to be had with these.
  • Light (Omni Model): References data allowing models to be placed that emit 360 degree (omnidirectional) light.
  • Light (Omni): References data which allows light to be emitted from a point in 360 degrees.
  • Light (Spot Model): References data allowing models to be placed that emit light on a point, or "spot".
  • Light (Spot): References data allowing light to be emitted from a point towards another point or "spot".
  • Look At: This actor type control "Look At" behavior. It need to co-work with triggers and other data. For example, if you use trigger to make actor a look at actor b. A "Look At" actor would be created in a's scope to continually make a look at b, even when b is moving. If you destroy this "Look At", then a would stop track b.
  • Missile:This is the data that projectile shooters reference to define what missiles do and look like.
  • Model:If a model is used for something that is not included in another actor category, then it will likely be found here. Example: The Battlecruiser's yamato cannon charge model is not a unit, doodad, etc. so it's data is instead listed here.
  • Portrait: Contains/displays portraits on the screen.
  • Power: Used to create/config the arts of protoss power field. And it can display different art depend on the power level.
  • Progress: Defines what should happen during different stages of completion of things such as Terran, Zerg, and Protoss buildings being created.
  • Quad: Quad: Used to create directional cursors for linear attacks, like in some MOBA titles.
  • Queried:Creates an actor for every attach point that is returned via the associated attach query. Can be used to arbitrarily attach fire to various damage attach points on a target, for example.
  • Query Response: Used to configure the response to actor queries. Can be used, for instance, to kill all doodads in response to a circular query. Or play an animation on them, tint them a particular color, or whatever.
  • Range: Defines specific details about how a multitude of ranged abilities should act.
  • Region (Arc/Circle/Combine/Game/Polygon/Rectangle/Water): An actor region is a actor with shaped area size. And it could interact with any other actors intersect with it. So it works like the regions in trigger. And you can actually convert a trigger region into a actor region with triggers, which is "Region (Game)". And "Region (Water)" cover are water area of the map.
  • Scene: A singleton actor available in every scene that can be used to configure global settings, like selection halo width.
  • Selection: Defines appearances of unit selection related graphics.
  • Shadow: Defines attributes for ground unit and flying unit shadows.
  • Shield: Defines shield visuals for Shield Impact (below) to utilize.
  • Shield Impact: When a shielded unit is attacked and you see a shield appear to take the damage. This makes the shield appear.
  • Simple: A minimal actor that exists only to send and response to messages in data. Can use any actor for this, but why use the extra overhead of, say, a CActorModel with an invisible model, if you just need the messaging capabilities.
  • Site: An actor that maintains a position and a rotation. Different from siteOps in that it can respond to messages and control the inheritance of hostedProps. Not as easy to chain together as siteOps, however.
  • Site (Mover): A type of Site actor that can move from A to B with configurable acceleration and deceleration. Needs to be a Site rather than a SiteOp, b/c it needs to respond to messages.
  • Site (Rocker): A type of Site actor that can be configured to tilt and sway, like it was floating on top of waves in the ocean, or was being held aloft by an anti-gravity field. Commonly used on loot items that can be picked up in the campaign (search for Pickup in units), as a way of making them stand out from the more static nearby terrain.
  • Site Operation (2D Rotation):
  • Site Operation (Action):
  • Site Operation (Attachment Volume):
  • Site Operation (Attachment):
  • Site Operation (Banker):
  • Site Operation (Basic):
  • Site Operation (Death Motion):
  • Site Operation (Effect):
  • Site Operation (Explicit Rotataion):
  • Site Operation (Forward Vector):
  • Site Operation (Height):
  • Site Operation (Higher Of Terrain And Water):
  • Site Operation (Host Bearings):
  • Site Operation (Incoming):
  • Site Operation (Local Offset): Defines an (X,Y,Z) offset from a host or point. For example, the Thor has a height offset of (0,0,-2.5) from a medivac while it is being carried so that it doesn't overlap the medivac.
  • Site Operation (Motion Direction):
  • Site Operation (Patch):
  • Site Operation (Physics Impact):
  • Site Operation (Random Point In Circle): Allows random points to be chosen in a circle for use with other things. The Thor's barrage ability uses this for example to determine where the explosions occur.
  • Site Operation (Rotation Random): Allows you to randomly rotate a model, perhaps useful for asteroids etc. (Guess)
  • Site Operation (Rotation Rotator): Allows you to rotate a model
  • Site Operation (Selection Offset): Defines the offset of the selection circles (Guess)
  • Site Operation (Serpent Head 2):
  • Site Operation (Serpent Head):
  • Site Operation (Serpent Segment 2):
  • Site Operation (Serpent Segment):
  • Site Operation (Shadow): Defines how a shadow appears in relation to what is casting the shadow. Allows you to define variations in how the shadow is cast based on height and other things of what is casting the shadow.
  • Site Operation (Smooth Rotation):Rotates an actor at a specific speed, likely blended via the video card resulting in updating at your current FPS.
  • Site Operation (Tipability):
  • Site Operation (Up Vector):
  • Site Operation (Variance Rotation):Rotate a model X degrees (guess)
  • Snapshot: Shows a frozen image of a CActorUnit if the player has seen the unit through the FoW, but no longer has vision of it.
  • Sound:These actors define when sounds should play based on when certain conditions are met. For example, every time the zerg hatchery upgrade completes, a sound actor plays the corresponding sound tied to that condition.
  • Splat: A widely used actor that creates a decal on the terrain. Used for blood, scorch marks, shadows and the like.
  • Squib: Helper actor that can create a model and/or a sound together. Supports picking sets of these based on the squibType of the target attach point that they are connected to, if desired.
  • State Monitor: Actor that enables data to monitor arbitrary conditions so to change between arbitrary states and perform actions on the state changes. Used to control the blood gushing from various Zerg buildings as they take damage and/or are healed, for instance.
  • Terrain: Used to control the terrain. (But it isn't the Terrain itself, Terrain isn't an actor!) For example, active/deactive the terrain squibs.
  • Terrain Deformer: Applies terrain deformation to a configurable area. Used to flatten terrain for buildings, create temporary craters when critters are killed, etc.
  • Text: Actors for customizable text that appears in instances such as canceling building and having returned resources displayed.
  • Turret: Refers to turret entities that exist on units at least which can rotate to face targets to attack.
  • Unit: Refers to assets that contain the data required to utilize a unit via placing them in the terrain editor as well as in-game.
Deletarius
Deletarius
Developer
Thanks for posting this thread. I'm going to go through an correct a few, or add further explanation to them from some of the people that actually created the systems themselves. Hopefully this will aid others in better understanding the data editor.



- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Actor Types- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

  • Action: Manages the many different aspects of a combat action, like launch squibs, hitting target attach volumes, spawning physics, dealing with units attacking from bunkers, etc. There are *many* different options on this actor.
  • Actor List: Stores a list of actors, so that data can send a message to an arbitrary set of them at once.
  • The difference between simple and standard beams isn't very big:
  • Beam (Simple): Draws beams between two actor hosts, which actually gets the job done in a 95% of the cases we have currently.
  • Beam (Standard): Standard beams have a synchronous component are part of a broader infrastructure that we haven’t had a chance to really bulk out yet. The plan is to make beams much more interesting and capable in the future, on both the sync and async sides.
  • Curve Set: Enables various actor properties, like TintColor, to be animated via splines.
  • Doodad Preserver: Used to make doodads appear to still exist even though they’ve been killed by enemy creep that hasn’t been revealed b/c of the FoW
  • Event Macro: Packages a set of messages so that can be shared across actors with a single line of data, rather than copying and pasting the same set of messages everywhere. Can also be used to remove sets of messages. Very useful.

  • I'd like to reiterate how useful Event Macros are - an example is, say you want to have one set of actor events that will be applied in multiple places throughout data, and on different units, without having to create those events again and again. This is when you would create a new event macro and apply that macro to a unit. The added bonus is that instead of having to modify every instance that would use the "child" events, you can modify the Event Set and anything that references that set will in-turn have their events updated.

  • Global Configuration: Stores global configuration data that has no business being replicated across multiple actor types. So, for instance, we store the custom death priority list here, b/c we should only store this in one place for the entire actor system.

  • Impulses are more or less gone now and have been replaced with forces. They enable modders to apply physics forces to models with physics bodies in them, such as ragdoll deaths. Lots of fun to be had with these.

  • Quad: Used to create directional cursors for linear attacks, like in some MOBA titles.
  • Queried: Creates an actor for every attach point that is returned via the associated attach query. Can be used to arbitrarily attach fire to various damage attach points on a target, for example.
  • Query Response: Used to configure the response to actor queries. Can be used, for instance, to kill all doodads in response to a circular query. Or play an animation on them, tint them a particular color, or whatever.
  • Scene: A singleton actor available in every scene that can be used to configure global settings, like selection halo width.
  • Simple: A minimal actor that exists only to send and response to messages in data. Can use any actor for this, but why use the extra overhead of, say, a CActorModel with an invisible model, if you just need the messaging capabilities.
  • Site: An actor that maintains a position and a rotation. Different from siteOps in that it can respond to messages and control the inheritance of hostedProps. Not as easy to chain together as siteOps, however.
  • Site (Mover): A type of Site actor that can move from A to B with configurable acceleration and deceleration. Needs to be a Site rather than a SiteOp, b/c it needs to respond to messages.
  • Site (Rocker): A type of Site actor that can be configured to tilt and sway, like it was floating on top of waves in the ocean, or was being held aloft by an anti-gravity field. Commonly used on loot items that can be picked up in the campaign (search for Pickup in units), as a way of making them stand out from the more static nearby terrain.
  • Snapshot: Shows a frozen image of a CActorUnit if the player has seen the unit through the FoW, but no longer has vision of it.
  • Splat: A widely used actor that creates a decal on the terrain. Used for blood, scorch marks, shadows and the like.
  • Squib: Helper actor that can create a model and/or a sound together. Supports picking sets of these based on the squibType of the target attach point that they are connected to, if desired.
  • State Monitor:Actor that enables data to monitor arbitrary conditions so to change between arbitrary states and perform actions on the state changes. Used to control the blood gushing from various Zerg buildings as they take damage and/or are healed, for instance.
  • Terrain Deformer: Applies terrain deformation to a configurable area. Used to flatten terrain for buildings, create temporary craters when critters are killed, etc.




Hopefully this helps clear a few things up for everyone.
Renee #494
Renee
Edited by Renee on 10/17/12 11:43 PM (PDT)
Glad to see you in the forum again, Deletarius.

OK, I will fill in all the rest actor types:

    Billboard :Billboard is, well... billboard. Used to make sure the actor always facing the camera. And you can fix its distance towards the camera or make it cannot be obstructed. This actor type doesn't have model property itself, it more like a site, and you can attach other actors on it.

    Impulse (XXXX): They are all actor forces, they are part of the actor physic system, can be used to create different typed force. But these forces would only affect models which have Physic Body. Since Startools isn't out yet, and I don't believe there is any 3rd party m3 plug-in would support Physic Body either. So far I could only use UltraEdit to directly modify the model files to add Physic Bodies.

    Look At : This actor type control "Look At" behavior. It need to co-work with triggers and other data. For example, if you use trigger to make actor a look at actor b. A "Look At" actor would be created in a's scope to continually make a look at b, even when b is moving. If you destroy this "Look At", then a would stop track b.

    Power: Used to create/config the arts of protoss power field. And it can display different art depend on the power level.

    Region (XXXX): They are actor regions. An actor region is a actor with shaped area size. And it could interact with any other actors intersect with it. So it works like the regions in trigger. And you can actually convert a trigger region into a actor region with triggers, which is "Region (Game)". And "Region (Water)" cover are water area of the map.

    Site Operation (XXXX): They are not 'true' actors, they are more like parameters which are used to adjust the site(i.e. position and rotation) of an actor. You can put them into the Site Operation field of your actor.

    Terrain: Used to control the terrain. (But it isn't the Terrain itself, Terrain isn't an actor!) For example, active/deactive the terrain squibs.

Please report any Code of Conduct violations, including:

Threats of violence. We take these seriously and will alert the proper authorities.

Posts containing personal information about other players. This includes physical addresses, e-mail addresses, phone numbers, and inappropriate photos and/or videos.

Harassing or discriminatory language. This will not be tolerated.

Click here to view the Forums Code of Conduct.

Report Post # written by
Reason
Explain (256 characters max)

Reported!

[Close]