Staredit Network

This will find the location of the unit regardless of where it starts.

Oh my god I hate my maps. Stupid Y-Coordinate Never works.

Edit - Map removed due to fix of bug
Edit2 - If you wanted the map, it is here [snapback]94433[/snapback]

wtf? this map doesn't make any sense? it goes all crazy and s**t!!!

i don't get it, but the coordinate system seems good.

JUST FIX IT!

I cant tell what the hell its doing. It seems like you get random minerals and gas and it tells you when it sets switches, and if you run around it gets worse!

What the point of the map? And, if it dosent work why did you post it?


And now for something completely different!

Woohoo!

oh...i'm lost...i don't seem to understand this map, but it is a good idea, try to fix it, please

Only difference between this and Tux is that yours may use different units...

Which Tux can fix in a second.

In other words both would be clones of each other.

Basically yes, and this one lacks the little feature known as progressive gun fire.

The Mineral count is the X and the Vespene gas is the Y
The Vespene gas (Y) does not work for some odd reason
It hasn't worked for me in the last coordinate map either.
The X works fine. The minerals just take a while to add up.

Well I compleatly rewrote your triggers to do the same thing, Well it works better, Y works and i used like alot less triggers but its slow. When i try to speed it up by copying triggers it seems to think you move in larger increments, I havn't figured out why yet, i have homework. Maybe some other time.

I don't know why my maps encounter this problem. The Y triggers are an exact copy of the X triggers except for the Y are for vespene gas and a different unit for death counter and 2 different locations... I didn't expect the bug to be so drastic :\

The multiple copies of the trigger is required for some reason, I dont know why yet...

KEnoli, wth is the blue blur?

Honestly i barely even looked at yours legacy weapon. When i started looking though it i was like i could do this with 10/th of the triggers. Since i don't know your triggers i'm not sure why you have your Y varable problems, i have a guess but its far fetched.

Likely reasons, your using smaller locations, for an annoying reason maybe that causes jumps over time?

Yea well, have you tried with only 2 triggers to find the X and Y places? It doesn't seem to work for some odd reason...

I'll try to make this with bigger locations

HAHA, I AM SOOO RETARDEd!!
The subtraction of Y-Coordinate Death counts to add to vespene gas were doing p2 instead of p1. Fixed!
YAYAY AY it works

congrats legacyweapon, it works!

a little slow, but it works! Now what is next?

The reason for the slowness is because minerals are a thing very slow to deal with. The Coordinate counter is set like way before the minerals finish.

Bolt sent me his map which had a bug with duplicating the checking triggers, such that it would only check it in multiples of the number of duplicates.

What's interesting about this is it hits the nail on the head to a bug that's plagued me since I started SC triggers. Specifically, why certain conditions just don't seem to get updated across triggers. It happens mainly with the "give" units actions, though I believe it also happens with others also. Apparantly SC sometimes doesn't check if anything has changed (unit-wise) in locations until after the triggers have all fired, hence why in the map he sent me when I tried to do the "correct" method of finding the coordinates it only counts in multiples equal to the number of duplicates of the position finding triggers.

The solution I used, in this case, was to "update" the thin vertical/horizontal locations (used to check if a P3 spider mine is inside them, thus confirming whether the coordinate has been found). Though it may seem redundant, simply using the 'center location' action, even if it's a completely different location (like what bolt did with the 'Point' location, or you could even the anywhere location itself... it doesn't seem to matter apparantly) forces SC to recheck what units are inside every location instead of waiting until the end of the trigger loop to do that.

Personally, I think it's either a bug with the SC trigger system or else a hidden lag reduction method to the same effect. Thoughts?

Aww well thanks. I was starting to lean towards OMG STARCRAFT IS ****ed. But it always seems like your admitting defeat when you say the reason your triggers don't work is because of a 'bug' in the editor.

Ironicly I did a few simple test that should of yeilded the same screwed up results, but it was all normal. I suppose you don't know anymore about it than you said tux. Do ytou know if certain things factor into when this happens like hyper triggers being present or other active waits? Do you know any other actions that have done that (did a center location always fix it?). Or are you as clueless as I am.

PS. Although my version of the map tux posted refers to zerglings there are no zerglings on the map. I realized it worked even with the zerglings removed.

PSS. Oh yeah i belive Dabuu had said somthing about this issue in one of his post but, i dismissed it thinking he was drunk or something when he did his testing. Tux do you know if it happens with the kill trigger too.

I remember looking over this simple test map for hours thinking it contradicted everything i knew about triggers. The situation was it killed a unit but the following trigger still detected its presence, i think i came to the conclusion that the unit exist breifly even after being killed because of his death animation (proboly a load of bull)

Well I haven't explored it in depth but I've isolated it to the fact that sometimes when checking for units in a location the units don't always stay "updated" across triggers. I think it's mainly with give unit actions that's the case, since I've seen it work with create unit a few times.

Whenever I encounter it, I just put in some sloppy-but-workable failsafes and get it over with. Not much you really can do without knowing exactly what it is, it seems.

What I think, though, is that it's not that the unit itself is still there. It's that supposedly there's some SC function that checks what locations each unit is in and updates a list or something for the triggers to use, and that function either is getting lagged somehow or isn't being triggered to update in the midst of the triggers being activated... unless an action forces it to (like 'create unit' or 'move location'). I think though that some actions, such as the give (and maybe kill/remove), don't cause the update to occur before the trigger cycle has ended, and thus you get those annoying "lingering" units that mess up complicated triggers every so often.

Pending tests though, that's all just hypothetical.

Maybe it works like this;

Give Unit or whatever

sets off a function within the Starcraft Engine to check with data and update the previous information, but cannot return the data update to the trigger list until the trigger list has finished checking itself.

Lots of programmers are also talking about the terrible way Starcraft was built, in that its full of errors and issues which lead to crashes all the time. This is just anotehr example.

But does anyone know what this concept could be used for, other than your unlimited gunner system?

Incorporating this into a map isn't going to help much if we don't have a use for it...

I'd thought of using it to create interesting Worm style conflict.

Explain please...
I mean what is this 'Worm style conflict' you speak of?

How about you try to think up new ideas and if this comes in handy good.

You could have it be a basic radar in a RPG to like track your enemy.

LoL you could create virtual locations like this
Current player accumulates at least 10 ore
Current player accumulates at most 20 ore
Current player accumulates at least 10 minerals
Current player accumulates at most 20 minerals.

LoL that would be a pretty cool location saving techniqe. Although it only really works for one unit at a time.

You could use the system to calculate displacement, like so you know how far a unit has walked from his starting point.

And from displacement you could work out Acceleration!