| 08-03-2003, 04:57 PM | #46 |
There are four functions for the use of forces or "teams" that I've found: SetPlayerTeam(player whichPlayer, integer whichTeam) integer GetPlayerTeam(player whichPlayer) SetTeams(integer teamcount) integer GetTeams() Where the first force is 0 and the second is 1 etc. Code:
function TeamForce takes integer whichTeam returns force
local force team = CreateForce()
local integer i = 0
loop
exitwhen i >= bj_MAX_PLAYERS
if ( GetPlayerTeam( Player(i) ) == whichTeam ) then
call ForceAddPlayer( team, Player(i) )
endif
set i = i + 1
endloop
return team
endfunctionRemove all the forces you have no need for as they remain in memory if you do not. Kind of silly really, come to think of it. |
| 08-03-2003, 06:34 PM | #47 | |
Quote:
I don't think so. From what I've seen the bj_ vars have trigger scope, local vars have function scope, and globals are... global. bj_ vars having trigger scope is why blizzard's functions still work. If the game only used threads under those conditions, the trigger queue would be redundant, and there'd be no need for locals. |
| 08-03-2003, 06:37 PM | #48 |
Can you put the whole pack into a ZIP or RAR? This would stop my problems downloading it (I don't want to delete my Cache). |
| 08-03-2003, 07:01 PM | #49 | |
Quote:
Go on and try it, I dare you :). If you have one trigger that increments bj_forLoopAIndex, prints it out and sleeps for one second and then loops back to the increment part, you will see that other triggers using bj_forLoopAIndex will affect it. In Trigger 1, which starts at map init: Code:
set bj_forLoopAIndex = 0
loop
call BJDebugMsg("Trigger 1: Current A Loop Index is " + I2S(bj_forLoopAIndex))
set bj_forLoopAIndex = bj_forLoopAIndex + 1
call TriggerSleepAction(1.00)
endloopIn Trigger 2, which has an event of your choosing: Code:
set bj_forLoopAIndex = 0
call BJDebugMsg("Trigger 2: Reset A Loop Index to 0")If you wait until Trigger 1 reaches 10 or so, and then trigger the event of Trigger 2, you will see that the count in Trigger 1 starts again from 0, which leads to prove that the bj_-globals are truly global. This works for any bj_-variable. |
| 08-04-2003, 12:34 AM | #50 |
Bjs are odd varaibles. In most cases if assigned correctly they have trigger scope as DA has put it. The integer ones don't have trigger scope I'm positive. But the unit ones I think do. Yet whats odd is I can print out who the dying unit is in another trigger yet have the original trigger keep running. (wait 10 second if no ones around revive dying unit always works). Bj vars are just wierd. |
| 08-04-2003, 12:35 AM | #51 |
Alright I did some testing and lo and behold: Peppar is right... and maybe wrong too? :P Peppar is right in that his example works. The confusion: I assumed that all Event Response functions had bj_ variables associated with them. I thought that maybe Peppar was right for direct assignment of bj variables, but maybe if you used the built in functions to access them, like GetForLoopIndexA(), that maybe they would have trigger scope like I thought. So I rigged up an experiment. I had a trigger detect a unit entering the center of the map, then turn itself off and just print the name of the unit over and over, like Peppar's printed the index over and over. Then I made another trigger that was identical except it didn't loop and it didn't turn itself off. Then I made another trigger that would spawn a footman the first time you entered a chat message, and a grunt the second time. I hypothesized that it would say footman over and over after the first time, then it would say grunt once (because of the second trigger), but continue saying footman after the second time. That, I thought, would prove that the bj_ variable for Event Response - Entering Unit had trigger scope. It worked just as I predicted! So then I went into blizzard.j to find the bj_ variable for GetEnteringUnit().... there isn't any :P All of the event response functions have trigger scope (note that Last Created Unit and such ARE NOT event response functions -- they do have bj_ vars) -- but blizzard.j and common.j don't give any indication as to how to make such a variable (common.j has the prototypes for the event response functions but niether .j has the definitions). And to think, none of this would be a problem if blizzard allowed one of two things: -Trigger scope variables -Passing arguments to functions called by ForGroup() Because my AOE damage function would be used primarily by JASS spells, which have various special effects and whatnot, that means I'd be using it mostly in triggers with waits -- which means multiple instances of the spell are gonna cause threads. I'm up shit creek :P Not sure how I'm gonna solve this problem :/ |
| 08-04-2003, 12:39 AM | #52 | |
Quote:
Damn, it might be true that it's different for different ones... yikes this could get ugly. I wish there were some way to easily tell which ones are and which ones aren't, or if it would take a million years to establish tests for them :P For sure IntegerA/B do not have trigger scope. So do event response functions (ableit they have no corresponding bj_ vars). Guess it's time to do some tests #_# I'm gonna start with the last dying/created ones, because I think those are most likely to have trigger scope. |
| 08-04-2003, 12:40 AM | #53 |
thanks DA you really have helped me figure out the strange pickle. |
| 08-04-2003, 12:42 AM | #54 | |
Quote:
I just replied to you. (replying again so you see you didn't make last post and actually read mine) |
| 08-04-2003, 01:01 AM | #55 |
Holy crap I think I just figured out how to get around this problem, and recode some of my function pack functions to work much more efficiently. Blizzard has hidden away in common.j: Code:
native FirstOfGroup takes group whichGroup returns unit So, for AOE damage, you set a group var to all units in range. You then do a loop, doing whatever actions you want on FirstOfGroup. Then at the end of the loop you REMOVE first of group from the group, so there's a new first and so on. Now you can iterate through unit groups!!! Yay!!!! I must go try this out =) EDIT: IT WORKS!!!! YAY!!!! No more of that stupid random unit stuff anymore!!! I'm adding a IterateGroup function to the function pack now... |
| 08-04-2003, 01:10 AM | #56 |
This is a most interesting discovery and I must say that I have never before even considered the idea that event responses are local :). Thank you for making that clear. Although my thoughts of the bj_-variables remain the same. I believe they are all truly global and that none of them are local to any triggers executed. Feel free to prove me wrong, though, just name a specific variable. |
| 08-04-2003, 01:17 AM | #57 |
Code:
function IterateGroup takes group whichGroup, integer unitindex returns unit
local group Units2Iterate = CreateGroup()
local integer i = 1
set Units2Iterate = whichGroup
loop
exitwhen IsUnitGroupEmptyBJ(Units2Iterate) or i >= unitindex
call GroupRemoveUnitSimple( FirstOfGroup(Units2Iterate), Units2Iterate )
set i = i + 1
endloop
return FirstOfGroup(Units2Iterate)
endfunctionNeed some assistance though.. (care to chime in Peppar? :ggani: ) First -- since I create a group am I going to half to destroy it too, or will the function closing do that for me? Second, will this line be troublesome?: Code:
set Units2Iterate = whichGroup i.e. will it treat Units2Iterate like a pointer (not what I want) and make it point to whichGroup, or will it treat it like a normal variable (what I do want) and just have it be a unit group with all the same units in it as whichGroup? Third -- If I'm just assigning Units2Iterate to have all the units of another group, do I still need to call CreateGroup()? |
| 08-04-2003, 01:26 AM | #58 |
I think that 'group' (or any handle-derived variables) act like pointers, making the code Code:
set Units2Iterate = whichGroup at the group passed to the function, as you feared. I don't know if there is any copy-group-function? Not to difficult to create though, I'd reckon. And yes, I think you have to manually create and destroy groups. :/ EDIT: Blizzard.j function GroupAddGroup should do the trick. Code:
function GroupAddGroup takes group sourceGroup, group destGroup returns nothing |
| 08-04-2003, 01:45 AM | #59 |
Just a side note though, wouldn't it be faster to use ForGroup- enumeration for iterating unit groups? Using blizzard globals would make it possible, even if it would get complicated. Anyway, just a thought :) The other functions working on groups I guess would be faster with your new discovery, like UnitTypeIsInRegion. |
| 08-04-2003, 02:05 AM | #60 | |
Quote:
Well, it would be FASTER, but it would require calling another function with the actions to perform on the group inside it, and I can't pass arguments to that function. =) |