The concept is simple: use any grid system of your choice (something that returns an accurate X and Y coordinate for the player's position at each moment), and then a set of triggers specifying which coordinates are NOT allowed, thus causing the relocation of the player's unit to its last valid position.
Since I don't have the patience to go through the tedious process of mapping each coordinate to define the whole coastal edge (I'm working on a method to map them out automatically), I just mapped out the top coast line loosely and left it at that (you get the point). The basic idea is that you can save a tremdous amount of locations using this method, but I still need to refine it further before anyone would be able to use it.
This version uses edge units to find the coordinate, since I was too lazy to use my newer unit-free system or Salacious's. Anyway, if anyone's interested in using this, I'll work out the best way to do it and setup a tutorial for everyone.
tux, looks great but btw, could you make a tutorial on how to make grids and wat they are useful for also?
half the people(including me) dont know how to make one and since your the master, I'd probably understand.
It is a quite simple concept. Just make 2 locations across the whloe map one would be your X coordinates and the other will be Y.
Depending where you move your unit those 2 locations will follow it thus moving. Bacaue you have a column and row of cannons at the edge of the map, 2 cannons will always be in those locations. One at X and the other at Y.
The cannons inside either a X or Y location will be given to another computer player thus the coordinate has been given. Now depending on which combination of cannons where given to another player you know know where the original unit where the X and Y locations are following.
Now you know where the unit is and can take any action that a simple location put there would've done.
This would be great for Clokr_'s map.
I really didn't see the triggers, I just saw the locations and cannons and basicly figured it out. If what I said in untrue then please correct me.
Wow, awesome idea. It took me a bit to understand how it works, but it would extremely usefull for saving locations and such.
anyone know how many cannons or unit that size would fit across one edge of a 256x256 map? I'm of course too lazy to think of a way to figure it out myself.
The only difference between this system and locations is
1) Using a hell of a lotta locations.
2) Taking a lot less time (you won't need to test where the cliff starts)
So I guess it depends on what you have
Depends on what type of unit you would use.
A photon cannon is 2x2 tiles so you divide the tile lenght and width of your map by that.
In a 256x256 map it would be 128 cannons horizontally and 128 cannons vertically.
A 2x2 area isn't very accurate when you want some units out of specific areas.
I would propose for the people who want accuracy using burrowed lings. Yes they are more triggers to be done but you ge tremendous accuracy.
Hmm...
QUOTE(Trigger)
(condition) Bring(CurrentPlayer, Exactly, 0, Buildings, [X]);
(actions) GiveUnits(1, Buildings, P2, [COLUMNS], CurrentPlayer);
MoveLocation([X], Men, CurrentPlayer, Anywhere);
SetResources(CurrentPlayer, Add, 1, Ore);
PreserveTrigger();
Comment("");
why are so many copies of that trigger (and the one for rows) necessarry?
also, I'm pretty sure you'd be able to use this for anything involving the Bring condition... you wouldn't need to make a location for where to bring a unit for something (for example a cutscene in in RPG or something), you'd just need to know the cannon (or other unit used for rows/columns) coordinates of the area.
^ - EDIT: duh, that's pretty much what the point of this topic was...
<end edit>
of course, it might be kind of akward depending on the size of the area... with the <length/width of location depending on whether x or y> being across the map, and being only 1, wouldn't the player have to bring their unit to the exact 1x1 area? or would it depend on the size of the unit used along the edges? (cannons in this case)
This is a lot like the method I was trying to describe to clokr_ on AIM the other day when he made that topic in map making assistance. Except yours can be much more precise and takes up many more triggers.
Good work, I hope to see this used in a map sometime.
Alright, I'm confused...
"The basic idea is that you can save a tremdous amount of locations using this method"
Alright, so the point is making sure the player's unit cannot get outside of a certain area once a certain event occurs(such as battle), but isntead of moving him, you move the battle area?
QUOTE(EzDay2 @ Jan 17 2005, 10:51 AM)
Alright, I'm confused...
"The basic idea is that you can save a tremdous amount of locations using this method"
Alright, so the point is making sure the player's unit cannot get outside of a certain area once a certain event occurs(such as battle), but isntead of moving him, you move the battle area?
[right][snapback]126859[/snapback][/right]
I think the main idea is that you can save locations because instead of having to make a location to detect if a player brings a unit to that area, you can just figure out what the "cannon coordinates" of the area and make the actions occur when a player has the number of resources/custom score corresponding to those coordinates.
Not just locations, but units too. A map lags with more units and if you cut down on the units and open up some more locations for you to use (because sometimes you need more locations than you have to do this sort of thing). You are essentially abusing the maps huge trigger limit to compensate for a lack of ability to place large numbers of units or locations.
QUOTE
I think the main idea is that you can save locations because instead of having to make a location to detect if a player brings a unit to that area, you can just figure out what the "cannon coordinates" of the area and make the actions occur when a player has the number of resources/custom score corresponding to those coordinates.
Either what I said or what you said can be easily solved.
Trigger |
nullConditions: |
¤ Player Bring 0 Unit to location Player |
Actions: |
¤ Move Location Player onto Unit for Player
|
¤ Move Location Detector on Unit for Player
|
¤ Randomize Switch "Battle"
|
¤ Preserve |
Trigger |
nullConditions: |
¤ Player Brings 1 Unit to location Town1
|
¤ Town Brings 1 Shop to location Detector |
Actions: |
¤ Shop Triggers
|
¤ Preserve |
The problem is that the edges take up a lot of units on their own (especially on large maps), and it becomes tedious to specify 'zones' by punching in numbers haphazardly. Fear not, though, since I'm working on a way to solve both problems, and allow greater precision (1 grid square instead of 2) and I'll post a tutorial (I'll try to make it easy to understand) on how to implement the whole system into any map.
For those still trying to figure this out, it's simply checking the player's unit's coordinates and enforcing boundaries if the player is within certain ones. You could instead do almost any effect you want while a player is within any coordinates you want, though.
QUOTE(Tuxedo Templar @ Jan 18 2005, 05:32 PM)
The problem is that the edges take up a lot of units on their own (especially on large maps), and it becomes tedious to specify 'zones' by punching in numbers haphazardly. Fear not, though, since I'm working on a way to solve both problems, and allow greater precision (1 grid square instead of 2) and I'll post a tutorial (I'll try to make it easy to understand) on how to implement the whole system into any map.
For those still trying to figure this out, it's simply checking the player's unit's coordinates and enforcing boundaries if the player is within certain ones. You could instead do almost any effect you want while a player is within any coordinates you want, though.
[right][snapback]127586[/snapback][/right]
I understand the concept but what is the way that uses no units, and how are you going to make the triggers better so that you dont have one trig for each x and y along the whole edge of the map, like now you have to use 64 trigs for one side of a 64x64 map
Well one way is to begin to 'move' from the edge origin out to the farthest coordinate possible, and use how much 'time' it took in moving on each axis until it encountered the unit to determine its coordinate. That technically does use units, just not preplaced ones, so it won't count toward the limit hugely. Another way, on the same note, is to 'move' by using relativity grids, or placing units and positioning a location on the one going in the direction you want, and then determining the coordinates by how many moves are needed. If you use enough triggers, you can do the move in one trigger cycle across any sized map, but the down side is that this method can lag a LOT, so you'd be wise to limit its use.
One final way is to find the unit's starting coordinates, and then as it moves, keep track of it's movement along each axis with the same relativity grid-type thing mentioned above. That involves mostly adding and subtracting from the starting coordinate, which would be a lot more lag and unit safe. I'll probably end up using this method.
I think I know what you are talking about, but why don't you post a map with this system you are working on? Or, if you don't post it here, why don't you post a link to the map when you create the tutorial?
Um, cause I haven't made it yet? It's easy to make the map, but I'm trying to get a way (maybe a small utility?) for people to declare 'zones' without tediously examining each point and making triggers for each number or number range they want an effect to occur in.
Once it's finished, this'll be a whole new way to do maps with affectively unlimited locations.
does the map you attached use that zone system? i just tested it out and it didnt work.
oh nvm it works. i didnt go to the right places.
Tux do you have a way to create a unit at where both locations meet?
No. Well, yes I do, but it involves a messy system of 'moving' to that location with relativity grids, which is nothing short of lag central. Plus, if anything obstructs the path as far as air units, there's a chance it'll screw up.
Hey Tux, now that you've made the perfect boundary system that can make unlimited "locational" boundaries, what do you plan on doing next?
*hint hint Move/spawn unit to location hint hint*It's not perfect, but this is one of the best grid uses ever. I have a quick question though, when giving away cannons, why not use the trigger
Trigger |
Conditions: |
¤ Current player brings exactly 0 unit to '[X]' |
Actions: |
¤ Center location labelled '[X]' on Photon Cannon owned by Player Comp at 'Anywhere'.
|
¤ Give 1 Photon Cannon at '[X]' to Current Player
|
¤ Set resources: Add 1 to Current player.
|
¤ Preserve trigger. |
Well one problem is, as far as I remember in the map, moving to cannons owned by the comp at 'anywhere' will only move along the Y axis, which is useless for the [X] location. Without recalled the exact triggers I used though, I can't really tell you why or why not offhand.