Chase view and Zoom out (external view)

[Windturbin]

My 1st attempt to write a script,

So far, this is what I have done....

ah, something like this?

SEQUENCE // IL2 chase view zoom out is what I want to do.
WAIT ( JS1.B7 ); // fighterstick hat 1 button 7 (referenced to CMS button 4)
CMS.B4 = TRUE; // CMS button 4 (key stroke F8 (chase view))
CMS.B2 = TRUE; // CMS button 2 (as mouse left click)
???????????? // CMS button ? (to zoom out a specified distance?) Can it be done?
ENDSEQUENCE

In IL2 there is a control key "Zoom Out (external)" which is, Left Mouse button + Mouse down.

In the game using keyboard strokes manually, F8 is your chase view, left mouse button and hold while pushing forward is zoom out. I read in another post where Bob said you get one click only for the mouse when programed as a button in CMS? Does that mean it can not be held down? Can it be held down for a certain amount of time for a time\distance formula to take effect?

Am using wide screen monitors with triplehead2go 3072 x 800 resolution causes my aircraft to be too large in external view. I need to fix this if its possible. I already am using the widest game fov view (page down key), but the view is still not wide enough. The only problem with wide screen monitors and triplehead2go.

Could use some help, Bob? anyone?

[Windturbin]

still trying making a bit more progress after reading and reading and reading.................

updated script........

SEQUENCE
WAIT ( JS1.B7 ); // Wait for button 7 to be pressed on fighter stick
DELAY( 3 ); // Wait approx an eighth of a second
CMS.B7 = TRUE; // CMS button 7 (F8 chase view) press
CMS.B2 = TRUE; // Left Mouse Button hold down
DELAY( 3 ); // Wait approx an eighth of a second
CMS.B7 = FALSE; // CMS button 7 (F8 chase view) release
CMS.B2 = FALSE; // Left Mouse Button release
ENDSEQUENCE

I finally figured out that the CMS button numbers are linked to the fighter stick button numbers, they are one in the same, ah ha!

Hat 1 down [B] is button 7 in the CMS.

The above script is working in the sim! Major break through for me :yahoo:

Cant tell if the mouse button is working cause I don't know how to tell it what to do yet.

[Bob Church]

Hi Windturbin,

>> My 1st attempt to write a script,

So far, this is what I have done....

ah, something like this?



SEQUENCE // IL2 chase view zoom out is what I want to do.
WAIT ( JS1.B7 ); // fighterstick hat 1 button 7 (referenced to CMS button 4)
CMS.B4 = TRUE; // CMS button 4 (key stroke F8 (chase view))
CMS.B2 = TRUE; // CMS button 2 (as mouse left click)
???????????? // CMS button ? (to zoom out a specified distance?)
ENDSEQUENCE


Can it be done?

In IL2 there is a control key "Zoom Out (external)" which is, Left Mouse button + Mouse down. <<

So what you want to do is set up a couple of buttons to click F8 to switch to chase view, then hold down mouse left, move the mouse downscreen by some fixed amount?

>> In the game using keyboard strokes manually, F8 is your chase view, left mouse button and hold while pushing forward is zoom out. I read in another post where Bob said you get one click only for the mouse when programed as a button in CMS? Does that mean it can not be held down? <<

No. It's the "Mouse Click" commands that doesn't stay down because they're not DX Mode commands, they're Programmed Mode, and so they have to go through the character processor. If you just take any of the buttons, set it to DX Mode, you can assign it, for example, to "Button 1" and "Mouse" ("Mouse" is down below CM Device 16 in the DX Device drop-down on the right side of the screen). Then it just tracks the button, it doesn't go through the character processor that way. Button 2 is Right Mouse and Button 3 is Middle Mouse. Mouse X and Mouse Y are what you'd expect, Mouse Z acts like a scroll wheel.

>> Can it be held down for a certain amount of time for a time\distance formula to take effect? <<

Yes, though the timing isn't very precise. It depends on Windows and the sim framerate more than anything, but you can usually get it to move about what you want it to. The SEQUENCE you started with is one way, you could use timers, too. With the sequence, first you have to deal with F8 going down and then going back up again. I don't think you want it held through the whole move, but let me know if I'm wrong. Next you'd need to feed a fixed value to the Y Axis on the Mouse for a fixed amount of time, then set the Mouse Y Axis back to whatever it was to be normally. Probably you'd want to stop any X Axis movement at the time. It would need to look something like this:


script
sequence
wait( js1.b7 ); // Wait for Button 7
cms.b4 = TRUE: // Turn on CMS Button 2, sends F8
delay( 1 ); // Give it time for the F8
cms.b4 = FALSE; // Turn off CMS Button 2 so F8 doesn't repeat
cms.b2 = TRUE // Turn on the mouse button
cms.a1 = 128; // Set CMS Axis 1 to 128 (will center the X)
cms.a2 = 112; // Set CMS Axis 2 to move the mouse "Up"
delay( 10 ); // Let it move
cms.a1 = js2.a1; // Set CMS Axes 1 and 2 back to using the
cms.a2 = js2.a2; // ministick on JS2.
cms.b2 = FALSE; // Turn off the mouse button
endSequence
endScript

You'd need to assign CMS Axes 1 and 2 to control the Mouse X and Mouse Y axes up in the GUI, and you'd need to assign CMS Button 4 to send an "F8" character and CMS Button 2 would get sent in DX Mode to Mouse Button 2. You could change the "how far" part with the value in
the "delay( 10 )" statement to set the time and the value assigned to CMS Axis 2 the first time (currently 112) to set the speed. The further from 128 it gets, the faster the mouse will move.

So, those would be the basics. You just need to be careful to undo whatever you've done, don't leave the mouse value or keys stuck, put the delays in where you need to see a response or send a character.

Mouse programming can be messy. A lot of times you make a mistake and it will drive the mouse to one edge of the screen and you can't get control for long enough to pull it back over and click "Direct Mode" to shut the map off. If you just unplug one of the controllers, that will shut it down right away. You can plug the controller right back in and it should be back in Direct Mode.

Anyway, it's probably not exactly what you want but hopefully close. Let me know if you run into any problems.

Best regards

- Bob

The StickWorks
http://www.stickworks.com

[Windturbin]

Hi Bob,

I tried that, am getting a conflict message at download.

Here is all my script, I found the first two here at CH hanger and they have been working well.

// CMS Script File

SCRIPT

IF ([JS2.A1 > JS2.A2]) then // IL2 pedal toe brake script
CMS.A1 = JS2.A1;
ELSE
CMS.A1 = JS2.A2;
ENDIF

SEQUENCE // IL2 Map and mouse pointer script
WAIT( JS3.B1 ); // Wait for button 1 to be pressed on the Pro Throttle
DELAY( 3 ); // Wait approx an eighth of a second
SCREENX=900; // Move cursor to map pop up window
SCREENY=200;
DELAY( 3 ); // Wait approx an eighth of a second
CMS.B2 = TRUE; // Left Mouse Button is held down
WAIT( JS3.B1 ); // Wait for button 1 to be pressed again on the Pro Throttle
DELAY( 3 ); // Wait approx an eighth of a second
CMS.B2 = FALSE; // Left Mouse button is released
DELAY( 3 ); // Wait approx an eighth of a second
SCREENX=1016; // Move cursor out of view
SCREENY=760;
DELAY( 3 ); // Wait approx an eighth of a second
ENDSEQUENCE

sequence // IL2 Chase view - zoom out script
wait( js1.b7 ); // Wait for Button 7
cms.b4 = TRUE: // Turn on CMS Button 2, sends F8
delay( 1 ); // Give it time for the F8
cms.b4 = FALSE; // Turn off CMS Button 2 so F8 doesn't repeat
cms.b2 = TRUE // Turn on the mouse button
cms.a1 = 128; // Set CMS Axis 1 to 128 (will center the X)
cms.a2 = 112; // Set CMS Axis 2 to move the mouse "Up"
delay( 10 ); // Let it move
cms.a1 = js3.a1; // Set CMS Axes 1 and 2 back to using the
cms.a2 = js3.a2; // ministick on JS2.
cms.b2 = FALSE; // Turn off the mouse button
endSequence

ENDSCRIPT

My js1 is fighter stick
My Js2 is pedals
My js3 is throttle

Could my conflict be is this script or might it be in control manager, when I get the conflict message it does not specify what exactly is conflicting.

My guess is it might have something to do with my a1 a2 mini stick? Or my toe brakes?

[Bob Church]

Hi Windturbin,

A conflict is always in the MAP, not the CMS files. It happends when you try to assign two physical axes (FighterStick X and Pro Throttle X to CMS Device 1, Y Axis for example. It should pop up the "Conflict Finder" when it happens and take the GUI screen to the first control that it's detected as being in the conflict. If you click the buttone a the the bottom of the box, you can switch the GUI display from one of the conflicting controls to the other and figure out which it is.

I'd guess it's the mouse axes. You've probably still got them assigned directly to the mouse, and now we're assigning them to a CMS axis too. If that's the case, you need to assign the axis at the ProThrottle itself to a DX Device and a DX Control of "None". You may get them on the mouse buttons, too. In that case, the CMS-generated button needs to be "OR"ed in the script with the actual button and then the direct programming removed. That way, only the CMS axis/button will be driving the CM Device and no conflict should occur.

Anyway, run the download again, have a look at the two controls that the thing is reporting conflict on and we can see where to go next.

Best regards,

- Bob

The StickWorks
http://www.stickwork.com

[Windturbin]

You'd need to assign CMS Axes 1 and 2 to control the Mouse X and Mouse Y axes up in the GUI

How can I assign CMS Axes 1 and 2 to control the Mouse if Axes 1 and 2 already control my toe brakes?

This is where I get confused with understanding the basic philosophy of the CH software.

I have 64 axes buttons for CMS Controls but all three of my Devices (Stick,Pedal,Throttle) all require the use of axes buttons 1 and 2 only?

The regular CMS buttons have me stumped as well, I would have thought I could assign an action to any CMS button available and then assign that button to one of my device buttons so as to use for script. But it doesn't seem to work that way either. My device 1 button 7 reads CMS button 7 in a script, but it will not read CMS button 4 programed the exact same way? Go figure.

Gosh, I just seem to be missing the boat. I wrote the spreadsheet that runs my business (many complicated macros) back in 89, I think of myself as being some what computer literate, this is harder to grasp than that was! I know scripting is not something you learn overnight, but I'm hoping that if I keep trying, the basic philosophy of how your software works will finally click for me. Am hoping to say; oh I get it now.

At times I think I have it figured out and then (oh %$&^) ......

I will keep asking questions as long as you will answer them. Please don't get impatient with me I have learned so much already don't want to stop now.

[Bob Church]

Hi Windturbin,

>> How can I assign CMS Axes 1 and 2 to control the Mouse if Axes 1 and 2 already control my toe brakes? <<

You can't, but you can use CMS Axes 3 and 4, or some other unused axis. There's no magic to any of them, it doesn't matter which ones you use.

>> This is where I get confused with understanding the basic philosophy of the CH software.

I have 64 axes buttons for CMS Controls but all three of my Devices (Stick,Pedal,Throttle) all require the use of axes buttons 1 and 2 only? <<

Yes, but the CMS Controls don't all have to go to the same CM Device. You can send them anywhere. The CM Devices all have the capability of handling 32 button and 8 axes, so even if you've just created a map that passes everything through for a FighterStick, ProThrottle, and ProPedals, you have extra buttons you can assign. The FF and PT only have 16 buttons each, so you can assign to buttons 17 through 32. The Pro Pedals have no buttons at all, so you can assign them to 1 through 32. That's 64 already, and they'll just show up on the CM Device they're assigned to. Even if you run out, simply assigning something to a CM Device is enough to cause it to get created. Start a new map. Just add the CMS Controls, no real controllers at all. Take CMS Control Button 1 and assign it to CM Device 1, Button 32. If you download that and look at it in the test screen, you'll have one CM Device with 32 buttons and the X and Y axes (Windows requires those be be present). None of them will actually do anything, you haven't done anything with the map to cause them to change state, but the controller is created. There's not any fixed relationship between the physical devices and the CM devices. You can have more or less CM devices showing than you actually have physical controllers. One of the primary uses of the CM (not so much anymore) was to allow you to combine stick, throttle, and pedals into a single controller for old games that only saw one controller, but you can go the other way, too. Create as many Control Manager Devices as you need to do what you want to do by just making assignments to them. If there's an assignment, the Control Manager will create the CM Device. You can leave "holes" in the lineup, you have to use CM Device 1, then CM Device 2, etc. If you skip one, Windows will slide everything down to fill the gap and it gets kind of confusing, but otherwise you can do pretty much as you please. The only "anomaly" is the X/Y axes. Windows requires that joysticks have X and Y, so the CM creates dummy axes if you don't make an assignment. They'll show up in the list, but they won't do anything. Windows will be happy, it doesn't care if they do anything or not.

>> The regular CMS buttons have me stumped as well, I would have thought I could assign an action to any CMS button available and then assign that button to one of my device buttons so as to use for script. But it doesn't seem to work that way either. My device 1 button 7 reads CMS button 7 in a script, but it will not read CMS button 4 programed the exact same way? Go figure. <<

I'm not sure what you mean here. Basically, the CMS Controls are just like any other physical controller (FighterStick, ProThrottle, etc.) The only difference is there is no physical button associated with them. You turn them off and on, or move the axes, using the script. The script moves the CMS Control, you assign the CMS Control to a CM Device button or axis, and so whatever the script does to the CMS Control button/axis ends up acting on the CM Device button/axis that it's assigned to in the sim.

>> Gosh, I just seem to be missing the boat. I wrote the spreadsheet that runs my business (many complicated macros) back in 89, I think of myself as being some what computer literate, this is harder to grasp than that was! I know scripting is not something you learn overnight, but I'm hoping that if I keep trying, the basic philosophy of how your software works will finally click for me. Am hoping to say; oh I get it now. <<

You'll catch on. It's a little confusing at first, but the only thing that's really different is that you're moving the buttons and axes on the physical controllers, the script is moving the buttons and axes on the CMS Controls.

>> At times I think I have it figured out and then (oh %$&^) ......

I will keep asking questions as long as you will answer them. Please don't get impatient with me I have learned so much already don't want to stop now. <<

I'll be here. When you get stuck, just ask. Once you've been through it once or twice, it gets easier. :)

Best regards,

- Bob

The StickWorks
http://www.stickworks.com

[Windturbin]

Hi Bob,

I see now that you can assign any button, they were not working because my script had errors! My bad.

Ok I'm back to looking at my conflict. I understand how the conflict finder works.

Here is the conflict........

First control using mouse axis is mini stick on the throttle.

Second control using mouse axis CMS buttons a1 and a2.

Previously you told me to.......


I'd guess it's the mouse axes. You've probably still got them assigned directly to the mouse, and now we're assigning them to a CMS axis too. If that's the case, you need to assign the axis at the ProThrottle itself to a DX Device and a DX Control of "None". You may get them on the mouse buttons, too. In that case, the CMS-generated button needs to be "OR"ed in the script with the actual button and then the direct programming removed. That way, only the CMS axis/button will be driving the CM Device and no conflict should occur.

If I go to my mini stick X&Y-Axis [A1] and change the DXDevice from mouse to CM Device 3 and DX Axis from X&Y-Axis to NONE (which is what I think you described abv) I get an error compiling CMSscript message.

When you say pro throttle itself, your not reffering to the mini stick though, right?

[Windturbin]

Ok I am past message #8

Here (again) is the script the error message is referring to.


SEQUENCE // IL2 Map and mouse pointer script
WAIT( JS3.B1 ); // Wait for button 1 to be pressed on the Pro Throttle
DELAY( 3 ); // Wait approx an eighth of a second
SCREENX=900; // Move cursor to map pop up window
SCREENY=200;
DELAY( 3 ); // Wait approx an eighth of a second
CMS.B1 = TRUE; // Left Mouse Button is held down
WAIT( JS3.B1 ); // Wait for button 1 to be pressed again on the Pro Throttle
DELAY( 3 ); // Wait approx an eighth of a second
CMS.B1 = FALSE; // Left Mouse button is released
DELAY( 3 ); // Wait approx an eighth of a second
SCREENX=1016; // Move cursor out of view
SCREENY=760;
DELAY( 3 ); // Wait approx an eighth of a second
ENDSEQUENCE


This is a script I copied from Revvin and I believe he had CMS controls button 1 unused and button 2 and 3 were set up as mouse buttons 1 and 2.

I just changed them back and the way they were and adjusted the script accordingly.

Now I'm able to download without error, but like you mentioned my mouse is going balistic.

Will keep working.

[Windturbin]

No conflicts, No error messages, but loose control of my mouse, is all over the desktop.


I'd guess it's the mouse axes. You've probably still got them assigned directly to the mouse, and now we're assigning them to a CMS axis too. If that's the case, you need to assign the axis at the ProThrottle itself to a DX Device and a DX Control of "None". You may get them on the mouse buttons, too. In that case, the CMS-generated button needs to be "OR"ed in the script with the actual button and then the direct programming removed. That way, only the CMS axis/button will be driving the CM Device and no conflict should occur.

the CMS-generated button needs to be "OR"ed in the script with the actual button and then the direct programming removed.

Am stuck here. "OR"ed ? Could I get a example of this?

[Bob Church]

Hi Windturbin,

If the mouse is moving like that, it's because the Mouse X and Mouse Y values aren't set to 128. Some axis, regular or CMS, is assigned to the Mouse X/Y, if they're not at 128 then the mouse will move.

Figure out what's assigned to the mouse, then figure out why it's not 128. :) If you're using direct mouse sets like that, you can just assign nothing to the mouse, e.g. whatever is going to a Mouse axis now, set it to "None" and "None" on the right side of the screen. If nothing sends it a value, the CM will leave it alone.

Edit: I should mention, the SCREENX and SCREENY direct sets for mouse position may disappear. Vista doesn't seem to like them and if I can't make them work I'll have to take them out. I did turn up a bug in that logic the other day, though, so I'm hopeful that they'll remain. Without them, there's really no way to know where the cursor is or to place the cursor at some specific point like that.

Best regards,

- Bob

The StickWorks
http://www.stickworks.com

[Windturbin]

Will keep tinkering with it this week and let you know if I can get it going.

The reason I wanted to zoom out was because my 3 wide screen monitors via triplehead2go will only support 3840 x 800 resolution there for I loose an inch of viewing on the top and bottom of my display, and the fov is not as wide as I would like it to be. Objects are a bit larger than I would prefer them.

If I could get the script to work it would have taken care of the exterior FOV view, but not the cockpit interior view.

I am also now looking at my original dilemma from a different angle. There may be a way to convert the fov to adjust to wide screen in game (maybe) :unsure:......


http://www.widescreengamingforums.com/forum/viewtopic.php?t=511&sid=6c30d177e9d24badc076630262b69b69


Thanks again for answering all my questions, will post again if I come up with a solution or have anymore CH questions.

[Bob Church]

Hi Windturbin,

Okay. To clarify a little, you'll always be able to move the mouse, that function isn't in jeopardy. It just the "SCREENX = 200" statements that are up in the air for the moment. The way you started to do it will still work, and to get the cursor out of view you can always set the Mouse X and Mouse Y to 255 and it till move quickly down to the lower right corner of the screen, so you might be able to work something out that way.

Anyway, if you get back into it and I can help, just ask!

Best regards,

- Bob

The StickWorks
http://www.stickworks.com

[Windturbin]

Hi Bob,

I disabled the throttle mini stick mouse axis by using "None".

That is the only physical device or button assigned to the mouse. (Besides the scripts)

The moment my profile is downloaded my mouse pointer heads to the upper left and I totally loose control of her. Can't do anything but unplug throttle usb to get it back.


It just the "SCREENX = 200" statements that are up in the air for the moment.

If it comes down to choosing between using Jevvins mini stick mouse IL2 map script or making this one work (If I can't have both) I would rather keep Jevvins Map script. Its pretty cool.


The way you started to do it will still work, and to get the cursor out of view you can always set the Mouse X and Mouse Y to 255 and it till move quickly down to the lower right corner of the screen, so you might be able to work something out that way.

No sure I follow, set the mouse X&Y to 255? In the script?
I don't want my mouse to move at all (are you refering to after download?)?

Would be nice to be able to pull off what I was trying to do but not sure if its worth messing up the other scripts that are using mouse controls and working well. :)

I would keep trying stuff but don't really know what to try next without messing up my mini stick mouse.

Thanks again for all your help, I will keep thinking about it and will be keeping an eye on the CH forums in case you or anyone adds to this post.

I downloaded your CM4Guide last night and did some reading. Maybe I can pick up on something there that might help.

[Bob Church]

Hi Windturbin,

>> I disabled the throttle mini stick mouse axis by using "None".

The moment my profile is downloaded my mouse pointer heads to the upper left and I totally loose control of her. Can't do anything but unplug throttle usb to get it back. <<

Are you using the original "sequence" script? If you are, it woold be Axes 1 and 2 on the CMS Control Tabs that were moving it. You'd need to clear those to "None" or set to the values that you wanted. The data on the ministick was passed to cms.a1 and cms.a2, so they'd be the axes that the system sees.

>> If it comes down to choosing between using Jevvins mini stick mouse IL2 map script or making this one work (If I can't have both) I would rather keep Jevvins Map script. Its pretty cool. <<

I don't know the script but if it does what you want, why not just use that?

>>>> The way you started to do it will still work, and to get the cursor out of view you can always set the Mouse X and Mouse Y to 255 and it till move quickly down to the lower right corner of the screen, so you might be able to work something out that way. <<<<

>>No sure I follow, set the mouse X&Y to 255? In the script?

I don't want my mouse to move at all (are you refering to after download?)? <<

At the end of the your second script where you were using the SCREENX and SCREENY commands, you had:


script
....
SCREENX=1016; // Move cursor out of view
SCREENY=760;
,,,.
endScript

It looked like you wanted to get the mouse cursor off the screen. Setting the X and Y Mouse axes to 255 moves the mouse as rapidly as possible to the lower/right corner of the screen essentially what yo were doing. Not a direct "set" like the SCREENX/SCREENY functions, but it will push the cursor out of view pretty quickly. It was just meant to emulate your 1016,276 function.

>> Thanks again for all your help, I will keep thinking about it and will be keeping an eye on the CH forums in case you or anyone adds to this post. <<

You're welcome! If you get back into it and run into problems, let em know!

>> I downloaded your CM4Guide last night and did some reading. Maybe I can pick up on something there that might help. <<

It's really just the same Users Guide you see when you click the yellow book "Help" button in the GUI. If you can recall about where the info is, you can find it there pretty quickly. The PDF is easier to read I think.

Good luck with it!

Best regards,

- Bob

The StickWorks
http://www.stickworks.com

[Windturbin]

Hi Bob,

Giving it another go...... so as to simplify......

I started a new map with only my fighter stick so as to be sure nothing else could conflict with what I am trying to do.

There were 8 steps that I made, maybe you can pin point which step is in error.

Remember what I am trying to accomplish is:

(F8-chase view)-(left mouse click and hold button down while pushing mouse forward for a certain length of time as to zoom out view)

Step 1)
I created a new map with fighter stick only (device 1)

Step 2) assigned this button to direct X control button 7
1160

Step 3) programed CMS button 7 as key stroke F8 (chase view)
1161

Step 4) assigned CMS control button 2 as mouse button 1
1162

Step 5) assigned CMS control button 3 as mouse button 2
1163

Step 6) assigned axes 1 as mouse x-axis
1164

Step 7) assigned axes 2 as mouse y-axis
1165

NOW, right here after step 7, if I download the map I lose my mouse control on my desktop, therefore I am not able to even click the download "loaded ok" button, let alone execute my flight simulator! Could you tell me exactly which step above is incorrect and how I might correct it?

Then there is step 8) the script, which I don't see how it could be creating the mouse gone wild problem because I have tried downloading the map with it and without it with the same outcome.
1166

Or could it be an error with the script???????

[Bob Church]

Hi Windturbin,

Well, the problem is really with the script. It's not handling the mouse unless the sequence is active. It needs to have the ProThrottle axes copied over when it not running the sequence, otherwise it just runs the mouse at whatever value it has, those would be 0,0 when the map started.

The cms.b2 flag that controls the mouse button is on during the importan part of the sequence, a prime candidate for a switch. I'd use it to force the script to use the microstick when the sequence wasn't running. It would look like this:


script

sequence
wait( js1.b7 ); // Wait for Button 7
cms.b4 = TRUE; // Turn on CMS Button 2, sends F8
delay( 1 ); // Give it time for the F8
cms.b4 = FALSE; // Turn off CMS Button 2 so F8 doesn't repeat
cms.b2 = TRUE; // Turn on the mouse button
cms.a1 = 128; // Set CMS Axis 1 to 128 (will center the X)
cms.a2 = 112; // Set CMS Axis 2 to move the mouse "Up"
delay( 10 ); // Let it move
cms.b2 = FALSE; // Turn off the mouse button
endSequence

// If it's not in the sequence, use the microstick
//
if( NOT cms.b2 ) then
cms.a1 = js2.a1; // Force CMS Axes 1 and 2 to use the
cms.a2 = js2.a2; // ministick when not running the sequence.
endIf

endScript

I ran the above and it seems to do what you want. I did need to add some deadzone for the mouse. That needs to be set on CMS axes A1 and A1 since those are the ones that are actually talking to the mouse, not at the microstick. Those should just be left at 0.

Best regards,

- Bob

The StickWorks
http://www.stickworks.com

[Windturbin]

Hi Bob,

That script does the job For the chase view\zoom script! :cheers: Thank you!

But it does pork the mini stick mouse, Like you said earlier I have to put "none" for the DX mini stick axis so as it won't conflict with the CMS Control Axes a1 and a2.

Also, did I mention I'm running vista 64 bit OS? That might be a problem to, as I read in the CMCC screen and mouse variables section. Although the mini mouse map was working before I incorporated this script into the mix.

Question: Running the CMCC just means after downloading your map, you leave the CM Control manager open right?

[Bob Church]

Hi Windturbin,

>> That script does the job For the chase view\zoom script! Thank you! <<

You're welcome!

>> But it does pork the mini stick mouse, Like you said earlier I have to put "none" for the DX mini stick axis so as it won't conflict with the CMS Control Axes a1 and a2. <<

It should be switching back to the ministick when you're out of the sequence, but it depends on the ProThrottle being the second device in the map. The tabs should be (left to right) "Program Settings", "FighterStick", "Pro Throttle", "CMS Controls", which I thought was the order you were actually using. I just went back over it, though, and see that you've removed the Pro Throttle. Did you put it back in? The assignments to JS2.A1 and JS2.A2 will connect them to the ministick If you did, otherwise you don't really have a JS2.

>> Also, did I mention I'm running vista 64 bit OS? That might be a problem to, as I read in the CMCC screen and mouse variables section. Although the mini mouse map was working before I incorporated this script into the mix. <<

No. Vista 32 or 64 shouldn't bother it. It's the SCREENX/SCREENY stuff that's affected. Here we're just moving the mouse and that happens from within the Control Manager.

>> Question: Running the CMCC just means after downloading your map, you leave the CM Control manager open right? <<

No. The CMCC is the Control Manager Control Center utility. It's not in the Vista install. It's a little background application that lets you start and stop the CM, do downloads, etc. It was what determined the SCREENX/SCREENY values but wasn't really working in Vista. The regular Control Manager GUI that you've been using only needs to run while you're editing a program or using it to download, etc. There's no reason to leave it running once the map is started.

If you want to attach a copy of your MAP, CMS, and any CMC file that you're using in the map. I can take a look, maybe see where it's gone astray if you like. If the mouse move thing is working okay, getting it to track the Pro Throttle the rest of the time shouldn't be any trouble at all.

Best regards,

- Bob

The StickWorks
http://www.stickworks.com

[Windturbin]

If you want to attach a copy of your MAP, CMS, and any CMC file that you're using in the map. I can take a look, maybe see where it's gone astray if you like. If the mouse move thing is working okay, getting it to track the Pro Throttle the rest of the time shouldn't be any trouble at all.

Yes, that would be great :thumbsup:

1179

1180

1181

[Bob Church]

Hi Windturbin,

I got the map and all and ran it up, everything seems to work fine. I did have some trouble with the mouse drifting, maybe that's what you're seeing. Calibrate the ProThrottle again. When it asks you to set center, try to get in the center of the backlash zone, that minimizes the deadzone you need. Then you may need to increase the deadzone, the ministicks take a bit more. The deadzone has to be set on CMS Axis 1 and Axis 2, though, since they are the ones that see the mouse.

The only other thing I might do, more for neatness sake than anything, is that you've got assignments made to the Ministick X and Y axes for some of the Modes. I'd set them to be "None" and "None" for all 6 positions (X and Y, 3 Modes). It worked just as you sent it, though. If the mouse is still going off screen on you, it's probably just calibration and deadzone that's causing it, not a fault in the script itself.

Give it a try and see if it helps!

Best regards,

- Bob

The StickWorks
http://www.stickworks.com

[Windturbin]

Hi Bob,

The mouse drifting a bit was not what I was referring to, although I did need to fix that. The calibration and dead zone adjustments did take care of that, thank you very much.

I should have been more specific. The mini stick mouse pointer sequence in the (2nd script) is not working as it did before I incorporated the chase-zoom sequence (3rd script).

Before, I could press the mini stick button, which would lock the mouse pointer and drag the in game IL2 map positioning.

It quit working when I changed the throttle mini stick Y&X axis from "mouse" to "none". (so as it would not conflict with CMS a1 and a2 axes which are set as "mouse".

Did you try it?

*press button 15 on the fighter stick to activate the in game IL2 in game map.

*then click the mini stick button to lock or hold down the mouse while moving the mini stick which in turn should move the map up dawn sideways etc.

I originally downloaded this sequence form here....


http://www.ch-hangar.com/forum/showthread.php?t=2659&highlight=screenx%3D900

Post #6

[Bob Church]

Hi Windturbin,

>> Before, I could press the mini stick button, which would lock the mouse pointer and drag the in game IL2 map positioning.

It quit working when I changed the throttle mini stick Y&X axis from "mouse" to "none". (so as it would not conflict with CMS a1 and a2 axes which are set as "mouse". <<

Well, moving the axis wouldn't kill it like that. There's really no difference in what the sim sees, the mouse values are just coming from a different source, but the mouse movement itself is generated in the script. I suspect it's the use of CMS.B2 since the last block of logic would disconnect the mouse whenever you'd latched the button down.

Are you trying to create a single action, sort of a combination of the two, where you click a button, it does the zoom, and then just goes back to normal or are you looking for to separate functions - one to do the incremental zoom in/out and one that works like Revvin's original script and just lets you drag the view around to wherever you want it? It's easy enough to get rid of the cms.b2 dependency by just using another bit, but I'm not sure that's going to really accomplish what you want to do.

Also, I'm not at all sure the SCREENX and SCREENY functions are even working in Vista. They get their data from the CMCC and that wasn't included with Vista, the SCREENX and SCREENY functions being one of the reasons. I tried them here but mainly it just crashed Vista. I'm not sure what the problem was yet, that's why I mentioned using the functions earlier. Are you using an older version of the CMCC? There were other changes, honestly I don't recall them all, but how much of the older CMCC versions will still work with Vista or what other functions might be broken isn't really clear. There were changes in the way the compiler talked to the main GUI program, the old CMCC versions weren't updated to work into the new system. I'd guess for the most part they still work, but it's not using the same compiler as the main GUI at this point.

They create a couple of problems in the script. Getting the cursor off-screen isn't much trouble, you just need to feed it a big move to drive it to a screen corner. Hitting the 900,200 position could be difficult since you don't know where you are when you start. About all you can do without the SCREENX and SCREENY functions is to drive it hard to the nearest corner (the cursor will only go to the maximum screen coordinates) and then find a move time/speed that gets you back to 900,200. Whether it can be done reliably sort of depends on how critical 900,200 is. If it has to be 900,200 then it's probably going to be trouble. if it can be anywhere in a box that's maybe 100 pixels square (850 to 950 and 50 to 150 for example) you can probably get it to work, though. Still, I have to wonder what else might be happening with the change in compilers.

Questions, questions. :)

Best regards,

- Bob

The StickWorks
http://www.stickworks.com

[Windturbin]

Hi Bob,


Well, moving the axis wouldn't kill it like that. There's really no difference in what the sim sees, the mouse values are just coming from a different source, but the mouse movement itself is generated in the script. I suspect it's the use of CMS.B2 since the last block of logic would disconnect the mouse whenever you'd latched the button down.

Yes, at the end of the script......


if( NOT cms.b2 ) then // If it's not in the sequence, use the microstick
cms.a1 = js3.a1; // Force CMS Axes 1 and 2 to use the
cms.a2 = js3.a2; // ministick when not running the sequence.
endif

If I change it to......

if( NOT cms.b3 ) then // If it's not in the sequence, use the microstick
cms.a1 = js3.a1; // Force CMS Axes 1 and 2 to use the
cms.a2 = js3.a2; // ministick when not running the sequence.
endif

Then the micro stick script works. I am able to drag the in game map around.


Are you trying to create a single action, sort of a combination of the two, where you click a button, it does the zoom, and then just goes back to normal or are you looking for to separate functions - one to do the incremental zoom in/out and one that works like Revvin's original script and just lets you drag the view around to wherever you want it? It's easy enough to get rid of the cms.b2 dependency by just using another bit, but I'm not sure that's going to really accomplish what you want to do.

Am not trying to create a single action. I have my hat 3 right [B14] programed to RCLICK for zooming in and out. I just want to be able to drag it around with my micro stick.


using another bit means?

I don't understand, what is a bit?


Also, I'm not at all sure the SCREENX and SCREENY functions are even working in Vista. They get their data from the CMCC and that wasn't included with Vista, the SCREENX and SCREENY functions being one of the reasons. I tried them here but mainly it just crashed Vista. I'm not sure what the problem was yet, that's why I mentioned using the functions earlier. Are you using an older version of the CMCC? There were other changes, honestly I don't recall them all, but how much of the older CMCC versions will still work with Vista or what other functions might be broken isn't really clear. There were changes in the way the compiler talked to the main GUI program, the old CMCC versions weren't updated to work into the new system. I'd guess for the most part they still work, but it's not using the same compiler as the main GUI at this point.

ScreenX&Y are for positioning my mouse when the in game map pops up right? That has and is working fine. My OS is vista 64bit.


They create a couple of problems in the script. Getting the cursor off-screen isn't much trouble, you just need to feed it a big move to drive it to a screen corner. Hitting the 900,200 position could be difficult since you don't know where you are when you start. About all you can do without the SCREENX and SCREENY functions is to drive it hard to the nearest corner (the cursor will only go to the maximum screen coordinates) and then find a move time/speed that gets you back to 900,200. Whether it can be done reliably sort of depends on how critical 900,200 is. If it has to be 900,200 then it's probably going to be trouble. if it can be anywhere in a box that's maybe 100 pixels square (850 to 950 and 50 to 150 for example) you can probably get it to work, though. Still, I have to wonder what else might be happening with the change in compilers.

My cursor goes off screen fine when shutting down the in game map (Revvin-seiben script.)

The two script seem to be fighting each against the other. Where I stand right now is the Revvin-seipen micro stick is working again but my chase zoom no longer is working even when I change the above example back the way it was! I get one to work, then try to get the other to work, and back and forth we go. :eek:

Man this stuff is touchy!

[Bob Church]

Hi Windturbin,

>> Am not trying to create a single action. I have my hat 3 right [B14] programed to RCLICK for zooming in and out. I just want to be able to drag it around with my micro stick. <<

Okay. It didn't sound like it at first, then as time went along I wasn't really sure if you were trying to merge the two or not.

>> I don't understand, what is a bit? <<

Everything that's not a number, really. :) You did it when you switched to cms.b3, actually. It's just a flag that's "OFF" or "ON", "TRUE" or "FALSE", etc. Buttons, pretty much anything that starts with "B", ("B1", "JS1.B7", "CMS.B24", etc.) are bits. Also the "D" bits that you use in device statements like timers:


timer( INTERVAL, d1, 2, 2, ) = js1.b2;

D1 is a bit that indicates the timer's current output state. Comparisons are effectively bits, too:


b1 = [ js1.a1 > js1.a2 ];

the result of the comparison is a bit that's TRUE or FALSE depending on the relative values of js1.a1 and js1.a2 is a bit and so can be assigned to b1.

Anyway, that little problem shouldm't be too hard to fis. We can't use CMS.B2 as the determining flag, but any of the unused bit variables will do. Take b1, set it TRUE at the top of the second sequence and FALSE at the bottom. Then use it to determine which way the axes get switched:


script
//.....
sequence
wait( js1.b7 ); // Wait for Button 7
b1 = TRUE; // Flag the fact that the sequence has started
cms.b4 = TRUE; // Turn on CMS Button 2, sends F8
delay( 1 ); // Give it time for the F8
cms.b4 = FALSE; // Turn off CMS Button 2 so F8 doesn't repeat
cms.b2 = TRUE; // Turn on the mouse button
cms.a1 = 128; // Set CMS Axis 1 to 128 (will center the X)
cms.a2 = 112; // Set CMS Axis 2 to move the mouse "Up"
delay( 10 ); // Let it move
cms.b2 = FALSE; // Turn off the mouse button
b1 = FALSE; // Clear the "in-sequence" flag
endSequence

// If it's not in the sequence, use the microstick
//
if( NOT b1 ) then
cms.a1 = js2.a1; // Force CMS Axes 1 and 2 to use the
cms.a2 = js2.a2; // ministick when not running the sequence.
endIf
endScript

Give that a try and see where things stand. As long as you don't try to run both sequences at the same time, I don't really see any place else they'd collide, but you never know until you try.

Best regards,

- Bob

The StickWorks
http://www.stickworks.com

[Windturbin]

Hi Bob,

:thumbsup:

Thats it my friend! At first it didn't work, then after some more re-calibrating and re-adjusting the mouse dead zones, it came to life. All three of my scripts are now working cohesively and correctly.

It is such a good feeling when the stickworks! :cheers:

Now that I have learned a bit, I might try to copy and then tweak the script to do some simular zooming on some of the other views as well.

Thanks for having patience with me!

[Bob Church]

Hi Windturbin,

You're quite welcome, Windturbin! I'm glad it all came together. It can be a bit troublesome at first, but it gets easier after you've done a few.

Have fun, and if you need any help just ask!

Best regards,

- Bob

The StickWorks
http://www.stickworks.com