Well the main reason i wanted the disallow units to attack through walls is for realism and that shooting through walls might give a EXTREMELY unfair defensive advantage, as when you have sight you can attack, so any enemy units that have to go around the entier wall to get to the entrance will be getting attacked on their way. Im obbessive complusive about making things realistic, and shooting through walls qualifies as a proposterous capability. I could solve defensive imbalance but not realism, except through this method. If only the editor was capable of a footprint that "Broke Attack Beams". If something like this existed then all of this wouldnt be nessecary... I guess ill have to live with ridiculous physics until i can muster the willpower to change everything manually...
If such Footprints existed you'd still have to do the Launch Missile/Persistent part though, because there is no other way to validate the whole attack path of your attacks.
I agree that it would be nice to have something like this in the Editor, but you have to see that Starcraft 2 is designed in a way that there should be 200-300 units in a battle at the same time without lag. If you implement a built in way to calculate the attack path for every of their weapons it gets laggy really, really fast. And as it's not a requirement for standard strategy SC2 play it is understandable that it is not a part of the Data Editor.
First problem you will run into is that you have to edit every single type of weapon/ability that is in your map and not supposed to shoot through walls into the Launch Missile/Persistent combination that is described in the tutorial, while making the Missile invisible. You don't need additional Validators if you use Units. It will still be a lot of work, so unless it is really an important and core mechanic of your map I'd just scrap the whole idea right now.
Another problem is that the projectiles described in the tutorial are set up in a way that they fly straight in front of the unit and don't always connect with the target, while you want your projectiles to always hit the target (like a normal attack). You can fix that problem by modifying the Target: Location and Impact: Location fields in the Initial and Launch Missile Effects described in the tutorial.
Another problem is that even when you did all that it will still not do exactly what you want, because this method doesn't prevent units from trying to shoot through walls, they will still always target the closest unit. That problem isn't solvable in Data as far as I'm concerned.
Another problem might be that your projectiles aren't traveling fast enough so there is a delay until they impact on your target, unlike normal attacks which connect immediately. You can't make your movers as fast as you want with the standard method described in the tutorial, because the periods in which they check if a target is near them can not be lowered less than 0.0625 seconds, so if the missile is too fast it might fly past the whole target in these 0.0625 seconds. There are ways to circumvent that problem and you can make your projectiles still collide on their path even if they are much faster, but it needs some adaptions.
There will probably be other problems that I can't think of right now.
So, overall i need to have a launch effect with a persistent effect that checks for units? Does that mean that the attack missile will activate its impact effect if it collides with a unit? Which means i will have to convert my walls into units..which means reworking the entire terrain. Is it possible that a mover checks to see if it collides with a unit, and at the collision is actiavtes the impact effect?
Movers can't fire effects and they also can't see if they collide with a unit. Movers just determine the flight path of a missile (or a unit/jumper).
I also wouldn't rework the entire terrain with units, not only would that be a lot of unnecessary work of converting Doodads into Units, you also already put a lot of work into making the terrain look good. I would make one type of unit that you use for that stuff, give it an invisible model and just put it everywhere where you want it to be. Make sure to make the Editor Model for it something easily visible (I would use the Cylinder Shape model and scale it into the right radius of the unit and give it a large Z scale so you can easily place them and see it later on).
It's also easier to make the hitboxes look right with that method, because units can only have circular radiuses (radii?), while your walls and other obstacles probably have other shapes, so it's hard to realistically convert them into units without running into a lot of trouble.
Hmm, i just added a validator that at first seemed to work better than you said, it wouldnt let me shoot through walls or even target units through walls, this could be bad because it causes units to just simply not attack even if thye could go around the wall... but this will do for now. however, there are many doodads that use similar footprints, there are walls(the difference is that these ones block line of sight), and scenery such as crates(which just block unit movement and building). So now both of these doodad(footprint) types cannot have missiles passing them while this validator is in effect. So is the solution youre giving me fix this, or would it still come up with the same issue?
AFTER VIEW SECOND POST: Youre map is very unique, that is not quite how i my attacks to work(they work exactly as regular Starcraft 2 attacking does), yes i want them to be blocked by doodads(footprints) but not ALL doodads. A
Yes, but if you think of the units you see like normal units instead of that WASD-controlled style and of the projectiles of normal attacks instead of that rapid fire then it is similar to the thing that you want? I don't see much of a difference, you don't want to be able to shoot through walls and I don't want to be able to shoot through walls.
The solution I gave (with Doodads) has exactly the issue that you are talking about that Footprints aren't very specific and you can't shoot through a lot of stuff that you want to be able to shoot through. That's why we recommended to use Units, because that way you can decide yourself which parts of the scenery you want to be able to shoot through (these are the Doodads with or without pathing) and which you don't want to be able to shoot through (these are Units).
Triggers are lame, Ill wait for the Compatibility patch thats going come out in 1-3 weeks if you look at WoW initial patches.
Vailreth was working on his Tome Shop and said that they were fixed in HoTS due to this problem being fixed, thats when I realized I had a problem in WoL :P
Oh, that's pretty cool :)
Also helps me with one of my problems, although I'll probably stick with the method that I'm currently using. Definitely useful to know though!
This video shows a pretty early version of my map, but you can see how the enemy unit tries to avoid my damage by taking cover behind the doodad and notices (well, at least sometimes) when his line of sight prevents him from shooting me so he also tries to move somewhere else. That's similar to what you want, right? Just without the visible projectiles, but that's only the missile model that you have to change.
I don't know of any other way to do this kind of stuff. If you find a way, let me know. :)
I understand that doodads are just visual, i was mainly focusing on the footprint of the doodad, not the model of it. I guess i have no choice but to add a missile for all weapons which is a huge inconvenience. I put the validator for the weapon in the launch missle effect?
No, you have to set up a Persistent effect that periodically checks if the missile is colliding with something in its way (that method is described in the tutorial that I linked and that DrSuperEvil was talking about) and in that periodic check you have to validate whether or not the missile is still on pathable terrain.
That still doesn't prevent the unit from trying to fire through the wall though, so even if there is a unit in a choke or something like you described the unit will still try to fire through the wall if there is an enemy that is closer.
If you need a more realistic system with smarter units I would strongly recommend to use triggers for that.
Also, they wouldnt check for a unit, they would check for a doodad since i use many wall segments and converting all of them to units could cause lag
You can preplace a lot of units without causing lag. But even if you want to do it without units you can validate your ability so it doesn't shoot through an area if that area is not pathable, so giving your doodads footprints would make them both unpathable as well as not allowing to shoot through.
also while this is a nice substitute for what i wanted i was planning on units not even targeting a unit through a wall, because then in a situation with a choke point, unit might prioritize targeting a unit tha tis behind the wall, while other units are getting through the choke. I will see if i can accomplish what i want frmo this tutorial.
I don't know any way to do that kind of stuff in the data editor, I have doubts that it's possible. Doing this via triggers is definitely possible though.
You have to realize that Doodads themselves aren't even part of the game for units, the only interaction between units and doodads from an engine standpoint is that Doodads can have Footprints which prevent Units from walking there. Other than that, Doodads don't even exist for Units as far as I'm aware.
Before i read the tutorial, i downloaded the map that came from the tutorial, just to see if my doodads would block the missiles from these abilities, and they dont... so i dont think this is what im looking for otherwise it should work as i desire, this tutorial is for missiles colliding with UNITS, not doodads.
That's because the projectiles in the tutorials don't have validators that validate whether an area is pathable or not. You can easily add them after you understand the ability though, which makes your weapons unable to shoot through FOOTPRINTS. Doodads aren't even a thing that you can validate via Data, Doodads are just a visual thing.
I think there was a similar thread a couple of months ago.
The only thing I personally want asap is offline latency for Singleplayer maps. I think the campaign already has that (does anyone know if that statement is true? It should be, right?) and there is literally no reason for Blizzard to deny it for Arcade 1 Player maps.
I test tested to se eif my weapon that do use missiles couldnt shoot past these walls, and they do shoot through them... so would making these weapon launch missiles even help? Or is it possible that the footprint the doodad is using is allowing missiles to pass it?
These are the kind of missiles DrSuperEvil was talking about, you have to set them up in a way that they check periodically whether or not they are colliding with a unit that is in their path.
It definitely isn't in the Beta right now (edit: Oh, it might actually be, I didn't see the Permanent flag before. Has anyone tested it? As far as I was aware it's just a method available to categorize Behaviors and reference these categories somewhere else. ), and I doubt they wait to add this specific feature at release. It's not even really a feature in my opinion. But I don't know of course.
If your system is data only I think there is a way to fire effects before the unit actually dies, that might work (instead of using Death Response it's something like Damage Response with Killing Blow checked. I don't know the exact names etc though, I'd have to search myself). If you also use triggers I would use Custom Values in your case and just save the amount of Terrazine every unit has through that. It is probably the easiest way to do it like this, but I don't know if there is a way to reference/access the Custom Value of a unit via Data, but most certainly not. So you'd have to make the whole Terrazine ability costs etc. via Triggers instead of Data.
1. Damages are effects, you can find the damage effect that is linked to a weapon under the Effect: Effect field of your weapon.
2. I haven't used it before, but I think there is an event that is called "Unit Dies", use that and then set an Integer Variable to something like (Owner of Unit (Last Attacker (Triggering Unit))) to get the player who killed it. I'm not 100% sure how the Last Attacker function works and if it's compatible with the "Unit Dies" event because I've never used it before, but I think it should be. I think there's also a function called "Killing Unit", I don't know if that's compatible with the "Unit Dies" event but it also sounds promising.
If you can't get it to work with the "Unit Dies" event try the "Unit Property Changes" event with some conditions to determine whether the unit died or not.
It's bittersweet that some of what Blizzard promised about the editor is only practical in single player.
I like single player, but only in the context of multiplayer. Meaning, it's frustrating that many of these popular maps don't even function properly when you load them in single player (supposing you feel like exploring the finer details). It's like, have both assholes, or else it feels like I care more about the map than the author. Where is the pride?
I think they are aware of that problem though and I think they will fix it for LotV or at some other point in the future.
0
If such Footprints existed you'd still have to do the Launch Missile/Persistent part though, because there is no other way to validate the whole attack path of your attacks.
I agree that it would be nice to have something like this in the Editor, but you have to see that Starcraft 2 is designed in a way that there should be 200-300 units in a battle at the same time without lag. If you implement a built in way to calculate the attack path for every of their weapons it gets laggy really, really fast. And as it's not a requirement for standard strategy SC2 play it is understandable that it is not a part of the Data Editor.
0
Hmm, hard to say in advance. I'll try.
First problem you will run into is that you have to edit every single type of weapon/ability that is in your map and not supposed to shoot through walls into the Launch Missile/Persistent combination that is described in the tutorial, while making the Missile invisible. You don't need additional Validators if you use Units. It will still be a lot of work, so unless it is really an important and core mechanic of your map I'd just scrap the whole idea right now.
Another problem is that the projectiles described in the tutorial are set up in a way that they fly straight in front of the unit and don't always connect with the target, while you want your projectiles to always hit the target (like a normal attack). You can fix that problem by modifying the Target: Location and Impact: Location fields in the Initial and Launch Missile Effects described in the tutorial.
Another problem is that even when you did all that it will still not do exactly what you want, because this method doesn't prevent units from trying to shoot through walls, they will still always target the closest unit. That problem isn't solvable in Data as far as I'm concerned.
Another problem might be that your projectiles aren't traveling fast enough so there is a delay until they impact on your target, unlike normal attacks which connect immediately. You can't make your movers as fast as you want with the standard method described in the tutorial, because the periods in which they check if a target is near them can not be lowered less than 0.0625 seconds, so if the missile is too fast it might fly past the whole target in these 0.0625 seconds. There are ways to circumvent that problem and you can make your projectiles still collide on their path even if they are much faster, but it needs some adaptions.
There will probably be other problems that I can't think of right now.
0
Movers can't fire effects and they also can't see if they collide with a unit. Movers just determine the flight path of a missile (or a unit/jumper).
I also wouldn't rework the entire terrain with units, not only would that be a lot of unnecessary work of converting Doodads into Units, you also already put a lot of work into making the terrain look good. I would make one type of unit that you use for that stuff, give it an invisible model and just put it everywhere where you want it to be. Make sure to make the Editor Model for it something easily visible (I would use the Cylinder Shape model and scale it into the right radius of the unit and give it a large Z scale so you can easily place them and see it later on).
It's also easier to make the hitboxes look right with that method, because units can only have circular radiuses (radii?), while your walls and other obstacles probably have other shapes, so it's hard to realistically convert them into units without running into a lot of trouble.
0
Yes, but if you think of the units you see like normal units instead of that WASD-controlled style and of the projectiles of normal attacks instead of that rapid fire then it is similar to the thing that you want? I don't see much of a difference, you don't want to be able to shoot through walls and I don't want to be able to shoot through walls.
The solution I gave (with Doodads) has exactly the issue that you are talking about that Footprints aren't very specific and you can't shoot through a lot of stuff that you want to be able to shoot through. That's why we recommended to use Units, because that way you can decide yourself which parts of the scenery you want to be able to shoot through (these are the Doodads with or without pathing) and which you don't want to be able to shoot through (these are Units).
0
Oh, that's pretty cool :)
Also helps me with one of my problems, although I'll probably stick with the method that I'm currently using. Definitely useful to know though!
0
To elaborate on that:
This video shows a pretty early version of my map, but you can see how the enemy unit tries to avoid my damage by taking cover behind the doodad and notices (well, at least sometimes) when his line of sight prevents him from shooting me so he also tries to move somewhere else. That's similar to what you want, right? Just without the visible projectiles, but that's only the missile model that you have to change.
I don't know of any other way to do this kind of stuff. If you find a way, let me know. :)
0
No, you have to set up a Persistent effect that periodically checks if the missile is colliding with something in its way (that method is described in the tutorial that I linked and that DrSuperEvil was talking about) and in that periodic check you have to validate whether or not the missile is still on pathable terrain.
That still doesn't prevent the unit from trying to fire through the wall though, so even if there is a unit in a choke or something like you described the unit will still try to fire through the wall if there is an enemy that is closer.
If you need a more realistic system with smarter units I would strongly recommend to use triggers for that.
0
Just replicate the abilities in the tutorial and try to understand how they work.
You can preplace a lot of units without causing lag. But even if you want to do it without units you can validate your ability so it doesn't shoot through an area if that area is not pathable, so giving your doodads footprints would make them both unpathable as well as not allowing to shoot through.
For this tutorial they don't need any special movers. A simple Guidance Mover is completely fine, you can use whatever Mover you want though.
I don't know any way to do that kind of stuff in the data editor, I have doubts that it's possible. Doing this via triggers is definitely possible though.
You have to realize that Doodads themselves aren't even part of the game for units, the only interaction between units and doodads from an engine standpoint is that Doodads can have Footprints which prevent Units from walking there. Other than that, Doodads don't even exist for Units as far as I'm aware.
edit:
That's because the projectiles in the tutorials don't have validators that validate whether an area is pathable or not. You can easily add them after you understand the ability though, which makes your weapons unable to shoot through FOOTPRINTS. Doodads aren't even a thing that you can validate via Data, Doodads are just a visual thing.
0
I think there was a similar thread a couple of months ago.
The only thing I personally want asap is offline latency for Singleplayer maps. I think the campaign already has that (does anyone know if that statement is true? It should be, right?) and there is literally no reason for Blizzard to deny it for Arcade 1 Player maps.
0
http:www.sc2mapster.com/forums/resources/tutorials/17154-data-colliding-projectiles/
These are the kind of missiles DrSuperEvil was talking about, you have to set them up in a way that they check periodically whether or not they are colliding with a unit that is in their path.
0
misclick, post can be deleted
0
What people are saying it is "fixed" with HotS?
It definitely isn't in the Beta right now (edit: Oh, it might actually be, I didn't see the Permanent flag before. Has anyone tested it? As far as I was aware it's just a method available to categorize Behaviors and reference these categories somewhere else. ), and I doubt they wait to add this specific feature at release. It's not even really a feature in my opinion. But I don't know of course.
If your system is data only I think there is a way to fire effects before the unit actually dies, that might work (instead of using Death Response it's something like Damage Response with Killing Blow checked. I don't know the exact names etc though, I'd have to search myself). If you also use triggers I would use Custom Values in your case and just save the amount of Terrazine every unit has through that. It is probably the easiest way to do it like this, but I don't know if there is a way to reference/access the Custom Value of a unit via Data, but most certainly not. So you'd have to make the whole Terrazine ability costs etc. via Triggers instead of Data.
0
1. Damages are effects, you can find the damage effect that is linked to a weapon under the Effect: Effect field of your weapon.
2. I haven't used it before, but I think there is an event that is called "Unit Dies", use that and then set an Integer Variable to something like (Owner of Unit (Last Attacker (Triggering Unit))) to get the player who killed it. I'm not 100% sure how the Last Attacker function works and if it's compatible with the "Unit Dies" event because I've never used it before, but I think it should be. I think there's also a function called "Killing Unit", I don't know if that's compatible with the "Unit Dies" event but it also sounds promising.
If you can't get it to work with the "Unit Dies" event try the "Unit Property Changes" event with some conditions to determine whether the unit died or not.
0
I think they are aware of that problem though and I think they will fix it for LotV or at some other point in the future.
0
Yeah, that actually is pretty interesting, I didn't know that.
Does anyone know how frequently it happens and what kind of regions you would merge to maximize the chance of getting a (0, 0) return?