A scope is defined by an effect tree, so you basically need one unit to cast an effect on the other. For non-unique units, especially when massed, this isn't really feasible, but thankfully certain unit-creating effects (Create Unit, Launch Missile, Transport/Magazine abilities etc.) have fields you can use to apply an effect to the newly-spawned unit. For your concrete setup this means you must cast whatever creates the mineral field directly from the wreckage.
You specify the target units via the various "Target+" or "Location+" fields on each effect. You can also specify an effect from which to draw these unit references from, but the scope effect must lie in the past of the current effect, hence the above restriction: You can make the Mutalisk weapon's second bounce apply a debuff to the first target, but you can't make the first strike "pre-load" a debuff onto the last target directly.
For the point transfer use a Damage or Modify Unit effect to reduce wreckage HP, and a Modify Unit effect to increase mineral HP/resource count. For point-to-point transfer the chain probably has to be Create Unit(Mineral Field)->"Create Effect": Persistent(Period 0, Period Count higher than any HP number)->Set->Damage/Modify effects. Plus a few validators to check when HP run out, and if using Modify Unit instead of Damage on the wreckage, to handle shield points properly. For your scopes you can probably use Persistent.Caster for the wreckage and Persistent.Target for the mineral field.
To check your chosen scope, make the effect create the Psi Storm persistent e.g. replace the Modify Unit with a Set, then add the Psi Storm to that. Provides a nice blue cloud on whatever is the focus of the scope.
Buffs and Modify Unit effects can change ownership, and you can select the predefined players "Neutral" or "Hostile" from the list. I know that for Modify Unit effects you have to explicitely tick the "Change Ownership" flag or it won't work. Not sure if you can maintain the original team color without case-to-case actor edits, if that is desired. Then again I could swear there was a flag to set the population impact to 0, go through all the mind control abilities from the campaigns, maybe one of them has it.
The point-to-point transfer is fairly easy if you can get both units into the same scope: run a 0 period Persistent effect that drains one point from the sender and gives one point to the receiver, with a validator to check if the sender has any points left. In this case check for the unit wreckage having 1hp, then execute a different effect (Switch or Persistent:Effect-Final field) that gives a final point to the receiver and kills the sender. You could even change the "give" effect to a Modify Unit to actually grant minerals I believe.
I think you could also do it in data, but the response time would be a bit of an issue:
Choose an arbitrary update frequency/time interval
Give the unit shield points equal to the amount of damage you want to allow during this time interval
Apply a Damage Response that prevents all damage to HP, but not shields
Pulsing with the chosen frequency, use Modify Unit effects to transfer HP into shields until the latter are full (+/-1 point with a 0 duration Persistent and "ShieldsNotFull" validator should work)
Use validators to kill all of the above setup once the unit reaches 1HP
Based on the chosen update frequency this will either be a very visible "pulse" as the shields regen every second, or massively punish burst fire as the equivalent HP value for 1/16 second would be 16 times lower. Think of a dozen Tanks/Tempests all firing at once, then having to reload for 3s.
Misc. pointers: Shield healthbars can be disabled, as can the Protoss dome visuals if you look at Kerrigan's "Wild Mutation" ability. Damage responses don't stack well, so this probably won't be reliable if the boss has innate "retaliation" effects or such. Balancing this against "proper" play will be a nightmare, since technically standing there and letting the units fire will be more effective than stutter-step micro and such. Should also work using energy as the health reserve, or even as the "shields" if you can redirect the damage taken somehow.
"Display Cooldown" or "(array:) Show Progress" are the progress bar fields.
You should only bother with the Larva if you want the intermediate cocoon stage as a unique unit but shared between all morph paths. Different stats/visuals for different upgrade paths, or jsut plain not having the cocoon, are better handled by individual Morph abilities. A visual-only cocoon with the stats of the old or new unit is easy to do with ModelAddition actors or ModelSwap events.
You can try messing with the "construction mover" assigned on each individual Build ability, this is mainly intended to handle SCVs fidgeting around across the half-constructed building, but it might be valid for the post-construction displacement you mention.
And there's probably a "construction end effect" field or something similar which you could use to teleport, lift or kill the builder if desired, your post doesn't really explain in which way you want to change it.
For a visual-only version use a "Site Mover" actor like the Colossus beam does, or a "Site Rocker" if that can move fast enough. You might have to host the actual missile model on a ModelAttachment actor to make proper use of the Site mechanism.
Just position something "adequately high up" and draw a regular beam to the ground. A Persistent effect can create vertical offsets, or you could place a dummy unit up there to host the beam.
If you look at existing assets that's essentially what they do, only hardcoded into the model file. The nuke, drop pods and TARDIS outhouse all only "work" up to a specific distance.
As for how to set it up, probably a Site-hosted beam similar to the Medivac heal, or maybe you can copy something from HotS campaign. If you use a dummy unit you can directly draw it from "AttachCenter" to "Shadow".
Technically the Unit and Missile actors are the same basic structure, just with different preset values. You can make missile selectable, give them wireframes and icons, and Abduct launches regular units as missiles. Compare the Unit, Action and SiteOperation actors for truly different types, they share only the most basic actor fields.
When in doubt, always try to think of an existing, Blizzard-made asset that works the way you want. Even if you can't copy it directly, trying to understand how it functions will usually teach you how to get your own version up and running.
Uh, there's a reason I told you to look at existing weapons...
Your "bullet", while defined as a Unit, should have a Missile type actor. This actor needs to be selected in your weapon attack (Action) actor under "Art: Missile" for that actor to synchronise its effects with the missile trajectory. Technically Unit and Missile type actors are the same, but the default (grey text) events and properties are different in a few places, which make missiles work as such.
The point-to-point transfer will be the hardest part I think.
Units have their own "death response" fields which you can use, or set a Buff with a Damage Response. Tick the "Fatal" flag in the latter case.
You have to create individual wreck units for each potential mineral cost, or at least Modify Unit effects to hardcode the HP. Triggers would probably be more elegant here. Graphics design again has to be per-unit unless you use a generic wreckage model and merely scale its hp.
Buff or Persistent effect with that duration, Morph ability or Create Unit effect for the conversion.
"Not Dead" validator if necessary, buffs vanish automatically if their host unit dies.
Probably best done via trigger, but a Persistent with period duration 0, period count higher than any HP value in your map should work, make it apply a Set effect that deals 1 damage to the wreck and gives 1 resource unit to the created deposit (Modify Unit effects or so can modify resource amounts, check how the Auto-Refinery does it)
Could you please check and reply to all the various points individually? Effect scopes, AttachMethods compared to existing setups, anything else you might have edited on the effects/actors...
"It doesn't work" doesn't give us much of a handle for helping you without in-depth information on what does and doesn't work, what you've tried already, or a demo map so we can look at it ourselves.
Check where events like ValidateUnit run, maybe you can make a "host=Bunker" check or something.
Or, if actor events really don't work for "Hidden" units (and you can't disable that with some obscure flag), set it up in reverse: make an actor event on the Marine trigger the Stimpack model! Instead of having that model create itself, put the Behavior.Stimpack.On->Create event in the Marine actor.
Probably the combination of 0 casting arc and maintaining the "use ability" command through the channel. I never tried if escaping the "Arc Slop" area actually breaks the channel, but you can observe the same behavior in units continuously attacking with regular weapons (continuous use of the "Attack" ability)
You can probably get around this if need be, by having a dummy ability for the button: The command card ability you make visible to the player has 0 casting arc and triggers an Issue Order effect, which then makes the unit cast the second, hidden, ability with 360° casting arc and the actual channeled effect. Just a heads up in case you need it.
Oh, it's only a missile weapon? There's plenty of old threads on the "missile launching from units' feet" problem, maybe check the effects you use too: the "...Location+" fields should refer to Unit type scopes. And mess with the AttachMethods some more, also use the "Show Field Differences" button to compare with existing missile launchers (Stalker or Hydralisk, most Terran units have unique AttachMethods that won't work as-is)
The missile itself should always hit part of the visible 3D mesh even on air units. It might pick out the tips of wings though, or ofc hit a Protoss shield. What I was concerned about is the beam ending at the ground beneath the missile, separate from the actual bullet, as that would indicate a similar problem with the beam impact location/attachment.
Always shoot left or right on the map when testing altitude issues, and up or down when testing angle distributions, to avoid confusion due to the 3D perspective.
The core problem still is a hosting/scope/attachment issue of your beam setup though. Are you using an Action actor to create the beam (Archon/Sentry weapon), a Launch+Impact Model setup (Medivac heal beam) or a self-sufficient beam actor?
0
A scope is defined by an effect tree, so you basically need one unit to cast an effect on the other. For non-unique units, especially when massed, this isn't really feasible, but thankfully certain unit-creating effects (Create Unit, Launch Missile, Transport/Magazine abilities etc.) have fields you can use to apply an effect to the newly-spawned unit. For your concrete setup this means you must cast whatever creates the mineral field directly from the wreckage.
You specify the target units via the various "Target+" or "Location+" fields on each effect. You can also specify an effect from which to draw these unit references from, but the scope effect must lie in the past of the current effect, hence the above restriction: You can make the Mutalisk weapon's second bounce apply a debuff to the first target, but you can't make the first strike "pre-load" a debuff onto the last target directly.
For the point transfer use a Damage or Modify Unit effect to reduce wreckage HP, and a Modify Unit effect to increase mineral HP/resource count. For point-to-point transfer the chain probably has to be Create Unit(Mineral Field)->"Create Effect": Persistent(Period 0, Period Count higher than any HP number)->Set->Damage/Modify effects. Plus a few validators to check when HP run out, and if using Modify Unit instead of Damage on the wreckage, to handle shield points properly. For your scopes you can probably use Persistent.Caster for the wreckage and Persistent.Target for the mineral field.
To check your chosen scope, make the effect create the Psi Storm persistent e.g. replace the Modify Unit with a Set, then add the Psi Storm to that. Provides a nice blue cloud on whatever is the focus of the scope.
0
Buffs and Modify Unit effects can change ownership, and you can select the predefined players "Neutral" or "Hostile" from the list. I know that for Modify Unit effects you have to explicitely tick the "Change Ownership" flag or it won't work. Not sure if you can maintain the original team color without case-to-case actor edits, if that is desired. Then again I could swear there was a flag to set the population impact to 0, go through all the mind control abilities from the campaigns, maybe one of them has it.
The point-to-point transfer is fairly easy if you can get both units into the same scope: run a 0 period Persistent effect that drains one point from the sender and gives one point to the receiver, with a validator to check if the sender has any points left. In this case check for the unit wreckage having 1hp, then execute a different effect (Switch or Persistent:Effect-Final field) that gives a final point to the receiver and kills the sender. You could even change the "give" effect to a Modify Unit to actually grant minerals I believe.
0
I think you could also do it in data, but the response time would be a bit of an issue:
Based on the chosen update frequency this will either be a very visible "pulse" as the shields regen every second, or massively punish burst fire as the equivalent HP value for 1/16 second would be 16 times lower. Think of a dozen Tanks/Tempests all firing at once, then having to reload for 3s.
Misc. pointers: Shield healthbars can be disabled, as can the Protoss dome visuals if you look at Kerrigan's "Wild Mutation" ability. Damage responses don't stack well, so this probably won't be reliable if the boss has innate "retaliation" effects or such. Balancing this against "proper" play will be a nightmare, since technically standing there and letting the units fire will be more effective than stutter-step micro and such. Should also work using energy as the health reserve, or even as the "shields" if you can redirect the damage taken somehow.
0
"Display Cooldown" or "(array:) Show Progress" are the progress bar fields.
You should only bother with the Larva if you want the intermediate cocoon stage as a unique unit but shared between all morph paths. Different stats/visuals for different upgrade paths, or jsut plain not having the cocoon, are better handled by individual Morph abilities. A visual-only cocoon with the stats of the old or new unit is easy to do with ModelAddition actors or ModelSwap events.
0
You can try messing with the "construction mover" assigned on each individual Build ability, this is mainly intended to handle SCVs fidgeting around across the half-constructed building, but it might be valid for the post-construction displacement you mention.
And there's probably a "construction end effect" field or something similar which you could use to teleport, lift or kill the builder if desired, your post doesn't really explain in which way you want to change it.
0
For a visual-only version use a "Site Mover" actor like the Colossus beam does, or a "Site Rocker" if that can move fast enough. You might have to host the actual missile model on a ModelAttachment actor to make proper use of the Site mechanism.
0
Just position something "adequately high up" and draw a regular beam to the ground. A Persistent effect can create vertical offsets, or you could place a dummy unit up there to host the beam.
If you look at existing assets that's essentially what they do, only hardcoded into the model file. The nuke, drop pods and TARDIS outhouse all only "work" up to a specific distance.
As for how to set it up, probably a Site-hosted beam similar to the Medivac heal, or maybe you can copy something from HotS campaign. If you use a dummy unit you can directly draw it from "AttachCenter" to "Shadow".
0
Technically the Unit and Missile actors are the same basic structure, just with different preset values. You can make missile selectable, give them wireframes and icons, and Abduct launches regular units as missiles. Compare the Unit, Action and SiteOperation actors for truly different types, they share only the most basic actor fields.
When in doubt, always try to think of an existing, Blizzard-made asset that works the way you want. Even if you can't copy it directly, trying to understand how it functions will usually teach you how to get your own version up and running.
0
Uh, there's a reason I told you to look at existing weapons...
Your "bullet", while defined as a Unit, should have a Missile type actor. This actor needs to be selected in your weapon attack (Action) actor under "Art: Missile" for that actor to synchronise its effects with the missile trajectory. Technically Unit and Missile type actors are the same, but the default (grey text) events and properties are different in a few places, which make missiles work as such.
0
The point-to-point transfer will be the hardest part I think.
0
Could you please check and reply to all the various points individually? Effect scopes, AttachMethods compared to existing setups, anything else you might have edited on the effects/actors...
"It doesn't work" doesn't give us much of a handle for helping you without in-depth information on what does and doesn't work, what you've tried already, or a demo map so we can look at it ourselves.
0
Check where events like ValidateUnit run, maybe you can make a "host=Bunker" check or something.
Or, if actor events really don't work for "Hidden" units (and you can't disable that with some obscure flag), set it up in reverse: make an actor event on the Marine trigger the Stimpack model! Instead of having that model create itself, put the Behavior.Stimpack.On->Create event in the Marine actor.
0
Probably the combination of 0 casting arc and maintaining the "use ability" command through the channel. I never tried if escaping the "Arc Slop" area actually breaks the channel, but you can observe the same behavior in units continuously attacking with regular weapons (continuous use of the "Attack" ability)
You can probably get around this if need be, by having a dummy ability for the button: The command card ability you make visible to the player has 0 casting arc and triggers an Issue Order effect, which then makes the unit cast the second, hidden, ability with 360° casting arc and the actual channeled effect. Just a heads up in case you need it.
0
Oh, it's only a missile weapon? There's plenty of old threads on the "missile launching from units' feet" problem, maybe check the effects you use too: the "...Location+" fields should refer to Unit type scopes. And mess with the AttachMethods some more, also use the "Show Field Differences" button to compare with existing missile launchers (Stalker or Hydralisk, most Terran units have unique AttachMethods that won't work as-is)
0
The missile itself should always hit part of the visible 3D mesh even on air units. It might pick out the tips of wings though, or ofc hit a Protoss shield. What I was concerned about is the beam ending at the ground beneath the missile, separate from the actual bullet, as that would indicate a similar problem with the beam impact location/attachment.
Always shoot left or right on the map when testing altitude issues, and up or down when testing angle distributions, to avoid confusion due to the 3D perspective.
The core problem still is a hosting/scope/attachment issue of your beam setup though. Are you using an Action actor to create the beam (Archon/Sentry weapon), a Launch+Impact Model setup (Medivac heal beam) or a self-sufficient beam actor?