I don't really understand what has changed wrt wreck handling in script killed(). I tried to change the return value from return (0) to return (corpsetype), but I still have the issue that a wreck is always produced. This is arm podger, which also couldn't be fixed by the cob_fixer.py script.
Here's the script: http://pastebin.com/ND60wnkf
Re: COB: always use the return value of the Killed thread to determine wreck level (none if omitted)
Moderator: Moderators
Re: COB: always use the return value of the Killed thread to determine wreck level (none if omitted)
you miss a " return (corpsetype);" in the end of Killed() function
Re: COB: always use the return value of the Killed thread to determine wreck level (none if omitted)
You're not returning anything at the end of the function, if none of the if statements are true.
Also those callins function signatures seem noticeably different from Lua, are you sure they're correct?
See https://github.com/ZeroK-RTS/Zero-K/blo ... #L280-L295 : returning 2 shouldn't generate a wreck.
Also those callins function signatures seem noticeably different from Lua, are you sure they're correct?
See https://github.com/ZeroK-RTS/Zero-K/blo ... #L280-L295 : returning 2 shouldn't generate a wreck.
Re: COB: always use the return value of the Killed thread to determine wreck level (none if omitted)
Hmmm, that fixes it but it makes it harder to do the corresponding replacements in the bos scripts, they are all like this.
Presumably the return (0); wasn't needed before, since the statement was the last statement in the script anyway and not returning anything was equal to returning false.
But why is that still not the case? The changelog says:
Presumably the return (0); wasn't needed before, since the statement was the last statement in the script anyway and not returning anything was equal to returning false.
But why is that still not the case? The changelog says:
(none if omitted)
Re: COB: always use the return value of the Killed thread to determine wreck level (none if omitted)
changelog is incorrect as Cob automatically returns 0 if no return statement is present, and the engine for some reason treats a corpseType of 0 the same as 1.
Re: COB: always use the return value of the Killed thread to determine wreck level (none if omitted)
Any "return 0" (or "return -123" or "return 42" or "return whatever") statement was ignored before in favor of the value assigned to corpsetype, unless the execution of Killed encountered a sleep (in which case it was the other way around).Presumably the return (0); wasn't needed before, since the statement was the last statement in the script anyway and not returning anything was equal to returning false.
Wrong, no return equals -1 for all threads. The difference is that whatever value gets left on the stack by Killed is now discarded.changelog is incorrect as Cob automatically returns 0 if no return statement is present
I'm still not sure if that's intentional.the engine for some reason treats a corpseType of 0 the same as 1.
Re: COB: always use the return value of the Killed thread to determine wreck level (none if omitted)
That's technically correct, but Scriptor automatically returns 0 if no value is specified, so no return never happens.Kloot wrote:Wrong, no return equals -1 for all threads
The -1 thing is delayed return when a thread sleeps.
Re: COB: always use the return value of the Killed thread to determine wreck level (none if omitted)
I'm afraid I don't accept specific compiler shenanigans as sufficient grounds to claim the "changelog is incorrect"; at most it could be called incomplete.
"none if omitted" technically also applies to the case where a Killed function has not been defined at all (as BA found out), so it does.no return never happens
Re: COB: always use the return value of the Killed thread to determine wreck level (none if omitted)
It's not a specific compiler's shenanigans, it's popular in VMs that all function calls have a return value which defaults to 0.Kloot wrote:I'm afraid I don't accept specific compiler shenanigans as sufficient grounds to claim the "changelog is incorrect"; at most it could be called incomplete.
I'd bet that TA's cob VM implementation (which is very likely slimmer than spring) uses this model.
So spring's implementation allows the running of incomplete bytecode by having enough overhead to compensate.