I have a unit with an ability that creates a beam between it and the target. Now, if the target receives a certain behavior while the beam is still active, I want to tint it.
A data solution is preferred but I've tried triggers as well without success.
I can't just have an actor event in the beam that triggers when behavior is on.
If you add the beam to the scope of your target, it should easily be possible to utilize the Target - field for your actor messages. You have multiple choices here, you can either directly send the Set Tint Color message, or you use a Signal instead and set the tint color within the beam when receiving this signal. For the target field, you can use the id of the beam, or you can create a new reference for it (only, if there is only one beam per target).
You could even use an alias, which is especially useful, if you planned on adding different beams to the target simultaneously, which all should change colors. In this case, I would also recommend the signal to be able to tint each beam individually.
I'm afraid I'm not experienced enough with actors to figure out how to do it with that information alone. If you could elaborate (preferably on all methods so I can learn all of them), I would be incredibly grateful.
Okay, have you worked with actor events before? if you haven't, I strongly suggest some basic actor tutorials here in the forums or on the official battle.net website.
Since I am not entirely sure, how DrSuperEvil would implement his own solution, I will leave explaining that to him ;)
My suggestion was to use the Target - field within the actor events. If you create a new actor event, it consists of 2 parts, the Event (first part) and the Message (2nd part). If you click on the message, it has a field at the very top of the window, it is called Target. It is empty by default and you can enter a string.
This target field is a mighty tool, it allows you to communicate with other actors. If it is empty, the message will be send to self, to the actor, for which you added the event. If you change the target, you have multiple possibilities to reference other actors.
For this, the concept of an Actor Scope is important. Every single actor in the game belongs to a scope. The scope is usually the unit of the actor (or other main object).
With the target field you can easily communicate with other actors within the same scope. You can, for example, just add the id of the actor you want to send the message to in the target field. The game will then search for an actor with that id within the scope and if it finds one, send the actor message to it.
Instead of the actual id, you can also use an Alias instead. Actors have an alias - field you can modify at will. An alias usually starts with an underscore _. You can use the same alias on multiple actors, for example every unit actor uses the aliases _Unit and _Selectable by default.
You can create your own alias, like _MyBeam, give this alias to your beam actor and use it in the target field.
The Signal is just an actor message you can send to an actor. It does nothing by itself, but it can trigger actor events. So you can send a signal via the target field to another actor, this actor has an event reacting to the signal and then does the stuff you actually want. As mentioned, this is useful, if you for example want to change the color for multiple beams (which you can do when using the alias), but you don't want the color to be the same for all beams. If you would directly send the set tint color actor message, all beams would be the same color. If you send a signal and let the beams color themselves, you can specify different colors for each of them.
I'd say I have a decent understanding of actors already. I followed ProzaicMuze's beam tutorial but except that, I'm mostly self-taught. However, these are some concepts that I haven't messed around with before. I learned about actor scopes just a couple of days ago.
When you mentioned the Target - field, I actually started looking for it, but I missed it. I now understand what you're saying and I think I would be able to implement your methods. There's just one problem. All these methods assume the beam is in the same scope as the unit. This is not the case.
I did a live dump of all actors using actor cheats and the mining beam is in the persistent effect's scope. It looks something like this:
Now, if I understand you correctly, since the target field is used to communicate with other actors in the same scope, I can't use your methods unless I somehow add the beam to the unit's scope.
If you add an ->At Target term to your creation event, the beam should be added to the scope of the target.
€ Oh well, you use an action actor for the beam, right? I am not sure, where exactly you would add the term in this case, or if it is even possible. It should definitely work, if you use the beam without the action actor (if you don't need it specifically).
You could also use global references instead, but this would disable multi unit instanceability.
I experimented around with using the "At" term in the action actor but without success. I tried At Caster, At target and with no "At" at all. It's always created in the Scope[MineastroidPersistent, Effect]
I didn't know you could use beams without the action actor. The only reason I'm using the action actor is because I though it was necessary for the beams to work.
I need multi unit instanceability, so global references are no good, I'm afraid.
If you use a persistent to create the beam, you can use the beam actor without the action actor by adding following events (to the beam actor):
Effect.(YourPersistent).Start
-> At Target
Create
Effect.(YourPersistent).Stop
-> At Target
-> FromEffectTreeDescendant
AnimBracketStop BSD
Also, you will need to set the Host Launch and Host Impact subjects to _Selectable and for our case the launch scope from implicit to Scope Source or Caster. Additionaly, you might want to modify the site operations to get your desired attachment points
I have a unit with an ability that creates a beam between it and the target. Now, if the target receives a certain behavior while the beam is still active, I want to tint it.
A data solution is preferred but I've tried triggers as well without success.
I can't just have an actor event in the beam that triggers when behavior is on.
If you add the beam to the scope of your target, it should easily be possible to utilize the Target - field for your actor messages. You have multiple choices here, you can either directly send the Set Tint Color message, or you use a Signal instead and set the tint color within the beam when receiving this signal. For the target field, you can use the id of the beam, or you can create a new reference for it (only, if there is only one beam per target).
You could even use an alias, which is especially useful, if you planned on adding different beams to the target simultaneously, which all should change colors. In this case, I would also recommend the signal to be able to tint each beam individually.
Or use a Validate Unit/Effect term that uses a validator to check the behaviour count.
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
With a periodic check on the beam?
@Kueken531: Go
I'm afraid I'm not experienced enough with actors to figure out how to do it with that information alone. If you could elaborate (preferably on all methods so I can learn all of them), I would be incredibly grateful.
Okay, have you worked with actor events before? if you haven't, I strongly suggest some basic actor tutorials here in the forums or on the official battle.net website.
Since I am not entirely sure, how DrSuperEvil would implement his own solution, I will leave explaining that to him ;)
My suggestion was to use the Target - field within the actor events. If you create a new actor event, it consists of 2 parts, the Event (first part) and the Message (2nd part). If you click on the message, it has a field at the very top of the window, it is called Target. It is empty by default and you can enter a string.
This target field is a mighty tool, it allows you to communicate with other actors. If it is empty, the message will be send to self, to the actor, for which you added the event. If you change the target, you have multiple possibilities to reference other actors.
For this, the concept of an Actor Scope is important. Every single actor in the game belongs to a scope. The scope is usually the unit of the actor (or other main object).
With the target field you can easily communicate with other actors within the same scope. You can, for example, just add the id of the actor you want to send the message to in the target field. The game will then search for an actor with that id within the scope and if it finds one, send the actor message to it.
Instead of the actual id, you can also use an Alias instead. Actors have an alias - field you can modify at will. An alias usually starts with an underscore _. You can use the same alias on multiple actors, for example every unit actor uses the aliases _Unit and _Selectable by default.
You can create your own alias, like _MyBeam, give this alias to your beam actor and use it in the target field.
The Signal is just an actor message you can send to an actor. It does nothing by itself, but it can trigger actor events. So you can send a signal via the target field to another actor, this actor has an event reacting to the signal and then does the stuff you actually want. As mentioned, this is useful, if you for example want to change the color for multiple beams (which you can do when using the alias), but you don't want the color to be the same for all beams. If you would directly send the set tint color actor message, all beams would be the same color. If you send a signal and let the beams color themselves, you can specify different colors for each of them.
Hm, that became long
I'd say I have a decent understanding of actors already. I followed ProzaicMuze's beam tutorial but except that, I'm mostly self-taught. However, these are some concepts that I haven't messed around with before. I learned about actor scopes just a couple of days ago.
When you mentioned the Target - field, I actually started looking for it, but I missed it. I now understand what you're saying and I think I would be able to implement your methods. There's just one problem. All these methods assume the beam is in the same scope as the unit. This is not the case.
I did a live dump of all actors using actor cheats and the mining beam is in the persistent effect's scope. It looks something like this:
USER 1510 94.375 94.416 [ 14f a] Scope[MineastroidPersistent, Effect] B[P 48.40 161.12 3.75 R.F 0.76 -0.65 -0.00] USER 1510 94.375 94.416 [ 6fd 8] CActorBeamSimple[MiningBeam] Launch[48.40 161.12 3.75] Impact[51.78 158.20 3.85] HostLaunch[0x00000004 0.4 Medivac] Launch SiteOps[MiningBeamLocalOffset2] HostImpact[0x0121000A 289.10 GenericAttackImpactSite] Model[MinerBeam] m3[MothershipPhotonBeam] Radii[Contact 0.03 Vis 0.00] Scale[User 0.05]
Now, if I understand you correctly, since the target field is used to communicate with other actors in the same scope, I can't use your methods unless I somehow add the beam to the unit's scope.
If you add an ->At Target term to your creation event, the beam should be added to the scope of the target.
€ Oh well, you use an action actor for the beam, right? I am not sure, where exactly you would add the term in this case, or if it is even possible. It should definitely work, if you use the beam without the action actor (if you don't need it specifically).
You could also use global references instead, but this would disable multi unit instanceability.
I experimented around with using the "At" term in the action actor but without success. I tried At Caster, At target and with no "At" at all. It's always created in the Scope[MineastroidPersistent, Effect]
I didn't know you could use beams without the action actor. The only reason I'm using the action actor is because I though it was necessary for the beams to work.
I need multi unit instanceability, so global references are no good, I'm afraid.
If you use a persistent to create the beam, you can use the beam actor without the action actor by adding following events (to the beam actor):
Also, you will need to set the Host Launch and Host Impact subjects to _Selectable and for our case the launch scope from implicit to Scope Source or Caster. Additionaly, you might want to modify the site operations to get your desired attachment points