Mouse and fixed views

[abe_beson]

Thanks Bob,
yes I found my way here, and this is now my favourite site... ;o)

I moved the discussion about using the micro stick for view control into this forum because I did not want to clutter the control manager features thread with technical CMS stuff. See:
http://www.ch-hangar.com/forum/index.php?showtopic=19

Yes I have already thought about the reference point idea, and sure I could go to a certain view. But how do I return to my previous view? Is there a way of keeping track of the x,y mouse counts issued from the micro stick?

Of course I could program the POV-hat for mouse control and thus keep track of the mouse position in the script. The problem is I need the POV-hat for view control as well as a mouse, and the micro stick programmed as a mouse is very nice for viewcontrol.

The micro stick programmed as TrackIR however would allow for using the TrackIR software, and all the problems above would hopefully be solved and the goodies would still be there!
:w00t:

/Abe

[Bob Church]

Hi Abe,

>> yes I found my way here, and this is now my favourite site... ;o) <<

Mine, too. :) Revvin&#39;s done a great job with it.

>> Yes I have already thought about the reference point idea, and sure I could go to a certain view. But how do I return to my previous view? Is there a way of keeping track of the x,y mouse counts issued from the micro stick? <<

Well, I haven&#39;t tried it, but I&#39;d think you could keep track of them pretty closely without much trouble. The basic script for mouse moving would look like this:

script
if( CLOCKTICK ) then
cms.a1 = js1.a1;
cms.a2 = js1.a2;
else
cms.a1 = 128;
cms.a2 = 128;
endif
endScript

The two CMS axes go to the mouse XY up in the GUI.

The CLOCKTICK bit is set when the scan clock has timed out. That&#39;s when you need to give a value to the mouse axes. You&#39;d need to keep a running count of the X and Y mouse moves at that point, that would give your current position, and then find your way to the view point you want. You&#39;d have to do it 255 pixels at a time, but other than that it sounds like it would work. It kind of depends on how repeatable things are. I&#39;d wonder if mouse acceleration by Windows or the driver would keep you from generating the same movement every time. Nothing much to do but try it, though. If you did run into drift, maybe tag the view forward key to reset all the viewpoint variables at the same time to keep things lined up.

- Bob

The StickWorks
http://www.stickworks.com

[abe_beson]

Thanks for your reply Bob,
yes an extension to this script keeping track of the mouse movement will do it I think, since the game does not use mouse accelration I think. :)

The real problem is that there are other ways in the game to control the view than using the mouse. Further there is a limit for how far back one can look. But I can work around this also, just by not allowing any other view-controls than the mouse and keeping track of the view limit in accumulated mouse coordinates.

OK, say that I am able to keep track of the current view point by the extended script, then I would like to be able to set certain views on the fly and even be able to keep some of them between control manager sessions. Is there a way to declare variables static (to be stored between sessions)?

If not, to have "static varibales" is my second suggestion on improvement on the otherwise great control manager! B)

/Abe

[Bob Church]

Well, I don&#39;t know. I&#39;d never thought about statics that would be maintained across a restart. You could certainly record views on the fly, and fixed view points would just be a matter of some constants in the script to mark the right positions, but there&#39;s no way to save those at the moment. I&#39;ll have to give that one some thought when I get back to the script. The values could be saved easily enough, there&#39;d need to be some sort of read/write commands implemented. I&#39;ll look at it next time I&#39;ve got the script processing open and see what it would take.

Let us know if you can get the views to track. If it can be made to work, you could set up virtually any set of fixed views in any sim with a VC, could be very useful!

- Bob

The StickWorks
http://www.stickworks.com

[abe_beson]

Hi again!
Here we are! :thumbsup:
I finally have somthing that is possible to use. The script is huge, probably I missed a feature or two of the controlmanager...

There is a problem of tracking the mouse exactly due to the acceleration, or rather decceleration done by the mouse driver. This seems to be impossible to turn off in XP. But I have a script that works in the avarage case. :rolleyes:

When the map is active the ministick switches over to use pan views. This may get out of synch, but it is possible to get back by pressing the ESC or map key on the controller followed by a ESC from the keyboard.

Use it at your own risk and report the bugs back here!

/Abe

[Bob Church]

Hi Abe,

>> I finally have somthing that is possible to use. <<

Great!

>> The script is huge, probably I missed a feature or two of the controlmanager... <<

No, nothing really. There&#39;s a bit now for "Hat Centered", so the line that&#39;s currently:

%define viewButtonPressed JS2.B31 or JS2.B27 or JS2.B25 or.....

could be written:

%define viewButtonPressed NOT js2.b24

and there were a couple of places where you might have worked out a single routine to handle all view positions if space had been tight, but you&#39;d only used about 1/3rd of the script memory anyway and it would have just been harder to keep track of. Anyway, it looks wonderful! I love the use of the %define stuff. :)

>> There is a problem of tracking the mouse exactly due to the acceleration, or rather decceleration done by the mouse driver. This seems to be impossible to turn off in XP. But I have a script that works in the avarage case. <<

I thought that might be trouble. I don&#39;t know any way around it, really. Windows combines the mice above the Control Manager and applies the acceleration up there. It&#39;s nothing that can be controlled from the CM. Your remark about deceleration is interesting, though. The mouse routines I&#39;ve looked at based the mouse acceleration on some threshold value. If you get enough mickeys in one move, then the acceleration kicked in and you&#39;d get more pixels/mickey. When you got close to the target, you&#39;d tend to slow down, so depending how far off the target you were you might end up getting different deceleration values depending on how you came into the targe.

Mouse moves are generally small, though. If you send a fair number, say 32 or 64 at a time, you&#39;re probably past maximum threshold because they would seem (to Windows) to happen intantaneously. If that would maintain you at maximum acceleration, at least things would be repeatable. Then it would depend on how much resolution you actually needed. If you had to hit every pixel you&#39;re right back where you started, but if hitting a 32 x 32 pixel grid were "good enough", the stability might not be that hard to achieve. You&#39;d only send 32 mickey moves and you&#39;d never need to decelerate since one of those is going to land right on the target every time.

Anyway, great work, Abe! Congratulations!

- Bob

The StickWorks
http://www.stickworks.com.

[abe_beson]

Hi Bob!

I found that 5 "mickeys" (%define minMove 5) is the largest value that still gives the right "feel" of the view movements. This works as a deadzone but the first value is minMove, not 0 as it would be in a real deadzone algorithm. The deadzone algorithm I use is also simplified in the way that if the input is above a certain value, the internal axis-variable is set to the maximum value of an axis reading. This is done in order to avoid rescaling the axis, and the user does not notice anyting anyway!

It might be as you say about the acceleration, but it is just a matter of reference (everything is relative). My reference is large mouse movements! :idea:

I&#39;m using the script all the time now and have noticed some minor glitches when pushing the same view-button repeatedly, no big deal, really, so I just let that be for the moment. I will probably make the movements a bit smother though. Right now the script tries to get to the target as fast as possible in the x and the y direction separately. This means that the movement in one direction stops before the movement in the other.

In order to make this really nice I would need the sqrt function though. I would also appriciate to be able to use negative values and double precision and a range of the variables of at least 100 000 000. Just kidding, I will find a better algorithm for calculating the movements! :P

However if the ministick could be programmed as a TrackIR source all this would be pure theory. My script would still be limited to the combined break axis, and all my work would be in wain. But I still think that solution would be a lot better...

/Abe

[abe_beson]

A better way of accomplishing what I did with the mouse-view script is to make use of a nice program called newView. NewView in turn makes use of the trackIr standard to control the views.

I intended to publish this profile on the profiles section, but there is some strange problem uploading my profile there. I am sure Revvin can explain what is wrong better than I can. However here it is, as it would have been in the profiles section:

The configured controls are:
the Pro Throttle USB,
the Fighterstick USB and
the Pro Pedals USB.

The special thing about this profile is the view and mode controls.

The view control is accomplished through the ministick on the pro throttle in cooperation with newView:
http://www.mousevision.com/game/newView.htm
The POV on the throttle is used together with the ministick to give a very good control of the view in the game.

I have included the file NPClient.ini, which is my newView settings, in the bundle.

The current mode is controlled by two of the three small buttons on the throttle handle. The buttons used for mode control is button 3 and button 4.
Mode 1 is the default mode,
mode 2 is entered while button 4 is depressed,
mode 3 is entered while button 3 is depressed,
mode 4 is entered while both button 3 and button 4 are depressed.

The toe brakes are mapped into a single axis.

/Abe (F16_Abe in HL)