Did you just ignore my other idea? You can put the conditions from 8 triggers into a single trigger, which has the potential to reduce the trigger load a lot. I admit that I was wrong before, I'm getting too used to programming, however, this idea works.

How so? Could you explain?

Okay, nevermind, I'll shut up now, I was thinking like I could use an OR in the conditions.. Programming has ruined me..

EDIT: Uhm.. yeah, I'm back, thinking about it, I think my original idea could still work, except rather than being detected in squares, you'd detect a line of pixels at the same time, it should work as long as the pixels are numbered going either vertically or horizontally.

Second Edit: Wow. Sorry, I am stupid, that's already what he's doing.. Agh..

Post has been edited 2 time(s), last time on May 24 2009, 1:28 am by Falkoner.

They are lagging like hell I've already answered this question somewhere but cant find where.

Also, morph if I understand right coordinates stored in memory in a DWORD variable like LOW_WORD HIGH_WORD. The y coordinate is in low word and x is in high word. You have 2 EUD conditions which point to the low word and check the interval for y: y>y1 and y<y2. However this is for all x yet. Then you have another 2 EUD conditions which point to the high word and check for x: x>x1 and x<x2 (whatever the next word is).

Won't this work? As far as I remember you can point with EUD conditions starting from each byte in memory.

EDIT:
Also I've remembered that SCMD can't handle more than 60 000 triggers (at least you can't input them via text triggers in SCMD, because it won't compile or something). But this is not the lower bound of SCMD capabilities which is somewhere between 30 000 and 60 000.

Post has been edited 5 time(s), last time on May 24 2009, 7:23 am by Wormer.

testing with multiples of my D1 demo1 map triggers:
30.048 works
60.096 works
90.144 works
120.192 trigedit crashes while compiling.

Um... probably I was mistaken.

Well, that's what I thought as well, but it seems it's contained in a way that basically each pixel gets a single number(At least according to Morphling), and it just runs across and jumps to the next line when it hits the back, and while it would be totally feasible if we could perform math operations on it, there's no way to copy the variable into a Death Count that can be worked with.

well that's what i meant, i didn't think i had to include that there's actions in a trigger

Before I give up completely, I'm going to use MacroTrig and test large numbers of death count conditions.

It's unlikely, but my hopeful theory is that that because a death count condition is simply reading a piece of memory (literally in this case), that it might not lag as much as the triggers that are tested on that map.

Anyways, I have an idea for a entirely different approach to this concept map now. I can't read the x coordinate, but I'm going to take advantage of the fact that I can read the y coordinate.

There are test maps where I have 240 trigger executions per cycle with the one Always condition. What can lag less than Always?

Never.

What good is one half of a coordinate?

You shall see

Aww...
You have inspired me to make a map out of this. I was going to before, but thought that it was not worth it. Now I think it is worth the effort.

current position is detectable x and y, fyi. There might be others, I haven't fiddled around enough to see what are.

As for y position, you can have a horizontal bar occur near a hero or something. If you limit it to a small location, the horizontal part won't be that large.

A typical EUD trigger reads a 4 byte number every 4 bytes. For 2 byte data, it's quite difficult to read those first 2 bytes. I looked into different conditions, but I couldn't get any to work. Those that did were the same as deaths.

the only way to effectively use "target position" or "rally point" is to have a unit which never moves, allowing you to move to that unit's centerpoint, which is detectable.