DSP Robotics Support

...don't call your parsing method "parse"!

It breaks the RubyEdit in a rather, erm... interesting way. After a bit of digging, I discovered that RubyEdits already have a method called "parse". It gets called every time you edit the code to, erm... parse the Ruby code into method definitions. So if you override it by defining your own, the RubyEdit no longer understands Ruby!

The usual convention is to use leading/trailing __underscores__ for "under the hood" Ruby methods which are likely to cause name collisions - but it seems DSPr like to keep us on our toes!

It's exactly that what I meant with careless integration on another "forum". The famous "@x" (a RubyEdit input named "x") is another example, internally reserved by DSPR without letting us know or protecting against us using it (luckily resolved in FS4!).

Should have taken you some time to realize it

I really ought to check out my old "Ruby hit-list" to see what's been fixed and what needs reporting. I've had a few crashes from bog-standard methods like .dup and .clone - the versions inherited from Object don't work so well (in 3.0.6) for some of the objects that wrap GDI+ pointers!

Mind you, I do get a rather perverse sense of enjoyment out of hacking my around them!