Jump to content
The simFlight Network Forums

Pete Dowson

Moderators
  • Posts

    37,997
  • Joined

  • Last visited

  • Days Won

    158

Everything posted by Pete Dowson

  1. MOVED FROM FAQ REFERENCE SECTION! Please never post support requests into reference subforums. They are clearly marked "not for support"! That makes no sense. It either interfaces to SimConnect, or to FSUIPC. Both are interfaces to FSX. As far as I know, nothing by CPFlight uses FSUIPC. If it does use FSUIPC, then with FSX running in Admin Mode, so much all the software wanting to talk to FSUIPC. If you think it is supposed to work through FSUIPC, then please show me the FSUIPC4.LOG. Pete
  2. I'm afraid I know nothing at all about MOBIFLIGHT. That sounds like that particular aircraft does its own thing, ignoring the built-in FS spoiler logic. No. That cannot be if the FS spoiler logic is used. To start with, if you try to test on the ground then as soon as the value 4800 is passed the spoiler will fully deploy, just as they would when you land with armed spoilers. All that is different for spoilers compared to other flight controls is that the range 0 to 4799 does nothing. Note that even with your raw axis values you can calibrate spoilers in FSUIPC by writing the value to 3BB2 (or in fact any of the offsets 3BA8 to 3BC4). Then FSUIPC will detect is as if it was a USB joystick interface, allowing you to calibrate it properly. Then you wouldn't need your formula. However, it sounds like that aircraft takes no notice of the FS spoiler. You need to find out (from documentation of the author) what you can use. Maybe you need to assign it directly to Axis_Spoiler_Set and not calibrate. That would deal with it assuming the aircraft logic traps the control directly, but then you'll need your formula applied. Pete
  3. FSUIPC7 should run automatically when you run MSFS, so try starting MSFS instead of FSUIPC7. Pete
  4. You mean not writing to the offset 0330, I assume. It's got to be that the STD button in that aircraft is not doing what it should. You need to get the author to fix it, I can't. Ah! that's "Set standard altimeter" -- I wouldn't recognise it as "Q1013". So you need to ask FSLabs what is going on. Note that neither PMDG nor FSLabs aircraft use or depend on FSUIPC. They'll be setting the pressure value via SimConnect -- or should be, at least. FSUIPC interfaces to SimConnect to read the value and populate offset 0330. Pete
  5. You simply use the function to PRESS the key(s), then use ipc.sleep for whatever time you want, then use the function again to RELEASE the key(s). Sorry, but I thought that didn't need explaining. 😞 Pete
  6. You need to Monitor offset 0330 (FSUIPC Logging Tab, right-hand side, offset 0330 type U16. For 1013 that will read 1013x16 = 16208, or if it sets it more accurately (1013.25) then 16212. check the option below to write it to the log. If your STD button is not writing this value then that will explain your problem. Sorry, you need to explain that. "Q1013" isn't a control recognised by FSUIPC. Pete
  7. In the lua library document, look at the entry just below ipc.keypress, called ipc.keypressplus. With that you can hold the keypress as long as you wish. Pete
  8. That's normally done by calibrating the spoiler axis. Isn't your potentiometer seen as a joystick axis? If not, how are you reading it? The 4800 value for "arm" is a built-in FS/P3D value. You'd normally calibrate a region of the axis movement so that you can guarantee to set ARM when the lever is in the ARM detente. I don't understand how your formula relates to the potentiometer input. What values do you get from that? If you are writing to 0BDC for flaps then one would expect Aerosoft to respect 0BD0 for the spoilers. If not, what are you supposed to use? Pete
  9. Yes, as normal. The STD pressure, 1013, is set by the aircraft panel, not the other way round. The Kollsman value is held as hPa x 16 in offset 0330 (an unsigned 16-bit word). That sounds rather cock-eyed. The aircraft panel should set 1013 to the offset when STD is pressed. And if it is using Flight Levels if the pressure read is 1013, it will be wrong when that is the true value but you are not above the transition altitude. It is always up to the aircraft programming to set STD mode. It is never automatic in the Sim, as it doesn't know the local TA. It is only changed by the cockpit panel. You adjust it using a dial for the true current pressure which you get from ATIS or from ATC, or by pressing STD to go to Flight Levels. Neither FSUIPC nor the Sim changes it without the correct input. There's also a separately set Kollsman value for the G1000 if that is installed. That's at offset 0332. The behaviour is the same. Pete
  10. I don't know about the limiter in NVI. My frame rate 'limiter' is VSync set in P3d. The FR Limit is set to infinity. I can get 25fps pretty consistently (mainly by limiting the AI Traffic with a frame-rate controlled lower limit in FSUIPC. So I set both Projectors to 25Hz refresh rate with VS on in P3D. With a single P3D screen I think the frame rate control in RTSS does well. There you can set a limit using a divisor of the sync rate. Unfortunately it doesn't work properly with more than the one screen. If you can identify exactly what FSUIPC requests are taking so long then John or I could have a look as see if there is a reason other than lack of processing time. Pete
  11. There are two possibilities I can think of: 1. You have made a request via FSUIPC which involves FSUIPC asking FS for something and waiting for the result. Typical would be reading L:Vars, as an example. 2. The high (unlimited?) frame rates being allowed in the simulator are precluding sufficient time for other interfacing applications. This would typically be occasional, not constant. Best always to advise users to limit frame rates (either directly by the FR limiter, or via VSync), to something just below the average attained. Without knowing more about exactly which requests are timing out I can't really help further. You should also state the versions of both FSUIPC and FS/P3D. Pete
  12. Please also supply the actual Lua file. How can we possibly help otherwise? For instance, what is on line 92, as that is where the error is. It looks like a bad character somewhere. I can check the file (view it in Hexadecimal) if you attach it. I can't help blind. Pete
  13. Sorry, but I don't think there is a way for mouse macros to work with XML gauges in FSX or P3D1-3. They do work in all gauges in P3D4 and 5 because L-M implemented the facility for them internally, in the PDK. Pete
  14. Re-programmed in FSUIPC or FSX? FSUIPC doesn't "lose" settings, but there are several reasons why a joystick ID might change. If you are using the facility to use Letters instead of Numbers for IDs then FSUIPC can usually deal with that automatically. Anyway, next time there's a problem check the Event Viewer for both or either of FSUIPC and FSX crashing (one might lead to the other), and supply your FSUIPC4.INI file as well as the FSUIPC4.LOG for the crash. Pete
  15. The Log you attached shows a successful close-down, not a crash. This was after a session of 1hr57mins. The only odd thing in the Log is the hige number of stoppages in the first 46 minutes, before you loaded a flight from RJAF to RJNH using the SOAR DG8085. Without a log from a session which crashed I can't really help. You also need to state what add-ons you were using at the time of the crash. I think it is most likely to be down to one of those. Perhaps you can remember what you changed before FSX started crashing. I assume it wasn't always crashing before you changed something? Pete
  16. There is one other thought I've had. The limit of 127 Lua files in the Modules folder is only because in the assignments encoding only 7 bits are available to encode the Lua index from the [LuaFiles] list. Those you are starting without assignment don't need to be indexed, so aren't confined to 127. By placing them all in the Modules folder you should be able to use LuaKill via the 0D70 method (though I've not tried that). Pete
  17. I'm not sure that the whole pathname is needed for LuaKill. It isn't as if it needed to locate it on disk. Try it just with the Lua name only. Pete
  18. There's no rule stating that you can only open one COM device per plug-in. Just use different handles. Pete
  19. You posted a P3D question in the subforum for FSUIPC7 in MSFS. I've moved it for you. Please always check where you are when posting a support question. I don't know how the registry has become so messy, but the first thing to try is to renumber the #4 item which has been seen. i.e. change these lines in the INI file 4=Saitek Pro Flight Rudder Pedals 4.GUID={419BB610-5786-11EB-8017-444553540000} to the next available ID: 6=Saitek Pro Flight Rudder Pedals 6.GUID={419BB610-5786-11EB-8017-444553540000} FSUIPC will then try to correct the registry. You may need to start P3D more than once for this to take effect properly. Another way, before resorting to Registry editing, is to use the JoyIDs utility to change the duplicated ID. see https://theairtacticalassaultgroup.com/forum/showthread.php?t=13009 Pete
  20. I don't understand why you need so many separate plug-ins, all in their own threads, for the same aircraft. Better with a single Lua per aircraft, loaded via [Auto.<profile>] statements. /that /Panels one is an easy exampe -- why not sort out the panel windows as the first action in such a plug-in? Sorry, I plead memory loss through old age. Roman's ideas look good too. Pete
  21. I cannot imagine a scenario where so many Lua plug-ins are required. It sounds like you have separate plug-ins for lots of little things which would be more efficiently dealt with in fewer larger ones. Can you explain what sorts of functions these >127 plug-ins are actually performing? I'm actually surprised that works. There was no designed intention of allowing plug-ins to be run from other folders. No, sorry. At least not easily. You'd need to build the termination into the plug-in's code, with it instigated by an event on a key or button press. I would seriously look at rationalising the way you have coded the plug-ins so that their numbers can be substantially reduced. Pete
  22. Assignments in the FSUIPC INI file can be to Key presses or Controls. To differentiate between those they are preceded (not followed by) a K or a C. But that is nothing to do with the Lua library functions like ipc.keypress and ipc.control, where the parameters are numbers and there's no danger of confusion in any case. Glad it is working for you. Pete
  23. Actually this is one case where using a timer event to do the AGL calculation at intervals (eg one a second should be enough) would be better, because otherwise you'll either get almost continuous events, or actually completely miss the trigger altitude if the ground is rising rather than the aircraft descending. So, something like aglhigh = false function checkAGL() ground = ipc.readSW(0x0B4C) altitude = ipc.readSW(0x0574) agl = (altitude - ground) * 3.142 -- convert to feet if agl > 550 then aglhigh = true elseif agl < 450 and aglhigh then aglhigh = false --SEND KEYSTROKE OR CONTROL HERE: -- ipc.keypress(keycode, shifts) -- ipc.control(control number) end end event.timer(1000, "checkAGL") You'll need to fill in the action to be taken, where I've said. I've allowed 50 feet either side of 500 feet to avoid unnecessary repetitions with an uneven descent. I've not tested this, but it should be okay. 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.