Staredit Network

Oh I think I get it. You mean use rows of air units, and when ordered to a point check which ones move straight along their paths or fall outside. Heh, had to think that out myself to understand it, and was about to post it seperately until I realized that was what you were saying anyway.

It's a good way to do it, but the limit (if I understand correctly) is 6 strips for each axis (unless one is to be longer than another), as hotkeys can only hold 12 units max. It is simpler to implement, though, but the global method might hold more power and versatility if it can be pulled off.




The one thing that's been puzzling me about how to find angles (or actually the slope of the air units) for the global method, as putting tiny locations all around them would be clumsy at best (without a lot of work). However, you could instead use mini-strips for each air unit in their respective containers (and you may only need 2 in opposite corners of the map), and then use strips of tightly packed (1 pixel spaced) burrowed units along each axis of their little containers.

When the air units approach the boundaries of their area (it need not be circular or anything), the strips following that unit will then 'mark' one of the burrowed markers, the air units will be reset, and then the distance of each 'mark' will be counted from the start of that area. Using a system similar to what I created for my old unlimited gunner system, you'd then be able to find the slope of the travel path of the air units, from which you could run it through some math functions and find the intersect point (which would be the next tricky step to implement).

Then the final task would be to 'set' to the intersect point. I outlined 2 ways to do that earlier, and with those it'd effectively complete the implementation.

ya, i was wondering about your revised system. like tux said, it'd have 6 units per axis, how would these cover even a 64x64 map?

Well, the way I have planned is to have 7 air units on the top (or bottom, whichever hemisphere of the map you're in), and 5 on the side. Now, this system would work on your screen position, not the entire map. As I stated before, you could have another option that allowed you to click a point on your screen and the screen would lock onto that new position. You could even have a toggle between 'hero screen' and 'mobile screen' (mobile being a locked screen, but you click on an area in it to lock your screen onto those new coordinates).

Tuxedo, how far away would the air units in your idea of the system take to travel before it registered?

my bad lethal i didn't realize you meant clicking within the screen to move it.

anyhow, it seems like your revised edition is already finished, so i don't quite know what to add onto it.

IRT tux

you're still talking about the global method right?

how about having a one pixel location centered on the air units. there would be burrowed units 'touching' against this one pixel location, one pixel* offset of each other. as soon as the wraith moves, it should hit one of the burrowed units. from there, a database of predetermined slopes would be accessed**.

i imagine the speed(for input) on this would be near instantenous. although it would require a immense amount of units. while only requiring one location per vector. however, if we followed my four hemispheres concept. it should reduce the amount of units per vector(with the exception of the center vector).

*depending on map size and desired sensitivity.

**not required, but it would seem to make things simpler. instead of performing calculations every time.

Lethal, how far you'd make it is simply about how precise you want to be. If a 2x2 precision is what you're going for (which I'd consider the norm), you'd have to calibrate it so the 1 pixel spaced markers match up with all 2x spaces selectable across the map. I couldn't tell you how far that is unless I were to make a prototype. I might consider making one later, if I have time, for a 256x256 map. Got other things to worry about at the moment, though.

And zeratul, using predetermined slopes would be fine, except calibrating it would be a pain. Using some math triggers might be a pain at first, but it makes calibration easy, and hence why I'm suggesting them. There's no reason you couldn't convert to pre-defined slopes, though, once you've gotten the right calibration settings.

The system you're talking about (from what I read) sounds like it would be extremely hard to trigger... It's fine if you wish to do that, but using a system such as the one I thought up could (hopefully) get it down to 1x1 percision. The only restriction would be a large number of units needed to use it, and you can only select within your screen area.

There are two versions of this system. Here are the problems.

System One [Anywhere]

The problem with your original idea is that it would require an absurd amount of locations. To get an accuracy of within one tile you would need 128 locations per player, making it utterly impractical. In this system you gain absolutely nothing by using more than one unit per axis.

System Two [Localized]

The problem with this system is that it only works with one player, and it only works near your hero. This ends up being difficult to trigger and is no better than just using a Defiler's Dark Swarm.

You could make the localized system with as many players as you want. All you need to do is have different rows for each players (I thought up a way to do this to use 2 locations per player with no extra burrowed units). Also, you could theoretically do this on a 256x256 map where the air units are not even near the hero (or screen for that matter). I may post a big, long post on it later.

No desparado, you'd only need strips of burrowed units, and 3-5 locations per container. The only real trick is getting the math and calibration; the former would just be combining together some addition, subtraction, or multiplication triggers (just cut and paste some premade ones if you're that much of a wuss... there's several maps using them that I know of), while the latter would just be simple trial and error.

The only obstacle I can see is having multiple players, as you might need to calibrate 4 sets of containers in different positions for it to work right. But besides that, if you can make one container, then it's just cut and paste to make others, really.



And lethal, I was using 2x2 for a practical example. There's no reason with enough calibration you couldn't go make it 1x1 or less.





EDIT- But really, this is all at the extreme end of trigger making. It'd really just be best to use a dark swarm system or something like that, for most practical implementations.

Of course, who says we need to be practical?

what maps are using arithmetic triggers?

anyhow, anyone have ideas for finding intersections? effectively?

You mean finding them or 'setting' them? You'd have to use maths for finding them.

Here, if I can get up some gumption I'll go ahead and give it a shot. Dunno when that'll be, though.

setting them is very easy. we'd just use Desperado's unit coordinates system. finding them is what i meant.

Unit coordinates? Is that where you arrange a pre-placed grid of units across the map, the one where you use mobile grids to 'travel' to the set point, or the one where you just place strips of units along the edges and use multi-sized locations to push off the edge out into the map to find the spot?

Ok ermm i don't have much help to offer right now because i really cant be bothered to read each and every post in extreme detail but i got the jist of it. All i have to say is -- desprado your a detestable human being.

hm, maybe desperado's map doesn't do this .anyway, its the same system fishgold used. where you have locations centering on units that don't exist in the other location. essentially, centering locations on locations.

Shmidley's map was a conservative way to get the individual unit's coordinates. You could then easily just use strips of locations from the modified coordinates and do the desired action.

wow, thats a lot of math....

math isn't very hard to do in starcraft. its just a pain to actually make it though.

Not with the power of cut and paste.

i don't have the power of cut and paste

It's called SCMDraft 2. Or guedit. Or even Starforge. Just use their text-based trigger editors.


It's a tad tedious, but better than Staredit for sure.

SCMD2 blew up on me not that its trigedit ever worked for me anyhow. you can copy and paste trigs in starforge ? maybe i'll try guiedit

Well SCMD2 has known issues when sharing triggers with staredit-family editors (or rather, staredit-family has issues loading triggers modified by SCMD2). Otherwise, I've been working on my latest map which has thus far clocked in at 2500 triggers with trigedit alone, which has benefitted greatly with my new process for handling triggers by text, including commenting and organizing, backups, information tracking, etc. I might post a tutorial eventually on the process I'm using, to encourage others to use it as well (it'd be the best way to handle the trigger-aspects of team-based projects, without a doubt).

By the way, I don't recommend guedit. It actually has a fixed trigger limit of 640 or something, which becomes a real pain for larger maps. I dunno about Starforge, though (haven't gotten into using it much on account of a few earlier issues).

i'm well aware of the benefits of scmd2's trigedit. the thing is, it just doesn't work. period. regardless of any circumstances. all i have is a white ractangular box that i can't click.

Wow. Missing any required files or anything?