About that whole 'every editor was free' bit: No, the editors came with the games and the only way you'd acquire them is by acquiring them from the same source that the game came from, just this is the first time that with the aid of the magic of the internet blizzard has finally been able to realistically keep it within the community, which you are clearly professing and demonstrating you do not wish to be part of.
Yah but that's kinda the thing: You can't used the editor without being able to use the game. Not only does the editor need the game's libraries and assets to do anything remotely useful you need a working game client to test the maps you're building with it. I really don't know what else to say, if you aren't willing to pay the membership fee to join the community (purchasing the game), why should you be allowed to play with the best part of the game for free?
There is no nickel & diming here, there is a one-shot purchase of a computer game and the editor is freely included in that, the end. If you want to use the editor (which is part of the game) you need to pay for it.
I consider the editor more of an extension of the game, and honestly more fun to play with then the game itself and see no problem with blizzard wanting only their paying customers to be able to use it.
I'm pretty sure its literally the CPU time needed to complete a thread that triggers the error, as I posted above I didn't change the amount of calculations each run was doing but by shifting the method of looping to whiles instead of fors it reduced it down to under .5 seconds (which I'm thinking is the threshold) and it didn't complain after that. Unless for loops count as more calculations then while loops going through the same data, which could be entirely possible. I'd also met another instance of that when a single trigger was handling a whole pile of these sorts of things in a row (not nested, just happening consecutively) and just by splitting them up to different threads it stopped complaining then too.
The generic for-loop built into the galaxy editor is notorious for being a very badly optimized function, I'd highly recommend changing the logic to use while loops instead that cycle the data instead. Believe me I'd been using two giant for loops in a function when they hit that dreaded error and by merely shifting to using while loops that do the same thing it cut the CPU time needed to 25% of the for-loop version.
Pretty sure from what I understand that will indeed create a fork to a new thread but that's kinda ignoring the underlying thing this error is trying to tell you which is the trigger's activities could likely be done in a better way that's more optimized for the engine. Definitely something to look at on a case by case basis though.
Anti-banning talk is all good because that affects all of us, but shouldn't conversations involving the development of a specific project go into the project section under the thread for that project?
Using the searcher on launch effect method eh? I found that worked 99% of the time but that 1% still wasn't good enough. (The missiles I'm creating are sometimes firing at such speeds and quantities that it wasn't catching them all in time)
I'm starting to wonder then if in the case of the launch effect's pointers that 'caster' is the missile and then possibly 'origin' is the creator. I've asked many times for better clarification of what all of those references mean and so far its been a pretty silent response but I agree I'd love to have a more proper method of doing this sort of thing as well. If you feel like experimenting I'd really recommend yah just copy the suicide effect and screw around with its references to see if you can get it to erase the launcher instead cause then you know how to refer back to the it and that's the key.
ED: But does launch effect actually work out for you? I found it never worked for me with this.
Because of what I'm doing with missiles I found a not so elegant (but functional) method is to have two event triggers: One that's watching for any time a unit uses the ability and it sets a global variable to that unit, then another event for whenever a missile from that ability is created which takes that global variable and does an 'add the KillsToCaster behavior from LastAbilityUser to missile'.
Its horribly hackish but seems to be a very consistent way to make things work right. The way the generic units use it is directly applying the behavior using an effect within the 'create unit' effect but the 'create missile' effect lacks an equivalently proper mechanism to declare the missile it built to tag it with such an effect.
Gets tricky here, you need that ignite effect to actually come from the caster of the fireball instead of the fireball missile (since its for all intensive purposes a unit of its own). One way to get around this is to use a trigger firing upon the missile's death that some how knows who created the missile and then, to create the ignite effect within the trigger and aim it back at the original caster. The infestor's terran spawn & spider mines both use a 'killstocaster' behavior that shifts their kill cred back to the caster but in the cast of a DOT effect I'm not sure that'd work since the missile itself is probably long gone throughout the duration.
Without testing I can say that if it reaches 20K it'll at least go to 32K and if it can get past 32K it'll go right up to 2.14 billion and probably 4.3 billion if they just made it an unsigned long int. Those are the usual limits of counting that various variables can reach, since I have no idea why they'd leave kills as a signed value (able to go negative) then its very likely a 4.3 billion limit since I'm pretty sure the game engine is still running 32bit mode to accommodate older hardware & OSes.
0
About that whole 'every editor was free' bit: No, the editors came with the games and the only way you'd acquire them is by acquiring them from the same source that the game came from, just this is the first time that with the aid of the magic of the internet blizzard has finally been able to realistically keep it within the community, which you are clearly professing and demonstrating you do not wish to be part of.
0
@Colt556: Go
Yah but that's kinda the thing: You can't used the editor without being able to use the game. Not only does the editor need the game's libraries and assets to do anything remotely useful you need a working game client to test the maps you're building with it. I really don't know what else to say, if you aren't willing to pay the membership fee to join the community (purchasing the game), why should you be allowed to play with the best part of the game for free?
There is no nickel & diming here, there is a one-shot purchase of a computer game and the editor is freely included in that, the end. If you want to use the editor (which is part of the game) you need to pay for it.
0
I consider the editor more of an extension of the game, and honestly more fun to play with then the game itself and see no problem with blizzard wanting only their paying customers to be able to use it.
0
@progammer: Go
I'm pretty sure its literally the CPU time needed to complete a thread that triggers the error, as I posted above I didn't change the amount of calculations each run was doing but by shifting the method of looping to whiles instead of fors it reduced it down to under .5 seconds (which I'm thinking is the threshold) and it didn't complain after that. Unless for loops count as more calculations then while loops going through the same data, which could be entirely possible. I'd also met another instance of that when a single trigger was handling a whole pile of these sorts of things in a row (not nested, just happening consecutively) and just by splitting them up to different threads it stopped complaining then too.
0
@Thenarden: Go
The generic for-loop built into the galaxy editor is notorious for being a very badly optimized function, I'd highly recommend changing the logic to use while loops instead that cycle the data instead. Believe me I'd been using two giant for loops in a function when they hit that dreaded error and by merely shifting to using while loops that do the same thing it cut the CPU time needed to 25% of the for-loop version.
0
@Thenarden: Go
Pretty sure from what I understand that will indeed create a fork to a new thread but that's kinda ignoring the underlying thing this error is trying to tell you which is the trigger's activities could likely be done in a better way that's more optimized for the engine. Definitely something to look at on a case by case basis though.
0
Anti-banning talk is all good because that affects all of us, but shouldn't conversations involving the development of a specific project go into the project section under the thread for that project?
0
...so how many threads exactly are going to end up in the general sub forum over this one project?
0
@Kueken531: Go
Hah, good stuff yah this should help smooth things out quite a bit :)
0
@RileyStarcraft: Go
Using the searcher on launch effect method eh? I found that worked 99% of the time but that 1% still wasn't good enough. (The missiles I'm creating are sometimes firing at such speeds and quantities that it wasn't catching them all in time)
0
@Kueken531: Go
I'm starting to wonder then if in the case of the launch effect's pointers that 'caster' is the missile and then possibly 'origin' is the creator. I've asked many times for better clarification of what all of those references mean and so far its been a pretty silent response but I agree I'd love to have a more proper method of doing this sort of thing as well. If you feel like experimenting I'd really recommend yah just copy the suicide effect and screw around with its references to see if you can get it to erase the launcher instead cause then you know how to refer back to the it and that's the key.
0
@Kueken531: Go
ED: But does launch effect actually work out for you? I found it never worked for me with this.
Because of what I'm doing with missiles I found a not so elegant (but functional) method is to have two event triggers: One that's watching for any time a unit uses the ability and it sets a global variable to that unit, then another event for whenever a missile from that ability is created which takes that global variable and does an 'add the KillsToCaster behavior from LastAbilityUser to missile'.
Its horribly hackish but seems to be a very consistent way to make things work right. The way the generic units use it is directly applying the behavior using an effect within the 'create unit' effect but the 'create missile' effect lacks an equivalently proper mechanism to declare the missile it built to tag it with such an effect.
0
Gets tricky here, you need that ignite effect to actually come from the caster of the fireball instead of the fireball missile (since its for all intensive purposes a unit of its own). One way to get around this is to use a trigger firing upon the missile's death that some how knows who created the missile and then, to create the ignite effect within the trigger and aim it back at the original caster. The infestor's terran spawn & spider mines both use a 'killstocaster' behavior that shifts their kill cred back to the caster but in the cast of a DOT effect I'm not sure that'd work since the missile itself is probably long gone throughout the duration.
0
What is this 'class selection point' made up of? Possibly portraits and dialogs that aren't properly cleared up after wards perhaps?
0
@OdenTheMage: Go
Without testing I can say that if it reaches 20K it'll at least go to 32K and if it can get past 32K it'll go right up to 2.14 billion and probably 4.3 billion if they just made it an unsigned long int. Those are the usual limits of counting that various variables can reach, since I have no idea why they'd leave kills as a signed value (able to go negative) then its very likely a 4.3 billion limit since I'm pretty sure the game engine is still running 32bit mode to accommodate older hardware & OSes.