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.
Not perfect, but here's one method mostly datafied. I had to use one trigger though, as I haven't been successful at attaching units to units.
Edit: I added another map. This one attaches units to each other all in the data editor. The method did produce a few side effects, but at least they look like one model, with no delay in the movement between them. I'm not sure how to stick the unit to an attachment point yet though.
Using this method only makes the two units look like they are one, so the (invisible) attached unit has to be moved along with the host unit to avoid strange things happening around the map.
I've set it up so one single behavior is all it takes to attach a unit.
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!
@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!
Glad you like it
Could you tell me a little about your approach? I'm not sure what you mean by using spawn to eliminate the damage - kill effect. Also, how did you make the unit addition stick to an attachment point?
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.
I've never used a spawn behavior before, so I'm not sure how to use it. Couldn't figure out how to use it.
About the attachment points. When I try to add stock SOps to the unit actors of the attachments, they become those white spheres at ground level. Not sure what I'm doing wrong there. When holding 'alt' their hp bars indicate they are attached to the right points. I tested with various SOps, including SOpAttachOverhead.
The side effect about turrets is apparent even without attachment points. That's one of the strange issues I was talking about. I've tried changing the facing angles of the attached units to match the host unit, and that doesn't help the issue. (Edit: this is actually wrong. I must have done something wrong when I tested it)
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.
You're right. Using triggers makes it a whole lot easier, so you probably have to resort to that. I doubt it's so slow that it'll be an issue, but of course, it depends on how many of these attachments you have around.
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
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.
Try asking the maker of the Voidcraft map.
Contribute to the wiki (Wiki button at top of page) Considered easy altering of the unit textures?
https://www.sc2mapster.com/forums/resources/tutorials/179654-data-actor-events-message-texture-select-by-id
https://media.forgecdn.net/attachments/187/40/Screenshot2011-04-17_09_16_21.jpg
Not perfect, but here's one method mostly datafied. I had to use one trigger though, as I haven't been successful at attaching units to units.
Edit: I added another map. This one attaches units to each other all in the data editor. The method did produce a few side effects, but at least they look like one model, with no delay in the movement between them. I'm not sure how to stick the unit to an attachment point yet though.
Using this method only makes the two units look like they are one, so the (invisible) attached unit has to be moved along with the host unit to avoid strange things happening around the map.
I've set it up so one single behavior is all it takes to attach a unit.
@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!
Glad you like it
Could you tell me a little about your approach? I'm not sure what you mean by using spawn to eliminate the damage - kill effect. Also, how did you make the unit addition stick to an attachment point?
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.
@caspersc: Go
I've never used a spawn behavior before, so I'm not sure how to use it. Couldn't figure out how to use it.
About the attachment points. When I try to add stock SOps to the unit actors of the attachments, they become those white spheres at ground level. Not sure what I'm doing wrong there. When holding 'alt' their hp bars indicate they are attached to the right points. I tested with various SOps, including SOpAttachOverhead.
The side effect about turrets is apparent even without attachment points. That's one of the strange issues I was talking about. I've tried changing the facing angles of the attached units to match the host unit, and that doesn't help the issue. (Edit: this is actually wrong. I must have done something wrong when I tested it)
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)
@caspersc: Go
Sweet, adding the SOpUpDefault fixes that issue.
Yeah, it's really too bad we have to use move - turn. I'm working on something that I think might facing. I'll let you know if it turns out right
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.
You could get the attached units models to be rotated using the (Explicit Rotation) SOp.
Contribute to the wiki (Wiki button at top of page) Considered easy altering of the unit textures?
https://www.sc2mapster.com/forums/resources/tutorials/179654-data-actor-events-message-texture-select-by-id
https://media.forgecdn.net/attachments/187/40/Screenshot2011-04-17_09_16_21.jpg
@DrSuperEvil: Go
Exactly how would that help?
@caspersc: Go
You're right. Using triggers makes it a whole lot easier, so you probably have to resort to that. I doubt it's so slow that it'll be an issue, but of course, it depends on how many of these attachments you have around.