It can be easy to fire more than thousands. For example, if you have many units with an attack speed of zero, "any unit is attacked" can cause overflow problems.
Show me proof, create a testmap, where an event failed to trigger. I have yet to see a map, where an event fails, which is 100% not related to any other stuff interfering (and by that, I do not mean too many events at once, but just other triggers, conditions or variables messing with the actual trigger)
When you say thread, are you referring to it in the context of parallel processing, or does the term have a different meaning in the editor?
Does the editor actually give you control over how many concurrent threads are run on your processor?
Not the threads on your processor, but the threads handled by the game. Each trigger starts its own thread for example. In Gui, you can create functions, which run in their own thread as well (well, this translates to galaxy by actually creating a new trigger anyways).
@TheAlmaity: Go
Catalogs sound like fun. Are they restricted to modifying effect parameters? Or can we mess around with the Ability parameters as well? I'm thinking of using some unused field to store the damage values. I'd like to avoid having to create extra effects where possible (Trying to avoid any unecessary map size increase and keep things optimal.)
They can basically be applied to any data object; however quite a lot of fields are read-only (for example almost all behavior fields except duration). For abilities, they also change the values for all data objects of the player, so they can only be used if one player cannot use multiple levels of the abilities simultaneously.
They can change the same fields an upgrade object can change.
And why store the damage in unused fields, when you can just make the tooltip show the damage and change the damage directly via catalogs? This is my current method (the one posted earlier in this thread is out-dated), and it works just fine, not only for damage, but for many other values as well. Tooltips can show the same values catalogs can read and modify, and they show the modified values properly.
Yeah, parallel processing. The trigger that runs the spell is never created until it is needed. Once the spell is cast, it is created, run, then destroyed. (Case A) If my understanding of how this works is right, this isn't the same as having a trigger that is created and left in the background until it is needed. (Case B)
In case B, if 1000 events fire, the single trigger in the background might not be able to handle it quick enough (that is assuming it runs in a sequential manner). Whereas in Case A, every spell cast means one instance of the trigger is created and run parallel with the rest.
What Keuken says, I believe is probably more accurate.
Quote:
Does the editor actually give you control over how many concurrent threads are run on your processor?
Not too sure about how the editor handles this. I haven't found any function that allows me to do that so far, but who knows, it might exist. Either that or its done automatically.
Edit:
Quote:
And why store the damage in unused fields, when you can just make the tooltip show the damage and change the damage directly via catalogs? This is my current method (the one posted earlier in this thread is out-dated), and it works just fine, not only for damage, but for many other values as well. Tooltips can show the same values catalogs can read and modify, and they show the modified values properly.
I don't suppose you could share a simple example of how this is done by any chance? I'm sort of a reverse engineer, I learn better through practical >_>
By the way, forgot to ask. If I change a catalog value, is it universal? Lets say I use DummyEffectA to store my damage. But when I change the damage with catalog, wouldn't all players be affected by it? If this is so, If two players have the same ability, one has it at level 1, the other at 2, wouldn't the tooltip display incorrectly for one of them?
Edit: Seems it allows catalog setting for individual players. I foresee a problem if the same player has 2 units with the same ability though.
All catalog values have a playergroup parameter, they can be changed for each player individually. The tooltips will show up correctly, as long as only one instance of the ability is allowed per player (or all instances always have the same level).
I will create a small example map. You are familiar and fine with galaxy script, correct? If not stated otherwise, I will use it.
Not to worry, Galaxy script is fine. I believe you're slightly mistaken:
bool CatalogFieldValueSet ( preset catalog, string entry, string fieldPath, int player, string value )
It takes a player, not a player group.
Quote:
as long as only one instance of the ability is allowed per player (or all instances always have the same level
This is actually what has me stumped. Im working on the assumption that there might be a possibility where 1 player has dupes of the same units, but the instances might not be the same level. It gives the ability more flexibility that way.
I only have anecdotal evidence from my Tower Defense. All I can say is that triggers would not always fire. I'm not sure how to prove it, other than I eliminated every other possibility. The only thing left was to conclude that the triggers did not fire.
If you make an ability that deals 0 damage and do the damage with triggers you can sort of make the tooltip dynamic without requiring triggers to update it.
For example, Snipe does 125 damage to a target at level 1 and we want it to do an additional 75 damage per level. In the Command Card - Tooltip field you can actually change the tooltip for each level. You will need to put in an effect for each level, but it can be the same one. Attached are some screenshots to better illustrate how it works.
Also note that you skip the first tooltip because the initial button you use for the ability does that for you. The same applies for the Image and Name which can also be modified per level.
When you say thread, are you referring to it in the context of parallel processing, or does the term have a different meaning in the editor?
Does the editor actually give you control over how many concurrent threads are run on your processor?
As Kueken said, it's refered to the threads inside Sc2. To elaborate: Sc2 can use multithreading, but I'm fairly certain they only do it for system processes like AI, unit handling, etc.
All "Galaxy threads" will always be handled in only one system thread. Two galaxy threads can never truly run at the same time. The only reason galaxy threads can be called "thread" is because they don't wait for each other (ignore the sleep events).
About the events:
All events are caught in an internal handler and then passed to galaxy triggers. This system shouldn't fail and there should never be a "lost" event unless you screw up somewhere in the triggers.
I'm not very knowledgable in terms of Data editing, but I've seen times where attribute behaviors modified the ability's stats. I don't know if that was simulated via triggers or through native data, but if there is a way to reference attributes in a spell then this would be the way go I, I'd say.
After casting the spell 3 times, it should appear as level 0,1,2 not 0,1,3.. I've no idea why it's skipping 2 and i'm pretty damn sure its not caused by the script... FML
Feel free to try it out below.. Just load the map and throw some projectiles.
1024 threads. Keep in mind that this limit could maybe change when playing on different settings or over battle.net.
This is also a great way to kill your game's performance lol.
I had that same problem for about a month in my TD. Context: When a player's hero levels, the cost of an ability to purchase experience is supposed to be increased. I use ability level to control the price.
It says in the description that it sets the level. I finally figured out today that this is incorrect. It adds the number you put in the field.
For months, I had to deal with the price of the ability increasing exponentially.
I made a small example map, which basically holds the hero/ability system I use currently. It is data-only, except the part where catalog functions are used to modify the effects for higher levels. Since this is a one-time change (only when the player levels up the ability) this should be quite performance friendly.
The tooltip shows the correct damage for each level, without the need of special handling or any change of the tooltip via trigger.
The only downside is the only 1 instance of the ability per player problem (and the fact that not all values can be changed by catalogs, of course)
Not to worry, Galaxy script is fine. I believe you're slightly mistaken:
bool CatalogFieldValueSet ( preset catalog, string entry, string fieldPath, int player, string value )
It takes a player, not a player group.
Yes, you are correct of course :)
Quote:
This is actually what has me stumped. Im working on the assumption that there might be a possibility where 1 player has dupes of the same units, but the instances might not be the same level. It gives the ability more flexibility that way.
If you need this, Catalogs are not an option, I guess.
-.- damnit Blizzard. Thank you so much for sharing that, it probably saved me from going a little more insane than I already am. I owe you one, i swear this woulda kept me up til pretty late..
Could just use multiple effects for the ability, it will switch automatically. But this kind of misses the point, we try to find alternatives for this ;)
In the end I went with cataloging and the effect amount parameter because I personally feel having to manually edit the tooltips one by one is just too tedious.
Thanks so much Kueken, Your map helped my understanding on this a lot. Theres some wierd stuff though.. When I change stuff in the data editor, it sometimes causes the set catalog value trigger to fail randomly for some unknown reason. It's not clear whether this is trigger or data related. After a few tries it works perfectly as it should though. Urgh.. its happening again. The values aren't updating and there is no error message. It seems to work fine when I remove my "run trigger" function..
Edit: Okay, its not the run trigger function. It's just not updating randomly and not spitting any error messages -_-
That is fair enough, I guess I should have a look at it too (eventually).
Unfortunately Blizzard left out the auto-fill feature from the Warcraft 3 editor and with the Starcraft 2 editor being buggy and sometimes rather slow with the UI, it doesn't make things any easier or faster.
In my code example, I commented out a message, which shows you, if the trigger will react and which level the ability is. I suggest enabling/adding such a message for your own trigger.
The learn ability index can be a little tricky. It seems to be pretty random, which number is used by an ability; if you only have one, it will be most likely 0, but for multiple abilities in the learn ability, the order tends to vary pretty much randomly.
I usually just make a bunch of triggers reacting to each index to manually test for the index ingame.
Do you mind sharing your code? Maybe we will see something :)
Sure, I hope it won't intimidate you though =/ It's pretty long and I use a lot of custom functions.
Still mid way working on the learn ability thing. The current trigger that handles spell level ups is
t_SpellHandler. Basically it levels up the spell whenever it's cast, and it's supposed to update the catalog too.
Oh, and if you see any potential ways I can improve my coding, please do let me know.
And uh.. forgive me, its not exactly cleaned up yet.
Edit:
Quote:
The learn ability index can be a little tricky. It seems to be pretty random, which number is used by an ability; if you only have one, it will be most likely 0, but for multiple abilities in the learn ability, the order tends to vary pretty much randomly.
I usually just make a bunch of triggers reacting to each index to manually test for the index ingame.
Thinking back about this.. i did notice something else wierd. Under the abilities cost, you have 5 indexes to represent the number of spells. In my code, I put 4 (Intending to have a 4 level spell) But my ability was jumping to level 5.
I suspect this may be happening as your snipe ability begins unlearned, whilst mine doesn't.. But still.. that doesn't seem logical at all. Anyway.. back to working on the learn ability.
Show me proof, create a testmap, where an event failed to trigger. I have yet to see a map, where an event fails, which is 100% not related to any other stuff interfering (and by that, I do not mean too many events at once, but just other triggers, conditions or variables messing with the actual trigger)
Not the threads on your processor, but the threads handled by the game. Each trigger starts its own thread for example. In Gui, you can create functions, which run in their own thread as well (well, this translates to galaxy by actually creating a new trigger anyways).
They can basically be applied to any data object; however quite a lot of fields are read-only (for example almost all behavior fields except duration). For abilities, they also change the values for all data objects of the player, so they can only be used if one player cannot use multiple levels of the abilities simultaneously.
They can change the same fields an upgrade object can change.
And why store the damage in unused fields, when you can just make the tooltip show the damage and change the damage directly via catalogs? This is my current method (the one posted earlier in this thread is out-dated), and it works just fine, not only for damage, but for many other values as well. Tooltips can show the same values catalogs can read and modify, and they show the modified values properly.
@Vexal: Go
Yeah, parallel processing. The trigger that runs the spell is never created until it is needed. Once the spell is cast, it is created, run, then destroyed. (Case A) If my understanding of how this works is right, this isn't the same as having a trigger that is created and left in the background until it is needed. (Case B)In case B, if 1000 events fire, the single trigger in the background might not be able to handle it quick enough (that is assuming it runs in a sequential manner). Whereas in Case A, every spell cast means one instance of the trigger is created and run parallel with the rest.What Keuken says, I believe is probably more accurate.
Not too sure about how the editor handles this. I haven't found any function that allows me to do that so far, but who knows, it might exist. Either that or its done automatically.
Edit:
I don't suppose you could share a simple example of how this is done by any chance? I'm sort of a reverse engineer, I learn better through practical >_>
@Kueken531: Go
By the way, forgot to ask. If I change a catalog value, is it universal? Lets say I use DummyEffectA to store my damage. But when I change the damage with catalog, wouldn't all players be affected by it? If this is so, If two players have the same ability, one has it at level 1, the other at 2, wouldn't the tooltip display incorrectly for one of them?
Edit: Seems it allows catalog setting for individual players. I foresee a problem if the same player has 2 units with the same ability though.
@FuzzYD: Go
All catalog values have a playergroup parameter, they can be changed for each player individually. The tooltips will show up correctly, as long as only one instance of the ability is allowed per player (or all instances always have the same level).
I will create a small example map. You are familiar and fine with galaxy script, correct? If not stated otherwise, I will use it.
@Kueken531: Go
Not to worry, Galaxy script is fine. I believe you're slightly mistaken:
bool CatalogFieldValueSet ( preset catalog, string entry, string fieldPath, int player, string value )
It takes a player, not a player group.
This is actually what has me stumped. Im working on the assumption that there might be a possibility where 1 player has dupes of the same units, but the instances might not be the same level. It gives the ability more flexibility that way.
@Kueken531: Go
I only have anecdotal evidence from my Tower Defense. All I can say is that triggers would not always fire. I'm not sure how to prove it, other than I eliminated every other possibility. The only thing left was to conclude that the triggers did not fire.
If you make an ability that deals 0 damage and do the damage with triggers you can sort of make the tooltip dynamic without requiring triggers to update it.
For example, Snipe does 125 damage to a target at level 1 and we want it to do an additional 75 damage per level. In the Command Card - Tooltip field you can actually change the tooltip for each level. You will need to put in an effect for each level, but it can be the same one. Attached are some screenshots to better illustrate how it works.
Also note that you skip the first tooltip because the initial button you use for the ability does that for you. The same applies for the Image and Name which can also be modified per level.
As Kueken said, it's refered to the threads inside Sc2. To elaborate: Sc2 can use multithreading, but I'm fairly certain they only do it for system processes like AI, unit handling, etc.
All "Galaxy threads" will always be handled in only one system thread. Two galaxy threads can never truly run at the same time. The only reason galaxy threads can be called "thread" is because they don't wait for each other (ignore the sleep events).
About the events:
All events are caught in an internal handler and then passed to galaxy triggers. This system shouldn't fail and there should never be a "lost" event unless you screw up somewhere in the triggers.
@FuzzYD: Go
I'm not very knowledgable in terms of Data editing, but I've seen times where attribute behaviors modified the ability's stats. I don't know if that was simulated via triggers or through native data, but if there is a way to reference attributes in a spell then this would be the way go I, I'd say.
PS: VoidPotato's solution is even better.
@s3rius: Go
"All "Galaxy threads" will always be handled in only one system thread."
Thanks, that answers my question.
There must be a limit to how many can be queued at once. I am absolutely positive it is possible to overload it.
@VoidPotato: Go
I'll probably be going with this method.. I've got a really strange problem that wasn't a problem before now..
My debugger output:
I'm using this to set the ability level. This line of code occurs only once and executes whenever the spell is cast.
After casting the spell 3 times, it should appear as level 0,1,2 not 0,1,3.. I've no idea why it's skipping 2 and i'm pretty damn sure its not caused by the script... FML
Feel free to try it out below.. Just load the map and throw some projectiles.
@Vexal: Go
Yes, that's possible. However, I'm not 100% sure where the limit is:
This test should create a ton of threads.
http://simplest-image-hosting.net/png-0-unbenannt56
And indeed it does:
http://simplest-image-hosting.net/png-0-unbenannt57
And the end result:
http://simplest-image-hosting.net/png-0-unbenannt58
1024 threads. Keep in mind that this limit could maybe change when playing on different settings or over battle.net.
This is also a great way to kill your game's performance lol.
PS: 2000 posts!
@FuzzYD: Go
I had that same problem for about a month in my TD. Context: When a player's hero levels, the cost of an ability to purchase experience is supposed to be increased. I use ability level to control the price.
It says in the description that it sets the level. I finally figured out today that this is incorrect. It adds the number you put in the field.
For months, I had to deal with the price of the ability increasing exponentially.
I made a small example map, which basically holds the hero/ability system I use currently. It is data-only, except the part where catalog functions are used to modify the effects for higher levels. Since this is a one-time change (only when the player levels up the ability) this should be quite performance friendly.
The tooltip shows the correct damage for each level, without the need of special handling or any change of the tooltip via trigger.
The only downside is the only 1 instance of the ability per player problem (and the fact that not all values can be changed by catalogs, of course)
Yes, you are correct of course :)
If you need this, Catalogs are not an option, I guess.
@Vexal: Go
-.- damnit Blizzard. Thank you so much for sharing that, it probably saved me from going a little more insane than I already am. I owe you one, i swear this woulda kept me up til pretty late..
@Kueken531: Go
Thanks! :) Will take a look at this after I get some rest. Almost midnight here
@FuzzYD: Go
have you tried.... switch effects?
basically you keep an invisible behavior on the unit to track what level it is...
the switch effect uses different effects depending on the count of the "level tracking behavior" on the unit....
pros
cons
@SouLCarveRR: Go
Could just use multiple effects for the ability, it will switch automatically. But this kind of misses the point, we try to find alternatives for this ;)
@Kueken531: Go
In the end I went with cataloging and the effect amount parameter because I personally feel having to manually edit the tooltips one by one is just too tedious.
Thanks so much Kueken, Your map helped my understanding on this a lot. Theres some wierd stuff though.. When I change stuff in the data editor, it sometimes causes the set catalog value trigger to fail randomly for some unknown reason. It's not clear whether this is trigger or data related.
After a few tries it works perfectly as it should though.Urgh.. its happening again. The values aren't updating and there is no error message. It seems to work fine when I remove my "run trigger" function..Edit: Okay, its not the run trigger function. It's just not updating randomly and not spitting any error messages -_-
@FuzzYD: Go
That is fair enough, I guess I should have a look at it too (eventually).
Unfortunately Blizzard left out the auto-fill feature from the Warcraft 3 editor and with the Starcraft 2 editor being buggy and sometimes rather slow with the UI, it doesn't make things any easier or faster.
@FuzzYD: Go
In my code example, I commented out a message, which shows you, if the trigger will react and which level the ability is. I suggest enabling/adding such a message for your own trigger.
The learn ability index can be a little tricky. It seems to be pretty random, which number is used by an ability; if you only have one, it will be most likely 0, but for multiple abilities in the learn ability, the order tends to vary pretty much randomly.
I usually just make a bunch of triggers reacting to each index to manually test for the index ingame.
Do you mind sharing your code? Maybe we will see something :)
@Kueken531: Go
Sure, I hope it won't intimidate you though =/ It's pretty long and I use a lot of custom functions.
Still mid way working on the learn ability thing. The current trigger that handles spell level ups is t_SpellHandler. Basically it levels up the spell whenever it's cast, and it's supposed to update the catalog too.
Oh, and if you see any potential ways I can improve my coding, please do let me know.
And uh.. forgive me, its not exactly cleaned up yet.
Edit:
Thinking back about this.. i did notice something else wierd. Under the abilities cost, you have 5 indexes to represent the number of spells. In my code, I put 4 (Intending to have a 4 level spell) But my ability was jumping to level 5.
I suspect this may be happening as your snipe ability begins unlearned, whilst mine doesn't.. But still.. that doesn't seem logical at all. Anyway.. back to working on the learn ability.