I wanted to know whether there was an alternative when trying to use existing model attachments. The carry buffs/attachments exist already, they're tied to the stock resource nodes. The standard solution will obviously work, I was wondering whether there was a more compact solution.
As a common example, you could track down all actors involved with Protoss shield visuals and add validators+alternative SOps if you give shields to a non-Protoss model (which doesn't have the default Shield attachment point). No one does this, because you can simply use the Attachment Properties field on the Model to redeclare an existing point as the Shield attachment (usually Origin or Center).
This also works with attack visuals and these resource attachments, but the field doesn't include an option for offsets or rotations, so the mineral chunks are stuck in the HT's chest. So I was wondering whether there was a separate field I had somehow missed, or if (maybe) we could tack SOps onto the hardpoints themselves instead of individual attachments. If no one has found such an option of course I can just go with "the standard".
That's an alternative too, but in the end everything requires an up-to-date list of attachment models or equivalent editing of said actors. There's no built-in alias to target with outside events, so unless I'm missing something a Simple actor would also have to validate the identity of carry behaviors/actors.
Oh well, if there's no hardcoded alternative I'll just stick to tried and tested SOps.
Okay, so that at least confirms the HostSiteOpsSet event action works in principle. Unfortunately it still requires editing all resource-carrying actors, is there a way to get around that? Oh well, tacking one Event Macro on to them won't be too bad.
My original idea was more akin to how we set up TextureSelectById and shield visuals on models that don't support them by default. The Model data type already allows us to define aliases for existing attachment points, so I was wondering whether we could also add static offsets or rotations. Would definitely be a quick, elegant solution to the constant "my custom tower is shooting from the ground" problems.
I want to use a stock model (Dark High Templar in this case) for a custom worker unit, but it doesn't have the appropriate attachment point for the resource-carrying model.
Now, I know I can just copy the relevant actors, tack on an offset SOp and use a validator to check for my custom unit type. However this is a lot of work and must be extended to all future resource nodes to function properly. Since the Attachment Properties field on the model lets you add aliases for existing attachment points I was wondering whether you could also add in a permanent offset(+rotation?) somehow.
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
@abvdzh: Go
I wanted to know whether there was an alternative when trying to use existing model attachments. The carry buffs/attachments exist already, they're tied to the stock resource nodes. The standard solution will obviously work, I was wondering whether there was a more compact solution.
As a common example, you could track down all actors involved with Protoss shield visuals and add validators+alternative SOps if you give shields to a non-Protoss model (which doesn't have the default Shield attachment point). No one does this, because you can simply use the Attachment Properties field on the Model to redeclare an existing point as the Shield attachment (usually Origin or Center).
This also works with attack visuals and these resource attachments, but the field doesn't include an option for offsets or rotations, so the mineral chunks are stuck in the HT's chest. So I was wondering whether there was a separate field I had somehow missed, or if (maybe) we could tack SOps onto the hardpoints themselves instead of individual attachments. If no one has found such an option of course I can just go with "the standard".
@DrSuperEvil: Go
That's an alternative too, but in the end everything requires an up-to-date list of attachment models or equivalent editing of said actors. There's no built-in alias to target with outside events, so unless I'm missing something a Simple actor would also have to validate the identity of carry behaviors/actors.
Oh well, if there's no hardcoded alternative I'll just stick to tried and tested SOps.
@DrSuperEvil: Go
Okay, so that at least confirms the HostSiteOpsSet event action works in principle. Unfortunately it still requires editing all resource-carrying actors, is there a way to get around that? Oh well, tacking one Event Macro on to them won't be too bad.
My original idea was more akin to how we set up TextureSelectById and shield visuals on models that don't support them by default. The Model data type already allows us to define aliases for existing attachment points, so I was wondering whether we could also add static offsets or rotations. Would definitely be a quick, elegant solution to the constant "my custom tower is shooting from the ground" problems.
I want to use a stock model (Dark High Templar in this case) for a custom worker unit, but it doesn't have the appropriate attachment point for the resource-carrying model.
Now, I know I can just copy the relevant actors, tack on an offset SOp and use a validator to check for my custom unit type. However this is a lot of work and must be extended to all future resource nodes to function properly. Since the Attachment Properties field on the model lets you add aliases for existing attachment points I was wondering whether you could also add in a permanent offset(+rotation?) somehow.