We all know that starcraft's location limit is painfully low and therefore precious, but sometimes map elements just seem to call for the use of many locations at once... or do they?

I've been thinking of ways to substantially reduce location usage for some of the most common elements that require the use of them, but can't come up with many. If you can think of anything location-heavy, post it here and I'll see if I can think of a way to reduce location usage without substantially complicating things.

1. Beacon purchase/spellcasting system
This is such a location drainer, effectively requiring 1 location per beacon at first glance. So for a system with a ton of units/beacons, you are pretty much screwed if you wanted to expand it beyond 255 unit combinations/spells; or are you?

Rather than the traditional method of "if player x brings x civilian to location x then...", you can constantly move a single location to the unit used for purchasing/spellcasting. Since beacons for spellcasting/purchasing usually have a unit right next to them to tell the player what that beacon does, the "if Neutral brings x unit to purchaser then..." can replace the location conditional.

This can similarly reduce location usage for treasure chests, powerups, etc.

RESULT:
-Location usage decreased from 1 location per beacon/unit/spell/object to 1 location per player.

2. Grids

I swear that I'm working on a 256x256 location grid using <10 locations, and a non-lagging mobile grid. Probably won't come out any time though because I'm still in the experimenting stage.

3. <Suggest more things that can be trimmed down!>

Using a very low definition location grid to define around 36 equally-spread points on the map and use a mobile grid from those points. Right?

Problem is that you don't really need a grid over the entire 256x256 map that has 1 tile accuracy and uses 10 locations. Why? Because you can easily create a 1 tile accurate grid over a same-sized map with about 131 locations and not have to bother with using other locations for just about anything. It will also have the bonus of not using mobile grids at all, thus being more air unit friendly.

But don't stop working on the experimental map. It's always good to sharpen your skills with a project like that.

You could use something like this for big selection systems



OR, you could use one location for the above beacons

Conditions:

• Player 8 brings at least one beacon to "Anywhere"
  

Actions:

• Center location "Beacon" on Terran Beacon owned by Player 8 at anywhere
  
• Give all Terran Beacon owned by Player 8 at "Beacon" to Player 7
  
• Set deaths for Player 8, add one for Cave-in
  

=======================
Individual beacon triggers go here
=======================



Conditions:

• Player 8 brings exactly 0 Terran Beacon to "Anywhere"
  

Actions:

• Give all Terran Beacon at "Anywhere" owned by Player 7 to Player 8
  
• Set deaths for player 8, set to 0 for Cave-in
  

Example individual beacon trigger for beacon number 5:

Conditions:

• Player 1 brings at least one (unit) to "Beacon"
  
• Player 8 has suffered exactly 5 deaths of Cave-in
  

Actions:

• (whatever you want beacon to do)
  
• Center location labeled "Snap back" on Zerg Zergling owned by Player 12 at "2x2"
  
• Move all (unit) for Player 1 at "2x2" to "Snap Back"
  

"2x2" would be a 2 by 2 tile location constantly centered on the selector's unit, and snap back would be used to center on the burrowed zergling, in order to remove the selector from the beacon after the selection

Post has been edited 2 time(s), last time on Apr 1 2010, 4:02 am by Leeroy_Jenkins.

You may want to look at the "One location bound" (or something...). I can't remember where I saw it, but it was basically a complete bound with only one location!

11 locations? such a waste...


it's "that one bound". http://www.staredit.net/files/268/

Yeah, grids can do a lot.

Sure, it only uses one location besides 'Anywhere', but it uses 1052 units.

2 if you count anywhere.

I would use 4 or 5 locations, 1 DC and many triggers for that beacon grid. (my system wouldn't lag less than cycling through the beacons with give.)

You can move locations to the left and up/down with centering on the beacons (centering always centers on the leftmost unit with the lowest ID [or highest? hmm, lowest makes more sense to me ] ).

edit:
thx rockz. I meant the position in the memory (or order of creation) and not the unitID. But if I remember correctly it even was the position in the memory (for preplaced units it equals the position in the memory / order of creation) because centering the location reverses the order. That's something lethal_illusion told me long time ago. I've never used that.

Post has been edited 1 time(s), last time on Apr 1 2010, 10:30 pm by Ahli.

IDK if it's the ID or it's the location in memory. I think it's the location in memory, which means the first unit placed on the map would always have preference, and the second unit placed on the map would go last. I believe the order goes 0 1699 1698...3 2 1.

One trick I used in my RP's that I made, (for those of you who aren't familiar with RPs, they have a beacon-spawn for each unit in starcraft just about), was to carefully arrange the grid of units, then center a single location on each unit, check if a zling is there, cycle to the unit, check for that, cycle to the next, ect. Traditional RP's used a location for every spawn, and I used 1 for all I was proud of myself.

Another trick is to utilize location elevations. Very useful for defining non-square locations.

This is for systems that use the "unit order to cast spell" system. Rather than using 1 location per unit, stretch it over all of them to allow for location saving, and if you have the same unit for the same player, put a burrowed unit under each one and cycle through it when one moves to detect which one(s) it was (see the location "Center").

This can also be used for non-inverted location systems to detect which beacon a player walks on, using only TWO locations rather than one location per player. FUCKING PWNT! (But the only downside is they all have to be on a line)
Shiiiit beat by like 25 minutes... shoulda refreshed rather than wait half an hour to actually post it... and his beats mine by ONE location... Q.Q...
But his actually requires you have only ONE of that unit on the map (for that player, presumably p9-11 (and not 12 obviously because when a player leaves he then p12 would own one of his units...)), or it is the farthest left one.
You could just cycle the beacons... frick shoulda read more carefully...

This post should be voted #1 for most fail and Strike-outs

Post has been edited 2 time(s), last time on Apr 1 2010, 11:58 pm by TiKels.

Sounds like the same system I described above!

Rereading your post, I think it IS the same.

For my RPG I'm using pre-placed burrowed units to spawn enemies.

I have a location over each unique area, and an array of pre-placed burrowed units under that location. I also have an inverted location on the character's unit to count steps. When these steps reach a certain amount, I spawn a randomized number and type of enemy unit near the character by centering locations onto the pre-placed units.

The downsides to this would be the amount of units it requires.

The pros would be very minimal location usage: 1 location to center and spawn for the whole map, and 1 over each unique area. Also, there are very rarely any "unit unplacable" errors since the spawn locations are pre-placed.

Sounds like the same system used in that one bound.