DSP Robotics Support

Well . . . this is going to be a lot more difficult than I expected.

I've been googling and reading the few Ruby books I have for a couple of days now and there doesn't seem to be much information available anywhere. Plenty of results for C & VB but hardly anything for Ruby, apart from a couple of Gems that we can't use (yet . .. )

I'm not asking anyone to code it for me but if someone could show me a simple example that I could adapt for my own purposes that would be great!

Failing that I'll just have to increase my clock speed

DaveyBoy, did you try to ask for help here:

https://stackoverflow.com/questions/

If they can they will help you, just place your question clearly and under the applicable section.

Hope this help.

Hi Tiffy

No I haven't,I've been busy at work this last week so it's been on the back burner but thanks for the suggestion, that's my next port of call.

I haven't given up yet

Been playing with this again recently.
Not got anywhere with the windowproc suggestion but am getting a little bit nearer.

The attached FSM is a hybrid of Spogg's green suggestion, Tiffy's trigger limiter and my original hack.

It seems to be working as required ie instantaneously or key held down, and includes a ruby module to detect if the Flowstone window is on top or not (if there's a better way to do this please let me know), I am thinking this should work with exported exes and vsts but have not tested this.

As always any suggestions are welcome.
Feel free to use as you wish.

Hi Daveyboy, I am not sure what the schematic is supposed to do due to my lack of experience.

However, I had a look at the schematic and I noticed that the Tick 100 sends those triggers to all parts of your schematic none stop putting an unnecessary load on your computer.

Thus, I blocked most of if not all of the unnecessary triggers and your schematic still appears to be working as before.

Please check it out as I have left the Trigger Counters in the schematic so you can inspect and see that the triggers passing through the schematic now are only those when needed.

Cheers.

Hi Tiffy


The attached schematic shows what I am trying to do.

Once an item in the list is selected with the mouse the selection can then be changed with the up and down arrow keys.
The selection will respond to fast repetitive arrow key presses or will auto-change if the arrow key is held down . . just like on most windows programs.

I was trying to find a way to do this using ruby only without the green triggers flying around all over the place but so far without success.

If i block the triggers like you suggest it doesn't work as desired.

Hope this helps.

I just came across this thread, apologies for being 6 months behind! I discovered earlier this week what you'd been doing because I was hunting for something similar using keyboard arrow keys, for pushing bar-graph elements up and down. Not exactly the same application but I thought I'd offer up a demo of my recent experiments in case they're of interest.

I've added a conventional auto-repeat feature, incorporating a delay after the first trigger, by calling the 'fast' method immediately after it to change gear. I've probably committed Ruby-crimes here (as usual), but it seems to basically work correctly - I'm sure someone will advise!

I've also added the 3 trigger-blocker modules, they're the type that check two consecutive values for a repeat (Not one of mine..). Seems to eliminate the need for the separate trigger input into Ruby, and stops the Tick25 propogating any further than necessary.

I've been surprised at the simplicity that I've arrived at here, particularly that 'input 100' does not seem to be needed in the 'if ..' lines in order to trigger a repeat event .. surprised at that and I'm not exactly clear what goes on here

Hugh, I've cleaned it up a little bit and tweaked it. I also commented in the RubyEdit, so that it hopefully explains what's happening sufficiently.

Thanks Tulamide. But strangely I can only get that to do as you specify if I re-insert 'clearEvents', like this :


Like this you can indeed set the repeat rate at 0.04, or any other rate; otherwise it just seems to run at full speed and fall over.

Anyway, it's interesting, thanks for the explanation. So presumably a Ruby event is always - and only - called from physical inputs, yet can be sustained ad infinitum by a virtual input such as 'input 100' .. is that the case?

I've also since realised that my original '2-speed' auto-repeat only needs a single 'clearEvents' (same as the above); like this :

Seems quite useful I think, assuming it's legit (i.e. not a cpu disaster!)
Cheers
Hugh

Adding 'clearEvents' works better in my version of FS.