Attachment Issue

[Spellbound]

Disclaimer: Asked this quesion on Sc2Mapster already but i haven't really had much success with this website so I figured I'd try my luck here. The following quotes are the exchange I had on sc2mapster so far.

I'm having a little visual bug where an attached Model Actor won't follow the motions of an attachment point. Here's a video showcasing the problem:

I checked in the cutscene editor and the starport's Overhead attachment moved with it as the model bobs up and down while it's lifted off. The problem I'm getting is that, as you can see, the attached Model Actors don't follow the subtle up and down airborne movements. Both the undeployed reactor and the turbine on top of the Starport are Model Actors. They're both hosted on the Unit Actor of the Starport. The attachment site operations used are, in this order:
- The default Overhead attachment of the Starport
- A local offset site operations

Here's a screenshot of the events of the Turbine Model Actor:

Can anyone help me fix this?

Tried attaching an infinitely small marine and then attaching your model to that marine at the origin?

you mean create another model actor with a tiny marine model (or the stock invisible model maybe?) which attaches to the overhead of the starport and then attach the turbine model actor to the marine?

EDIT: Well at first it seems work in the editor, but when I test it the attached models still refuse to follow the airborne up-and-down movements. I tried multiple models from marine, baneling, phoenix and the invisible model. All work in-editor, but don't once I test the map in-game.

PS: not sure if it's relevant information, but I'm testing this from a .SC2Mod file and spawning the units on Init with triggers.

So, if anyone has an idea of how I can circumvent this visual bug, please help. It's kinda driving me insane.

 

[Dr Super Good]

Any chance for a demonstration map? The map only need feature that building with the broken attachments in a way that the problem can be reproduced.
SC2 actors are notoriously fidgety and often the best way to find a solution is a hands on approach.

As a rough guess the actor is being attached statically to the Starport at the attachment offset at time of creation rather than to the attachment point. As such if the attachment point moves (eg bobs up and down) then it does not update. However hard to say for sure or if there is a solution without being able to fidget with it.

 

[Spellbound]

Alright, I copied the unit and it's actors and models over to a map.

Oh and while I'm at it, d'you have any idea what the x and y values would be if I want to rotate an object 120 degrees anti-clockwise using explicit rotation? Assuming I'm understanding explicit rotations right, that is.

 

[Dr Super Good]

The problem is that the attachment offset is only updated when the unit moves (position or rotation changed). While the unit is stationary the offset does not update so the attachments do not bob up and down with the starport. However if the starport is moving then the attachment positions are being updated and so it does bob up and down with the attachment points.

Currently I have found no solution to this. I think DrSuperEvil did but I recall it being hacky at best.

 

[Spellbound]

That's really weird because I remember playing around with the attachments on other units and managed to get the airborne bobbing to function on an invisible, stationary phoenix. Maybe the Starport attachments have something weird going on with them?

 

[Dr Super Good]

According to DrSuperEvil some models do not update attachment positions every frame while others do. Structures probably mostly do not because it is assumed they are always stationary so it would not be worth the extra computational load on every frame. Units on the other hand move a lot so probably all do.

I found a hacky solution though. The Rotator site operation is a dynamic site operator in that it represents a rotation that constantly changes so must be updated every frame. Adding a dummy one which applies no rotation (rate 0) to the SOp tree forces the attachment position to be updated every frame. The result is that even when the building stands still the reactor and turbine still bob up and down with the model. I do not know how efficient this is, but hopefully the rotator SOp has trivial overhead.

Attached is the fixed demonstration map where the reactor and turbine should now bob up and down with the starport model while standing still.

 

[Spellbound]

Ah, I see. That does make sense, I suppose. Thanks for figuring this out

EDIT: Someone actually found another way to do it.

ahahah, i remember when i used to have this problem - i went through heaven and hell finding a solution.
Don't use Unit Birth it's buggy.

Make a dummy behavior, give it to your unit
Actor Event
Behavior,BehaviorName,On
Create

For some reason, using Unit Birth only causes model attachments to work when the unit is actively moving. It doesn't work when the unit is static.

Test Map

I don't imagine a Behaviour would carry the same overhead as a Rotator, so maybe I should use that instead? The only issue there is that I can't see the result in-editor, but I suppose the behaviour method can be saved for when all the attachements have been properly placed.

 

[Dr Super Good]

What about other events? If unit birth is buggy then why not actor creation instead?

 

[Spellbound]

Idk, the last time I used Actor Creation, nothing happened. I'll try again and get back to you.

EDIT: I set the model to create when the actor of the unit is created, and nothing happened.

ActorCreation.InvasionPlatform
- Create

No model appeared :/

The behaviour method does cause problems if I'm trying to morph the unit since both morphs have a version of that behaviour in case both flying and grounded versions are pre-placed in a map. What happens is that every time the Behaviour is on, the model is created, which means every time the starport lands and takes off. Trying to circumvent that by creating the model on behaviour off or disable, but I can't find a trigger that turns a behaviour off or disabled it.

 

[Dr Super Good]

It seems that actors bound to units, via unit creation event, do not update position automatically when the unit is standing as the position should not change during that time. This is perfect for unit's main actor but not for attachments as they will not update with attachment point animations. The solution is to get the unit actor to create its attachment actors on actor creation.

No hacky site ops. No hacky behaviours.

 

[Spellbound]

Oh... for some reason it never occured to me to use Actor Creation like that, derp.
Thanks, Doc. Saving the day once again

 

[Dr Super Good]

You might need to look into death events and animations. It looks cool floating around but if it gets killed it just disappears.

 

[Spellbound]

I will, but not for the time being. Most of the stuff I'm attaching have deaths that leave behind husks, so it's not ideal for those. I'll get to those eventually.