SP API Question

tangofoxtrot

Is there a more comprehensive description of the SP API than that given in the Wiki under ”Events and Scripted Functions”? I was hoping that there is a description of the conventions for referencing objects like joints, global variable usage, how scripts communicate etc.

Also, where can I find coding examples?

Thanks for any help

Mr.K.1

Well the tutorials aren't 100% but they get you started:
http://sketchyphysics.wikia.com/wiki/SP_Tutorials

And if you need some specifics just ask here, there is always someone who knows around.

tangofoxtrot

Thanks for the response Mr K. My immediate problem is that I’m trying to figure out how to control a motor joint from a ruby script rather than from a slider. I am already reasonably fluent in Sp (doing things manually) and the SU Ruby API, but I don’t know the architecture of SP-Ruby. In particular, I don’t know how to find the motor, what methods it responds to, and how to send them. I have been looking at various SP code snippets that I’ve found, but this is a slow and tedious way to learn the API. I was hoping that someone might have written an overview and that there was a better description of methods and their use than the one I found in the Wiki.

Mr.K.1

Well it's really straight forward, you can write any sort of ruby script into that controller(or any other blue field), usually it's best to just use one variable and then change that at will in other scripts.

Best way to do it is with getVar() and setVar(), these methods are specifically designed for this so you don't haveto worry about initialization and variable range.
So put getVar('banana') into your motor and then you put setVar('banana',10.0) <-10.0 is can be any number/variable you want, and that setVar() can then be used in any script to control it.

You can also write full scripts into the controllers themselves, but that just comes back to bite you in the ass when you haveto edit them.

tangofoxtrot

Again, thanks MR. K,

I tried that and it worked as you described.
From my reading of the ControllerCommands.rb file it appears that the variable names
are global to a simulation. I assume they are arbitrary (the user can make them up), writing the scripts, one must then watch out for name collisions. For example, using the variable 'speed' for two different motors that one wished to control independently, would not work. One would have to use 'speed1' and speed2'. Is that right?

Thanks

Mr.K.1

Variable range is where SP gets a bit tricky, essentially every blue text field is in it's own bubble of local variables(unless they are the SP predefined ones).

So let's say you put "speed1" into the motor controller and then "speed1=10" in the ontick box you would just get errors that "speed1" is undefined because it is only a local variable.
So then you have:
@speed1 - this makes it slightly global(it extends beyond the current block but may not be visible everywhere)
@@speed1 - makes it fully SP global(it will be reachable in every script across SP)
$speed1 - makes it fully SU global(best used for testing because you can also reach it in the Ruby console, and it stays active until you close SU, however these variables can clash with each and every global variable that SU and it's plugins use)

But for controllers I always advise using get/setVar because these always return a value, the other variables however may not be defined at the start of SP and that can crash your models.

mptak

What an incredibly good explanation. I guess it is now time to go back and get rid of all of those $Variables in my scripts.(:))

tangofoxtrot

MR K thanks for the scoping explanation, it helps. Actually, I was using the getVar and setVar methods in my script. My question about name collisions was in reference to the names stored in the $SP3xSimulationVars hash with these methods.

I have a couple of other questions, but let me first digest the info in your post - perhaps the answers are there.

Thanks again

Mr.K.1

Well yes the names can collide with any preexisting variable, method or ruby command, there are too many to actually list but here are some of the simpler SP variables you should avoid: frame, a, b, x, y, leftx, lefty, rightx, righty, joyLX, joyLY, joyRX, joyRY, ...

Easiest way to get around this is to use names specific to your model: car_motor, car_steering, boat_motor, track_distance, ...

Also all names are case sensitive, so car, cAr, caR are completely different variables.