# KSP bug to watch out for



## kotori (Aug 5, 2010)

Hi everyone,

I thought I'd share some info about a KSP bug that can be quite confusing. Inside a function that has been invoked using "call" one cannot invoke another function on the last line inside a compound statement (eg. if, while, or the function definition itself). Doing so causes the execution of the current callback to prematurely halt. Until NI fixes this don't use code like this (if func1 was invoked using "call"):

*function* func1````
``*if* 1=1
````*call* func2``````
``*end if*``
*end function*

or

*function* func1````
``_{ ... statements ... }_
``*call* func2````````
*end function*

In order to make the functions above work you need to write them like this:

*function* func1````
``*if* 1=1
````*call* func2``````
````nop
``*end if*``
*end function*

or

*function* func1````
``_{ ... statements ... }_
``*call* func2
``nop````````
*end function*

where "nop" is defined like this:

*function* nop```_{ dummy statement - no operation }_
``*declare* i
``i := i
*end function*

I hope this can help others. I cannot even express how confusing it was to first isolate the problem since adding message(...) invokations for debugging purposes acts just as the nop function and actually fixes the problem. So when I was trying to just passively study things, the act of just showing debug messages actually radically changed the behaviour of the script. 

(I have filed a bug report)

/Nils


----------



## Big Bob (Aug 5, 2010)

Hi Nils,

Thanks for the timely warning (I'm getting close now to doing some scripting again). I'll bet isolating this was a real 'brain bender' :o . Thanks again for sharing this.

God Bless,

Bob


----------



## TechLo (Aug 5, 2010)

Oh man, I've had some troubles with this, lol, and I also tried to use messages for debugging/detecting if code was running to the end of the callback. I learned that I had to do things like:

if (a=x)
call b
call c
else
call e
call c
end if

instead of...

if (a=x)
call b
else
call e
end if
call c

or "c" was not being reached inside of callbacks.
I think I was also getting this same problem using pgs keys instead of the initial callback.

That's a big heads up about using "nop" -- I had not isolated a solution, thanks!


----------



## kotori (Aug 5, 2010)

Big Bob @ Fri Aug 06 said:


> Thanks for the timely warning (I'm getting close now to doing some scripting again). I'll bet isolating this was a real 'brain bender' :o . Thanks again for sharing this.



Brain bender is indeed a good description. I think that I have, throughout my KSP programming time, never have had a deeper experience of loosing the feeling of standing on firm ground. 



TechLo @ Fri Aug 06 said:


> Oh man, I've had some troubles with this, lol, and I also tried to use messages for debugging/detecting if code was running to the end of the callback. I learned that I had to do things like:
> 
> if (a=x)
> call b
> ...



Right. However, assuming that the code above is contained within a function invoked using "call" the line "call c" would still abort script execution (the c function would be executed, but that would be the last thing). It would only work as long as that's the last significant line to be executed in the callback.


----------



## kotori (Aug 6, 2010)

blakerobinson @ Fri Aug 06 said:


> I was having this problem too and it was driving me nuts trying to track down what was wrong! Thanks Nils.



Glad to be of help. Really cool demos in that presentation thread of yours btw. 

Since I find this bug quite distracting I added a setting in KScript Editor to have it automatically introduce the dummy statements where necessary. I haven't tested it yet thoroughly, but I think it should work well. Just compile your code in KScript Editor 1.4.4 and the problems with this KSP bug should automagically go away. Will update the OSX version too when I find time to do so.

Cheers,
Nils


----------



## TechLo (Aug 7, 2010)

Here's an example of code not being executed in an "on pgs_changed" callback:

if (get_key)
____if
________if
________not
________end if
____end if
____if 
____end if
____select
________case 0
________case 1
________case 2
____________if
____________else
________________select (MMM)
____________________case 4
____________________case 5
____________________case 6
________________________call PPP ***Location 1***
________________end select
____________end if
____________if (MMM=6) ***Location 2***
________________call PPP
____________end if
____________--unexecuted code ZZZ--
____________if (MMM=6) needs to be here at ***Location 3*** for ZZZ to run.
________________call PPP
____________end if
____end select
end if

The PPP callback doesn't have any callbacks inside of it. In my experience, I've had problems like this with call statements inside of select statements, usually when the ifs and selects are a few layers deep.


----------



## kotori (Aug 7, 2010)

blakerobinson @ Sat Aug 07 said:


> Thanks, glad you like my script stuff! Thanks a lot for KScript. Has become an invaluable piece of software!
> 
> I gave 1.4.4 a try but I'm not sure it's working properly. It detects that the call bug is in the code, and it also shows the warning that I need to declare a variable for it to use, but I'm not sure it adds the code after the call.



Oops. The modifications I performed on the full AST were only output if one had activated the "Optimize compiled code" option. Now I have changed it so that it's output if either the optimize mode or call bug work-around mode is active. I uploaded a new 1.4.4 installation file (same name) and replaced the previous one.

Cheers,
Nils


----------

