event is the key to success. Note that the triggering unit must have the highlightable flag set to true in data for this to fire. (Can also force it on for all units by using a trigger)
Not trying to ruin the mood here, but I think it was fairly obvious from the beginning that the WC3 model pack was never a really high priority thing for Blizzard, but much rather a nice to have bonus.
I think we should try to be happy with what we've got rather than complain about what we don't have. Their modelers are probably fairly busy with HotS and LotV right now.
That said, its still only a PTR, so those bugs may get fixed before official release.
It all comes down to making the scripting tools easier to use for beginners.
Humans naturally start counting from 1, which is why Blizzard decided to make most indexes start at 1 (Not all do though.). I personally dislike this as it teaches beginners wrong programming habits and makes it harder to understand for people who already have coding experience.
This is also the reason why GUI arrays are always 1 element bigger than their defined size.
I disagree that the issue is Galaxy here. The GUI editor is specifically built so that it is not necessary to understand Galaxy in order to code.
The function looks very simple to use, which is why many people will not read the documentation very carefully.
Its just that nobody expects such behavior as it is highly unusual.
See, exactly this is why you use the UI and not the script.
The script version implies that normal control structures can be used, which obviously cant work because the dummy action doesnt actually convert to Galaxy and no real logic is performed.
One reason might be that using the script dummy function is not really "worse" than the preload UI. I just personally think it makes more sense to use the UI as the dummy action is sort of confusing as it doesnt actually compile to script.
No offense, but I think you guys are way overthinking this problem.
Realistically, how many units will die during a game? How many will die per second? Probably not too many. Not to say that the unit check will be stupid fast.
Of course you can do whatever you like, I personally would still recommend going for the "easy route" here and use a generic event, unless for some reason in your game there are a ridiculous amount of dying units all over the place.
While I agree that in most cases its a good approach to make the events as specific as possible, I think one always needs to make a cost <> benefit decision, and if you are trying to create the absolute perfect code for every single thing you do you will probably never get your project done. In a perfect world every piece of code is thought out and optimized, but from my experience reality is different because it actually NEEDS to be to get stuff done in reasonable time.
If the unit is not fixed I recommend using a generic "unit dies" event and a condition to check for the right unit.
While it introduces some overhead because it will trigger for all units, most of the time this is non critical and doesnt matter. If you want a "clean" solution you can do what ImperialGood suggested and reconstruct the trigger everytime the unit changes. Due to its increased complexity I would not recommend that though.
Always remember that premature optimization is the root of all evil. I personally think that even if UnitRefFromVariable worked it is a very unclean style and I would still not use it. What if you rename the variable for example? Just go for the easiest way and profile your project once you are done.
Didnt check everything, but the variable definitions cant compile as the array dimensions are based on constants defined after the actual arrays itself.
You cant write constants as you attempt to do in your function. Also take a close look at your second for loop condition.
As a person with years of c/c++ experience you should be able to find simple compilation errors like these yourself though.
0
Yes it can be done. The
event is the key to success. Note that the triggering unit must have the highlightable flag set to true in data for this to fire. (Can also force it on for all units by using a trigger)
0
Not trying to ruin the mood here, but I think it was fairly obvious from the beginning that the WC3 model pack was never a really high priority thing for Blizzard, but much rather a nice to have bonus.
I think we should try to be happy with what we've got rather than complain about what we don't have. Their modelers are probably fairly busy with HotS and LotV right now.
That said, its still only a PTR, so those bugs may get fixed before official release.
0
Reading some of the posts really makes me wonder what some people expected. A full HD remake of all models?
0
Well, whatever you do, make backups.
Really. Make backups.
0
Make sure you are checking in the right place.
There is a difference between custom games and Arcade games.
0
It all comes down to making the scripting tools easier to use for beginners.
Humans naturally start counting from 1, which is why Blizzard decided to make most indexes start at 1 (Not all do though.). I personally dislike this as it teaches beginners wrong programming habits and makes it harder to understand for people who already have coding experience.
This is also the reason why GUI arrays are always 1 element bigger than their defined size.
Player 0 is indeed a player (Neutral).
0
@ImperialGood: Go
I disagree that the issue is Galaxy here. The GUI editor is specifically built so that it is not necessary to understand Galaxy in order to code.
The function looks very simple to use, which is why many people will not read the documentation very carefully.
Its just that nobody expects such behavior as it is highly unusual.
0
See, exactly this is why you use the UI and not the script.
The script version implies that normal control structures can be used, which obviously cant work because the dummy action doesnt actually convert to Galaxy and no real logic is performed.
0
@ImperialGood: Go
One reason might be that using the script dummy function is not really "worse" than the preload UI. I just personally think it makes more sense to use the UI as the dummy action is sort of confusing as it doesnt actually compile to script.
0
Should use the UI for preloading the banks rather than the script.
The script action only exists for backwards compatibility. Back in the day the UI for preloading banks didnt exist.
0
No offense, but I think you guys are way overthinking this problem.
Realistically, how many units will die during a game? How many will die per second? Probably not too many. Not to say that the unit check will be stupid fast.
Of course you can do whatever you like, I personally would still recommend going for the "easy route" here and use a generic event, unless for some reason in your game there are a ridiculous amount of dying units all over the place.
While I agree that in most cases its a good approach to make the events as specific as possible, I think one always needs to make a cost <> benefit decision, and if you are trying to create the absolute perfect code for every single thing you do you will probably never get your project done. In a perfect world every piece of code is thought out and optimized, but from my experience reality is different because it actually NEEDS to be to get stuff done in reasonable time.
0
If the unit is not fixed I recommend using a generic "unit dies" event and a condition to check for the right unit.
While it introduces some overhead because it will trigger for all units, most of the time this is non critical and doesnt matter. If you want a "clean" solution you can do what ImperialGood suggested and reconstruct the trigger everytime the unit changes. Due to its increased complexity I would not recommend that though.
Always remember that premature optimization is the root of all evil. I personally think that even if UnitRefFromVariable worked it is a very unclean style and I would still not use it. What if you rename the variable for example? Just go for the easiest way and profile your project once you are done.
0
Try
instead.
0
Didnt check everything, but the variable definitions cant compile as the array dimensions are based on constants defined after the actual arrays itself.
You cant write constants as you attempt to do in your function. Also take a close look at your second for loop condition.
As a person with years of c/c++ experience you should be able to find simple compilation errors like these yourself though.
0
I feel like many of your questions will answer themselves once you spend 10 minutes in the editor and take a look and the resources already provided.