I've been using a show/hide solution with requirement up till now, and only started worrying about the limit after I realized I'm gonna surpass it.
Since there is no way to add/rem abilities, I'll just have to work around it. Many of my abilities share properties, so I'll merge them and have a switch work out what the ability will do depending on conditions.
If anyone figure out how to add/rem abilities, then I'm still interested in it. Otherwise, consider this topic closed.
There is a limit to 32 abilities on a single unit. Although I don't need to have that many abilities on a unit at the same time, I would benefit greatly from having more potential abilities on a unit.
Is there a way to add/remove abilities to units at run time? I've only found triggers that enables/disables, and that does not suffice.
I'm not sure how dimmed units work. Would it be possible to check for visibility on the point of the unit instead of checking if the unit itself is visible?
base ::RollingIndex this allows the attachment point to change index in a linear matter. Looping around to the first attachment point again when reacing the end.
driver here you should write the ID (double click your effect to see the id) of the effect you want to be used as a counter for the rolling index. (maybe other data types can be used as well)
multiplier 1 from limited testing it seems this is how much the index increases by every time another driver is added to the effect tree.
offset 0 the starting index for the attachment point used.
It's important to understand that nothing is saved between attacks. If you want alternating attachment points for your beams, you will have to do both sides during one attack, for example with a Create Persistent.
Now to choose the right driver. A simple solution for a projectile ability is Launch Missile. The AMPattern will increase the index every time you launch the missile. For a beam ability you can instead use a Modify Unit effect. Leave it as default, and make sure you run this effect after every beam.
If you run into any problems, I'll be happy to help further. It'd be nice though if you include a map so it will be easier to debug.
how are you going to enable the abilities? maybe check if the upgrade is researched or the building created
The thing is, the requirements for my abilities are varied, so I need a generic solution that doesn't check for the units created or the behaviors that are or are not on the unit.
It would be a very daunting task having to link all those different requirements to every ability, and be able to check for them with only the ability as input. I might as well redo the whole requirement system if I'd have to go that route, and that just seems like a waste of time.
The simplest way in my opinion is to create a new Site Operation (Attachment). Let's call it SOpAttachOriginNoRotate.
Set Actor - Hold Rotation to Enabled.
Set Attachment - Attachment Query+: Fallback to Origin.
If you now use this site operation actor as a Host Site Operation for one of your attachments, it will get attached to origin of the host unit, but will not rotate with it.
Increase the unit's Stats - Death Time (default at 0).
Weapons and abilities usually filter out dead units. Instead have your corpse-targeting ability require dead units in their target filter. Although I haven't tested it, I'm pretty sure this will work.
You should also mess with the actors to make sure the dead units are visible of course, but that shouldn't be very hard.
After a bit of testing I've come up with a theory. It seems to me that the site actors are being created after the beam, and thus the beam cannot find the sites it is supposed to attach itself to. Both the sites and the beam are created at Channel Start, which could cause a problem if you're unlucky with the order these actors are being created.
Simple fix: (Tested and working in the attached map)
In the launch site, change the first event from SourceChannelStart to SourceCastStart.
In the impact site, change the first event from TargetChannelStart to TargetCastStart.
This way, the sites will always be created before the beam.
0
Look at the default validators Enemies Nearby and No Enemies Nearby, and modify the search filter for friendly units.
0
I've been using a show/hide solution with requirement up till now, and only started worrying about the limit after I realized I'm gonna surpass it.
Since there is no way to add/rem abilities, I'll just have to work around it. Many of my abilities share properties, so I'll merge them and have a switch work out what the ability will do depending on conditions.
If anyone figure out how to add/rem abilities, then I'm still interested in it. Otherwise, consider this topic closed.
0
I've actually never looked into upgrades. I'm gonna check it out right now.
Edit: I can't find anything resembling adding or removing abilities with upgrades.
0
There is a limit to 32 abilities on a single unit. Although I don't need to have that many abilities on a unit at the same time, I would benefit greatly from having more potential abilities on a unit.
Is there a way to add/remove abilities to units at run time? I've only found triggers that enables/disables, and that does not suffice.
0
Bump
0
Is it possible to create and import new text styles from downloaded fonts?
I'm sorry if this is the wrong forum section for this question.
0
Why is a for-loop bad in relation to the trigger limit?
0
I'm not sure how dimmed units work. Would it be possible to check for visibility on the point of the unit instead of checking if the unit itself is visible?
0
Do you have a map we can look at?
I have no idea what it could be, but it does sound like it could be useful, so I'm interested in taking a look at it
0
You'll want an AMPattern with
It's important to understand that nothing is saved between attacks. If you want alternating attachment points for your beams, you will have to do both sides during one attack, for example with a Create Persistent.
Now to choose the right driver. A simple solution for a projectile ability is Launch Missile. The AMPattern will increase the index every time you launch the missile. For a beam ability you can instead use a Modify Unit effect. Leave it as default, and make sure you run this effect after every beam.
If you run into any problems, I'll be happy to help further. It'd be nice though if you include a map so it will be easier to debug.
0
The thing is, the requirements for my abilities are varied, so I need a generic solution that doesn't check for the units created or the behaviors that are or are not on the unit.
It would be a very daunting task having to link all those different requirements to every ability, and be able to check for them with only the ability as input. I might as well redo the whole requirement system if I'd have to go that route, and that just seems like a waste of time.
0
Of course. Here's a map showing it actually does work
0
The simplest way in my opinion is to create a new Site Operation (Attachment). Let's call it SOpAttachOriginNoRotate.
Set Actor - Hold Rotation to Enabled.
Set Attachment - Attachment Query+: Fallback to Origin.
If you now use this site operation actor as a Host Site Operation for one of your attachments, it will get attached to origin of the host unit, but will not rotate with it.
0
Increase the unit's Stats - Death Time (default at 0).
Weapons and abilities usually filter out dead units. Instead have your corpse-targeting ability require dead units in their target filter. Although I haven't tested it, I'm pretty sure this will work.
You should also mess with the actors to make sure the dead units are visible of course, but that shouldn't be very hard.
0
After a bit of testing I've come up with a theory. It seems to me that the site actors are being created after the beam, and thus the beam cannot find the sites it is supposed to attach itself to. Both the sites and the beam are created at Channel Start, which could cause a problem if you're unlucky with the order these actors are being created.
Simple fix: (Tested and working in the attached map)
In the launch site, change the first event from SourceChannelStart to SourceCastStart.
In the impact site, change the first event from TargetChannelStart to TargetCastStart.
This way, the sites will always be created before the beam.