MV22B Rel1.0 released

... I will then, if the roll is gone, try seeing if I can figure out just which entry Maryadi added is the "secret" entry that fixes it. I'll try just adding one of those last 4 entries at a time to see which, if any, is the magical entry that fixes everything. ...
Be back with test results ASAP.
Pat☺

it not a secret, the " 4 " entries are mention clearly in FSX/P3D SDK documentation. that was a multipliers on the effects induced by rotating propellers, called "left turning tendencies".
 
After I suck down some more coffee, I'll be getting on this to test those changes Maryadi posted. I always fly all Realism sliders full right, as well. Perhaps taking one down a little will also alter the roll situation. A lost of .air file settings consider the realism sliders thus: Full right, 100% effect of the setting in question, ANYthing below full right, the .air file considers 50% effect, or even 0% effect. So, just adjusting the General Realism (usually) slider to anything other than full right can have a large effect. Much larger than it seems it should, but that's how .air files work. Now, if the settings in question aren't included in the .air file, many in R1534 and higher, then the realism sliders wouldn't have much effect. Since many are over-ridden by the aircraft.cfg settings, the sliders don't matter any way, but I still leave mine full right, just to be on the safe side.
I will then, if the roll is gone, try seeing if I can figure out just which entry Maryadi added is the "secret" entry that fixes it. I'll try just adding one of those last 4 entries at a time to see which, if any, is the magical entry that fixes everything.
Again, more testing ASAP. I will post my results this afternoon (my time, PST) or at worst, this evening.

Mark,
it sounds to me like your EXE.XML got changed/corrupted somehow. Have you added, or changed, anything that could do that? This includes Windows updates, which can have unexpected effects. May I suggest you take and make a copy of your existing EXE.XML file and store it someplace safe, like in the FSX folder, since it doesn't look there for the exe.xml file. Then, make sure the only entries in the EXE.XML file in the normal location are the regular, first entry, that it comes with by default, and the AICarriers entry, unless there's another entry in it you absolutely must have to make the sim function properly. This way, we can be certain nothing is changing or altering the AICarriers entry. Then you can start adding any other entries to your EXE.XML file that you have. Remember, you have to shut FSX down, and then restart it to see any changes to the EXE.XML file. Kinda time consuming, buuuut...
Another thing to check, especially if you have gotten any Windoze updates installed, is whether your .NET Framework needed for AIC is still installed AND running. If not, you may need to reinstall it.
You can also try starting AIC manually with a shortcut to the AICarriers.exe file in the AICarriers install folder you would normally start it with the EXE.XML. Always Run As Administrator. It sounds to me like, for some reason, AIC isn't starting automatically when the sim starts any longer. Now let's see if we can figger out why :D
We'll get it. I'm stubborn...

By the way, I don't get the low altitude Jitter that Mr. Seawing has mentioned. I can post my computer specs if you want. I am using FSX:SE.

Be back with test results ASAP.
Pat☺

Pat,

Grrr! I wrote quite a long reply to you, didn't send it, then had to reboot because .NET told me to. Got back to this forum thread and my incomplete reply had GONE!:banghead: Guess I'll learn from that and save anything I haven't sent before rebooting...

So here goes again, but probably shorter. :untroubled:

I did as you suggested and saved a backup copy of my EXE.XML and then deleted all irrelevant sections. No improvement after restarting FSX.

II also check and Repaired .NET Framework (hence the reboot!).

NOW! After that enforced reboot, I finally have the AICarriers' window coming up with Shift+J...:biggrin-new:

No idea which bit of fiddling about did it - may have been .NET. Anyway, my next step is to see if AIC still works after reinstating the backed up EXE.XML.

Time for a beer!

Mark

PS: It still works with original EXE.XML
 
I am really glad it's up and working again!
Also glad we figured it out. It was the .NET Framework. Like I said, Windows updates can have unexpected effect on the system. I'm just glad it working again.
Now, quit breaking it! LOL :biggrin-new:


As to testing Maryadi's updated [flight_tuning] section: Yes, they did seem to stop the uncommanded roll, and no one, or combination of any 2 or 3 settings alone would be effective. In other words, it took all 4 together.
My question now would be: What undesirable effect(s) on other flight characteristics will there be? Like Rob said, that effectively turns off those "[h=5]Propeller-induced turning effect parameters". How will this affect the plane's flight characteristics over-all? I believe the props are counter-rotating, Would this eliminate those effects anyway? It wouldn't have an affect in Helicopter mode, but when it's airplane mode, nacelles at 0°, it basically acts like a Beech twin engine plane, just to use an example. Or a P-38. The list of twin engine planes is very long. And since either engine can power both props, the loss of one isn't as bad as in a regular twin.[/h]Since I've been mostly involved in jets, I am not all that versed in propeller driven FDE's. Is it possible that making those settings all a very low number, like 0.01, or even 0.001, would activate the "propeller-induced turning effects", to maintain correct flight effects of the propellers while eliminating the uncommanded roll? Or reducing it to a hardly noticeable effect? Or are they even needed, given the design of the plane? I obviously have a lot still to learn!
Obviously, a lot more testing is needed. :encouragement:

I did notice one interesting thing, however, that may, or may not be having an effect on this situation: The plane seems to use the fuel in the right side tanks first. Could this be contributing to a weight imbalance, leading eventually to a rolling moment? When the tanks are full, and with Maryadi's settings installed, yes, the uncommanded roll is cleared up. BUT: Would the way the plane uses fuel cause it to reappear as the right side tanks are emptied? Or is it just the way the Fuel page displays what's really happening, ie: it's using the fuel equally from both an left and right sides, maintaining a balance?
Or does it even matter in FSX?

Pat☺
 
Hi Rob,

I may have both issues, I'm afraid. The frame rate may have been low (dense scenery) and I am using proportional toebrakes (though calibration seems to be fine). I will test again in a less dense area with more than 20 fps and report back! If you could send me the test gauge to rule out the brakes!?

Yes, disabeling the gauge seemed to cure it, though I initially I had Accufeel messing up the flight behaviour until I turned it of. With the disabled gauge the MV-22 hovers fine so far.

Thanks! I get up to about 30-35 fps out of the system, however, in dense areas it drops down considerably.

Seawing

Hi Rob,

it is definately not the brakes. I tried the tow/push both on a dense airport (doesn't work - around 10-12 fps) and on an oil rig in the North Sea (fps >30 -> works as advertised). So it is due to the low frame rate only, I guess.

I had inhibited the jitter gauge, it all worked fine initially (over land, ships and oilrigs) and I did some SAR and sling load flying. When I came to a frigate, though, (and later over the airport) the jitter re-appeared even with the gauge commented out. When over the frigate the fps were >30, so that shouldn't have been a factor. Any other thoughts?

Best regards,

Seawing
 
it is definately not the brakes. I tried the tow/push both on a dense airport (doesn't work - around 10-12 fps) and on an oil rig in the North Sea (fps >30 -> works as advertised). So it is due to the low frame rate only, I guess.
The very low FPS would explain it.
A bit technical explanation, but it may shed some light for you (and other people) on how FSX internally works.
What most probably happens here:
In FS, XML gauges are normally scheduled at a rate of 18 Hz (every 55 msec), and when an XML gauge issues an event, the coding would normally assume that the result of such an event is reflected in the state of the corresponding FS variable in the next schedule of the gauge. However, when framerate drops below 15, this is not always the case.
So what happens here:
When you have set the throttle to 1/3, the gauge issues an event to release the ParkingBrakes and sets the Tow-Active state.
But, due to the low FPS, in the next schedule of the gauge the FS variable indicates that the ParkingBrakes are still ON.
Causing the Tow feature to immediately de-activate again, because it "thinks" the user has set the ParkingBrakes ON again.

If you PM me your Email address, I will mail you a patch of the gauge that doesn't check this so it would work OK always.
Downside is, that if you would manually set ParkingBrakes ON during a TOW session, it has an odd effect.


I had inhibited the jitter gauge, it all worked fine initially (over land, ships and oilrigs) and I did some SAR and sling load flying. When I came to a frigate, though, (and later over the airport) the jitter re-appeared even with the gauge commented out. When over the frigate the fps were >30, so that shouldn't have been a factor. Any other thoughts?
I assume you haven't activated AccuFeel again ?
What I forgot to add to my readme is, that AccuFeel conflicts with my V(S)TOL solution. Not just for this MV22B, but any aircraft that has my V(S)TOL in it.
Reason being, that AccuFeel uses the same kind of tricks as I do, to simulate a "better" flightbehavior by overwriting FS variables through SimConnect.
Which conflicts, because there can't be "two captains on one ship" ...LoL

Rob
 
I assume you haven't activated AccuFeel again ?
What I forgot to add to my readme is, that AccuFeel conflicts with my V(S)TOL solution. Not just for this MV22B, but any aircraft that has my V(S)TOL in it.
Reason being, that AccuFeel uses the same kind of tricks as I do, to simulate a "better" flightbehavior by overwriting FS variables through SimConnect.
Which conflicts, because there can't be "two captains on one ship" ...LoL

Rob

Hi Rob,

thanks for shedding the light ;-) !!

No, infact it was during the same flight, so AccuFeel was still off. It actually interferes with a lot of aircraft, but somehow I can't just turn it off - it will reactivate on the next loading of FSX.

I#ll send you a PM!

Best regards,

Seawing
 
Hi Rob,

thanks for shedding the light ;-) !!

No, infact it was during the same flight, so AccuFeel was still off. It actually interferes with a lot of aircraft, but somehow I can't just turn it off - it will reactivate on the next loading of FSX.

I#ll send you a PM!

Best regards,

Seawing
Email with new gauge sent ....

Rob
 
Hi all!
Been a while, but I have a new, and quite perplexing problem.
As you can see in thee picture below, the NR reading on the STAT screens, both the center console, the small black and white screen above it, and the MFD STAT screen ENG page, show it to be apparently operating sort of backwards.
attachment.php


When I first load the plane in, it reads 158, and once the engines settle down, and it's ready to fly, as I increase the throttle is drops to 35 or about that. The area colored in as the reading changes, also seems backwards, with the black being the reading, and the green being the "empty" area, reversed from all the other gauges.
The engines function perfectly normally, all other engine readings are well within normal parameter throughout their range. Just the NR is in error. I also have a constant Master Caution light.

I am quite puzzled. I have changed NOTHING in the aircraft.cfg, other than the Flight_Tuning parameters discussed above, nor have I touched the .air file.
Any help that can be provided will be greatly appreciated. It doesn't change the way the plane operates, it's just a display problem, I think.
Have fun everyone!
Pat☺
 

Attachments

  • ScreenHunter_2792 Jul. 22 14.01_A.jpg
    ScreenHunter_2792 Jul. 22 14.01_A.jpg
    72.3 KB · Views: 0
Hi all!
Been a while, but I have a new, and quite perplexing problem.
As you can see in thee picture below, the NR reading on the STAT screens, both the center console, the small black and white screen above it, and the MFD STAT screen ENG page, show it to be apparently operating sort of backwards.


When I first load the plane in, it reads 158, and once the engines settle down, and it's ready to fly, as I increase the throttle is drops to 35 or about that. The area colored in as the reading changes, also seems backwards, with the black being the reading, and the green being the "empty" area, reversed from all the other gauges.
The engines function perfectly normally, all other engine readings are well within normal parameter throughout their range. Just the NR is in error. I also have a constant Master Caution light.

I am quite puzzled. I have changed NOTHING in the aircraft.cfg, other than the Flight_Tuning parameters discussed above, nor have I touched the .air file.
Any help that can be provided will be greatly appreciated. It doesn't change the way the plane operates, it's just a display problem, I think.
Have fun everyone!
Pat☺

need confirmation: did you make any update on dll gauge?

will investigate it.
 
Weird ....
Is this in Accel or Steam ????

I'm using Accell, and it works fine for me.


Another thing I noticed in your Picture:
The MWGB value (maybe Maryadi will explain what that value is) in the EICAS screen reads 0 with you; for me, it reads value 462, with the corresponding green segment displayed.

PS:
Pat, is this problem with the version of file Mar_MV22B.dll in the panel folder, I provided in Addon4 zip file ?? (creation date May 7th 2017, size 490 kB)

@Maryadi: tried all versions of the dll I have since Rel1 (incl. the VS2015 one); all works the same (properly) for me.
 
Weird ....
Is this in Accel or Steam ????

I'm using Accell, and it works fine for me.


Another thing I noticed in your Picture:
The MWGB value (maybe Maryadi will explain what that value is) in the EICAS screen reads 0 with you; for me, it reads value 462, with the corresponding green segment displayed.

PS:
Pat, is this problem with the version of file Mar_MV22B.dll in the panel folder, I provided in Addon4 zip file ?? (creation date May 7th 2017, size 490 kB)

@Maryadi: tried all versions of the dll I have since Rel1 (incl. the VS2015 one); all works the same (properly) for me.

MWGB get value from PRGB, if it 0 value, it seem PRGB 1 have opposite value. thinking ... a possibility flight tuning give effect on engine parameter. I need more info... please remember any change on Osprey aircraft.cfg / air file, an add on that control / make modification to get reality flight. Osprey dll gauge still simple code that get value from aircraft.cfg and air file.

@rcbarend nicely done for VS2015 dll gauge, I'll send AVM.dll (VS2015) soon. still testing on P3D v4, FSX camera gauge make P3D v4 got CTD. I need new refuel gauge without FSX camera gauge, plus still waiting doug refuel gauge 64 bit
 
It's FSX:SE.
It's the add-on from Mr. Rob v4 from rcb_MV22B1_Addon4.zip.
Only changes to the aircraft.cfg are the Sling Load entries I modified, a lights add-on to make the VC more visible at night from mv_22b_vc_mods.zip, a strobe light change from this file: JS_V22B_NavStrobe.zip, and the Flight_Tuning entries you provided. I DID change the first one, p_factor_on_yaw to 0.001 as a test. I don't see how that could cause this, but I can zero it again to test it, if you think I should.
I can reinstall it from the zip file to with no changes to anything to test. That was my next step anyway. Install one add-on at a time until it happens again...
Pat☺

EDIT:
PS:
Pat, is this problem with the version of file Mar_MV22B.dll in the panel folder, I provided in Addon4 zip file ?? (creation date May 7th 2017, size 490 kB)
Yes, it is. Sorry, I forgot to answer that originally.
Another thing I forgot to say: Many thanks go out to you both for the quick responses. I really appreciate it!
Finally:
The MWGB value (maybe Maryadi will explain what that value is) in the EICAS screen reads 0 with you;
On mine, it goes to 0 when the engines have been running high enough to hover, then are brought to idle with the F1 key. About 89 to 92 N1, give or take...
Pat☺
 
Email with new gauge sent ....

Rob


Hi Rob,

again, thanks for the revised gauge. It tested it both in simple and complex sceneries and it works everywhere!

Regarding the jitter, it seems memory depended, as it mainly happens in complex areas and usually starts at the moment the ground dirst/sand blast effect sets in. However, if I take-off from complex aerodromes, it doesn't happen in the beginning. On the other side even on ships out at sea it does happen after a long flight.

best regards,

Seawing
 
Hi Rob,

again, thanks for the revised gauge. It tested it both in simple and complex sceneries and it works everywhere!

Regarding the jitter, it seems memory depended, as it mainly happens in complex areas and usually starts at the moment the ground dirst/sand blast effect sets in. However, if I take-off from complex aerodromes, it doesn't happen in the beginning. On the other side even on ships out at sea it does happen after a long flight.

best regards,

Seawing
Aha .... this is not the "jitter" we discussed, but simply "stutters", probably caused by the CPU not been able to keep sending data to the videocard. Or maybe low on free memory.
Try this... just remove the smoke.system definitions from the aircraft.cfg ( so there's no more grounddust effect) and see if this helps.
Rob
 
Aha .... this is not the "jitter" we discussed, but simply "stutters", probably caused by the CPU not been able to keep sending data to the videocard. Or maybe low on free memory.
Try this... just remove the smoke.system definitions from the aircraft.cfg ( so there's no more grounddust effect) and see if this helps.
Rob

Hm, I did remove all smoke effects from the aircraft.cfg, but I still get this jitters or stutters ... running out of ideas really ...

Maybe the new PC (due in about two weeks) will do the trick...

Regards,

Seawing
 
Hm, I did remove all smoke effects from the aircraft.cfg, but I still get this jitters or stutters ... running out of ideas really ...

Maybe the new PC (due in about two weeks) will do the trick...

Regards,

Seawing

another "trick":
disable gauge by adding " // " (no quote)

Code:
[Vcockpit00]
file=..\texture\$old_fashion.bmp
background_color=0,0,0
size_mm=1024,1024
visible=1
pixel_size=1024,1024
texture=$old_fashion
gauge01=rcb-gauges!VSTOLControlIPC_Function,  0,0
gauge02=rcb-gauges!VSTOL_Jitter,  0,0
gauge03=AVM!Maryadi_lv2av, 0, 0
gauge04=rcb-gauges!V22RotorWashEffectControl,  0,0
//gauge05=rcb-gauges!NacellesFollowSpoiler, 0,0         // Remove "//" to command the nacelles with SpoilerAxis control 
gauge06=mv-22b!compass,  786,343,195,180
//gauge07=mv-22b!peta,  0,0,508,508
gauge08=Mar_MV22B!mar_function,    786,343, 1, 1
gauge09=../sound/dsd_fsx_xml_sound!Sound, 0,0

[Vcockpit01]
file=..\texture\$display_1.bmp
background_color=0,0,0
size_mm=1024,1024
visible=1
pixel_size=1024,1024
texture=$display_1
//gauge00=Mar_MV22B!mar_pfd,      0,   0,   512, 512, 1
//gauge01=Mar_MV22B!mar_pfd,      512, 0,   512, 512, 2
//gauge02=Mar_MV22B!mar_pfd,      0,   512, 512, 512, 3
gauge03=Mar_MV22B!mar_pfd,      512, 512, 512, 512, 4

it will disable MFD 1,2, and 3. including map. let see would be happen.

for more extreme you can disable the CDU:
Code:
//gauge00=Mar_MV22B!mar_cdu,  0, 0, 708, 512
engine parameter still can monitor from MFD.

Maryadi
 
another "trick":
disable gauge by adding " // " (no quote)

Code:
[Vcockpit00]
file=..\texture\$old_fashion.bmp
background_color=0,0,0
size_mm=1024,1024
visible=1
pixel_size=1024,1024
texture=$old_fashion
gauge01=rcb-gauges!VSTOLControlIPC_Function,  0,0
gauge02=rcb-gauges!VSTOL_Jitter,  0,0
gauge03=AVM!Maryadi_lv2av, 0, 0
gauge04=rcb-gauges!V22RotorWashEffectControl,  0,0
//gauge05=rcb-gauges!NacellesFollowSpoiler, 0,0         // Remove "//" to command the nacelles with SpoilerAxis control 
gauge06=mv-22b!compass,  786,343,195,180
//gauge07=mv-22b!peta,  0,0,508,508
gauge08=Mar_MV22B!mar_function,    786,343, 1, 1
gauge09=../sound/dsd_fsx_xml_sound!Sound, 0,0

[Vcockpit01]
file=..\texture\$display_1.bmp
background_color=0,0,0
size_mm=1024,1024
visible=1
pixel_size=1024,1024
texture=$display_1
//gauge00=Mar_MV22B!mar_pfd,      0,   0,   512, 512, 1
//gauge01=Mar_MV22B!mar_pfd,      512, 0,   512, 512, 2
//gauge02=Mar_MV22B!mar_pfd,      0,   512, 512, 512, 3
gauge03=Mar_MV22B!mar_pfd,      512, 512, 512, 512, 4

it will disable MFD 1,2, and 3. including map. let see would be happen.

for more extreme you can disable the CDU:
Code:
//gauge00=Mar_MV22B!mar_cdu,  0, 0, 708, 512
engine parameter still can monitor from MFD.

Maryadi


Hi Maryadi,

thanks, I will test it, though, I think, I rather have the gauges activated.

One more thing I noticed, flying turbo-props in the RW. Turbo-props are pretty quick in decelerating, especially on high RPMs and large props. I also read about the MV-22 with its prop-rotors being able to accelerate and decelerate pretty quick. Now the FSX model decelerates rather slow from cruise speed with nacelles down. I am sure that is mainly due to sim limitations, but do you think there is any way to tweak this a little?

Best regards,

Seawing
 
QUOTE:-

Other than that, sounds like you will be in 7th heaven when you get the new joystick.

Hi Pat,

Well I got my new Hotas X a few days ago and installed it today. And all seems satisfactory, apart from assigning the various buttons, etc.

Wondering which buttons you assigned to Nacelle control? I was wondering if the Slider would work for that?

Mark
 
Back
Top