Hey guys, right now I'm having an issue with my buff system. I have it properly working atm to show the player his own buffs, from all sources. What I do is create a dialog button on the top left displaying the current buffs a player has. (Which is determined by triggers are not actual behaviors)
What I'm having trouble with is displaying a target's buffs. Think of an RPG. A player can see his own buffs, and when another target is selected, he should be able to see their buffs/debuffs as well. I don't know how to go about doing it... If needed, I can post everything up so you guys can see how I'm handling things.
The way I see it, you would need a data structure that lets you map from units to some records that specify what buffs are active.
You could make an array of records, and assign a custom value to units specifying an index in that array. By default, the custom value is 0, so it might be good to keep 0 as a "null pointer" (to indicate that no buffs are active).
Also, to make the system work for any number of units, you might want to make the array based on the data table rather than a regular array. That also makes index management easier (no need to reuse old indices). On the downside, the data table is slower than a global array, but I believe it's worth it unless you have a known small lower bound on the number of possible targets.
Based on that data structure, you can make algorithms to efficiently add and remove buffs, and to efficiently get buffs of a unit.
When adding a buff, get the custom value of the unit, if it is 0, then assign a new unused one, update the corresponding record, and update the buff frames for players targeting that unit.
When removing a buff, get the custom value, update the record, if no buffs are set, clear the record and set the custom value to 0, and finally update buff frames.
Getting the buff record when targeting a unit is just get the custom value, if 0, no buffs are present, otherwise get the record from the array.
The way I see it, you would need a data structure that lets you map from units to some records that specify what buffs are active.
You could make an array of records, and assign a custom value to units specifying an index in that array. By default, the custom value is 0, so it might be good to keep 0 as a "null pointer" (to indicate that no buffs are active).
Also, to make the system work for any number of units, you might want to make the array based on the data table rather than a regular array. That also makes index management easier (no need to reuse old indices). On the downside, the data table is slower than a global array, but I believe it's worth it unless you have a known small lower bound on the number of possible targets.
Based on that data structure, you can make algorithms to efficiently add and remove buffs, and to efficiently get buffs of a unit.
When adding a buff, get the custom value of the unit, if it is 0, then assign a new unused one, update the corresponding record, and update the buff frames for players targeting that unit.
When removing a buff, get the custom value, update the record, if no buffs are set, clear the record and set the custom value to 0, and finally update buff frames.
Getting the buff record when targeting a unit is just get the custom value, if 0, no buffs are present, otherwise get the record from the array.
I dont think a data table is required. We can already access a units behaviors via indexes via triggers. It is possible to get say the 1st buff on a units and the 5th buff on a unit as well as its name and duration; whether it is hidden or not, or activate on damage etc2. I think its even possible to get the buff's tooltips via Catalog functions as well.
@Enexy: this way all you would need to know are what units are the players currently tracking. and you would have to periodically update the units behaviors.
What I do is create a dialog button on the top left displaying the current buffs a player has. (Which is determined by triggers are not actual behaviors)
Still, behaviors might be more elegant, since that's the way buffs are supposed to work.
I'm probably gonna run into another problem with displaying the duration of the buff without causing a slowdown in the game.
A way to do that could be to just invalidate the buff bars every 1 second or every 0.5 seconds. Then you don't need to worry about when buffs are gained/lost. As long as you are happy with durations being in seconds, I don't think it will cause much lag.
Thanks lol. I'm probably gonna run into another problem with displaying the duration of the buff without causing a slowdown in the game.
well, looking at your project's thread, it looks like you already have a custom healthbar yes? Is it periodically updated or otherwise only updated when the unit takes damage?
If its periodically checked, then I suggest adding the actions for this buff bar to that periodic trigger to save it from having to create another trigger thread =D
And yes, just as SBeier said, I agree, I dont think it will cause that much lag. Especially since you already have custom healthbars too; so why not lol.
@SBeier: ohh, right. Didnt see that, my bad lol. well in a way I think having a dummy behavior would save the hassle of manually removing the 'buff' via triggers when a certain dispelling ability is cast. With at least a dummy behavior running, all Enexy has to do is check if the behavior is there and voila =P
Only updated when unit takes damage. Periodic updates are out of the question for me for anything.
What I do have is dummy behaviors already along with triggers.
Unfortunately I just ran into another problem where let's say Player A casts negative buff spell that lasts 15 seconds. 10 seconds later Player B casts that same negative buff spell... I think I might know a solution. This whole buff thing is very difficult for me, ugh.
Only updated when unit takes damage. Periodic updates are out of the question for me for anything.
What I do have is dummy behaviors already along with triggers.
Unfortunately I just ran into another problem where let's say Player A casts negative buff spell that lasts 15 seconds. 10 seconds later Player B casts that same negative buff spell... I think I might know a solution. This whole buff thing is very difficult for me, ugh.
I see. So by this I take it that you are gonna try to update the buffs only when it gets cast or removed. Well that is gonna be hard tbh, not impossible but alot of work.
If it was periodical, it would be wayy much simpler lol. But yeah I understand the need to have a map suffer less from bnet lag =(
By any chance, are you using dummy behaviors? or simply triggering all the duration of the buffs? I do have an idea using dummy behaviors that could probably solve that buff recast thing you are facing.
Behaviors have these 'Expire' and 'Finish' effects you see, one activates when the buff runs its full duration while the latter is whenever it gets removed. They also have 'Initial' effects that run when the buff first hits. What i'm picturing right now is, putting a dummy effect to each dummy behavior you have in your game that runs a dummy effect on initial, expire, and finish.
Have a trigger that runs whenever the 'dummy effect' activates that checks the unit's (just that specific unit that was hit by the effect) buffs and updates all other information for your buff bar.
now what if the spell is an AOE spell that spreads behaviors like a disease? wont it lag because it checks a heck lot of units' buffs?
All you would need to do is to create a dummy behavior (Yes I love dummies alot) that will indicate which units are 'tracked' by players. Then create a validator that checks whether this tracking behavior exists on a unit; and put it up on the dummy effect I mentioned earlier (the initial,expire,finish one), making the effect to only run on units that are tracked by players.
The result: Is a trigger that runs when a behavior is first cast, finishes, expires, or removed by another ability.
Of course this will mean you will need to familiarize doing things with data... or otherwise dummies and link them to triggers that way.
Yeah, I would loovvveee to do it as periodic checks, and I "might" do it and test out it's lag... But, this'll be the ultimate last resort.
I'm using dummy behaviors and triggering the duration of the buffs.
I see, let's say I make an aura type behavior, like cloak field or something from a mothership. Will any unit that goes out of it's range get the finish effect?
How about you come over to my team and help out :)
Answering your questions as I go:
Yeah, I would loovvveee to do it as periodic checks, and I "might" do it and test out it's lag... But, this'll be the ultimate last resort.
I'm using dummy behaviors and triggering the duration of the buffs.
I see, let's say I make an aura type behavior, like cloak field or something from a mothership. Will any unit that goes out of it's range get the finish effect?
How about you come over to my team and help out :)
lol, on my map's healthbar system, i used to have an On-damage update. The next thing I realized was my units all have a passive health regen.... so uh yeah. =(
Well.. from how I think the mothership's aura works, i think that would be the Expire (the buff runs its whole duration) effect instead of Finish. Because what it does is do an Area search around the mothership every 0.2 seconds and apply the Cloak behavior; that itself lasts 0.5 secs. So no forced removal involved here.
So yeah, I think doing an event that fires when a Behavior's Initial, Expire, and Finish effect activates is the key.
ahahha, well i was occupied by the TL melee map contest these past few weeks, and am now taking a break and doing other stuff. I'll see if im free later on; altho im not promising anything =S
Quick question. What is the maximum thread limit? Also, how many wait 0.0's can I have before the game will slow down? Will it slow down at all?
EDIT: Np, thanks for all the info. Looking at some other routes. Keep hitting road blocks with every system I try.
I believe ive seen someone say in these forums that, unless u have trigger that fires for every attack and you have 100 marines with machine-guns shooting at each other, performance issues from thread creation wont be that much of a problem. Ofc, you have to remember when you have the debug window open, the game becomes veryyyyyy slow. Dont even compare that to the actual bnet lag.
A wait counts as a thread i think. And personally, i dont really think wait counts slow down the game to a considerable effect; unless you have a bunch of infinite loops with waits and a long list of actions.
lol, well good luck with ur map >.< hope it goes well =D
Hey guys, right now I'm having an issue with my buff system. I have it properly working atm to show the player his own buffs, from all sources. What I do is create a dialog button on the top left displaying the current buffs a player has. (Which is determined by triggers are not actual behaviors)
What I'm having trouble with is displaying a target's buffs. Think of an RPG. A player can see his own buffs, and when another target is selected, he should be able to see their buffs/debuffs as well. I don't know how to go about doing it... If needed, I can post everything up so you guys can see how I'm handling things.
The way I see it, you would need a data structure that lets you map from units to some records that specify what buffs are active.
You could make an array of records, and assign a custom value to units specifying an index in that array. By default, the custom value is 0, so it might be good to keep 0 as a "null pointer" (to indicate that no buffs are active).
Also, to make the system work for any number of units, you might want to make the array based on the data table rather than a regular array. That also makes index management easier (no need to reuse old indices). On the downside, the data table is slower than a global array, but I believe it's worth it unless you have a known small lower bound on the number of possible targets.
Based on that data structure, you can make algorithms to efficiently add and remove buffs, and to efficiently get buffs of a unit.
When adding a buff, get the custom value of the unit, if it is 0, then assign a new unused one, update the corresponding record, and update the buff frames for players targeting that unit.
When removing a buff, get the custom value, update the record, if no buffs are set, clear the record and set the custom value to 0, and finally update buff frames.
Getting the buff record when targeting a unit is just get the custom value, if 0, no buffs are present, otherwise get the record from the array.
I dont think a data table is required. We can already access a units behaviors via indexes via triggers. It is possible to get say the 1st buff on a units and the 5th buff on a unit as well as its name and duration; whether it is hidden or not, or activate on damage etc2. I think its even possible to get the buff's tooltips via Catalog functions as well.
@Enexy: this way all you would need to know are what units are the players currently tracking. and you would have to periodically update the units behaviors.
@Zolstice: Go
Thanks for the help, I got some good info on what I can possibly do.
alrightt, post again if something comes up, ill try and help. dont see why it shouldnt work.
Good luck with that RPG of yours =D
@Zolstice: Go
Thanks lol. I'm probably gonna run into another problem with displaying the duration of the buff without causing a slowdown in the game.
@Zolstice: Go
Well.. he did say that the buffs were not actual behaviors, but purely trigger based.
Still, behaviors might be more elegant, since that's the way buffs are supposed to work.
A way to do that could be to just invalidate the buff bars every 1 second or every 0.5 seconds. Then you don't need to worry about when buffs are gained/lost. As long as you are happy with durations being in seconds, I don't think it will cause much lag.
well, looking at your project's thread, it looks like you already have a custom healthbar yes? Is it periodically updated or otherwise only updated when the unit takes damage?
If its periodically checked, then I suggest adding the actions for this buff bar to that periodic trigger to save it from having to create another trigger thread =D
And yes, just as SBeier said, I agree, I dont think it will cause that much lag. Especially since you already have custom healthbars too; so why not lol.
@SBeier: ohh, right. Didnt see that, my bad lol. well in a way I think having a dummy behavior would save the hassle of manually removing the 'buff' via triggers when a certain dispelling ability is cast. With at least a dummy behavior running, all Enexy has to do is check if the behavior is there and voila =P
@Zolstice: Go
Only updated when unit takes damage. Periodic updates are out of the question for me for anything.
What I do have is dummy behaviors already along with triggers.
Unfortunately I just ran into another problem where let's say Player A casts negative buff spell that lasts 15 seconds. 10 seconds later Player B casts that same negative buff spell... I think I might know a solution. This whole buff thing is very difficult for me, ugh.
I see. So by this I take it that you are gonna try to update the buffs only when it gets cast or removed. Well that is gonna be hard tbh, not impossible but alot of work.
If it was periodical, it would be wayy much simpler lol. But yeah I understand the need to have a map suffer less from bnet lag =(
By any chance, are you using dummy behaviors? or simply triggering all the duration of the buffs? I do have an idea using dummy behaviors that could probably solve that buff recast thing you are facing.
Behaviors have these 'Expire' and 'Finish' effects you see, one activates when the buff runs its full duration while the latter is whenever it gets removed. They also have 'Initial' effects that run when the buff first hits. What i'm picturing right now is, putting a dummy effect to each dummy behavior you have in your game that runs a dummy effect on initial, expire, and finish.
Have a trigger that runs whenever the 'dummy effect' activates that checks the unit's (just that specific unit that was hit by the effect) buffs and updates all other information for your buff bar.
now what if the spell is an AOE spell that spreads behaviors like a disease? wont it lag because it checks a heck lot of units' buffs?
All you would need to do is to create a dummy behavior (Yes I love dummies alot) that will indicate which units are 'tracked' by players. Then create a validator that checks whether this tracking behavior exists on a unit; and put it up on the dummy effect I mentioned earlier (the initial,expire,finish one), making the effect to only run on units that are tracked by players.
The result: Is a trigger that runs when a behavior is first cast, finishes, expires, or removed by another ability.
Of course this will mean you will need to familiarize doing things with data... or otherwise dummies and link them to triggers that way.
@Zolstice: Go
Answering your questions as I go:
How about you come over to my team and help out :)
lol, on my map's healthbar system, i used to have an On-damage update. The next thing I realized was my units all have a passive health regen.... so uh yeah. =(
Well.. from how I think the mothership's aura works, i think that would be the Expire (the buff runs its whole duration) effect instead of Finish. Because what it does is do an Area search around the mothership every 0.2 seconds and apply the Cloak behavior; that itself lasts 0.5 secs. So no forced removal involved here.
So yeah, I think doing an event that fires when a Behavior's Initial, Expire, and Finish effect activates is the key.
ahahha, well i was occupied by the TL melee map contest these past few weeks, and am now taking a break and doing other stuff. I'll see if im free later on; altho im not promising anything =S
@Zolstice: Go
Quick question. What is the maximum thread limit? Also, how many wait 0.0's can I have before the game will slow down? Will it slow down at all?
EDIT: Np, thanks for all the info. Looking at some other routes. Keep hitting road blocks with every system I try.
I believe ive seen someone say in these forums that, unless u have trigger that fires for every attack and you have 100 marines with machine-guns shooting at each other, performance issues from thread creation wont be that much of a problem. Ofc, you have to remember when you have the debug window open, the game becomes veryyyyyy slow. Dont even compare that to the actual bnet lag.
A wait counts as a thread i think. And personally, i dont really think wait counts slow down the game to a considerable effect; unless you have a bunch of infinite loops with waits and a long list of actions.
lol, well good luck with ur map >.< hope it goes well =D
@Zolstice: Go
Thanks - I think I got the solution finally.