Determining point-in-polygon is a commonly required programming task. It is typically done by conceptually drawing a straight line (ray) from the position in question in ANY direction and counting the number of times that line crosses the polygon's boundary. If the ray crosses the polygon boundary an odd number of times, then the point is inside the polygon. If it crosses an even number of times (0 is an even number too), the point is outside the polygon.
To do this programmatically, you need to define the vertices of the polygon and then test the resulting line segments one-by-one. It's actually simpler than it sounds. I uploaded some Lua code that does it. See the attachment.
You can create this logic in the trigger editor, and use it to test point-in-polygon for ANY polygon shape. I'd use the center points of circular zones to define the vertices of your triangle, quadrilateral, pentagon, whatever. However, the expression editor appears to be either bugged or programmed by Neanderthals: see my help topic about the expression editor, hopefully I get some assistance soon!!!!
Oh yea, here's a Wikipedia entry on point-in-polygon:
Actually, this behavior seems to have changed. I went and opened an older map (about a year old) and it gives me errors when I try to edit the expressions. Could a recent patch have introduced a bug, or is there some awful setting I have enabled somewhere on the map editor?
OK, this is REALLY infuriating. I'm JUST trying to write a function in the trigger editor, but it is like the map editor is trying to run my expressions IN THE MAP EDITOR using the DEFAULT values (WTF?!). First, I discovered that I couldn't even do any math using the parameters I am passing in or I would get the "Error initializing variable" error. So, I added local variables that were initialized to junk values (like zero) and then set equal to the passed parameters just so the map editor would shut up and allow me to use the passed in values in an expression. Now, I'm trying to just divide two numbers by each other, but the map editor thinks I'm trying to divide by zero. This screenshot sums it up perfectly:
innerRadius and outerRadius are VARIABLES so why the !@#$ does the map editor think this is a divide by zero? Why is it even CHECKING if it's a divide by zero, did the programmers not understand the definition of VARIABLE?!
Thanks! I did not consider that possibility. That is partly because I do believe that I DID try it over battlenet by myself, and it worked, BUT, I MIGHT be confusing that with playing by myself in the "test map" function.... I've done both. Also, it's not that the trigger logic doesn't WORK, it's that the trigger logic doesn't work reliably. Sometimes the fall-out in a location doesn't increase enough after a nuke lands, sometimes it doesn't increase at all. That kind of thing. So, it can be hard to tell if it's really working or not.
Does this memory limit apply as a TOTAL limit or is it a limit on a per-variable basis? And what is it a limit on? triggers only? Or could I reduce something else to free up room for triggers?
I'd just be surprised if a 400x400 array caused a problem. I would think that 160000 floating point numbers is absolutely nothing compared to the rest of the data traffic that is going on.
Perhaps I'm updating the array too quickly? It gets updated every time a nuke lands. It takes something like 300 to 1000 nuclear launches to win a map (assuming you go all-nuclear), and there can be like five nukes landing within the same second. I'm already adjusting the logic to update the arrays only once every 4 game-seconds. (In the new method, nuke impacts get temporarily stored in another array, and when a timer expires, this nuke impacts array gets read and that updates the radiation map).
Perhaps I should adjust my trigger logic to just work with a 256x256 array instead. It wouldn't be so hard if I was trying to program this in an actual programming language; trying to make complicated conditional statements and loops in the trigger editor is a real PITA (AND they are really hard to read, as well).
Is there any way at all to open some kind of debug message window DURING MULTIPLAYER and see if the map is generating errors? Another thing that makes this hard is the lack of any debugger (that I know of).
Anyway, I really hope you're wrong, because I've been working on an update to the logic that implements a fall-out map for each player so that the "Radiation sickness" debuff & DoT can award kills to the players who actually caused the fall-out that gave the enemy unit radiation sickness. Right now, enemy units that die from radiation sickness don't count towards your kill total. (OH YEA, I have so much fun dropping a couple "salted" thermonukes on zerg bases and watching them slowly wither and die from radiation sickness. Let's just say that this map is most definitely NOT intended to be even remotely fair, that's the best part about it :D. Because, let's be honest: IRL, Terrans would win every single battle because Zerg can't grow nukes and Protoss are too environmentally conscious to use them.)
I was curious if you guys could help me trouble-shoot this anomalous behavior I've been getting. I've only ever made one SC2 map, so I'm kind of a noob. What I did was take the standard melee game and modify it so that nukes were more realistic (like infinite range, ghost not required, much more powerful, etc.)
My trouble has arisen with the logic that calculates nuclear fallout for specific map coordinates. To implement nuclear fallout, there is a 400X400 array of Reals called radiationMap that represents nuclear fallout. The array indices represent the map coordinates with a +72 offset (to avoid array out-of-bounds). Whenever any player explodes a nuke, the floating point values (errmm... I mean "Reals") at the appropriate indices within radiationMap are updated. Basically, if I want to add radiation to map coordinate (x,y), I do:
HERE'S THE PROBLEM: It works great playing by myself. However, I frequently play this map with a RL friend of mine who has a somewhat slow computer in multiplayer. He'll lag pretty bad when there are six active elite and insane AIs. I've never played it with anyone else. When I play with my friend, the radiationMap values do not update properly. He'll drop a nuke and sometimes the radiationMap values won't change at all at the impact point. I swear, I've even seen the radiationMap values go DOWN. I think, but I'm not certain, that radiationMap sometimes malfunctions after I drop a nuke, too.
What's going on?! How is this possible? I've searched through my logic repeatedly, I cannot find the flaw, and it works FINE when I'm by myself. radiationMap is always properly updated. It's only once I take it to multiplayer that I see the problem.
If I truly don't have any errors in my logic, then it must be my assumptions (or, unlikely, a bug in the trigger system itself). I am assuming that global variables are only running in one spot (host? battlenet? Who handles trigger execution logic?) and that triggers are not multi-threaded (i.e., an infinite loop will freeze the game; the game allows as many CPU cycles to finish trigger loops as those loops require, it does not save pause long loops and resume them later). Anyway, perhaps each player runs triggers and has global variables stored, and that my friend's global variables can interfere with MY global variables?!
Thanks for the info! I didn't change anything at all the the standard units- at least, at first. The latest versions of my map DO change the units, but that's beside the point, because this problem existed when the map was simply a pure melee map. So, I guess the problem is that I am not using "bottomless pits". I have high areas and low areas on my map and the water just covers the low areas.
So what you're saying is that most people have the water areas as bottomless pits then?
Next time I fire up the editor, I'll see if I can find this "ignore terrain height" flag. However, what if the terrain height exceeds the value you use in "ignore terrain height"? I have a very tall volcano on my map, obviously, I don't want units to fly under the terrain.
How do you prevent air units from diving under water? Air units seem to follow height above the terrain (or sea floor!) and do NOT respect height above water. On the map I made, I "fixed" this problem by making the water really shallow, but surely there must be some better way of preventing air units from diving into the water?! I'd like to put deep water on my map but this stupid problem prevents that.
This seems like it should be a VERY commonly asked question, because this problem is going to pop up almost EVERY time someone makes a map with water on it (the water does not have to be very deep at all before air units turn into "submarines"!), but I can't find the answer anywhere! Google searches and searches of this forum brought me no answers, indeed, I couldn't even find MENTION of this problem. Either no one puts water on their maps or the answer is very obvious and just something I missed...
0
I started a topic on Blizzard's forums about this:
https://us.battle.net/forums/en/sc2/topic/20761696976#1
0
Determining point-in-polygon is a commonly required programming task. It is typically done by conceptually drawing a straight line (ray) from the position in question in ANY direction and counting the number of times that line crosses the polygon's boundary. If the ray crosses the polygon boundary an odd number of times, then the point is inside the polygon. If it crosses an even number of times (0 is an even number too), the point is outside the polygon.
To do this programmatically, you need to define the vertices of the polygon and then test the resulting line segments one-by-one. It's actually simpler than it sounds. I uploaded some Lua code that does it. See the attachment.
You can create this logic in the trigger editor, and use it to test point-in-polygon for ANY polygon shape. I'd use the center points of circular zones to define the vertices of your triangle, quadrilateral, pentagon, whatever. However, the expression editor appears to be either bugged or programmed by Neanderthals: see my help topic about the expression editor, hopefully I get some assistance soon!!!!
Oh yea, here's a Wikipedia entry on point-in-polygon:
https://en.wikipedia.org/wiki/Point_in_polygon
0
Here's the error I get when I try to edit the expression I made like a year ago.
https://imgur.com/xG0fR3R
Nothing's changed. The trigger works fine. But now, the map editor won't let me edit the expression.
0
Actually, this behavior seems to have changed. I went and opened an older map (about a year old) and it gives me errors when I try to edit the expressions. Could a recent patch have introduced a bug, or is there some awful setting I have enabled somewhere on the map editor?
0
Here's an example that's about as simple it could be:
https://imgur.com/PnJqciX
1) The map editor should not attempt to evaluate expressions within the trigger editor screen.
2) It's not even correct.
0
OK, this is REALLY infuriating. I'm JUST trying to write a function in the trigger editor, but it is like the map editor is trying to run my expressions IN THE MAP EDITOR using the DEFAULT values (WTF?!). First, I discovered that I couldn't even do any math using the parameters I am passing in or I would get the "Error initializing variable" error. So, I added local variables that were initialized to junk values (like zero) and then set equal to the passed parameters just so the map editor would shut up and allow me to use the passed in values in an expression. Now, I'm trying to just divide two numbers by each other, but the map editor thinks I'm trying to divide by zero. This screenshot sums it up perfectly:
https://imgur.com/lwj32NF
innerRadius and outerRadius are VARIABLES so why the !@#$ does the map editor think this is a divide by zero? Why is it even CHECKING if it's a divide by zero, did the programmers not understand the definition of VARIABLE?!
0
Thanks! I did not consider that possibility. That is partly because I do believe that I DID try it over battlenet by myself, and it worked, BUT, I MIGHT be confusing that with playing by myself in the "test map" function.... I've done both. Also, it's not that the trigger logic doesn't WORK, it's that the trigger logic doesn't work reliably. Sometimes the fall-out in a location doesn't increase enough after a nuke lands, sometimes it doesn't increase at all. That kind of thing. So, it can be hard to tell if it's really working or not.
Does this memory limit apply as a TOTAL limit or is it a limit on a per-variable basis? And what is it a limit on? triggers only? Or could I reduce something else to free up room for triggers?
I'd just be surprised if a 400x400 array caused a problem. I would think that 160000 floating point numbers is absolutely nothing compared to the rest of the data traffic that is going on.
Perhaps I'm updating the array too quickly? It gets updated every time a nuke lands. It takes something like 300 to 1000 nuclear launches to win a map (assuming you go all-nuclear), and there can be like five nukes landing within the same second. I'm already adjusting the logic to update the arrays only once every 4 game-seconds. (In the new method, nuke impacts get temporarily stored in another array, and when a timer expires, this nuke impacts array gets read and that updates the radiation map).
Perhaps I should adjust my trigger logic to just work with a 256x256 array instead. It wouldn't be so hard if I was trying to program this in an actual programming language; trying to make complicated conditional statements and loops in the trigger editor is a real PITA (AND they are really hard to read, as well).
Is there any way at all to open some kind of debug message window DURING MULTIPLAYER and see if the map is generating errors? Another thing that makes this hard is the lack of any debugger (that I know of).
Anyway, I really hope you're wrong, because I've been working on an update to the logic that implements a fall-out map for each player so that the "Radiation sickness" debuff & DoT can award kills to the players who actually caused the fall-out that gave the enemy unit radiation sickness. Right now, enemy units that die from radiation sickness don't count towards your kill total. (OH YEA, I have so much fun dropping a couple "salted" thermonukes on zerg bases and watching them slowly wither and die from radiation sickness. Let's just say that this map is most definitely NOT intended to be even remotely fair, that's the best part about it :D. Because, let's be honest: IRL, Terrans would win every single battle because Zerg can't grow nukes and Protoss are too environmentally conscious to use them.)
0
Hello all,
I was curious if you guys could help me trouble-shoot this anomalous behavior I've been getting. I've only ever made one SC2 map, so I'm kind of a noob. What I did was take the standard melee game and modify it so that nukes were more realistic (like infinite range, ghost not required, much more powerful, etc.)
My trouble has arisen with the logic that calculates nuclear fallout for specific map coordinates. To implement nuclear fallout, there is a 400X400 array of Reals called radiationMap that represents nuclear fallout. The array indices represent the map coordinates with a +72 offset (to avoid array out-of-bounds). Whenever any player explodes a nuke, the floating point values (errmm... I mean "Reals") at the appropriate indices within radiationMap are updated. Basically, if I want to add radiation to map coordinate (x,y), I do:
radiationMap[x][y] = radiationMap[x][y] + <additional fallout>
where <additional fallout> is a calculated value or a flat value depending on how close coordinates (x,y) are to the nuclear blast.
See the screenshots below (sorry, for some reason, I cannot put them into my post).
https://imgur.com/Lp41uSr
https://imgur.com/OutmwWV
HERE'S THE PROBLEM: It works great playing by myself. However, I frequently play this map with a RL friend of mine who has a somewhat slow computer in multiplayer. He'll lag pretty bad when there are six active elite and insane AIs. I've never played it with anyone else. When I play with my friend, the radiationMap values do not update properly. He'll drop a nuke and sometimes the radiationMap values won't change at all at the impact point. I swear, I've even seen the radiationMap values go DOWN. I think, but I'm not certain, that radiationMap sometimes malfunctions after I drop a nuke, too.
What's going on?! How is this possible? I've searched through my logic repeatedly, I cannot find the flaw, and it works FINE when I'm by myself. radiationMap is always properly updated. It's only once I take it to multiplayer that I see the problem.
If I truly don't have any errors in my logic, then it must be my assumptions (or, unlikely, a bug in the trigger system itself). I am assuming that global variables are only running in one spot (host? battlenet? Who handles trigger execution logic?) and that triggers are not multi-threaded (i.e., an infinite loop will freeze the game; the game allows as many CPU cycles to finish trigger loops as those loops require, it does not save pause long loops and resume them later). Anyway, perhaps each player runs triggers and has global variables stored, and that my friend's global variables can interfere with MY global variables?!
Any help at all would be much appreciated.
0
Thanks for the info! I didn't change anything at all the the standard units- at least, at first. The latest versions of my map DO change the units, but that's beside the point, because this problem existed when the map was simply a pure melee map. So, I guess the problem is that I am not using "bottomless pits". I have high areas and low areas on my map and the water just covers the low areas.
So what you're saying is that most people have the water areas as bottomless pits then?
Next time I fire up the editor, I'll see if I can find this "ignore terrain height" flag. However, what if the terrain height exceeds the value you use in "ignore terrain height"? I have a very tall volcano on my map, obviously, I don't want units to fly under the terrain.
0
Hello all,
How do you prevent air units from diving under water? Air units seem to follow height above the terrain (or sea floor!) and do NOT respect height above water. On the map I made, I "fixed" this problem by making the water really shallow, but surely there must be some better way of preventing air units from diving into the water?! I'd like to put deep water on my map but this stupid problem prevents that.
This seems like it should be a VERY commonly asked question, because this problem is going to pop up almost EVERY time someone makes a map with water on it (the water does not have to be very deep at all before air units turn into "submarines"!), but I can't find the answer anywhere! Google searches and searches of this forum brought me no answers, indeed, I couldn't even find MENTION of this problem. Either no one puts water on their maps or the answer is very obvious and just something I missed...