Jump to content
The simFlight Network Forums

Pete Dowson

Moderators
  • Posts

    38,265
  • Joined

  • Days Won

    170

Everything posted by Pete Dowson

  1. That presumably is an assignment in MSFS, not FSUIPC. Certainly the Delta in FSUIPC is a fixed value unless you specifically edit the actual number in the FSUIPC Assignments tab. John can check your FSUIPC INI file (ZIP it if it is too big) but do NOT have the same axes assigned in both MSFS and FSUIPC. They will conflict. Pete
  2. They are just hexadecimal numbers, so you could also use Vendor = 0x04D8 Product = 0x8A3D but the string versions of those should work. I assume you have checked those values in the FSUIPC log file where the devices are logged? Is the Lua plug-in being run? How are you starting it? Yes, but you may want to adjust the timing and poll rate to suit the device and your needs. Check the comments in the plug-in. Pete
  3. I've no idea what SPB files are. You don't get them saved for normal flights. Are they only to do with missions? The ones on my system have titles like "A320_Landing_edition",. and all to do with the A320 and varying from 4k (the A320_Landing_edition one) to 40k (A320TakeOff). But there's also "AirlineICAOCodes" (262 kb) and "Alaska" (34kb). Looking at my other Sims they appear in FSX and FSX-SE as well and seem to be mainly associated with missions. But also "AutogenDescriptions" are SPB files for all FS sims through to P3D5. I expect for any sort of file decoding you'll need the SDK -- and maybe the FSX or P3D SDK will be more complete as the MSFS one is a work-in-progress. All FSUIPC can do is call the SimConnect_FlightSave function. What then happens is entirely up to SimConnect. And that still seems to be buggy in so many ways. John and I have been trying to figure out why loading SimConnect saved flights sometimes works, sometimes does nothing, and sometimes crashes MSFS. Pete
  4. No, FSUIPC5 is a 64-bit DLL and therefore only suitable for 64-bit sims (i.e P3D4 and P3D5). FSUIPC4 was the one originally released in 2005 and aimed at FSX and, later, FSX-SE. Go check on SimMarket. Pete
  5. That's for use by external applications (or Lua plug-ins), but you can also use the option in FSUIPC7's File menu, if you've enabled the facility there. Both methods use the same SimConnect calls, but from different procedures. They should be identical. Pete
  6. As well as taking john's good advice, do make good use of the tools at your disposal so you can see what is going on. As well as using Lua tracing (which can sometimes be a bit mind-boggling as it logs every step), try using the ipc.log function to just log details of what you read and write, and also make good use of the FSUIPC monitor facilities (right-hand side of the Logging tab) where you can monitor (to the FSUIPC log) the values of up to 4 offsets of whatever type they are. To make things easier to see, run the Sim in Windowed mode and enable the FSUIPC console log. You will then see these logging entries in real time, on screen. Pete
  7. I wouldn't get your hopes up. I've just tried loading autosaved flights using the FSUIPC facility (version 7.0.5), and also with the MSFS Load flight facility, and I can't seem to get either to do anything . I don't know what Asobo think they've fixed. 😞 Do let us know if you do any better! Pete
  8. I don't know of one, sorry. (Aren't all Arduino's serial port COM devices by default, not Ethernet, or is that just mine?) Perhaps it's a project you can undertake. Pete
  9. Maybe ProSim doesn't need to know the deflections? If it isn't reading them then your only options are either to obtain them from FSUIPC offsets, or interface to SimConnect directly. Either would need programming. Have you tried asking these questions on the ProSim forum? Presumably your needs aren't unique? Pete
  10. Yes, but it isn't easy. Check the Lua documents provided. Are you familiar with the protocols etc? If ProSim has a SIOC driver which is working for you, can't you use that? I assume it's a different sort of Arduino if it has an Ethernet interface -- or is that an add-on board for it? I ask because serial port support is built into the FSUIPC Lua libraries, whereas the ethernet stuff has extra files and a folder structure you need to follow. There's an example of the use of those provided in the Examples ZIP file. It uses an ethernet LAN connection to link to copies of Flight Sim on different PCs -- "MasterClient.lua" and "SlaveServer.lua". Please don't bother posting those pictures in your messages. They are barely readable and I don't see the point of them in any case. Sorry. I think really you are more likely to get help with hardware interfacing for ProSim on the ProSim forums. There's one there entitled "cockpit building questions". We support FSUIPC and WideFS but we are far from being hardware experts. For my cockpit I rely on others. Pete
  11. Why do you think it's to do with winds? Sounds much more like conflicting controls to me, or faulty controls. Check assignments -- only in P3D, or in FSUIPC, do not mix them. You could try FSUIPC logging of axes to see ewhat inputs to FSUIPC are being made. Then you'd need to track them down. Faulty yoke of conflicting assignments. Pete
  12. No. The method of extracting FSUIPC offsets are described in the FSUIPC SDK. FSUIPC is a different product to ProSim!! You need to ask the SIOC folks. They probably already have an FSUIPC interface. We cannot undertake to support every possible piece of hardware out there. FSUIPC is the interface many hardware makers use to interface to the flight sims, and they provide their own drivers for that purpose. In your exchange with John you talked about an Arduino. Is SIOC supporting Arduino too? I use an Arduino to operate the magnetic latches on my 737 starter switches, but I had to write the Arduino code and an FSUIPC plug-in 9in Lua) to interface to it. It uses a serial COM port, not Ethernet. Pete
  13. Yes, as documented. If you don't understand the terms used, you could refer to the thread in the FAQ subforum:
  14. Sorry, I don't know SIOC or how to 'get data' from ProSim. Those are questions forProSim support. You can get aileron and elevator deflection from FSUIPC offsets -- just search for 'deflection' in the supplied Offsets Status document. Do you have software to do that? FSUIPC doesn't 'send' offsets, it is up to applications to read them using the defined software interface (in the SDK). Pete
  15. How do you know it doesn't work? What was the result? It will not be as you want because you are using 0x66E1 to 0x66E4 as a 4 byte offset (UD = unsigned DWORD, which is 32 bits or 4 bytes), and you are writing 0 or 1 to 0x66E2, which is in the middle of the UD value in 0x66E1. What is supposed to be in the 4 byte offset 0x66E1? You said So you want a 2 byte SIGNED word (SW) not an UNsigned double word! You must make sure the offsets used do not overlap, like your 4 byte 0x66E1 and one byte 0x66E2. And if you want to check the value is between -15000 and +15000 you need to revise your test, obviously: if (val1 < -15000) or (val1 > 15000) then ... etc. Pete
  16. Did you use com.readlast on the event.com signal? Otherwise you could be missing some signals unless when the even occurs you read and process all of the input received. In the case of com devices there's really not such a great advantage of using event.com, but it depends very much on the devices concerned. As for performance with MSFS I'm afraid that's a general problem with all aspects involving SimConnect with MSFS. Part of that is because FSUIPC is a separate process and so the communications are nowhere near as efficient, but it is also to do with the dreadful SimConnect implementation at present. You should also look at the CPU usage of MSFS (and FSUIPC for that matter). Most folks seem to let MSFS run riot. It needs limits, same as P3D. Pete
  17. Then see if Windows recognises them. Or you could use HidScanner to list the details: It produces a log file too. Pete
  18. You need it in hexadecimal. There must surely be a way of doing that just in Lua, but as a test I used User offsets. This Lua plug-in works x = 1.7451561201336e-310 ipc.writeDBL(0x66c0,x) y = ipc.readSTR(0x66C0,8) ipc.log(y) The result is a 6 character string, space filled, but in this case it is "HGO", not the "BRK" you seem to have expected. Here's the part of the FSUIPC log where I also monitored offset 66C0 whilst running the above plug-in: 231687 Monitor IPC:66C0 (U32) = 0x204F4748 231687 Monitor IPC:66C4 (U32) = 0x2020 440781 LUA.2: HGO I'd like to work out a way of doing this in pure Lua but I cannot think of where to start at present. If a common use of L:Vars is to store string values it might be worth adding a special ipc.readLvarSTR function to the FSUIPC Lua library, but there are too many other things to do at present. Pete
  19. This is because you made the mistake of installing FSUIPC7 into a protected folder. It is strongly recommended to install it into a normal folder, like C:\FSUIPC. Then you'd never have such problems. Note that if you run FSUIPC7 'as administrator' you need to run any FSUIPC client add-ons on the same PC 'as administrator' too, otherwise they cannot talk to each other. Pete
  20. You didn't need to post a picture of the error message -- I wrote the program and I know what the window looks like. It was your "other messages" which implied some sort of windows crash report. So, the MakeRwys_Scenery.cfg file, which is produced by the Lorby program, has some error in it. Please show me that. Please attach it as a file (Zipped if it is too big). It would help also if you attached your actual P3D scenery.cfg file, which you will find in your username AppData folder for Lockheed Martin Prepar3D, as I suspect it is that which is bad. I also strongly recommend that you run Lorby-Si's freeware AddOnOrganizer program and check the output from that. It provides a neat display of your scenery layers and allows easy corrections and adjustments. Pete
  21. ProSim does its own scanning, it doesn't import any MakeRunways files. You do need to talk to Humberto about its scanning on the ProSim Forum. Bear in mind that the MSFS support in ProSim is very much in its early Beta phase. I use ProSim for my 738 cockpit, using P3D5.1, and have no plans to move to MSFS for a long time yet. It needs multiscreen support to start with (2022?), and a lot more. And whilst it makes a good scenery viewer, it's not such a good flight sim yet. Maybe pottering about in a Cessna. Pete
  22. YES!!! Most certainly. You need an empty profile loaded for each controller in MSFS. You can have keypress assignments in MSFS but certainly not axes if you are using FSUIPC for your axis assignments. Otherwise they most certainly will clash. BTW you won't have trouble uploading text files like INI and LOG files if you ZIP them first. Text files Zip up very compactly. Pete
  23. Offset 3308 provides FS version numbers right back to FS98, but there's no finer granularity (eg for FS9.0 vs FS9.1). That was added from FSX onwards. And as John says, for FS9 and before you are talking about FSUIPC3 (and before). Pete
  24. Sorry, but we cannot answer questions on these VRi devices. Maybe LINDA support can help, or else you need VRi support. Pete
  25. Perhaps the rationale behind the way it works should be explained, so you can better understand. Buttons, switches and keypresses are only activated when you use them -- i.e. press a button, operate a switch, or press a key. So generally assigned ones will not interfere with a flight unless operated. But axes are always active. You don't want axes which aren't to be used in the current aircraft to interfere with flight just because they may jitter a little by themselves, or be nudged by mistake. The other consideration is calibration. Different aircraft have different sensitivities and calibration needs. A stunt aircraft or fighter needs sensitive controls so that it can react very quickly, but a heavy airliner needs some amount of free play in the controls and less extreme reacting movements comparatively. I don't know how many profiles you've created, but it shouldn't be too hard to assign and calibrate other axes the first time you load an aircraft using a profile. Note that it isn't necessary to have a separate profile for every aircraft. You can often get away with one for props, one for turboprops, one for Boeing aircraft and similar, one for Airbus, and another for fighters and stunt aircraft. Oh, also helicopters when supported. Name your profiles accordingly, and select the appropriate profile when first loading a new aircraft. Multiple liveries of the same aircraft can be handled faster by editing the entry for the first added one in the [Profile.name] list to a shortened form which applies to them all. Hope this helps, 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.