Jump to content
The simFlight Network Forums

Muas

Members
  • Posts

    32
  • Joined

  • Last visited

Everything posted by Muas

  1. Here's how I got around this problem: I adapted the xml gauge as a new one, to toggle the landing lights using keys instead of mouse clicks, and added it to the VC panel and 2D panels. I kept the original gauge in the overhead panel, so the clickable mouse option is also working and perfectly syncronized. Next I mapped the keys to my toggle switch via FSUIPC et voilà. No lua program needed this time. Here is the gauge: (L:LL_SWITCH,enum) (A:LIGHT LANDING, bool) 0 == if{ 2 (>L:LL_SWITCH, enum) (>K:LANDING_LIGHTS_TOGGLE) } (A:LIGHT LANDING, bool) 1 == if{ 2 (>L:LL_SWITCH, enum) } (A:LIGHT LANDING, bool) 0 == if{ 0 (>L:LL_SWITCH, enum) } (A:LIGHT LANDING, bool) 1 == if{ 0 (>L:LL_SWITCH, enum) (>K:LANDING_LIGHTS_TOGGLE) } My toggle switch sends an "O" keystroke when at the on position, extending and turning up the landing lights; and a "shift+O" keystroke when at the off position, retracting and turning them off. That's it . End of the story. Thanks for the help, I learned to log the L vars in this process.
  2. Sorry, guess I misunderstood what the manual says about it. :( Yes, and that might be easier than it seems, because the code is there, one only must subsitute the mouse click call with a keypress call, or even better, a joystick call. Maybe I should learn a bit of XML myself... :roll:
  3. Yes, I did. I followed this thread when trying to sort this out. And only the LL_SWITCH var appeared in the console window. I tried to, but I'm on FSX SP2, and it seems the automated macro feature doesn't work with SP2... in fact the macro recording doesn't seem to work. I was about to do it manualy, but then I gave up, I was spending to much time around the issue, so it was time to ask for some help. That's the second time I plunge into this L:vars thing, the first was the lights system on my fave DA Fokker 100, on which I got no success also. The CLS DC-10 seemed easy to get into, but then I got stuck... I plan to return to the Fokker one of these days...
  4. Pete, I started tracking this with "the obvious" solution. The problem is the lights, they do not extend and don't switch on. Let's see if I can explain this clearly: 1) The panel switch is of cyclic kind and has three positions: retracted, extended off, and extended on (the animated landing lights rotate out of the fuselage on the DC-10); 2) Those are set by the switch position variable LL_SWITCH, values 0, 1 and 2 (cyclic mouse clicks gets them going 0,1,2,0,1,2...); 3) Using the default key event LANDING_LIGHTS_TOGGLE, nothing happens. The landing lights on/off should only work when they are extended, and that's seems to be the problem as the event LANDING_LIGHTS_TOGGLE doesn't extend the lights - I'm afraid something else (that might be programmed in the model itself) is taking care of the animation, and that's behond the L:vars and K:vars... I'll be checking this again, maybe I'm missing something...
  5. Hi everyone. I find this post very helpfull, but have a problem trying to implement this concept on the CLS DC-10. The overhead panel has a gauge for the landing lights operation, which I managed to get the variable out with Log Lvars.lua file. The variable is named LL_SWITCH, and gets the values 0, 1 and 2, to operate the landung lights. 0 value is for retracted; 1 is for extended off, and 2 is for extend and lit. There is another variable, dc10cls_sound_id, for the click sound - this is a clickable switch operation on the overhead panel. I wrote a MACRO file for this, which I named 1DC-10.MCRO, and tried setting the values 0, 1 and 2... [MACROS] 1=L:LL_SWITCH=SET This works, but I can only get the switch to move (I don't get the sound of it because I didn't set the dc10cls_sound_id values), but they do not operate the landing lights - switch operation ok, but no results?!? Here's the gauge xml code: (L:LL_SWITCH,enum) 8 (>L:dc10cls_sound_id, number) (L:LL_SWITCH,enum) ++ d 3 < * (>L:LL_SWITCH,enum) (A:LIGHT LANDING,bool) 0 == (L:LL_SWITCH,enum) 2 == & if{ (>K:LANDING_LIGHTS_TOGGLE) } (A:LIGHT LANDING,bool) 1 == (L:LL_SWITCH,enum) 2 < & if{ (>K:LANDING_LIGHTS_TOGGLE) } 8 (>L:dc10cls_sound_id, number) (L:LL_SWITCH,enum) ++ d 3 < * (>L:LL_SWITCH,enum) (A:LIGHT LANDING,bool) 0 == (L:LL_SWITCH,enum) 2 == & if{ (>K:LANDING_LIGHTS_TOGGLE) } (A:LIGHT LANDING,bool) 1 == (L:LL_SWITCH,enum) 2 < & if{ (>K:LANDING_LIGHTS_TOGGLE) } (c)2006 Commercial Level Simulations I believe there must be a way to solve this, but I'm not into xml coding and this postfix (?) syntax isn't easily understandble. Can somebody help?
  6. I made another update for the Sync 4 Throttle.lua file with the option to not syncronize the reversers. In my 4 lever (Saitek) setup, the reversers are activated as key strokes at the end of the lever travel - the Saitek has buttons especially for that, so I set them to decrease throttle value when pressed (by repeting default F2 keystrokes) and cut it when released (default F3) - it works very good this way, but I found that when syncronized, the reverse levers tend to move slower than usual, so I de-sycronized the reversers by default in the code. But there are people out there that uses half of the throttle lever travel to activate the reversers, so they might want to keep the throttles syncronized in negative values (reversed). If this is the case, one only needs to delete some marked lines in the code, and the 4 throttles will work syncronized during reverse operation too - as I said, on the above lua files Sync 4 Throttle.lua and Sync Axis.lua, the reverse sync option is disabled by default.
  7. Hi Pete. I edited the 4 engine throttle syncro code, as it was not working as I expected. Here's another working example for 2 engine throttle, prop pitch and mixture axxis sync. -------------------------------------------------------------------------- -- FSX Lua plug-in for thrust, pitch and mixture assimetry compensation -- -------------------------------------------------------------------------- -- [[Thrust, prop pitch and mixture assimetry compensation for twin engine aircraft. In this method, compensation is achieved by adding half of the detected assimetry to each engine throttle, pitch or mixture values.]] -- MaxThrottleAssimetry = 1000 -- maximum thrust assimetry allowed MaxPitchAssimetry = 1500 -- maximum prop pitch assimetry allowed MaxMixtureAssimetry = 1000 -- maximum mixture assimetry allowed while 1 do ipc.sleep(500) -- do nothing for half a second -- Throttle compensation Throttle1Now = ipc.readSW(0x088C) Throttle2Now = ipc.readSW(0x0924) if (Throttle1Now > 0) and (Throttle2Now > 0) then -- delete this line if reverse throttle compensation is required if math.abs(Throttle1Now - Throttle2Now) < MaxThrottleAssimetry then -- there's an assimetric thrust, let's compensate MidThrottleValue = (Throttle1Now + Throttle2Now)/2 ipc.writeSW(0x088C, MidThrottleValue) ipc.writeSW(0x0924, MidThrottleValue) -- done! end end -- delete this line if reverse throttle compensation is required -- Prop pitch compensation Pitch1Now = ipc.readSW(0x088E) Pitch2Now = ipc.readSW(0x0926) if (Pitch1Now > 0) and (Pitch2Now > 0) then -- delete this line if reverse pitch compensation is required if math.abs(Pitch1Now - Pitch2Now) < MaxPitchAssimetry then -- there's an assimetric pitch, let's compensate MidPitchValue = (Pitch1Now + Pitch2Now)/2 ipc.writeSW(0x088E, MidPitchValue) ipc.writeSW(0x0926, MidPitchValue) -- done! end end -- delete this line if reverse pitch compensation is required -- Mixture compensation Mixture1Now = ipc.readSW(0x0890) Mixture2Now = ipc.readSW(0x0928) if math.abs(Mixture1Now - Mixture2Now) < MaxMixtureAssimetry then -- there's an assimetric mixture, let's compensate MidMixtureValue = (Mixture1Now + Mixture2Now)/2 ipc.writeSW(0x0890, MidMixtureValue) ipc.writeSW(0x0928, MidMixtureValue) -- done! end end -- by Muas, November 2009 Save this file and name it Sync Axis.lua. It's worth assigning a keybord key to run this file on the FSUIPC interface, and another key kill it. Set the maximum allowed thrust values to taste. Tests on the FSX default Beechcraft Baron 58 showed excellent results.
  8. Try this: ------------------------------------------------------- -- FSX Lua plug-in for thrust assimetry compensation -- ------------------------------------------------------- -- [[Thrust assimetry compensation for 4 engine aircraft. In this method, assimetric thrust is compensated first on the outbord engines, then the inbord ones, and then the Left/Right couples.]] -- OuterMaxAssimetry = 1000 -- maximum outbord thrust assimetry allowed InnerMaxAssimetry = 1000 -- maximum inbord thrust assimetry allowed LeftMaxAssimetry = 1000 -- maximum left thrust assimetry allowed RightMaxAssimetry = 1000 -- maximum right thrust assimetry allowed while 1 do ipc.sleep(500) -- do nothing for half a second Throttle1Now = ipc.readSW(0x088C) Throttle4Now = ipc.readSW(0x0A54) if (Throttle1Now > 0) and (Throttle4Now > 0) then -- delete this line if reverse throttle compensation is required if math.abs(Throttle1Now - Throttle4Now) < OuterMaxAssimetry then -- there's an outbord assimetric thrust, let's compensate OuterMidValue = (Throttle1Now + Throttle4Now)/2 ipc.writeSW(0x088C, OuterMidValue) ipc.writeSW(0x0A54, OuterMidValue) -- done! end end -- delete this line if reverse throttle compensation is required Throttle2Now = ipc.readSW(0x0924) Throttle3Now = ipc.readSW(0x09BC) if (Throttle2Now > 0) and (Throttle3Now > 0) then -- delete this line if reverse throttle compensation is required if math.abs(Throttle2Now - Throttle3Now) < InnerMaxAssimetry then -- there's an inbord assimetric thrust, let's compensate InnerMidValue = (Throttle2Now + Throttle3Now)/2 ipc.writeSW(0x0924, InnerMidValue) ipc.writeSW(0x09BC, InnerMidValue) -- done! end end -- delete this line if reverse throttle compensation is required Throttle1Now = ipc.readSW(0x088C) Throttle2Now = ipc.readSW(0x0924) if (Throttle1Now > 0) and (Throttle2Now > 0) then -- delete this line if reverse throttle compensation is required if math.abs(Throttle1Now - Throttle2Now) < LeftMaxAssimetry then -- there's assimetric thrust on left engines, let's compensate LeftMidValue = (Throttle1Now + Throttle2Now)/2 ipc.writeSW(0x088C, LeftMidValue) ipc.writeSW(0x0924, LeftMidValue) -- done! end end -- delete this line if reverse throttle compensation is required Throttle4Now = ipc.readSW(0x0A54) Throttle3Now = ipc.readSW(0x09BC) if (Throttle4Now > 0) and (Throttle3Now > 0) then -- delete this line if reverse throttle compensation is required if math.abs(Throttle4Now - Throttle3Now) < RightMaxAssimetry then -- there's assimetric thrust on right engines, let's compensate RightMidValue = (Throttle4Now + Throttle3Now)/2 ipc.writeSW(0x0A54, RightMidValue) ipc.writeSW(0x09BC, RightMidValue) -- done! end end -- delete this line if reverse throttle compensation is required end -- by Muas, November 2009 Save this file and name it Sync 4 Throttle.lua. Put it in the Modules folder, run FSX and assign a keybord key to run this file on the FSUIPC interface. Also assing a key to kill it. Then test it, and set the maximum allowed thrust values to taste. Tests on the default FSX Boeing 747-400 showed excellent results. Please report back how it went.
  9. Hi everyone. The FSUIPC Sync Pos feature does well with throttle, pitch and mixture lever line up. However, I tried a LUA approach to compensate thrust assimetry, and it works very well too. Here's the code for twin engined aircraft - it easily can be adapted to four engined aircraft, and also for pitch and mixture. ------------------------------------------------------- -- FSX Lua plug-in for thrust assimetry compensation -- ------------------------------------------------------- -- [[Thrust assimetry compensation for twin engine aircraft. In this method, assimetric thrust is compensated by adding half of the detected assimetry to each engine throttle.]] -- MaxAssimetry = 1024 -- maximum thrust assimetry allowed while 1 do ipc.sleep(500) -- do nothing for half a second Throttle1Now = ipc.readSW(0x088C) Throttle2Now = ipc.readSW(0x0924) if math.abs(Throttle1Now - Throttle2Now) < MaxAssimetry then -- there's an assimetric thrust, let's compensate MidValue = (Throttle1Now + Throttle2Now)/2 ipc.writeSW(0x088C, MidValue) ipc.writeSW(0x0924, MidValue) -- done! end end -- by Muas, November 2009 The maximum assimetry value can be preset to taste. Both throttle levers work well on their own; it's when they are pushed together that this plugin will get them lined up. Compensated thrust is then set to the mid value between Throttle 1 and Throttle 2, unlike Sync Pos which line them up according to Throttle 1 value. Save this file and name it Sync 2 Throttle.lua. Put it in the Modules folder, run FSX and assign a keybord key to run this file on the FSUIPC interface. Also assing a key to kill it. Then test it, and set the maximum allowed thrust values to taste. Tests on the default FSX Boeing 737-800 showed excellent results. Hope it might be usefull.
  10. I'd follow the original FSUIPC ini file structure, including a common LUA section to list every threads to run everytime FS is "ready to fly", and specific LUA sections for each aircraft which would be started "on specific aircraft load". Could you make it check if the loading aircraft is the same as the previous, in which case nothing should be done, and specific aircraft threads should continue running... ...if the aircraft "on load" is different from the previous (aircraft changed), then it should kill all specific threads, and start the new aircraft ones according to the ini file - the common threads would still be kept running though.This is my thinking, hope it helps.
  11. Here's the code with the rejected take-off amended - works a charm! -------------------------------------------------------------------- -- FSX Lua plug-in for Project Fokker F-100 liftdumpers operation -- -------------------------------------------------------------------- PrevThrottle = 0 ThrottleThreshold = 128 -- nominal positive throttle value while 1 do ipc.sleep(500) -- do nothing for half a second ThrottleNow = ipc.readSW(0x088C) if ipc.readUW(0x0366) ~= 0 then -- we are on the ground -- 1: liftdumpers retraction on power up -- see if throttle has just gone over threshold if (PrevThrottle < ThrottleThreshold) and (ThrottleNow > ThrottleThreshold) and (ipc.readDBL(0x2A48) ~= 0) then -- left wing fold is non-zero, liftdumpers are extended ipc.control(66390) -- Toggle Wing Fold to retract liftdumpers end -- 2: liftdumpers extension on rejected take-off -- see if IAS has reached 80 kts if ipc.readSW(0x02BC) > 80 * 128 then -- we are over 80 kts -- see if throttle has been cut to idle if (PrevThrottle > ThrottleNow) and (ThrottleNow < ThrottleThreshold) and (ipc.readDBL(0x2A48) == 0) then -- left wing fold is zero, liftdumpers are retracted ipc.control(66390) -- Toggle Wing Fold to extend liftdumpers end end end PrevThrottle = ThrottleNow end Now about the aircraft dependable plug-in... Keep the good work.
  12. Great! Your code works as should. No further edits were necessary. Thanks a lot. As I mentioned, the lifdumpers on the Project Fokker F100 are deployed using the assigned TOGGLE_WING_FOLD event key. As it was programmed, I believed this had only one condiction to follow which is the "aicraft on ground" condition, so the assigned key works as an "arm" button when the aircraft is flying. With the lua plug-in you wrote, this works as it should on landing, being that, when previously armed, the liftdumpers extend upon touchdown and retract when a small thrust amount is applied, say, for taxi. Ok, good job. Now to be accurate, this system should also be deployed on rejected take off, where liftdumpers would extend when speed was once greater than 80kts and throttle retarded to idle. For this to work, we need to "arm" the liftdumpers on ground - and they should not extend this time - and then they must extend if the "speed greater than 80kts and throttle retarded" event occurs, if not, they should be automatcly disarmed upon lift off. This is as closer as it gets to the real life F100 (there is also a manual extension based on thrust reversal, if system was not armed). I'd appreciate if you could help me develop this liftdumpers system a bit further. Now, as an "ipcReady.lua" named file, it will be running when FS is "ready to fly", even if I'm not flying the F100. I don't have any wing folding aircraft installed anyway, but I'd prefer this solution could be aircraft assignable - if at all possible? Thanks again.
  13. Again, it works 100%. Thanks. One more, if I may... I have this old Project Fokker F100 installed on FSX and it works ok, except the liftdumpers which should "close" when thrust is applied on ground - there was an old gauge that made that happen but it doesn't work on FSX anymore. These liftdumpers are set by the TOGGLE_WING_FOLD event. What I'm asking is if its possible to toggle the wingfold automaticly to the "off" position by opening the throttle on ground. That should be dependant on the "on ground" and "throttle >0" conditions, and we can read the wingfold state using the FOLDING WING LEFT/RIGHT PERCENT variable, but is it possible to implement this with FSPUIC?
  14. I'm so happy about this possibility, I wonder if it's possible to use these kind of FSUIPC features to other "toggle only" commands like Parking Brakes, etc, making them ON/OFF's, even those ingame 6***** offsets?
  15. Hi Pete and hi everyone. I believe this must have been discussed before, specially between pit builders, but still I didn't find an answer, so: I use a cockpit console with button, rotary and toggle switches (MJoy16 card) and I'd like to have separate on/off switches for NAV LIGHTS and BEACON LIGHTS. As we know FSX only provide toggle support for these functions. Anyway, studing the FSX SDK, I realized there are ways to get these light states from the sim, so I think one could easily program a script to get ON/OFF facility for these light switches. This could be something like: Is NAV LIGHTS on? If YES, get JOY1 BUTTON31 to TOGGLE NAV LIGHTS; if NO, get JOY1 BUTTON32 to TOGGLE NAV LIGHTS. Joy1 buttons 31 and 32 would be connected to each side of a mini toggle switch on a cockpit panel. Now could this solution be implemented on FSUIPC? Or, what kind of script should be made for this? Lua? Via simconnect? Thanks.
  16. Pete, sorry for all this mess, I sent you my last (I hope) ini file just to check if that is the more efficient way of setting axes through FSUIPC. Beacause its more reliable on my analogue swithch arrangment, thats all. I tested it using the detents calibration facility, but it didn't work consistenly. As I told before, its a 4 position switch, not a real axis lever (a Telecaster switch - ironicaly in the fifties electric guitar parts came from post-war spares from the aviation industry, now I'm using one of those in my pit :wink:). As for a jet liner I agree the detents calibration facility is the most efficient way to do it, and I got set that way for specific aircraft like the 737. Your're right, I corrected that for 128, thats the minimum value my axes read. Well, I'm kinda use to it - I have no such a lever for the parking brake, an a on/off switch doesn't seem right, and it helps for that short runway take-offs, where you apply full power with parking brakes on an then release it without taking hand off yoke, just a by depressing it. No such a big deal, and it works perfectly. That wasn't clear for me. Now I've got them all set through FSUIPC calibration. Using all axes through FSUIPC calibration does seem to solve the problem - on flight start, trim axes are in neutral position now :D Cheers.
  17. Pete, I sent you my old ini file, and a new one after configuring FSUIPC all over again. Things look much stable now, there seems to be no conflict between axes, but, after an aircraft change, the aileron and rudder trims appear full deflected... after a little touch on their axes controls they wake up and return to neutral position - needless to say this is terrible in a "start on air" flight. Maybe its because I set wide deadzones on them, they were a bit spiky... but no, when I restart on the same aircraft this doesn't occur - gotta be another reason.
  18. Option 1 and 2 are out - I'm not using them. As I said at the end of my last post, I cleared all the ingame FSX axes assignments. I'm using FSUIPC to config them all, mostly options 3 and 5, I didn't realize option 4 was possible at all?!? I really wished that was possible, but I thought it wasn't. I'm also using option 6 for the analogue flap switch lever, but I allocated the flap axis too, together with send controls upon ranges - maybe this causes the conflict. Sorry for all this misjudgement, maybe it isn't all so clear in the manual, or maybe it's my fault. I know exaclty what I want, and now I think I know how to set it. I'll clear all the axes assignments and start from scratch with a generic set up, and then I'll check for conficts. Meanwhile I'll save the current ini and send it to you. Regards.
  19. Aileron and rudder go directly to FS; elevator goes to FSUIPC calibration to get a smoother curve output. Flaps goes directly tp FS using detents set by "send control" options. It's controlled by a four position lever switch using resistors. I set data intervals for each position. This is the generic configuration. Then I have specific config for 737, where flaps detents are set through FSUIPC calibration, and is controlled by a quadrant style lever axis. The prop ac flap lever is disabled for this config. The RAW option appears checked and greyed out for flaps (I cannot uncheck it) when using the generic config; thus initialy always displays RAW values. I really don't believe this is about bad connections; I tested the other way round, the quadrant lever axis setting the detents on "send control" (directly to FS) and the trim axis interference happened that way too. Generic config - non aircraft specific, I use it for piston/turboprop ac: Aileron directly to FS (yoke) Rudder directly to FS (pedals) Elevator through FSUIPC with a smooth curve output set (yoke); parking brakes on when full forward set on "send control" Throttle through FSUIPC calibrated -16384 to +16384 linear (quadrant), if I get it directly to FS it gets output 0 to +16384, thus working mid travel only Prop pitch through FSUIPC calibrated -16384 to +16384 linear (quadrant), just like thrust for the same reason Mixture through FSUIPC calibrated -16384 to +16384 linear (quadrant), just like thrust for the same reason Flaps directly to FS using "Flap detent set" and detents set on "send control" (4 pos lever switch sending raw data) Diferential brakes directly to FS (pedals) Aileron trim through FSUIPC with a smooth curve output set (thumb wheel) Rudder trim through FSUIPC with a smooth curve output set (knob wheel) Elevator trim through FSUIPC with a smooth curve output set (thumb wheel) Specific config for stock 737 (aircraft check): Aileron directly to FS (yoke) Rudder directly to FS (pedals) Elevator through FSUIPC with a smooth curve output set (yoke); parking brakes on when full forward set on "send control" Throttle through FSUIPC calibrated -16384 to +16384 linear (quadrant), if I get it directly to FS it gets output 0 to +16384, thus working mid travel only Spoiler directly to FS with up position "arm off" set on "send control" (quadrant) Flaps through FSUIPC with 8 detents set on calibration facilities (quadrant) Diferential brakes directly to FS (pedals) Aileron trim through FSUIPC with a smooth curve output set (thumb wheel) Rudder trim through FSUIPC with a smooth curve output set (knob wheel) Elevator trim through FSUIPC with a smooth curve output set (thumb wheel) All axes disabled on FSX settings interface; sensivity mode off set on fsx.cfg As far as I remember the flaps/trims interfere only when using the generic config; but its not control related, because I tested it changing lever controls. Off town tonight. I'll send it on Friday.
  20. The ones before were preceded, in the SimConnect log, with data corruption in the Axis events being sent. In 4.291 and after there are no Axis Events being sent for axes sent "Direct to FSUIPC calibration", and there cannot be corruption in data which doesn't exist. So to investigate further, to see if it was Simconnect related, I'd need to see the SimConnect log. It does actually sound as if your crash is not the one others have been suffering at all, and is therefore probably not related to axis assignments at all. There's is no way in FSUIPC itself that any such cross-interference could occur. That sounds very much like FSX has picked up its own assignments (again). This can happen quite easily if you ever unplug and re-plug in any controllers. And fully-deflected axes tend to arise from a bad connections, which can look to the Windows drivers like a fully deflected lever. This used to be a common occurrence in the Game Port days. Regards Pete Well, crashes seem to be gone now - only had that one on 4.291 - it didn't happen anymore. I'm still concerned about these trim/flap axes problem, cause it's still happening. I have flaps direct to FS, with 4 detents set at given ranges; elevator, aillerons and rudder trims go through FSUIPC for calibration. and strange thing is these usually show raw data -512 to 495 values, and after sometime they revert to -16384/+16384 range. When flight starts things seem to be alright everthing working as should, after sometime all trims fully deflect or flaps stop working. Very annoying. If there's anything I can log to sort this out, I'd be happy to.
  21. After some time spent on configuring and recalibrating axes on FSUIPC4291 (and some flying in between) I got one crash, exactly like the ones before. Also it seems that trim axes are interfering with flaps axes, sometimes I get the flaps dead, and trim axes one side full deflected, all three of them. All of these when sending axes directly to FSUIPC calibration. I couldn't replicate either issue of the above, there's no consistency. I'll try FSUIPC4294 tomorrow and see how it goes.
  22. I'll be glad to do that, but not until next saturday.
  23. To me, it is allways the same situation: the image freezes with the mouse pointer turning to hour-glass, the sound continues for a bit, then sound goes out, after one or two minutes the prompt box appears. I call it a hang, because I could restart FSX right after that, it did not crash the system. But this always happened like this to me. I said it happens on missions, but they were indeed free flight missions, cause these are the ones I mostly use, specially when configuring settings, but it happens on scripted missions too (abl), I tried them too. It's all I can tell by now.
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use. Guidelines Privacy Policy We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.