Sweet! Rotidecs and Artestru have now checked in, and they WILL be giving out information about features they might add and the like! See his post for more info: http://us.battle.net/sc2/en/forum/topic/6231594160#18
It appears this is not a one time thing, nor limited to that thread - they will simply stick around and post whenever they want, in reply to whatever they want.
Not sure if it's organized like that QA they did a few years ago or that the devs will just freely reply to topics in the custom map forums.
From the looks of it, they're going to be freely roaming and replying to topics at will! Deletarius already replied to two random threads - his own account and portrait, etc.
If they stick around this could really be great - especially if they post frequently, and actually reply to questions besides simple, easy ones.
I posted a couple of your guys questions there, but I'm not sure how much they'll reply to things that are essentially "feature requests" rather then questions about how to do something within the editor.
The version you posted, on page #12, has the same problem as mine: The persistent ordering the unit to return is never removed.
This is the sole issue remaining.
My latest version (see attached) will work intermittently: Sometimes the units will be ordered back and the persistent destroyed, but in some cases it will be destroyed before they return.
I've tried to follow every suggestion you made since I first complained about it in #17, and I've also tried other various solutions on my own, with no luck.
Thank you for your help, DrSuperEvil. I believe I ought to credit you on any map I make, irregardless if you were directly involved, because chances are you helped me with them in some part or another. :P (Seriously, you dedicate a lot of time to helping here. I see you post in nearly every thread. There isn't anyone else who does that. (Sadly))
I thought if a persistent's validator returned false, it would destroy itself.
The persistent is constantly checking the unit that has ammo to detect if it is full and order it back, then I could add a validator that is checking for a buff on that unit.. and if it returns false, it would get destroyed, right?
I'm not sure if it would be a more reliable way of doing it or not, even if it is possible. If anyone knows how to make the other method work, though, I'm all ears.
Is your destroy persistent lower in the list than your other effects in the set?
Yes.
Quote:
Problem with that solution is if the target unit dies the buff is known as removed.
Err, I meant the unit with ammo not the unit it was shooting - ie, the "target unit" for the persistent that is telling the unit to return once it is full of ammo again.
In that case, it wouldn't matter if it died because the persistent wouldn't be needed anymore, anyway.
Delay didn't fix it (though I was wondering how you'd add delay, so its good to know)
I was considering try and make it destroy itself via a validator rather then via Destroy Persistent by having a marker buff on the target unit so that the persistent destroys itself when the unit gets the marker buff that says the unit has been issued back.. Never got it to work, though.
Alright, sorry, got it working now. Tried looking it up but Destroy Persistent isn't very widely used\documented from the looks of it.
Now it works about 50% of the time, maybe less - it will send the units back and destroy the persistent some times, but the rest of the time the persistent is destroyed too soon and the unit is never sent back. I did give the returnammoset Set the validator my issue order has.
I confused by its intermittency - it seems to happen more often
.It only creates the persistent on unit death as a backup system.
Ah - I decided to use a Persistent from the start because if the target unit has moved away while the unit was attacking, in its current form the unit would chase it's target down and attack it anyway, even though the player wouldn't actually know where the unit to since it moved out of vision. I take it you don't recommend this because unlike the other way, it could cause lag?
Quote:
There is a Destroy Persistent effect which could help you. Try the persist until destroyed flag instead of high count numbers.
OK, thanks. Problem is, the persistent isn't removed until the attacking unit returns to the spot he should be at - I want it to be removed just after the unit is issued the order. Why? Because a player might decided he *doesn't* want the unit to return, and manually order the unit to stop. How it currently works he wont be able to do that, because the persistent will keep re-commanding the unit to the spot. Any idea why its currently working as such?
Edit: Me = stupid again - the persistent isn't ever being removed, just after attacking they have less then full ammo and it has a validator that only tells them to return when they get full ammo. That means I just failed to set up the remove persistent correctly. Still not sure what I'm doing wrong, though.
Quote:
You are also ordering the unit to attack itself.
Lol, I'm an idiot. Got it working now, thanks. Some of the other things might have been off because I was trying random things to get it to work, but I think this was my main problem.
Edit: Took the easy way out with displaying ammo count - just made an attribute that does nothing and had the ammo buff stack add one of it - and viola, ammo count. Works for me.
Get the behaviour to use a set effect that does what you want and then removes itself via a Remove Behavior effect.
I tried that, but it didn't work - the unit wouldn't return any more. My theory is that it removed the marker buff BEFORE the unit was ordered to return. Anyway, if I am going to use a Create Persistent instead, how would I have that destroy itself?
Quote:
What periodic checker?
Err, the Marker Buff (or in this case, the create persistent) that constantly checks if the unit has full ammo again so it can order it to return? I hope I didn't misunderstand you and make it in a completely different way then you intended.
I'm guessing it wont be an issue, though.
Quote:
You could insert a Create Persistent effect created at the point of the unit on death that does the same function.
I've decided just to use the Create Persistent effect from the start. (I think it will work better overall)
Ok, so heres what I currently have: The effect set for when you run out of ammo on the switcher has two effects - the global search to find the battery unit, and the Create Persistent effect instead of the Add Marker Buff effect.
The Create Persistent effect has a maximum number of periods (for the time being) with a period duration of 0.5 (thats what the marker buff was) and a period effect that issues the casting unit to return to the persistent if it has refilled on ammo.
But it doesn't work. Any idea what I did wrong? How should the targets be set up?
Here is the map once more, if you need to look at it in order to see how I muddled things up this time.
As always, grateful you haven't given up on me as a hopeless case,
I fixed my issue with using the battery by changing the command from Move to the Battery ability and switching the target\caster - in other words, it orders the ammo cache to target the marine, thus causing the marine to come back and refuel correctly.
I fixed the validator - all I had to do is move it to the correct position, as you said.
I made it so that a Return Buff is added to the target when the unit runs out of ammo (in a set along with the global search to order them to get ammo) and it correctly orders the unit to return. However, there is one problem: The unit continues being ordered to attack, even if you tell it not to - is there any way to cause the behavior to be removed or turned off after it orders the unit to attack once?
Also, do you think it will lag the game if too many units are being rapidly checked with the periodic checker?
I wish I hadn't thought of this just now, but using this method the unit will not go back to attacking if the target unit dies - is there any way to make the unit attack move to the position that the unit he was attacking used to be? Or would I be better off trying to trigger it if I want that. ._.
Then all I have to do is find *some* way of displaying the ammo count, which will be a pain... Modifying the UI interface using the Auir Chef method seems like the smartest way, but I have no experience with that.
Sorry, not tried using issue orders to activate a battery before, maybe you need a behaviour on the battery that orders it to use the battery ability on a 0 ammo unit at very low range.
Well, I thought the issue order command was simply treating its target as a point instead of a unit, and if you knew how to change it that would be fixed. If this isn't possible (or you think thats not the issue) I can attempt to figure out how to make a behavior do that.
Quote:
How searches target units is down to Target Sorts, these can do alot but use TSDistance for your needs.
Hm. I actually tried that, because from looking at some other things that seemed like it would work. I am confused why I thought it didn't work the first time, but when I tried it this time it works for sure. So turns out, I had this one figured out and I just made a dumb mistake.
Quote:
In short when weapon fires it applies a buff to the target, this buff acts as a marker that sends the attacking unit back to it when it has max ammo stacks.. . .all looks ok except the lack of the application of the return when full buff to the target under the AmmoAttackSet effect.
Hmm, so I need to create a new, separate buff that is applied to the target in the Attack Set that issues the attacking unit to return to attacking it? Is this buff applied every attack?
I sorta get the idea in theory, but I have no clue how to set the buff up to do that.. Not sure how to detect when the unit has refilled on ammo as a result of running out, how to detect when it is full of ammo again, and then have it issue attacker to target itself - all using a buff.
Quote:
Now for the map, nice use of the Unit Ability validator, first time I have seen someone use it.
Err.. as I mentioned in my other post my Unit Ability Validator, as nice as it is, is not working - my unit goes to any type of building, irregardless if it has the ability or not. I'm at a complete loss as to why - I've experimented with its settings quite a lot trying to get it to work.
I'm real bad at actors, so I'm not going to try and tackle that one until I get the rest of the spell working, but the part that I imagined would be difficult about it is that I wanted it to appear above the "Kills" count on the unit, not just floating text above the units head. Whether your suggested method would do that or not, I don't know - but I'm pretty sure it'll be a bit difficult for me to do, so I'll solve my current issues first.
As usual, thanks for taking the time to answer every question and stick with me despite being slow to understand the ways of the editor.
I now start with a proper amount of stacks, and after attacking the right amount of times the stack wears off.
This is about the extent of my success: I've gotten him to move to a building, but I can't get the validator for whether it has the battery ability set up correctly.
And when it moves, it moves ON to the unit, not as if it is targeting the unit - ie, it does not trigger the battery ability. (Manually targeting it causes the battery to work fine)
I also don't know how to make it target the closet unit - in fact, it seems to target the furthest away by default.
I am also not sure how to get it to send him back - not sure what you meant by using marker effects to do this.
Then I just need to start working on getting an actor to display the ammo count on top of the weapon. >_<
Argh. Sorry for being such a noob - I tried for some time to figure out what I am doing wrong for some time, but with no success.
Here is the map if it helps you pinpoint what I'm doing wrong.
0
Sweet! Rotidecs and Artestru have now checked in, and they WILL be giving out information about features they might add and the like! See his post for more info: http://us.battle.net/sc2/en/forum/topic/6231594160#18
It appears this is not a one time thing, nor limited to that thread - they will simply stick around and post whenever they want, in reply to whatever they want.
0
From the looks of it, they're going to be freely roaming and replying to topics at will! Deletarius already replied to two random threads - his own account and portrait, etc.
If they stick around this could really be great - especially if they post frequently, and actually reply to questions besides simple, easy ones.
I posted a couple of your guys questions there, but I'm not sure how much they'll reply to things that are essentially "feature requests" rather then questions about how to do something within the editor.
0
Blizzard created a tutorial for the Cinematic Editor: http://us.media.blizzard.com/starcraft2/downloads/tutorial/SCII-CutsceneEditorInstructions.pdf
Patch is out on NA, servers aren't up though.
0
Sorry, I got derailed a bit there.
The version you posted, on page #12, has the same problem as mine: The persistent ordering the unit to return is never removed.
This is the sole issue remaining.
My latest version (see attached) will work intermittently: Sometimes the units will be ordered back and the persistent destroyed, but in some cases it will be destroyed before they return.
I've tried to follow every suggestion you made since I first complained about it in #17, and I've also tried other various solutions on my own, with no luck.
Thank you for your help, DrSuperEvil. I believe I ought to credit you on any map I make, irregardless if you were directly involved, because chances are you helped me with them in some part or another. :P (Seriously, you dedicate a lot of time to helping here. I see you post in nearly every thread. There isn't anyone else who does that. (Sadly))
0
Ergh. ><
I don't really want to give up on it this close to completion, but I'm running out of ideas for fixing it..
0
Errr, I'm confused.
I thought if a persistent's validator returned false, it would destroy itself.
The persistent is constantly checking the unit that has ammo to detect if it is full and order it back, then I could add a validator that is checking for a buff on that unit.. and if it returns false, it would get destroyed, right?
I'm not sure if it would be a more reliable way of doing it or not, even if it is possible. If anyone knows how to make the other method work, though, I'm all ears.
0
Yes.
Err, I meant the unit with ammo not the unit it was shooting - ie, the "target unit" for the persistent that is telling the unit to return once it is full of ammo again.
In that case, it wouldn't matter if it died because the persistent wouldn't be needed anymore, anyway.
0
Delay didn't fix it (though I was wondering how you'd add delay, so its good to know)
I was considering try and make it destroy itself via a validator rather then via Destroy Persistent by having a marker buff on the target unit so that the persistent destroys itself when the unit gets the marker buff that says the unit has been issued back.. Never got it to work, though.
0
Alright, sorry, got it working now. Tried looking it up but Destroy Persistent isn't very widely used\documented from the looks of it.
Now it works about 50% of the time, maybe less - it will send the units back and destroy the persistent some times, but the rest of the time the persistent is destroyed too soon and the unit is never sent back. I did give the returnammoset Set the validator my issue order has.
I confused by its intermittency - it seems to happen more often
0
Clearly I'm just setting up the Destroy Persistent effect wrong, because no matter what I do it doesn't destroy the persistent.
I tried it using 134 marines at once and it still seemed ok.. so I'm probably not going to worry about lag too much for the time being
Of course, maybe my computer is just badass, I dunno.
0
Ah - I decided to use a Persistent from the start because if the target unit has moved away while the unit was attacking, in its current form the unit would chase it's target down and attack it anyway, even though the player wouldn't actually know where the unit to since it moved out of vision. I take it you don't recommend this because unlike the other way, it could cause lag?
OK, thanks. Problem is, the persistent isn't removed until the attacking unit returns to the spot he should be at - I want it to be removed just after the unit is issued the order. Why? Because a player might decided he *doesn't* want the unit to return, and manually order the unit to stop. How it currently works he wont be able to do that, because the persistent will keep re-commanding the unit to the spot. Any idea why its currently working as such?
Edit: Me = stupid again - the persistent isn't ever being removed, just after attacking they have less then full ammo and it has a validator that only tells them to return when they get full ammo. That means I just failed to set up the remove persistent correctly. Still not sure what I'm doing wrong, though.
Lol, I'm an idiot. Got it working now, thanks. Some of the other things might have been off because I was trying random things to get it to work, but I think this was my main problem.
0
Edit: Took the easy way out with displaying ammo count - just made an attribute that does nothing and had the ammo buff stack add one of it - and viola, ammo count. Works for me.
I tried that, but it didn't work - the unit wouldn't return any more. My theory is that it removed the marker buff BEFORE the unit was ordered to return. Anyway, if I am going to use a Create Persistent instead, how would I have that destroy itself?
Err, the Marker Buff (or in this case, the create persistent) that constantly checks if the unit has full ammo again so it can order it to return? I hope I didn't misunderstand you and make it in a completely different way then you intended.
I'm guessing it wont be an issue, though.
I've decided just to use the Create Persistent effect from the start. (I think it will work better overall)
Ok, so heres what I currently have: The effect set for when you run out of ammo on the switcher has two effects - the global search to find the battery unit, and the Create Persistent effect instead of the Add Marker Buff effect.
The Create Persistent effect has a maximum number of periods (for the time being) with a period duration of 0.5 (thats what the marker buff was) and a period effect that issues the casting unit to return to the persistent if it has refilled on ammo.
But it doesn't work. Any idea what I did wrong? How should the targets be set up?
Here is the map once more, if you need to look at it in order to see how I muddled things up this time.
As always, grateful you haven't given up on me as a hopeless case,
- TheSkunk
0
I fixed my issue with using the battery by changing the command from Move to the Battery ability and switching the target\caster - in other words, it orders the ammo cache to target the marine, thus causing the marine to come back and refuel correctly.
I fixed the validator - all I had to do is move it to the correct position, as you said.
I made it so that a Return Buff is added to the target when the unit runs out of ammo (in a set along with the global search to order them to get ammo) and it correctly orders the unit to return. However, there is one problem: The unit continues being ordered to attack, even if you tell it not to - is there any way to cause the behavior to be removed or turned off after it orders the unit to attack once?
Also, do you think it will lag the game if too many units are being rapidly checked with the periodic checker?
I wish I hadn't thought of this just now, but using this method the unit will not go back to attacking if the target unit dies - is there any way to make the unit attack move to the position that the unit he was attacking used to be? Or would I be better off trying to trigger it if I want that. ._.
Then all I have to do is find *some* way of displaying the ammo count, which will be a pain... Modifying the UI interface using the Auir Chef method seems like the smartest way, but I have no experience with that.
0
Well, I thought the issue order command was simply treating its target as a point instead of a unit, and if you knew how to change it that would be fixed. If this isn't possible (or you think thats not the issue) I can attempt to figure out how to make a behavior do that.
Hm. I actually tried that, because from looking at some other things that seemed like it would work. I am confused why I thought it didn't work the first time, but when I tried it this time it works for sure. So turns out, I had this one figured out and I just made a dumb mistake.
Hmm, so I need to create a new, separate buff that is applied to the target in the Attack Set that issues the attacking unit to return to attacking it? Is this buff applied every attack?
I sorta get the idea in theory, but I have no clue how to set the buff up to do that.. Not sure how to detect when the unit has refilled on ammo as a result of running out, how to detect when it is full of ammo again, and then have it issue attacker to target itself - all using a buff.
Err.. as I mentioned in my other post my Unit Ability Validator, as nice as it is, is not working - my unit goes to any type of building, irregardless if it has the ability or not. I'm at a complete loss as to why - I've experimented with its settings quite a lot trying to get it to work.
I'm real bad at actors, so I'm not going to try and tackle that one until I get the rest of the spell working, but the part that I imagined would be difficult about it is that I wanted it to appear above the "Kills" count on the unit, not just floating text above the units head. Whether your suggested method would do that or not, I don't know - but I'm pretty sure it'll be a bit difficult for me to do, so I'll solve my current issues first.
As usual, thanks for taking the time to answer every question and stick with me despite being slow to understand the ways of the editor.
0
Thanks! I am getting oh-so-closer.
I now start with a proper amount of stacks, and after attacking the right amount of times the stack wears off.
This is about the extent of my success: I've gotten him to move to a building, but I can't get the validator for whether it has the battery ability set up correctly.
And when it moves, it moves ON to the unit, not as if it is targeting the unit - ie, it does not trigger the battery ability. (Manually targeting it causes the battery to work fine)
I also don't know how to make it target the closet unit - in fact, it seems to target the furthest away by default.
I am also not sure how to get it to send him back - not sure what you meant by using marker effects to do this.
Then I just need to start working on getting an actor to display the ammo count on top of the weapon. >_<
Argh. Sorry for being such a noob - I tried for some time to figure out what I am doing wrong for some time, but with no success.
Here is the map if it helps you pinpoint what I'm doing wrong.
Thanks again for your help, though.