Sorry I took over two days to respond. Yeah, I'm open to it, it's a testing/development map for me, not an actual project, so I wouldn't be giving up anything other than possible knowledge on how to make some quasi-basic things happen with data/triggers (most of which was acquired at least in part from tutorials here, a lot of them yours). Map is attached to post ( I hope - first time attaching something on this site). The unit in question is called Armageddon, and everything related to it in the Data Editor has that at the beginning of the name, so that should help you find everything. The way the unit is set up the attached-void-rays attack fires only on massive units and structures, so I have placed a bunch of massive units and just about one of each non-campaign building on the map to hopefully make testing more convenient.
Friendly warning: since my last post I have made some significant additions to the attached-void-rays attack - these changes do NOT at all effect how the attack action actor and the beam actor for each beam work in so far as impact/damage/launch attachments go (the beam actors just got some extra events dealing with animation changes and model swaps) - but just in case you do go rummaging through the attack's effects, bear in mind that the effects that use "Armageddon Target" and "Caster is Attacking" validators can freeze SC2 in its entirety if you remove those validators. As far as I know, with those validators in place there's no such game-freezing side effects under any circumstances, but it's possible some corner case slipped past my testing.
If anyone's interested, feel free to look at anything in the map (there isn't much, other than an 'overchargeable' void ray -style attack that when overcharged charges up twice as fast and has a fourth charge level that changes beam color, and a flight-capable melee unit whose only interesting feature is a set of triggers that adjusts his height to his target's height when he's attacking something when flying. The only request I have is that people don't just blatantly copy all or most of the two developed custom units in there.)
Yeah, that was actually exactly what I was asking about in my first post in this thread - how to do what you just suggested.
- Edit -
I also reset the IAQs to the defaults on the void ray beam actors in question before saving and uploading, so you can start from the defaults and work from there.
I spent a couple days (in between university classes and sleep, of course) altering and experimenting with different Impact Attachment Query combinations already, before posting that question.
Now, the void ray attack is a bit messy-er because it has that one action flag set (I don't remember the name off the top of my head, but it's in essence 'align impact to damage' or something like that) and this causes the damage attachment query field to effect the impact attachment locations in some almost-direct-but-not-quite way - I messed around with IAQs both with and without that action flag checked. "center" will cause the beams to hit the 'center' of the target for sure, but the problem is that for large targets - say, the Command Center - the beams shoot 'inside' the building (the void ray beam, as you probably know by memory, has a noticeable ball-like 'end' where it impacts the target - when the IAQ is Center, this ends up being 'inside' the target', instead of where the beam is making contact with it).
From there, just about every combination of IAQs I've tried has either done the above, hitting 'inside' the unit where the beam model goes noticeably 'through' the outside of the target when hitting large targets, or gotten stuck to the ground where the target unit's origin attachment was at the moment when it was fired upon, or, it will pick some target or another, but again, it'll pick them randomly and the two beams rarely ever converge.
I didn't exactly document what combinations I have tried so far, but it was a mix of the IAQs used by the Void Ray attack's beam normally, the IAQ "ClosestToCaster", "ClosestToTarget", and a generic one like "AMFilterTarget" or something like that that isn't one of the Void Ray's default ones. I also tried some direct methods, Like Target 0, but this doesn't really yield consistent results either.
I appreciate the suggestion, and if you can think of other IAQs that could possibly result in what I'm trying to achieve, I'm happy to try them. (I should've specified I had already tried a LOT of IAQ fiddling when typing my question originally.)
I have a question that's a bit on the complicated end of things for me, but will hopefully be a bit more doable to someone who has more experience with these things.
I have a unit that has two void rays attached to it. The unit attacks with the void rays, the same way normal void rays attack - they open up, fire the beam, charging up through three levels of beam 'power', retain the charge for a little bit as normal, the works. All this works, and the beams fire correctly from the void ray to the target.
However, I would like the impact points of the two beams to be the same, and currently, the two beams pick target impact attachments more or less randomly, and thus almost never hit the same point on the target at the same time.
On the technical side, this is how I have things implemented.
A copy of the void ray weapon.
A copy of all the Prismatic Beam Effects and Actors from the normal void ray (not the hero void ray, whose attack effects are made differently).
A second copy of all the Effects and Actors save for the "(Initial Persistent)" one. This is done so that the second void ray and its beam fires properly. At first I spent some time trying to copy just the effects I thought I needed to get the second void ray beam's actors working right, but I must have been missing something since I never got it working that way, so eventually I just copied the entire thing again, which got it working.
The way I combined the two copies is as follows - [void ray weapon copy name] has "[prismatic beam copy name] (Initial Persistent)" as the effect.
"[Prismatic Beam Copy Name] (Initial Persistent)" effect (which was already a set effect) has "[Prismatic Beam Copy Name] (Charge Persistent)" AND [Prismatic Beam 2nd Copy Name] (Charge Persistent)" as the effect.
From there, the two (Charge Persistent) effects proceed from there as normal, with their respective copies of the subsequent effects. (If you just look at the normal Void Ray Prismatic Beam weapon and its effects, this makes sense.)
Anyway, since the attack action Actors for each beam are linked to the "(Charge Persistent)" effects, each one fires of their respective (Charge Persistent) effect, using its own copy of the void ray beam actor. What I don't know is how to get one of those beams to use the impact attachment of the other beam as its own impact attachment, always. I know I could check the Force Impact Site action flag in its action actor, but I don't know how I could actually make a site actor at the impact attachment of one of the beams.
If I recall correctly I had the transient flag break the heal ability when I was messing around with it in one of my test maps. The problem is some abilities are ridiculously intricate and convoluted in their workings, so 'transient' might not play nice with some of the other aspects/effects of an ability. (I never looked deeper myself though.)
Are you sure the weapon you're using doesn't have its Arc set to 360 (you said you didn't edit the weapon, but you didn't say if you're using some other weapon other than the default psi blades a normal zealot uses)?
@adovid: Go
Not sure if the OP is still looking for a solution to this or already found one, but the Drakken (SP?) Laser Drill (the massive laser drill from the campaign on the mission where you get siege tanks) has exactly what you're talking about - it deals damage at its normal weapon rate once it fires, but has a 'lock on' delay after it first picks an attack target.
So enable campaign dependencies and see how they implemented that.
THANK YOU to the last two posts in this. The last because it let me solve my add-a-missile-turret-to-a-unit-and-get-the-missiles-firing-right problem (yes I had ready ProzaicMuse's tutorials already, and oddly enough they don't mention the Actor - Action Flags at all that I saw, probably because they all focus on beams and the uberlisk uses returning tentacles, which I suspect works differently enough to not need the "Launch Force Site" flags. And then the second to last post because without that post the last post wouldn't have existed in the first place.
Okay, I ended up not using either of the suggestions above for now, and ultimately went with a trigger solution - here's why:
"Tried using a returning missile with no ammo unit?"
This would require teleportation of the unit to do right - my melee air unit, other than flying, behaves like a normal melee unit - when it melee-attacks another air unit, it does not return to the location it was at, it stays at the same spot. Also, since the model has attack animations, and I have no clue how to make a missile's model play a specific animation upon impact, this wasn't ideal even with teleportation. And, on top of that, even with teleporting, it would look messy, as the unit would teleport but not change heights, so all consecutive attacks would still look like the unit performing a weird dive-rise/rise-dive loop.
Finally for DrSuperEvil's suggestions: I agree with the limited number of heights point - however, I typically start with units (particularly if I hope to use them in multiple maps/projects) when I mess around in the editor, so I wanted a generalized solution. A handful (three, counting attack plane changes for when the melee air unit swoops down low enough, whereupon it becomes targetable as ground instead - speaking of, yes I did try this with validators, unfortunately the compare field validator seems to ignore height changes made by triggers) of triggers is not ideal, but it's not bad, and it allows for more modular import/export, instead of modifying the validators for each map, making sure to cover all the possible target heights (yes, normally it'd just be 0, 3.75, and nothing else, but I like the principle of a completely general solution in such cases).
And sadly I have not had time to mess around more with validators and the 'other unit' thing to see if there really is a possible solution in that.
BorgDragon: That was a great example for an interceptor shuriken, but it had one flaw for the application I was going for - namely, it again required that you know in advance the target's height - and as I explain two paragraphs above, while I know that's practically doable, I can't help but prefer a 100% generalized solution, even if it meant turning to triggers. But I learned a decent amount from your linked thread, which is always a good thing.
nevjmac: Your suggestion was already given by another person before I posted, and didn't really apply to my particular pursuit, but was appreciated none-the-less.
If anyone's interested in how I got things set up with my melee air unit (currently this only works for one such unit at once, which is all I needed, but I suspect it could be adapted to work with indefinite amounts of such units at once), feel free to ask (and, unlike my original question, the actual how to wouldn't be even indirectly on-topic, and as such should probably go in a different thread), Currently there's two triggers that somewhat smoothly (could no doubt be made smooth-er if that was necessary) adjust the unit height up/down towards its attack target, and gradually lower/raise the unit back to its default position when it's not attacking. There's also another trigger/behavior combo that changes the targeting plain of the unit between air/ground depending on how high the melee unit is. (Because it can attack ground units too, and since it's a melee flying unit, it makes sense it would be floating low enough to be hit by ground units when low enough to be meleeing them.)
The Unit Compare Field validator can be used to determine target height and Buff behaviours can be used to adjust the height of a unit. It is then purely a question of how many different unit heights you will have in your map.
Any chance for a more detailed explanation on how to use the Unit Compare Field validator? Is there any way to compare the same field of two different units using a validator, instead of comparing one unit's field to a preset value?
I ask because I'm doing something like this right now, with a melee air unit - I'm trying to get the melee attack to look more natural by having the unit change height to the height to the attack target. Ideally, I would like to do this without triggers, and thus, a broader question: is there a way to do this through data editor stuff only, or would I have to resort to triggers for it (because I can't find a behavior/buff that will accept a variable height change either - it expects some preset value - I think it could still be done with a behavior for slightly raising the unit that only fires when the validator shows the target is higher, and vice versa for lowering/lower, but for all I know that might just end up being less efficient than using a trigger)?
I would greatly appreciate it if someone could make a modified prisoner zealot model where all the animations were made to look like the prisoner zealot was flying/floating.
I presume none of the polygons/bones/ribbon-emitters/whatever-it-is-modern-models-are-made-out-of would need any changes, merely the animations changed, so that the legs look like they're not touching a solid surface during all the movements. I imagine only minor tweaks of the animations of the other parts of the body would need to be tweaked to make the movements look natural.
Personally, I envision relaxed hanging leg positioning during the stand/idle/whatever animations (like High Templar's legs), legs slightly bent back and whole body leaned forward sharply for the move animation, and legs slightly bent (possibly moving a tiny bit in rhythm with the arm swings for attacks) with body angled normally-ish for the attack animations. But honestly, if it's a prisoner zealot model and it looks like it's flying/floating during all of its animations, I'd be greatful either way, without too much picky-ness about the animation details. I couldn't care less about taunt/dance animations looking floating/flying -ish, though if someone feels like doing those too, props to them.
Actually, if anyone pointed me to how I can freely change the positioning of individual limbs/parts of a model in a way that overrides normal animations through the data editor or triggers, I would be happy with that too - but the modified model would be a cleaner way to reach the same goal, I just can't model for crap, and don't want to get 3Ds Max on the hope that I can figure it out. (Now, if Blender had an m3 export plugin, I'd try doing it on it, but it doesn't afaik.)
@EdwardSolomon: Go
I was just searching for this today (I could afford 3Ds Max if I zealously overstretched my budget, but I'm rather strongly pro-open-source programs, and won't use closed source ones where open alternatives exist if at all possible) - as far as I can find, no such exporter exists.
0
@ProzaicMuze: Go
Sorry I took over two days to respond. Yeah, I'm open to it, it's a testing/development map for me, not an actual project, so I wouldn't be giving up anything other than possible knowledge on how to make some quasi-basic things happen with data/triggers (most of which was acquired at least in part from tutorials here, a lot of them yours). Map is attached to post ( I hope - first time attaching something on this site). The unit in question is called Armageddon, and everything related to it in the Data Editor has that at the beginning of the name, so that should help you find everything. The way the unit is set up the attached-void-rays attack fires only on massive units and structures, so I have placed a bunch of massive units and just about one of each non-campaign building on the map to hopefully make testing more convenient.
Friendly warning: since my last post I have made some significant additions to the attached-void-rays attack - these changes do NOT at all effect how the attack action actor and the beam actor for each beam work in so far as impact/damage/launch attachments go (the beam actors just got some extra events dealing with animation changes and model swaps) - but just in case you do go rummaging through the attack's effects, bear in mind that the effects that use "Armageddon Target" and "Caster is Attacking" validators can freeze SC2 in its entirety if you remove those validators. As far as I know, with those validators in place there's no such game-freezing side effects under any circumstances, but it's possible some corner case slipped past my testing.
If anyone's interested, feel free to look at anything in the map (there isn't much, other than an 'overchargeable' void ray -style attack that when overcharged charges up twice as fast and has a fourth charge level that changes beam color, and a flight-capable melee unit whose only interesting feature is a set of triggers that adjusts his height to his target's height when he's attacking something when flying. The only request I have is that people don't just blatantly copy all or most of the two developed custom units in there.)
@Kueken531: Go
Yeah, that was actually exactly what I was asking about in my first post in this thread - how to do what you just suggested.
- Edit - I also reset the IAQs to the defaults on the void ray beam actors in question before saving and uploading, so you can start from the defaults and work from there.
0
@ProzaicMuze: Go
I spent a couple days (in between university classes and sleep, of course) altering and experimenting with different Impact Attachment Query combinations already, before posting that question.
Now, the void ray attack is a bit messy-er because it has that one action flag set (I don't remember the name off the top of my head, but it's in essence 'align impact to damage' or something like that) and this causes the damage attachment query field to effect the impact attachment locations in some almost-direct-but-not-quite way - I messed around with IAQs both with and without that action flag checked. "center" will cause the beams to hit the 'center' of the target for sure, but the problem is that for large targets - say, the Command Center - the beams shoot 'inside' the building (the void ray beam, as you probably know by memory, has a noticeable ball-like 'end' where it impacts the target - when the IAQ is Center, this ends up being 'inside' the target', instead of where the beam is making contact with it).
From there, just about every combination of IAQs I've tried has either done the above, hitting 'inside' the unit where the beam model goes noticeably 'through' the outside of the target when hitting large targets, or gotten stuck to the ground where the target unit's origin attachment was at the moment when it was fired upon, or, it will pick some target or another, but again, it'll pick them randomly and the two beams rarely ever converge.
I didn't exactly document what combinations I have tried so far, but it was a mix of the IAQs used by the Void Ray attack's beam normally, the IAQ "ClosestToCaster", "ClosestToTarget", and a generic one like "AMFilterTarget" or something like that that isn't one of the Void Ray's default ones. I also tried some direct methods, Like Target 0, but this doesn't really yield consistent results either.
I appreciate the suggestion, and if you can think of other IAQs that could possibly result in what I'm trying to achieve, I'm happy to try them. (I should've specified I had already tried a LOT of IAQ fiddling when typing my question originally.)
0
I have a question that's a bit on the complicated end of things for me, but will hopefully be a bit more doable to someone who has more experience with these things.
I have a unit that has two void rays attached to it. The unit attacks with the void rays, the same way normal void rays attack - they open up, fire the beam, charging up through three levels of beam 'power', retain the charge for a little bit as normal, the works. All this works, and the beams fire correctly from the void ray to the target.
However, I would like the impact points of the two beams to be the same, and currently, the two beams pick target impact attachments more or less randomly, and thus almost never hit the same point on the target at the same time.
On the technical side, this is how I have things implemented.
A copy of the void ray weapon. A copy of all the Prismatic Beam Effects and Actors from the normal void ray (not the hero void ray, whose attack effects are made differently). A second copy of all the Effects and Actors save for the "(Initial Persistent)" one. This is done so that the second void ray and its beam fires properly. At first I spent some time trying to copy just the effects I thought I needed to get the second void ray beam's actors working right, but I must have been missing something since I never got it working that way, so eventually I just copied the entire thing again, which got it working.
The way I combined the two copies is as follows - [void ray weapon copy name] has "[prismatic beam copy name] (Initial Persistent)" as the effect.
"[Prismatic Beam Copy Name] (Initial Persistent)" effect (which was already a set effect) has "[Prismatic Beam Copy Name] (Charge Persistent)" AND [Prismatic Beam 2nd Copy Name] (Charge Persistent)" as the effect.
From there, the two (Charge Persistent) effects proceed from there as normal, with their respective copies of the subsequent effects. (If you just look at the normal Void Ray Prismatic Beam weapon and its effects, this makes sense.)
Anyway, since the attack action Actors for each beam are linked to the "(Charge Persistent)" effects, each one fires of their respective (Charge Persistent) effect, using its own copy of the void ray beam actor. What I don't know is how to get one of those beams to use the impact attachment of the other beam as its own impact attachment, always. I know I could check the Force Impact Site action flag in its action actor, but I don't know how I could actually make a site actor at the impact attachment of one of the beams.
Thanks in advance.
0
@rewazi: Go
If I recall correctly I had the transient flag break the heal ability when I was messing around with it in one of my test maps. The problem is some abilities are ridiculously intricate and convoluted in their workings, so 'transient' might not play nice with some of the other aspects/effects of an ability. (I never looked deeper myself though.)
0
@Andytang14: Go
Are you sure the weapon you're using doesn't have its Arc set to 360 (you said you didn't edit the weapon, but you didn't say if you're using some other weapon other than the default psi blades a normal zealot uses)?
0
@adovid: Go Not sure if the OP is still looking for a solution to this or already found one, but the Drakken (SP?) Laser Drill (the massive laser drill from the campaign on the mission where you get siege tanks) has exactly what you're talking about - it deals damage at its normal weapon rate once it fires, but has a 'lock on' delay after it first picks an attack target.
So enable campaign dependencies and see how they implemented that.
0
THANK YOU to the last two posts in this. The last because it let me solve my add-a-missile-turret-to-a-unit-and-get-the-missiles-firing-right problem (yes I had ready ProzaicMuse's tutorials already, and oddly enough they don't mention the Actor - Action Flags at all that I saw, probably because they all focus on beams and the uberlisk uses returning tentacles, which I suspect works differently enough to not need the "Launch Force Site" flags. And then the second to last post because without that post the last post wouldn't have existed in the first place.
0
Okay, I ended up not using either of the suggestions above for now, and ultimately went with a trigger solution - here's why:
"Tried using a returning missile with no ammo unit?" This would require teleportation of the unit to do right - my melee air unit, other than flying, behaves like a normal melee unit - when it melee-attacks another air unit, it does not return to the location it was at, it stays at the same spot. Also, since the model has attack animations, and I have no clue how to make a missile's model play a specific animation upon impact, this wasn't ideal even with teleportation. And, on top of that, even with teleporting, it would look messy, as the unit would teleport but not change heights, so all consecutive attacks would still look like the unit performing a weird dive-rise/rise-dive loop.
Finally for DrSuperEvil's suggestions: I agree with the limited number of heights point - however, I typically start with units (particularly if I hope to use them in multiple maps/projects) when I mess around in the editor, so I wanted a generalized solution. A handful (three, counting attack plane changes for when the melee air unit swoops down low enough, whereupon it becomes targetable as ground instead - speaking of, yes I did try this with validators, unfortunately the compare field validator seems to ignore height changes made by triggers) of triggers is not ideal, but it's not bad, and it allows for more modular import/export, instead of modifying the validators for each map, making sure to cover all the possible target heights (yes, normally it'd just be 0, 3.75, and nothing else, but I like the principle of a completely general solution in such cases).
And sadly I have not had time to mess around more with validators and the 'other unit' thing to see if there really is a possible solution in that.
BorgDragon: That was a great example for an interceptor shuriken, but it had one flaw for the application I was going for - namely, it again required that you know in advance the target's height - and as I explain two paragraphs above, while I know that's practically doable, I can't help but prefer a 100% generalized solution, even if it meant turning to triggers. But I learned a decent amount from your linked thread, which is always a good thing.
nevjmac: Your suggestion was already given by another person before I posted, and didn't really apply to my particular pursuit, but was appreciated none-the-less.
If anyone's interested in how I got things set up with my melee air unit (currently this only works for one such unit at once, which is all I needed, but I suspect it could be adapted to work with indefinite amounts of such units at once), feel free to ask (and, unlike my original question, the actual how to wouldn't be even indirectly on-topic, and as such should probably go in a different thread), Currently there's two triggers that somewhat smoothly (could no doubt be made smooth-er if that was necessary) adjust the unit height up/down towards its attack target, and gradually lower/raise the unit back to its default position when it's not attacking. There's also another trigger/behavior combo that changes the targeting plain of the unit between air/ground depending on how high the melee unit is. (Because it can attack ground units too, and since it's a melee flying unit, it makes sense it would be floating low enough to be hit by ground units when low enough to be meleeing them.)
0
Any chance for a more detailed explanation on how to use the Unit Compare Field validator? Is there any way to compare the same field of two different units using a validator, instead of comparing one unit's field to a preset value?
I ask because I'm doing something like this right now, with a melee air unit - I'm trying to get the melee attack to look more natural by having the unit change height to the height to the attack target. Ideally, I would like to do this without triggers, and thus, a broader question: is there a way to do this through data editor stuff only, or would I have to resort to triggers for it (because I can't find a behavior/buff that will accept a variable height change either - it expects some preset value - I think it could still be done with a behavior for slightly raising the unit that only fires when the validator shows the target is higher, and vice versa for lowering/lower, but for all I know that might just end up being less efficient than using a trigger)?
0
I would greatly appreciate it if someone could make a modified prisoner zealot model where all the animations were made to look like the prisoner zealot was flying/floating.
I presume none of the polygons/bones/ribbon-emitters/whatever-it-is-modern-models-are-made-out-of would need any changes, merely the animations changed, so that the legs look like they're not touching a solid surface during all the movements. I imagine only minor tweaks of the animations of the other parts of the body would need to be tweaked to make the movements look natural.
Personally, I envision relaxed hanging leg positioning during the stand/idle/whatever animations (like High Templar's legs), legs slightly bent back and whole body leaned forward sharply for the move animation, and legs slightly bent (possibly moving a tiny bit in rhythm with the arm swings for attacks) with body angled normally-ish for the attack animations. But honestly, if it's a prisoner zealot model and it looks like it's flying/floating during all of its animations, I'd be greatful either way, without too much picky-ness about the animation details. I couldn't care less about taunt/dance animations looking floating/flying -ish, though if someone feels like doing those too, props to them.
Actually, if anyone pointed me to how I can freely change the positioning of individual limbs/parts of a model in a way that overrides normal animations through the data editor or triggers, I would be happy with that too - but the modified model would be a cleaner way to reach the same goal, I just can't model for crap, and don't want to get 3Ds Max on the hope that I can figure it out. (Now, if Blender had an m3 export plugin, I'd try doing it on it, but it doesn't afaik.)
0
@EdwardSolomon: Go I was just searching for this today (I could afford 3Ds Max if I zealously overstretched my budget, but I'm rather strongly pro-open-source programs, and won't use closed source ones where open alternatives exist if at all possible) - as far as I can find, no such exporter exists.