Jump to content
The simFlight Network Forums

Pete Dowson

Moderators
  • Posts

    38,265
  • Joined

  • Days Won

    170

Everything posted by Pete Dowson

  1. I've no idea what you mean by "latest" or "original" at all! You need to provide actual VERSION NUMBERS! That's what they are for, so I can understand what on Earth it is you are trying to say. Additionally, for your information, there is nothing in FSUIPC which can affect any aircraft's autopilot, unless those aircraft aren't actually using FSUIPC. And for FSX very few add-on aircraft use FSUIPC for anything. I think that you've made some other changes and are blaming FSUIPC, as of course so many others do, as the "universal scapegoat" it has been for 14 years. Please calm down, think about what you are saying. and provide some actual details -- like exact version numbers, exact settings, lists of add-ons, versions of Windows, etc etc. I can'tt help with wild unspecific generalisations. Pete
  2. That's not an issue, let alone the "same issue"! That's how it works, the way Microsoft implemented the facility in FSX for add-ons to utilise modal dialogues (modal = stops the main program running). In all the five+ years that FSX has been like this, no one has found this to be a problem. It is just the way things were implemented by Microsoft. Regards Pete
  3. Can you tell me exactly what version of FSUIPC4 it is you have installed? Unfortunately the error report you provided states: Fault Module Name: FSUIPC4.dll_unloaded Fault Module Version: 0.0.0.0 Why it cannot get the proper version number I've no idea. No do I know why it appends "_unloaded" tp the name. That's weird. If you are not using version 4.758, please download it and install it from the Download Links subforum. I need you to be using the same version as I so that this information: Exception Offset: 6107c3ca Exception Code: c0000005 Exception Data: 00000008 can relate directly to the code I have. If you are already using 4.756 or 4.757 that offset appears to be within the VRI code. Are you using VRI devices? Please paste in your FSUIPC4.IBI file so I can see. The most worrying thing about your report is this: Application Name: fsx.exe Application Version: 10.0.60905.0 which shows you are still using the original bug-ridden release version of FSX. I'm not sure I can guarantee anything unless you update. You should be at least using FSX updated to SP1 level, and applying both SP1 and SP2 woould be best. Each update fixed many problems in FSX, and improved the performance of internally connecting Simconnect applications like FSUIPC no end. Regards Pete
  4. I don'y know whether they'll run on the same PC, because FS will be running on it as well. That's a question for the support forum of those packages. But if you mean using FS on computers A and C linked by WidevieW, and your external gauges on computer B, then there should be no problem. If you want the same performance on both A and C, so one doesn't appear jerkier than the other. Both need to be up to whatever standard you need to run FS flently. However, computer A also has the TRC cockpit to support, so I'd guess it would need to be the better of the two. But this is more a guess. I don't know TRC and I don't use WidevieW. Maybe your question would be better addressed to the latter's suppoty forum? Regards Pete
  5. It looks like the connection is being stopped by a firewall, probably at the Server end. Here's what Microsoft's reference says about that error 10060: 10060 Connection timed out. A connection attempt failed because the connected party did not properly respond after a period of time, or the established connection failed because the connected host has failed to respond. The Server log shows that no message ever got through for it to respond to. Regards Pete
  6. So, let me get this right, when you reload FSX, one time in three, approx, the assignments are all different? how many more reloads does it take till they go back again -- I think you mentioned only two different configurations. You DELETED assignments? You've not actually DISABLED the controllers? I think you need to re-check. Fs has a habit of reassigning. You said You don't say what from, only what to. And joysticks don't normally have only one axis each, so something needs clarifying. If it is consistent, state exactly what assinment changes into what other assignment, show me the axis assignments in FSUIPC .INI (the[ Axes] section). And check your assignments in FSX. It sounds very much like an FSX/FSUIPC conflict. FSUIPC cannot "invent" different assignments. It will be obeying what you've set, and so will FSX -- together! Pete
  7. No idea why that should be. Did you not try my suggestions which I think would be much more reliable? Regards Pete
  8. No, it isn't. It is a problem with FSCopilot, as indicated in the error log report: Fault Module Name: FSCopilot.dll_unloaded Try without FSCopilot, or uninstall and reinstall that. Regards Pete
  9. Is this with FS being reloaded between flights? Does it happen during a flight or only on loading a new one, or changing aircraft? It sounds very much like you either have dual assignments (whether in FSUIPC or in both FSUIPC and FSX), or, if it is only when loading a flight or aircraft, you have different assignments for different aircraft and this is what is changing them. First, if you ARE assigning everything in FSUIPC, make sure the controllers are all disabled in FS. If you've unplugged any and reconnected them, FS will often pick up control again. Second, if you are likely to unplug and replug devices, you should ensure your FSUIPC install is configured to use joystick lettering so that assignments don't get switched around. There's a chapter about joystick letters in the User Guide (see the contents list). Finally, if it is a problem with aircraft specific or multiple assignments, check the FSUIPC INI file. If you want help with that you'll need to paste it all in to a message here, but if you do that please relate details -- i.e. specific aircraft names and axes which 'switched'. You didn't say which version of FSUIPC you are using, but it it isn't the latest (4.756 or 4.757) please update -- see the Download Links subforum here. Regards Pete
  10. It certainly sounds like there's some sort of disconnection glitch which is causing this -- maybe wiring or maybe something in the unit itself. The symptoms you describe are exactly what you'd get if you pulled the USB plug out and plugged it in again. FS wouldn't recover from that without reloading. FSUIPC does rescan for new connections when you go into its options. Regards Pete
  11. You'd need to load an aircraft which is not already assigned to a Profile. Currently there's no way of removing an aircraft from a Profile assignment without editing the INI file. I might consider a way of doing that for a future release, but meanwhile, just load the FSUIPC INI file into an editor (like notepad) -- you'll find the file in the FS modules folder -- then find the [Profile ....] section listing your aircraft name below it, and delete the line containing the name. Regards Pete
  12. Ah, but that appears to have screens for those integrated instruments, so i assume they are either additional screens on the same PC as FS, or the system comes already equipeed with the other computers needed. That doesn't seem to mesh correctly with the OP's item 1: Regards Pete
  13. What software are you planning to purchase for this? I know Project Magenta, but there are several others - Sim-Avionics, Flight Deck Software, ProSim737, FSXpand and Aerosoft (Australia). Which one you choose would depend on your budget and the aircraft type you mainly want to simulate. Ah. That's different. You'd need each computer to be up to the same standard and all running FS, linked by something like WidevieW. I don't know if you can get such add-on gauges. I have the AofA indication on the Project Magenta PFD and the trim settings on an optional EICAS screen. (I fly a 738). I'm not aware of an accelerometer gauge. You need to investigate WidevieW to start with. It isn't my program. Nothing I support here really has very much to do with what you want to do. Regards Pete
  14. I managed to make it go wrong by trying to trigger the action (pressing the keys on the server) before the sounds etc had finished. The problem then is that the event for the offset never triggers because by the time the Lua plug-in has finished, the offset is 1 again -- no change from last time. Once it is tested as being 1 twice it can never re-trigger the offset event, so your routine can never reset it to 0. The whole idea is really rather frail when you think about it. I think that rather than test for 1 and reset to 0 you should simply increment the offset, and act on any value once it changes. The only problem then is that it will be triggered initially without you doing anything on the server. The way around that is to do this: firsttime = 1 function SOS() if firsttime == 0 then .... all your actions (no need to test 'value') end firsttime = 0 end[/CODE] BTW, additionally, when you read an offset for the first time in a client, there could be up to 500 mSecs delay whilst the client asks the server for it. Thereafter it is very fast -- the server simply keeps the client up to date. Some of your apparent ground reading problems may have been due to this delay. You can get around this by deliberately reading any offsets you want at the start, ignoring the values. i.e. add ipc.readUW(0x366) to Aiuto=0 and firsttime=1 at the beginning. Try it. Use "offset ubyte increment" with a parameter of 1 and your offset as needed. This is just to make it change. It doesn't matter about the actual value of course. Regards Pete
  15. I don't know what is going on with your system. I don't have your sound or your macros, so I adapted your Lua. I have this: Aiuto=0 -------------------------------------------------------------------------------------------- function SOS(offset,value) if value == 1 then ipc.writeUB(0x66c5,0) sound.play("d:\\fsx\\sound\\geardown.wav") ipc.sleep(50) sound.play("d:\\fsx\\sound\\gearup.wav") ipc.sleep(50) sound.play("d:\\fsx\\sound\\geardown.wav") ipc.sleep(100) gnd=ipc.readUW(0x366) ipc.log("gnd = " .. gnd) if Aiuto == 0 then sound.play("d:\\fsx\\sound\\gearwarn.wav") Aiuto=1 ipc.macro("wilcoseat:ON") return end if Aiuto == 1 and gnd == 0 then sound.play("d:\\fsx\\sound\\GPWS_sink_rate.wav") ipc.macro("wilcoseat:ON") end if Aiuto == 1 and gnd == 1 then ipc.macro("wilcoseat:OFF") NoAmbience=1 sound.play("d:\\fsx\\sound\\GPWS_pull_up.wav") ipc.keypress(69,1) sound.play("d:\\fsx\\sound\\GPWS_Dont_sink.wav") end end end ------------------------------------------------------------------------------------------- event.offset(0x66c5,"UB","SOS")[/CODE] The macro calls in this won't actually do anything, but the sounds I substituyed are from an FSX installation on my client. I added a log for "gnd" to make sure that was seen (it s -- see log below). On my server I assigned "TAB+S" to set 66C5 to 1, like this: 38=83,24,x010066C5,x01 Then, when I press TAB+S I get this log in FSUIPC: [CODE] 820766 KEYDOWN: VK=9, Waiting=0, Repeat=N, Shifts=16 820766 .. Key not programmed -- passed on to FS 821141 KEYDOWN: VK=83, Waiting=0, Repeat=N, Shifts=16 821141 IPC Offsets Control: Ctrl=x0100, Length=1, Offset=66C5, Param=x1 821141 .. This key is programmed in FSUIPC4 'Keys' options 821172 Monitor IPC:66C5 (U8) = 1 821250 KEYUP: VK=9, Waiting=0 821297 Monitor IPC:66C5 (U8) = 0 821297 KEYUP: VK=83, Waiting=0[/CODE] and the assorted sounds play (the geardown/gearup/geardown\gearwarn ones more or less play al at once since the 50 msec sleep is so short compared to their length). On the next time I press TAB+S, the same initial sounds occur but with "pull up" and "dont sink" also played simultaneously. Every time after that it's the same, of course, because your code never resets Aiuto to 0. Here's the log form the Lua program on the Client:from several separate loads: [CODE]********* LUA: "test" Log [from WideClient] ********* Date (dmy): 14/01/12, Time 00:19:29.437: Client name is FSXBEAST 784313 LUA: beginning "D:\WideClient\test.lua" 820407 LUA: gnd = 1 1227657 LUA: gnd = 1 1253094 LUA: gnd = 1 1384750 LUA: ended "D:\WideClient\test.lua" ********* LUA execution terminated: Log Closed ********* ********* LUA: "test" Log [from WideClient] ********* Date (dmy): 14/01/12, Time 00:29:29.921: Client name is FSXBEAST 1384797 LUA: beginning "D:\WideClient\test.lua" 1406860 LUA: gnd = 1 1510813 LUA: gnd = 1 1570344 LUA: ended "D:\WideClient\test.lua" ********* LUA execution terminated: Log Closed ********* ********* LUA: "test" Log [from WideClient] ********* Date (dmy): 14/01/12, Time 00:32:35.515: Client name is FSXBEAST 1570391 LUA: beginning "D:\WideClient\test.lua" 1574219 LUA: gnd = 1 1584907 LUA: gnd = 1[/CODE] At no time did anything go wrong. It is 100% consistently working! All this stuff is rock solid in many applications I have in my own cockpit, which uses 8 client PCs and lots of little plug-ins all over. i really don't understand what is going on on your setup. BTW, you Lua script contains the line "NoAmbience=1" which doesn't appear to relate to anything else at all. Sorry, I've no idea. I think you should do two things: 1. Add logging to each path through your Lua, ipc.log("message") to tell you it's been through that path. You can log variables, as I did for 'gnd': ipc.log("gnd = " .. gnd) Also, add logging in your WideClient.INI file. I assume you ARE using WideClient version 6.90? Please double check -- look in its log. set Log=Yes in the [user] section of the INI -- it will log all offset reads and writes. Regards Pete
  16. I don't know of any reason why not, and unfortunately I don't have enough information to determine what is happening. However, SP2 does fix a lot of bugs in FSX and it may actually be some other interaction going on. There's really no way of telling unless I'd be able to reproduce it.. You said "FSUIPC4 works just fine on my Windows7 computer." -- was the FSX version on that updated to SP2? Regards Pete
  17. If you did not re-install Windows there's no need to re-register. Just copy the KEY file along with the other files in your FSX Modules folder. Otherwise, to re-register, you must use the exact same name, email and code as originally. If the code is being rejected you are making a mistake in one or more of those three parts. Regards Pete
  18. The log shows a normal FS termination. It shows the default flight being loaded within 4 seconds of FS starting, then a NORMAL closure 10 seconds later. If FS is crashing it seems that it is only doing so after a normal close down, after FSUIPC4 has gone. There's no sign there at all of any other flight being loaded, or any attempt either. It looks like you closed FSX at the initial selection menu. Obviously that won't tell me anything useful. Regards Pete
  19. "Drift" is just an inaccuracy in the pressure reading. I've never seen a value set for it, but it is defined as part of the weather structure. There are better places than those old "adventure" offsets in any case. QFE is the pressure setting for the altimeter (written to 0330) which will make the altimeter read zero at the airfield you set it at -- the "FE" means "field elevation". There's no way you can calculate it without reference to the elevation of the field you are flying from/to. QFE is generally only used for training and practice flights at a single airfield. It is pretty useless for normal operations. Regards Pete
  20. No, obviously not, because you'd only then get multiples of 10 hPAs! Throughout the offsets lists the values are described as what they ARE, not how to convert them to something else. So x*16 means stored in x's units times 16. This method is consistent throughout. I've always thought it much more sesnible to state how things are stored in a storage list not how to handle them when removed. Thae latter depends what you want to do. I assumed you knew that one already because you quoted it in your question. And of course it is in the same units. Regards Pete
  21. I assume you mean the local QNH (pressure at sea level)? That's at offset 0EC6. If, instead, you mean the Transition Altitude (the altitude above which you set 1013 hPA or 29.92") or the Transition Level (the Flight Level below which you set QNH), then that's going to vary according to the local ATC control, and there's nothing in FS which will tell you. You need charts. FS doesn't actually simulate the transponder mode switch at all. That's why there's no offset. If you are flying on-line you use the facilities to communicate that mode to the on-line flight add-on. There's no easy way to test whether the aircraft is on the runway -- you'd need to compare the Lat/Lon coordinates with a database of runways (such as that created by my free MakeRunways program). If his transponder hardware switch is assignable in FSUIPC, assign it to a user offset (one of 66C0-66FF) and test that. Regards Pete
  22. I had wondered when you said what you'd done how it could work. The decoding of simple encoders with only two lines out needs thought, and trying to put it all through a keyboard encoder rather than a joystick button type interface looked a little freaky. All the encoders I've ever used had separate outputs pulsing up and down for each direction, which makes things dead easy. I guess they must be more expensive or more difficult to come across though. For the simpler types, Bob Church summarised it quite nicely, and I'm sure he won't mind me quoting his words here: "Normally the rotary encoders I've seen are set up to overlap the A and B pulses by half a pulse width so the signals are out of phase with each other half the time. A goes high, B goes high half a pulse width later, then A goes low, again half a pulse width after that, and finally B goes low after a fourth half pulse width. If you rotate the other way the edges will reverse order, B will go high first, A second. If you only keep track of the state of A or of B, you can't really tell which way it's rotating. A will always be seen before B and B will always be seen before A. You need to know if A was high or low when B went low, (pick an edge rather than the pulse itself). Then to determine the direction you need to know if the change on one pulse happened before or after the the other pulse. If A falls before B, it's going one way. If B falls before A it's going the other way". Now if you could arrange that via a keyboard interface and still detect the edges by keypress and release type signals, I suppose you could handle it with a Lua plug-in. but there's a lot of Ifs there. Check out the Leo Bodnar website. His cards aren't terribly expensive and are really (really!) easy to use. Regards Pete
  23. I know VSPE works -- it isn't anything to do with FS9 or anything else like that, it simply provides virtual serial ports, so that something like FSUIPC can link to your device as well as the VRi software. That's all VSPE is used for in this context. If you were going to program the MCP completely in FSUIPC you wouldn't use VSPE in any case. Regards Pete
  24. The FSUIPC VRI stuff is the same for both FS9 and FSX. The MCP-Combi is MCP1? I have one of those and an M-Panel. You are thinking about FS compatibility of VRiSim, I assume? But surely the gentleman must have installed and run VRiSim with his MCP before starting on setting things up for FSUIPC? Perhaps he can confirm. I won't have time for this till next week now. He could also check that the FSUIPC part works okay on COM19 by changing the line "1=COM19,COM3" to just "1=COM19". Regards Pete
  25. So I assume, then, that running FSX without Admin mode prevents NGX saving its files and so you don't then get the pause. Hmm. Makes sense I suppose. I would add something if i knew how to explain what to do. How do you do this 'exclusion'? Wouldn't it make more sense in any case, performance-wise, not to have any live automatic virus checking except in downloads, as in email receipts and browsers? I use "AVG Free" and I don't think that does live checks every time a file is created by a program running in your own PC. I'd hate such performance limiters! Regards Pete
×
×
  • 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.