SC2Mapster

Ok. NOW I think its solved.

If you want your secondary model actor to inherit the units Fog Visibility you need:

Snapshot - Visible

Alias - _Snapshot

Inherit Properties - Visibility = checked

EDIT:
Doesn't seem to work the same for Resource Units...

The Minimap Icons are never hidden, and setting SnapShot to Visible on a Resource Unit Type just makes the secondary model always visible...

I think I solved it. 

Apparently, secondary Model Actors need to be set to "Visible" in order to inherent their Unit's Fog Visibility.

EDIT:
Or not.

It worked on a mobile unit who's secondary model was a turret, but not a structure who's secondary model was spawned via the Actor Events..

Ive made several unit's that have secondary model actors attached, but those secondary models do not seem to inherit the unit's Fog visibility.

The Unit is set to SnapShot(and so are all its models), but the secondary model actor disappears in the fog while the main model remains.

How can I ensure that ALL models on an actor maintain the same fog of war visibility settings as their Unit?

Thank you both.

Very helpful. :)

Ive noticed some sounds Im using get muted if I fully zoomed out the camera, or if I move it far enough away from the source of the sound.

But that some sound do not do this. I can hear some sounds even when fully zoomed out, or clear on the other side of the map.

I can't seem to find the settings to determine which sounds do this and which don't, or at what range it occurs.

Where can I find these settings, if they exist?

Figured it out. Well, technically a work around.

I couldn't get HostSiteOpsRemove or HostSiteOpsAdd to work, but this fulfills my goal:

UnitActor Events:

UnitBirth=>

  Create MiddleManActor

MiddleManActor Events:

ActorCreation=>

   Create ModelActor

   Attach ModelActor SOpOffset, SOpRotator

Behavior.Off=>

   SetRotationFrom ModelActor

Behavior.Off=>

   Attach ModelActor SOpOffset

Behavior.On=>

   Attach ModelActor SOpOffset, SOpRotator

I have a UnitActor that Ive attached a rotating ModelActor to.

I want the ModelActor to stop rotating while the unit has a stun behavior applied.

Attachment process:

In the UnitActor's Events:

ActorCreation=>

    Create ModelActor

In the ModelActor's Host Site Operations:

Spinner (SOpRotator)

In the ModelActor's Event's:

Behavior.Stunned.Created=>

   HostSiteOpsRemove - UnitActor, Spinner (SOpRotator), Tail Immediate

During testing it throws a warning and does not stop rotating:

(ModelActor) Cannot remove site ops on Host UnitActor.

How should I go about this?

Ok.

Ive not messed with items much. After checking them out, I see what you mean.

The only thing I can think of is to have an apply behavior Effect for the bonus damage, then an Issue Order Effect that points to the Use Item (Target) command in the Inventory ability. Not sure how to tell it to use a specific item in the inventory tho. Like I said, Ive not messed with items much.

EDIT:
Or maybe Use Magazine?

It has a "Ammo Unit" field that seems to accept Items.

Ah.

So in the context of your OP, I am assuming this unit can somehow switch out its weapons and this ability needs to deal its damage (+20% bonus) based on whatever weapon is currently in use?

EDIT:
If that is the case, I would have all weapons intended to be used by the unit to have the same base damage.

Then at the beginning of the effect chain, apply a behavior to the caster that increases the damage to what you want for that weapon.

Then as posted above, in the pre effect behavior of each weapon add a different behavior with a damage dealt fraction of 1.2

The annoying part is that Im not sure if behaviors can ADD fix damage values, so you would have to do some math to figure out what the per weapon behavior bonus is going to be.

If the spell is a weapon:

I would try:

Make a non stacking Buff Behavior that has Modification > Damage Dealt Fraction set to 1.2

Set that behavior in the Weapon's Pre Effect Behavior field.

That should apply the behavior before the Weapon's Effects are started, and increase the units damage by 20%

Otherwise just make an ability that applies the behavior to the caster..

How exactly is this spell meant to be used?

...

I already know how to copy and paste an event... I meant is it possible to tell an Attached model to call the same animations as its Host at runtime.

Something like:

Event: AnimPlay.HostActor.Any

Message: AnimCopy - Actor: HostActor

One could also make octagon wheels for a car. Does not mean you should as they will not be better than round ones.

And figuring out that rounder is better, came about by trying things that were not round first.

Nothing new is ever made by sticking to what is already known.

And that is when "you really have a reason to".

Im not saying there shouldn't be reason behind a mod change, just that "Genre Standards" should not be used as a valid reason against a change, unless that is the map or mod's specific goal. And certainly not a valid reason for suggesting the "How To" someone posted, or the goal of that "How To", should be considered "not recommended".

There is no need to apply that label to the knowledge or tool, it is the knowledge or tools use that the label can be applied to.

If someone comes to these forums and says they want to make a standard RTS melee map with extra dark Team Colors, then that is a useful situation to bring up Genre Standards. Otherwise you are just suppressing the motivation(unintentionally or otherwise) for gathering and presenting information and tools that people could use.

Only reason vanilla gameplay uses bright colours is so people do not get mixed up whose units are what.

Temporarily mixing people up on whose units belong to who can be made into an ability tho.

Similar to stealth or cloaking, except more for disruption.

This is what Im talking about.

You are missing the point of the bright colors. They are there for Feedback. If you change the colors it just means you need to do something else as feedback to let the player know something changed.

If you precede the temparary team color change with some kind of unavoidably noticeable screen effect(or even a blatant direct text message), then changing the colors becomes expected by the player.

But I digress, Im getting too deep into design. The point is not to dismiss information or a tool as "Only for X".

Or do I have to manually call the animations in the attached models Events+ field?

I know Gather and Attack, ect.. animations are already done this way in the base actor. But Walk and Stand are handled via the Unit Actor's Animation: Baselines field. 

It would be a lot easier if I could just tell the Attached Actor to copy all the animations of its Host...

No offense but I say editing team colors is fine.

"Confusing people" is not reason enough not to.

Modding, and that is what we are doing here, is meant to create change from vanilla. From the standard.

Don't get me wrong, you don't always want to confuse the player, but if they are playing your map at all then they are already playing a non-standard map or mod. They should already have a baseline understanding that its going to have changes. Discovering and experiencing those changes is part of the fun, and part and parcel of playing a modded map to begin with.

Being forced to adhere to a preset genre standard is one of the things that can kill modding communities, and StarCraft2's editor is already afflicted with two of the other things. A Complicated Editor, and a lack of information on the Editors functions. The Wiki has done a decent job partially solving the second problem, but its not complete. So I will never be opposed to someone who presents more information on how to use the editor. Especially if that information is what the genre considers "non standard".

At the very least editing Team Colors is a great additional tool for making cinematics, or cut scenes.

Certainly. Who knows what future use Ill need for them, so any info would be great.