Line Tower Wars: Anti-block trigger malfunctioning

[OVRKLL]

Hey all,

A friend of mine started to un-bug a Line Tower Wars map (1.24.something, now 1.24K) and I figured I might just as well help him by adding a proper anti-block system. Instead of having manic-depressive little gnoll run through the mazes now and then I wrote three triggers to effectively handle block-cheating. Unfortunately, there is a problem. While the theory between the triggers (illustrated below) seems to work perfectly, I must have made a mistake in the programming somewhere sinse the game suddenly won't allow specific placements - primarily building the first towers of new lines.

Okay, I may need some illustrations... Here we go:

THEORY

1. Find all towers touching the currently constructing one.
2. Find all towers touching each of the previously found towers and repeat until a chain of towers is completed and no more touching buildings exist.
3. Find the horizontal span of the towers during step 2.
4. Find out whether the total horizontal span is greater than a certain value.
5. If step 4 is positive: KILL TEH TOWER (the currently constructing one, that is)!!!

PROBLEM

Here is an example of a problematic scenario (T's and O's are different towers):
|                |
|TTOOTTOOTTOOTT  |
|TTOOTTOOTTOOTT  |
|                |
|              OO|
|              OO|
|                |

For some reason I am not allowed to place the lower tower. Why, oh, why not?!

TRIGGER 1: 'ANTIBLOCK StartSequence'

ANTIBLOCK StartSequence
    Events
        Unit - A unit Begins construction
    Conditions
    Actions
        -------- Set variables --------
        Set UNIT_Antiblock_New = (Constructing structure)
        Set REAL_Antiblock_X1 = (X of (Position of UNIT_Antiblock_New))
        Set REAL_Antiblock_X2 = REAL_Antiblock_X1
        -------- Clear groups --------
        Unit Group - Remove all units from UNITGROUP_Antiblock_All
        Unit Group - Remove all units from UNITGROUP_Antiblock_New
        -------- Add to new units --------
        Unit Group - Add UNIT_Antiblock_New to UNITGROUP_Antiblock_New
        -------- Start primary loop --------
        Trigger - Run ANTIBLOCK PickCurrentUnits <gen> (checking conditions)

TRIGGER 2: 'ANTIBLOCK PickCurrentUnits'

ANTIBLOCK PickCurrentUnits
    Events
    Conditions
    Actions
        -------- Update groups --------
        Unit Group - Remove all units from UNITGROUP_Antiblock_Current
        Unit Group - Add all units of UNITGROUP_Antiblock_New to UNITGROUP_Antiblock_All
        Unit Group - Add all units of UNITGROUP_Antiblock_New to UNITGROUP_Antiblock_Current
        Unit Group - Remove all units from UNITGROUP_Antiblock_New
        -------- Pick new units --------
        Unit Group - Pick every unit in UNITGROUP_Antiblock_Current and do (Actions)
            Loop - Actions
                -------- Set picked unit --------
                Set UNIT_Antiblock_Picked = (Picked unit)
                -------- Start secondary loop --------
                Trigger - Run ANTIBLOCK PickConnectedUnits <gen> (checking conditions)
        -------- Primary loop --------
        If (All Conditions are True) then do (Then Actions) else do (Else Actions)
            If - Conditions
                (Number of units in UNITGROUP_Antiblock_Current) Equal to 0
            Then - Actions
                -------- End primary loop --------
                If (All Conditions are True) then do (Then Actions) else do (Else Actions)
                    If - Conditions
                        (REAL_Antiblock_X2 - REAL_Antiblock_X1) Equal to 896.00
                    Then - Actions
                        -------- Kill unit --------
                        Unit - Kill UNIT_Antiblock_New
                    Else - Actions
            Else - Actions
                -------- Continue primary loop --------
                Trigger - Run ANTIBLOCK PickCurrentUnits <gen> (checking conditions)

TRIGGER 3: 'ANTIBLOCK PickConnectedUnits'

ANTIBLOCK PickConnectedUnits
    Events
    Conditions
    Actions
        -------- Pick connected units --------
        Unit Group - Pick every unit in (Units owned by (Owner of UNIT_Antiblock_Picked) matching (((Distance between (Position of (Matching unit)) and (Position of UNIT_Antiblock_Picked)) Less than 182.00) and (((Matching unit) is in UNITGROUP_Antiblock_All) Equal to False))) and do (Actions)
            Loop - Actions
                -------- Add to new units --------
                Unit Group - Add (Picked unit) to UNITGROUP_Antiblock_New
                -------- Update positions --------
                If (All Conditions are True) then do (Then Actions) else do (Else Actions)
                    If - Conditions
                        (X of (Position of (Picked unit))) Less than REAL_Antiblock_X1
                    Then - Actions
                        Set REAL_Antiblock_X1 = (X of (Position of (Picked unit)))
                    Else - Actions
                        If (All Conditions are True) then do (Then Actions) else do (Else Actions)
                            If - Conditions
                                (X of (Position of (Picked unit))) Greater than REAL_Antiblock_X2
                            Then - Actions
                                Set REAL_Antiblock_X2 = (X of (Position of (Picked unit)))
                            Else - Actions

Can anyone help me find the cause of the problem? I've searched through the codes for an eternity but just can't figure it out!

So, can someone help? Any comments are appreciated!
Thanks.

 

[Cohadar]

The best antiblock for tower maps is making creeps have damage.
They will attach the towers if the way is blocked, simple as that.

 

[Romek]

I personally don't like the attacking system for blockages.
In a TD I'm making, the creeps have their Collision removed. =)

 

[FhelZone]

Collission is a major role in a TD, use the sides and add unbuildable terrain, make it a bit thick like 3 blocks. That way, the creeps would use the sides.

 

[AceHart]

Removing collisions is not the best of ideas, as, every now and then, they simply pass through your lines when blocked...

Presumably, they are ordered around with "move to".
Well, if they get some other order, like "attack", they were blocked and couldn't follow your original order anymore.


Looping through all home regions to try to find some open way is bound to run way too slowly.
Even more so with several players, and "complicated" paths...

 

[OVRKLL]

Excuse me...
But I still havent got ONE relevant thread.
I don't need to know why you think I'm doing stuff the wrong way - I need to know why my stuff isn't working MY way.
Oh, and no - it won't lag. Tested it. (Although an earlier theoretical template and code test proved to cause a major amount of lag... Fixed in this version, though)

EDIT:
Okay, that was rude - after all, I did ask for ANY comments.
Yeah, you have a point with the units-attack-and-go-berserk-if-blocked system but I still find mine a bit more... Sophisticated.

 

[Slapshot136]

i like your idea, i think the problem is that the range you picked for towers that are touching is too big tho (182), i think 142-149 is the range that your looking for, since 141 is to small since the distance between 2 towers that are next 2 each other is 100 pixels, therefore if the towers are touching as far apart as possible (diagonally), the distance should be 100 x sq2 = 141.something, and less then 150 because 150 would be the closest distance towers can be without touching, so try a number between those if your using the "normal" sized towers (like the human ones and the orc ones, not the undead or nightelf ones), if im wrong, try makeing a trigger that tells you the distance between the 2 last created towers and find the correct distance that way

 

[OVRKLL]

i like your idea, i think the problem is that the range you picked for towers that are touching is too big tho (182), i think 142-149 is the range that your looking for, since 141 is to small since the distance between 2 towers that are next 2 each other is 100 pixels, therefore if the towers are touching as far apart as possible (diagonally), the distance should be 100 x sq2 = 141.something, and less then 150 because 150 would be the closest distance towers can be without touching, so try a number between those if your using the "normal" sized towers (like the human ones and the orc ones, not the undead or nightelf ones)

Negative.
A tower has dimentions of 128x128 units. This means that the critical distance has to be at least qrt(128^2+128^2) = 181.something and less than qrt(0^2+192^2) = 192 exactly. Therefore, less than 182 should do the trick.

 

[Romek]

Removing collisions is not the best of ideas, as, every now and then, they simply pass through your lines when blocked...

Presumably, they are ordered around with "move to".
Well, if they get some other order, like "attack", they were blocked and couldn't follow your original order anymore.

Thats basically what I'm doing. The trigger runs when a 'creep' is issued a stop order. And it removes the collision of the creep, and depending on which region it last entered, moves it to the next one. Then when it reaches the next one, collision added again

It works very well

 

[Joker(Div)]

Why not just create a invis Anti-Walling unit that runs through players' mazes periodically?

 

[Slapshot136]

r u sure a tower's dimensions are 128? i was pretty sure that they were only 100.. i dunno then sry

 

[OVRKLL]

Why not just create a invis Anti-Walling unit that runs through players' mazes periodically?

Such a system basically works but can easily be exploided. A player can simply block the path just in front of a group of units, wait for them to bug and stand still or start running back, and remove the tower again. Odds are that no anti-cheat unit will pass in such a small amount of time which pretty much... sucks.

r u sure a tower's dimensions are 128? i was pretty sure that they were only 100.. i dunno then sry

Yeah, I'm sure... The 'Medium' grid is also 128. I guess they like that style; 16, 32, 64...
No need for apologies, we're all here to learn.

 

[Cohadar]

Excuse me...
But I still havent got ONE relevant thread.
I don't need to know why you think I'm doing stuff the wrong way - I need to know why my stuff isn't working MY way.

It does not and will not work because you are using GUI.

 

[OVRKLL]

It does not and will not work because you are using GUI.

Why is that?

EDIT:
...

EDIT:
Taking your time, eh?

 

[OVRKLL]

Okay. I'd still need to know why.

 

[Cohadar]

Okay. I'd still need to know why.

If you knew JASS you would not even need to ask.

Also: When a couple of more experienced people tell you that you are doing it wrong it does not have to mean that they are right but it is damn probable.

 

[Cokemonkey11]

i understand you want it to 'work your way' but it just adds lag for no reason. your triggers have leaks, and while they may seem fine in early game, you will notice a huge lag in later games. You may consider just doubling the ammount of referee's and making them too small to notice, with locust ability, and with no shadow.

That's what I did in my bug-less version of Team LTW.

 

[Slapshot136]

or sending the testers whenever a new tower is built/right infront of the creeps

 

[OVRKLL]

If you knew JASS you would not even need to ask.

Also: When a couple of more experienced people tell you that you are doing it wrong it does not have to mean that they are right but it is damn probable.

Eh. I write nine different programming languages including JASS. The thing is that I'd rather write a map's scripts using the GUI than spending my free time browsing through build-in variables and methods in Warcraft. I know I can improve the map's performance by writing everything in JASS but sinse I already know that this works out in GUI, why bother going beyong the intended level of programming at this stage? Okay, perhaps I may need to rewrite it once working to fix the last leaks (because of the map's dynamic depth) but right now I'm just trying to figure out why my script isn't working. So will you please tell me instead of suggesting that I am the biggest noob around? Not because you know more about programming than I do (but its very probable) - but because sometimes the writer himself simply can't find the mistakes. He needs someone else to point out the things he is overlooking. That's why I asked here.
Anyway. Yeah, I know everybody makes mistakes but when someone has spent so much time on a niche they are mostly pretty damn good at it... And right.

i understand you want it to 'work your way' but it just adds lag for no reason. your triggers have leaks, and while they may seem fine in early game, you will notice a huge lag in later games. You may consider just doubling the ammount of referee's and making them too small to notice, with locust ability, and with no shadow.

That's what I did in my bug-less version of Team LTW.

Damn it! I get your point but I'm still convinced that I am capable of producing a perfect lag-free anti-block system without primitive or exploidable aspects. So if you want to help, please have a look at the code instead of flaming my idea. I'll get to optimisation later on but right now I just need to get the essential mechanism of the code right.

 

[Cohadar]

Eh. I write nine different programming languages including JASS.

I know only 2 other programming languages (JASS is scripting language)
but I don't suck at any of them...