Found a rather annoying discrepancy in when spawn effects are applied.
CEffectCreateUnit appears to do the following, Create Unit, Unit Created Event, Apply Spawn Effect,
while CBehaviorSpawn does it in another order, Create Unit, Apply Spawn Effect, Unit Created Event.
The latter being the expected result, event emitted after the unit has been fully initialized.
Am unsure of how the different abilities handle this, Train, Arm Magazine etc but i bet there are some bugs there as-well.
This might seem minor, but having predictable event parameters is very important.
That viking is very OP by the way, morph him a few times, infinite auto turrets!
Anyhow, calling UnitSetFacing works just "fine", as expected it's a bit of a bottleneck but it gets rid of all the quirks.
It has it's advantages aswell i suppose, since you can do things like getting the actual attachment point facing, making things like attaching a seige tank on the barrel of a seige tank, which is rather amusing if you're a zerg player.
Issue with doing it in code, is primarily, that it's slow.
Same setup as yours more or less, except in your example you have an effect called CasterPuppetLinkEndTest
Can get rid of that effect by using a spawn behavior instead.
Behavior (Spawn)
Limit 1
Effect Attachment (Apply Behavior)
Flags (Spawn)
Kill Spawn On Death
And for the attachment points i just opened your map, opened the unit actors and added some of the stock SOps.
There is one side effect with turrets however, looks like setting the actor facing doesn't set the unit facing or something along those lines as it basically fires at units behind it. Still working on figuring out what exactly is going on there.
Edit:
Yeah so a quick debug shows that it's due to that the unit's facing is not the same as the actor's facing.
Eiv isn't active these days AFAIK and the map is no longer available on bnet (EU).
@Builder_Bob: Go
Awesome, i was taking the same approach with the behaviors (Although, i used spawn to eliminate the damage - kill effect, figured that aspect was up to the hosting unit) but couldn't figure out how to set up the scopes etc.
Attachment points appear to be working without requiring any further work with this setup as-well, pretty damn sweet!
Spawn can do that by default.
Otherwise you can always replicate it by using a behavior, initial effect create persistent -> create unit. Expire effect, search -> destroy unit. Upgrade morph effect -> search -> destroy unit.
Is it possible to arrange actors in a hierarchy while still being owned by different units?
Basically Unit B's (child) actor should be attached to Unit A's (parent) attachment point, but it should still receive messages from unit B. It's doable with triggers but looking for a way to datafy it.
Edit:
Clarification, I'll explain the goal instead.
Currently i have a parent unit that has an child unit, the child cannot move on it's own it merely copies the position of it's parent. (Mechanics dictate that it cannot be a mere model attachment, it has to be two separate order queues).
Anyhow, coping the position works fine for the game logic, but it does look all that great so i need a method of attaching said model to the parent while it still animates according to the child messages.
0
If you are talking about attacking while moving, then simply allow movement on the weapon.
0
Hum, how is this auto-attack? From your description sounds like this should be a periodic behavior.
0
Release Magazine effect.
0
Their wiki is coming soon!
0
Found a rather annoying discrepancy in when spawn effects are applied.
CEffectCreateUnit appears to do the following, Create Unit, Unit Created Event, Apply Spawn Effect, while CBehaviorSpawn does it in another order, Create Unit, Apply Spawn Effect, Unit Created Event. The latter being the expected result, event emitted after the unit has been fully initialized.
Am unsure of how the different abilities handle this, Train, Arm Magazine etc but i bet there are some bugs there as-well. This might seem minor, but having predictable event parameters is very important.
0
@DrSuperEvil: Go
Exactly how would that help?
0
That viking is very OP by the way, morph him a few times, infinite auto turrets!
Anyhow, calling UnitSetFacing works just "fine", as expected it's a bit of a bottleneck but it gets rid of all the quirks. It has it's advantages aswell i suppose, since you can do things like getting the actual attachment point facing, making things like attaching a seige tank on the barrel of a seige tank, which is rather amusing if you're a zerg player.
Issue with doing it in code, is primarily, that it's slow.
0
Odd, not sure what exactly makes it break but add another op before the attachment. SOpUpDefault or something like it.
Example that works for sure.
Still working on the facing issue, as far as i know it's not possible to set the facing of a unit in data (beyond move - turn)
0
Same setup as yours more or less, except in your example you have an effect called CasterPuppetLinkEndTest Can get rid of that effect by using a spawn behavior instead.
And for the attachment points i just opened your map, opened the unit actors and added some of the stock SOps. There is one side effect with turrets however, looks like setting the actor facing doesn't set the unit facing or something along those lines as it basically fires at units behind it. Still working on figuring out what exactly is going on there.
Edit: Yeah so a quick debug shows that it's due to that the unit's facing is not the same as the actor's facing.
0
Do you want to remove the order queue all together or just for the move ability?
0
Topic and question don't match. Suppose you can remove the target is not at max life validator. But why would you want to?
0
@DrSuperEvil: Go
Eiv isn't active these days AFAIK and the map is no longer available on bnet (EU).
@Builder_Bob: Go Awesome, i was taking the same approach with the behaviors (Although, i used spawn to eliminate the damage - kill effect, figured that aspect was up to the hosting unit) but couldn't figure out how to set up the scopes etc. Attachment points appear to be working without requiring any further work with this setup as-well, pretty damn sweet!
0
Or, Find the creep tumor, reset to parent -> liberty.
0
Spawn can do that by default. Otherwise you can always replicate it by using a behavior, initial effect create persistent -> create unit. Expire effect, search -> destroy unit. Upgrade morph effect -> search -> destroy unit.
0
Is it possible to arrange actors in a hierarchy while still being owned by different units?
Basically Unit B's (child) actor should be attached to Unit A's (parent) attachment point, but it should still receive messages from unit B. It's doable with triggers but looking for a way to datafy it.
Edit:
Clarification, I'll explain the goal instead. Currently i have a parent unit that has an child unit, the child cannot move on it's own it merely copies the position of it's parent. (Mechanics dictate that it cannot be a mere model attachment, it has to be two separate order queues). Anyhow, coping the position works fine for the game logic, but it does look all that great so i need a method of attaching said model to the parent while it still animates according to the child messages.