anyways i think ive gained what knownledge i can from this thread; thanks.
Creating units below the player, using grids... all seems incredibly unnecessary for tracking the hero.
honestly i dont know, i thought i said it quite clearly the thread served its purpose.
Well, it has served the purpose for you, but if people have something more to say why dont let them? =)
UnholyUrineEvery time I play the TempleSeige map I do notice a little lag. You should really think at optimizing your triggers if you want to develop the map further.
+1
Make one trigger for "all players" per hero with a condition that player has x deaths of a certain unit used as a death counter. If they have 1 death, they picked a marine, if 2 they picked a zealot, etc. This would detect how many deaths they have and constantly center the location on the appropriate unit based on that.
It is a good idea to do this when a player chooses the hero in any case. Simply using a command hero condition to decide what is the player's hero is not reliable. The hero may die which may leave the player without a hero at all for a few trigger cycles or the hero unit may be used as a spell-unit for another hero (like Lurker in TS).
You know, after I've posted the next answer to the next statement
Uhm, why not just 1 location per player and have 12 triggers (1 per hero) per player (72 total) that go like
P1: If Current Player brings at least 1 hydralisk to anywhere center P1 on hydralisk owned by Current Player
P2: If Current Player brings at least 1 marine to anywhere center P2 on marine owned by Current Player
... etc
Great.. now he's gotta do 6 triggers per spell... that's even worse than what Falkoner suggested..
Yeah, you can have "If current player bring at least 1 hero hydralisk to anywhere.. and if current player *casts spell 1* (w/e the condition may be... center location "hero hydra" to hydralisk owned by current player, create spell units (mutalisks) at "hero hydra" for current player.... but that's even more work than just having the triggers set in the beginning. and you get the same amount of locations that you need.
I went to bed and thought I was little wrong in my judgements. I thought about this
A more effective system would be to have a location per player to center on whichever hero they control. Then at the start of each player loop section center a universal location in the respective player location. That way you can just operate virtually everything from that location, without unnecessary class specification.
Lincoln, I'm only not sure whether the system is more effective (and in what sense). The only pro of the system against UnholyUrine's I can see is one can have players with the same heroes. IMO the amount of triggers the system requires is approximatly the same as the UholyUrine's. The system can also save a few locations (8-12 locations saving is the most I believe) if you have <number of available heroes> > <max number of players>. You know, of late time I used to think about CPU saving. The system if implemented straightforward will have much move location actions per each trigger loop than the UnholyUrine's (move Universal location), which is not good. But if one consider the note
but I dont see any reason to track heroes with locations. All spells could be done without tracking, just centering the required location when spell is casted.
I believe number of locations movements will be acceptable. The note is true in the UnholyUrine's system too. There is no real need (for spells) to constantly track heroes with their locations respectively. Though there is a need to track hero with a location when you have some kind of items which heroes could take.
I myself have more positive attitude towards the system Lincoln has described against UnholyUrine's, but I can't explain why I have such a feeling. Facts indicate both methods are good.
Also- isn't it easier to move a unit to a location over water to stun it? This would only require one location to use for all the stun triggers, you could even double it up as being used for another misc. system somewhere off the map. I have never used this myself, but i heard it works.
Nah. that doesn't work, as moving units with hyper trigs, other units will perceive it as being moved away and can not attack it.. Altho triggers can still detect them, the Unit AI cannot :S... it's strange.. However, you MAY be right because i've tried a different method, which is continually moving the unit to the spot it was at.. it may actually work with moving it to water I guess ><".. I'd have to check that out...
If you ever will implement this idea move the unit to the location which is preplaced out of map's bounds. This will have the same effect but lags lesser.
From the other topic (
http://www.staredit.net/132396/):
Moving many units to a location where they cannot be moved to, because other units block the whole area, causes much lag, too.
By the way moving units to a location which is out of map bounds causes no lag (very small).
Less, but not none. I've seen many maps lag solely because of excessive use of this.
A more effective system would be to have a location per player to center on whichever hero they control. Then at the start of each player loop section center a universal location in the respective player location. That way you can just operate virtually everything from that location, without unnecessary class specification.
Looks promising, but how does that work? .. So you have this one location that's being centered on everyone each time it loops? What if players use spells at the same time?
If, again, I have 12 heroes right? And each player can pick which one they want to be... So then I gotta prepare the spell triggers to be working for each hero for each player at all times. Since if two ppl uses their spells at the same time, then one person's spell units may be centered under another guy... it'd be funny, but not help ur map in anyway XD
If you mean to have each player their own location... then i don't understand. 1st, you already have a location per player.. 2nd, you still gotta do 6 triggers (if there're 6 players) per spell.
What I do is I have several locations (if need be.. of different sizes) on each hero if anyone owns them.
I think I'm missing something.. wanna straighten me out?
Let me give you an example of triggers to make it clear. I assume you have the hero type death counter (referenced as dcHero) set properly as I've said at the very beginning.
// You requre to know whether the current player casts a spell to reduce number of unnecessary
// location movements as I've said above. Let's assume we have a group of triggers which set the
// switch sCastSpell in the case. These triggers should also ensure the player can cast the spell.
// For example he has got enough mana and isn't casting any other spell at the moment.
Group1
{
TRIGGER
OWNERS: fPlayersForce
CONDITIONS:
Always.
ACTIONS:
Clear switch sCastSpell.
Preserve trigger.
// Other triggers.
...
}
// The second group of triggers distribute player specific locations lPlayer(p) between players.
Group2
{
// h is an integer value, the corresponding hero is referenced as HeroUnit(h)
REPEAT FOR EACH PLAYER p IN fPlayersForce
REPEAT FOR EACH HERO TYPE h
TRIGGER
OWNERS: p
CONDITIONS:
Switch sCastSpell is Set.
Current Player has suffered Exactly h deaths of dcHero.
ACTIONS:
Center location labeled lPlayer(p) on HeroUnit(h) owned by Current Player at lBattlefield.
Preserve trigger.
END REPEAT
END REPEAT
}
// to insure ourselves against spells triggers copying for each player location lPlayer(p) we do
// the next
Group3
{
REPEAT FOR EACH PLAYER p IN fPlayersForce
TRIGGER
OWNERS: p
CONDITIONS:
Switch sCastSpell is Set.
ACTIONS:
Center location labeled lUniversal on Men owned by Current Player at lPlayer(p).
Preserve trigger.
END REPEAT
}
// The next group are spells triggers. Each spell trigger owner is the whole force fPlayersForce.
// Spells triggers operate with the location lUniversal and thus need not to be copied.
Group4
{
...
}
One may ask, why do we need player specific locations lPlayer(p) at all. We could have handled the lUniversal location right in the triggers group Group2 and get rid of the Group3. The answer is that spells might require few trigger loops to operate. The scenario is the following:
1. Spell initialization at start. For example this may involve units creating at the cast point.
2. The spell is active. Several cases at this stage: the spell follows the hero or lives it's own life. In our case units simply attack nearby enemies from where the spell was casted.
3. At end, destruct the effects of the spell
at the place where the spell was casted. Remove our spell-units.
We can see that for the step 3 (and probably step 2 as well) we need somehow to save the point where the spell was casted because the hero unit could already run far away from that point. This could not be done with the location lUniversal because it might not (read does not) preserve it's place even throughout one trigger loop (it preserves during some "critical" section of triggers execution, where it is not modified though). We're saveing the point with the lPlayer(p) location.
While I was writeing this the idea that we can save the cast point by the mean of a burrowed unit came to my mind. Someone else could look if this will result in less triggers count, less possible lag and etc.
from there wormer went little offtopic, or thoughts about objects classification
By the way, at this point I have a good (IMO) classification of modifyable map objects in my mind. Under objects I assume mainly locations, death counters, switches, score. The first group are static objects which preserve their initial "value" (in wide interpretation) throughout the whole game. The most widespread example are locations of some static areas, like battlefield, areas of healing, inventory areas and such. The second group are player specific objects which hold some kind of a state for the dedicated player and could not be modified by other players triggers. In our case there are the deathcounter dcHero and all player specific locations lPlayer(p). The last group are local objects which might not hold their value even throughout one trigger loop. In our case there are the switch sCastSpell and the location lUniversal.
The classification is relatively conventional. The player specific group is the most vague, but it largely helps to organize everything in mind. Also such objects as death counters, most of the score (only except the custom score), resources, even timer and elapsed time could be modified not only by triggers but by the SC core engine between trigger loops as well. On the other hand kills counter could not be modified directly by triggers at all. Regarding to this property there are only three kind of pure objects which could be modified only by triggers, there are locations, switches and custom score.
Well... at this point Wormer just got tired and went to sleep...
P.S. Ah I have forgot the last, the most important.
What I gave you is the easiest to work with... Look into Temple Siege.. The triggers are set to be the LEAST stenuous in terms of trigger number.
How do you know them are the least? The least triggers usually is not the best. The least triggers usually does not mean the easiest to handle... I even
think have got an example.
A more effective system would be to have [...]
Ah guys, please, never say never.
Post has been edited 1 time(s), last time on Feb 19 2009, 10:19 pm by Wormer. Reason: never say never
Some.
UnholyUrine
