| 08-12-2009, 03:38 PM | #1 |
Please post your examples if you find any: Does not work: JASS://=========================================================================== private function Charge takes nothing returns boolean local unit target if IsUnitType(target, UNIT_TYPE_MECHANICAL) then return true else call AddSpecialEffectTarget(FX_UNIT, target, "chest") endif return false endfunction Works: JASS://=========================================================================== private function Charge takes nothing returns boolean local unit target if IsUnitType(target, UNIT_TYPE_MECHANICAL) then return true else call AddSpecialEffectTarget(FX_UNIT, target, "chest") return false endif endfunction Conclusion: if you have return in if you need a return in else. (or remove else branch) EDIT: This seems to be the only error, at least in my maps. Second solutions: JASS://=========================================================================== private function Charge takes nothing returns boolean local unit target if IsUnitType(target, UNIT_TYPE_MECHANICAL) then return true endif call AddSpecialEffectTarget(FX_UNIT, target, "chest") return false endfunction |
| 08-12-2009, 05:35 PM | #2 |
is this 1.24a or 1.24b |
| 08-12-2009, 05:36 PM | #3 |
To fix the return compile error you get when saving old maps again with codes, you just move all endifs after return to fix all compile errors? I'm right? Or is there more? ________________ Sry i got no examples, but is there also a problem with endfunction or is it the editor being wrong when i get compile errors upon saving? |
| 08-12-2009, 05:36 PM | #4 |
just usse latest jasshelper, and be done with it. |
| 08-12-2009, 05:42 PM | #5 | |
I use latest NewGen (but not latest jasshelper) I got wc3 patch from BNET today. Quote:
Slows things by a function call (not negligable for filters and conditions) Besides blizzard has a tendency to fix errors once in a millenia. This bug does not create compile errors, your map simple does not load. Stupid blizz detects this as H2I function (idiotic algorithm) |
| 08-12-2009, 08:02 PM | #6 | ||||
Quote:
Yes it does. Quote:
Quote:
The thing is, that we won't have a retail patch with these things fully fixed in a while... I thought 1.24b fixed them, but it seems not. If so then the real problem here is that blizzard will keep changing the algorithm. And thus we'll have to figure things out with each release (i.e. on 1.24 there were so many variations of it that it was crazy). It is just not worth it. Anyway, if you want to find the reasons for the bugs, just use the blizzard.j trick. Edit: Only functions with multiple returns "slow down", the reality is that from now on, we'll just have to get rid of double returns, begin refactoring. Let's ask again: Quote:
|
| 08-12-2009, 08:27 PM | #7 | |
Quote:
Would you be more specific? |
| 08-12-2009, 09:16 PM | #8 |
This thread? |
| 08-12-2009, 09:38 PM | #9 | |
... Actually: Quote:
|
| 08-12-2009, 09:39 PM | #10 |
hence my question |
| 08-12-2009, 09:58 PM | #11 |
His example compiles and runs in the new westfall patch. |
| 08-13-2009, 06:14 AM | #12 | |
Quote:
I don't know, explain? No I did not use westfall. And it is not possible to use remove all functions with multiple returns. (I muself don't plan on using a variable for return value of every filter I ever made.) @Mr_Saturn Are you saying that 1.24b has fixed the bug? |
| 08-13-2009, 08:46 AM | #13 | |
Quote:
Yes. |
| 08-13-2009, 02:13 PM | #14 | |
Quote:
Anyway, is it confirmed everything is fixed in 1.24b? I'll open a new thread... and close this as it was basically a fad... |
