Closed kaincenteno closed 3 years ago
@kaincenteno Are you sure your code and build is up to date? That warning was removed a decent amount of time ago.
@claywar reproduceable in Canary 385ac9a. The ability "Mmurk" that crashed it was NM in Promyvion Mea Promathia Mission
My guess is that core doesn't like the possible nil return from that script (we're doing a get on the result without checking). Can you try declaring local typeEffect=0
in the script and seeing if that temporarily resolves the issue for that skill?
But you actually don't want to return zero, because that is actually a valid effect ID (death, in fact, even though we never use it in dsp/tpz). We should probably just define it as WEIGHT first and then let that if check do slow if slow landed. misread the else's there
Edit: Returning nil shouldn't be a problem really. So that will need fixed if that's the case we have a ton of things that return a nil in similar circumstances. Does need a local declaration before getting to those conditionals though.
We definitely need to fix this on the core side. I just don't have the bandwidth at the moment fix that function. By design, the function in luautils would return 0 if the return result wasn't valid (though its broken).
Crashing on return result.return_count() ? result.get<int32>() : 0;
Since result.get<int32>(nil)
isn't making things happy. -- Note this is what I'm assuming
I like (not) how autocorrect tries to reverse the meaning of things I say all the time (does > doesn't)...
All instanced of return_count() -> get<>()
are replaced with get_type() == sol::type::_ ? get<>()
, meaning it'll handle nil's coming back from Lua safely:
https://github.com/topaz-next/topaz/commit/0ffae5aaa89cb8533c2c0439c18800e53dd87ba0
release
branch (if other branch, please specify)Additional Information (Steps to reproduce/Expected behavior) :
I am trying to reach out to the player to see what was their last action