After exploring the galaxy header files, I discovered more Actors and Siteops. Will have them each in their own section, along with my speculation of each.
Actors
ModelMaterial - Possibly define a model material for dynamic squib impacts
ForceLineSegment - Force that is one direction only?
EventMacroRunnable - Possibly allows actor events to be added at run time to actors
Overrides - Possibly allows actor events to be changed at run time?
SiteOrbiter (like Rocker) - Like rocker, but for orbiting about an object.
Site Ops
Orbiter - This is mostly for convenience, since this can be duplicated (badly) by a mix of offsets and rotators.
GameCameraFollow - Possibly quite useful to make something stay on screen at all times.
DeltaSum - Unknown
PersistentOffset
Tether - Possibly a variable local offset (can get up to a certain distance from the host)?
agree, this possibly changing actor events at runtime, could be extremely usefull in this case. Will affect how the same actor could behave in different scenarios
i assume this is something i mentioned in battle.net editor improvements thread, i mean it's not that Blizzard even read my suggestion but maybe they already needed it for their game designers. But maybe it's not that :)
Anyway here is what i suggested in battle.net thread:
"New Site Operation that allows you to attach actor from current position. So for example actor A has some offsets X, Y, Z in relation to actor B. Once being attached to actor B it save his position BUT if actor B (host) moves then it updating position accordingly (while saving the relative offset values).
I mean that 2 actors already exist (maybe even in different scopes) and i don't know the exact X,Y,Z offsets, i just need to attach actor from it's existing position, saving the offset ratio between 2 actors."
I'll just continue my speculation a bit more :)), i think that "tether" is realy what i described above but "delta sum" could be something different.
I think it can be some shyt that allows site(mover) actor to move in local coords of his relative host which will be something realy cool and not possible before. So for example i can have missile that moves straight forward and site(mover) that using this missile as a host (attached with this new SOp) and moving from left to right continiously, in such case i will get a zig-zag movement type, without changing the missile movement procedure in data editor. This could be needed in some rare complex effects, for example if i have a moving beam-star and whant make it to pulsate (changing size from min to max and so on by controling the position of verticies).
But again, maybe it's just my imagination cuz we haven't seen that yet :)
Event Macro Runnable is quite different then what I thought. It permits one to simply create it at an actor, and by doing so, send to that actor all the messages contained within.
This changes Reghars animation blends considerably,
Delta Sums is the relative position actor I think you wanted
<!-- Status Bar --><CActorSiteOpDeltaSumid="SOpStatusBarStabilizer"><DeltasSubject="MountModel"><AttachQuerySourceMethods="Origin"/><AttachQueryTargetMethods="Overhead"/></Deltas><DeltasSubject="_Selectable"><AttachQuerySourceMethods="Origin"/><AttachQueryTargetMethods="Overhead"/></Deltas><DeltaSumFlagsindex="ZOffsetOnly"value="1"/></CActorSiteOpDeltaSum>
From here we can see that adding the second host adds its delta between the attach points to the overall offset. Thus preserving the status bar height, mount or no mount.
From here we can see that adding the second host adds its delta between the attach points to the overall offset. Thus preserving the status bar height, mount or no mount.
Does it mean that they made a separate actor for status bar, or what?
First, it solves that issue with render to texture, when it wasn't possible to asynchronously attach game world models to the camera to use them as screens.
Another interesting use is to have "interface" looking buttons, which would select units without triggers-shmiggers. Those buttons looking actors would be attached to some invisible units holding the abilities, but this sOp will be used, so they'll always stay on screen, and clicking on them would select the units and reveal a bunch of abils in command card.
Also, semitransparent/refractive models could be used for vision modifying. Again, with pure data.
First, it solves that issue with render to texture, when it wasn't possible to asynchronously attach game world models to the camera to use them as screens.
Another interesting use is to have "interface" looking buttons, which would select units without triggers-shmiggers. Those buttons looking actors would be attached to some invisible units holding the abilities, but this sOp will be used, so they'll always stay on screen, and clicking on them would select the units and reveal a bunch of abils in command card.
Also, semitransparent/refractive models could be used for vision modifying. Again, with pure data.
After exploring the galaxy header files, I discovered more Actors and Siteops. Will have them each in their own section, along with my speculation of each.
Actors
ModelMaterial - Possibly define a model material for dynamic squib impacts
ForceLineSegment - Force that is one direction only?
EventMacroRunnable - Possibly allows actor events to be added at run time to actors
Overrides - Possibly allows actor events to be changed at run time?
SiteOrbiter (like Rocker) - Like rocker, but for orbiting about an object.
Site Ops
Orbiter - This is mostly for convenience, since this can be duplicated (badly) by a mix of offsets and rotators.
GameCameraFollow - Possibly quite useful to make something stay on screen at all times.
DeltaSum - Unknown
PersistentOffset
Tether - Possibly a variable local offset (can get up to a certain distance from the host)?
Tilter - Not sure.
thanks, was waiting for you to post this.
this is very useful stuff, i already faced necessity of this few times when working on buff visualisations.
agree, this possibly changing actor events at runtime, could be extremely usefull in this case. Will affect how the same actor could behave in different scenarios
i assume this is something i mentioned in battle.net editor improvements thread, i mean it's not that Blizzard even read my suggestion but maybe they already needed it for their game designers. But maybe it's not that :)
Anyway here is what i suggested in battle.net thread:
"New Site Operation that allows you to attach actor from current position. So for example actor A has some offsets X, Y, Z in relation to actor B. Once being attached to actor B it save his position BUT if actor B (host) moves then it updating position accordingly (while saving the relative offset values).
I mean that 2 actors already exist (maybe even in different scopes) and i don't know the exact X,Y,Z offsets, i just need to attach actor from it's existing position, saving the offset ratio between 2 actors."
Not sure what more can offer orbiter in compartion to rotator+rocker+offset combo.
The orbiter and tether site ops are so sorely needed. Can't wait to use them!
I'll just continue my speculation a bit more :)), i think that "tether" is realy what i described above but "delta sum" could be something different.
I think it can be some shyt that allows site(mover) actor to move in local coords of his relative host which will be something realy cool and not possible before. So for example i can have missile that moves straight forward and site(mover) that using this missile as a host (attached with this new SOp) and moving from left to right continiously, in such case i will get a zig-zag movement type, without changing the missile movement procedure in data editor. This could be needed in some rare complex effects, for example if i have a moving beam-star and whant make it to pulsate (changing size from min to max and so on by controling the position of verticies).
But again, maybe it's just my imagination cuz we haven't seen that yet :)
Ok, went digging for usages examples
Event Macro Runnable is quite different then what I thought. It permits one to simply create it at an actor, and by doing so, send to that actor all the messages contained within.
In this case, it is created via Skin data and does the texture swapping in Storm for skins.
Overrides lets you override the model animations and apply custom animation blends at will.
This changes Reghars animation blends considerably,
Delta Sums is the relative position actor I think you wanted
From here we can see that adding the second host adds its delta between the attach points to the overall offset. Thus preserving the status bar height, mount or no mount.
Does it mean that they made a separate actor for status bar, or what?
Forgot to Add
Model Material is hilariously powerful. You can now apply other materials on top of the host.
And to make things even nicer, in the Global Config actor, you can setup which model material wins when multiple are applied
@abvdzh: Go
Yes
Site Actor, which is then used...
Model Material, if you play storm, is how Living Bomb does its graphic, same with black arrow from Sylvannas.
Oh that's pretty nice. Does the claok effect take advantage of this since it's a similar style of graphic?
Oh, finally. If it is what it sounds to be.
First, it solves that issue with render to texture, when it wasn't possible to asynchronously attach game world models to the camera to use them as screens.
Another interesting use is to have "interface" looking buttons, which would select units without triggers-shmiggers. Those buttons looking actors would be attached to some invisible units holding the abilities, but this sOp will be used, so they'll always stay on screen, and clicking on them would select the units and reveal a bunch of abils in command card.
Also, semitransparent/refractive models could be used for vision modifying. Again, with pure data.
@ArcaneDurandel: Go
Is there anything, that would give a cue for terrain deformer actors improvements?
GameCameraFollow does extraly what you think. While command card things can be done better with the new dialog control "commard card".
The custom status bar are still UI frames. The actor are used to 'position' the frame. So they are mainly actor sites.