John Dowson

yes:

The substring oprion is set but you aren't using it! You need to change youe profile sections, e.g. can be just and to etc. i.e. just specify a substring that matches all the variants - and no others! For your issue, I also need to see the profile of the aircraft you have loaded so that I can see the assignments there and if they match the loaded aircraft, so for this example I would need to see your MD-*X profile for the Maddog X. Also, you are using Linda, I can't really diagnose FSUIPC issues when using Linda. Can you disable for the next test - just rename your linda.lua (or ipcReady.lua if thats all it starts) by renaming temporarily. Also, update you logging and, for the time being, disable axes event logging and enable logging for buttons & keys and events. Then load an aircraft, press a button with an assignment, and show me the files again (your .ini, .log and profile.ini for the loaded aircraft). The logs you posted show your devices were recognised and acquired ok.

Is this just a general question (ie. not related to FSUIPC6)? And what is EZCA? I have not noticed such issues - but I haven't flown much in P3Dv5.1 for a while now...

First, you posted in the FAQ sub-forum, where it explicitly states: So you see the FSIUPC7 splash screen? Once started, FSUIPC7 resides in your system tray and should be opened from there. If you don't see the splash screen and FSUIPC7 is not in the system tray, try double clicking the FSUIPC7.exe to see if it starts. If not, and you get an error, then you may need to re-install the VC++ redistributables (see the README.txt file provided). If it starts, there may be an issue with you EXE.xml. If that is the case, please see the following post: John

But that won't work correctly as you are not setting a value for val1 when the function is fired for a change in offset 0x66F5 (and you are overwriting the input value. To simplify, you could just read each offset directly and not use the input parameter if this is confusing you: And why change from 0x66E5 to 0x66F5? Ots a good idea to group the user offsets you use consecutively, but its not a functional issue.

Ok, then if its connecting to the PC running FSUIPC, you don't need WideFS. Sorry, but I don't know how you would use an arduino connected via ethernet to the main FS PC. You probably need to write an FSUIPC client (using the SDK) to read the data you need from FSUIPC and then send that to your Arduino yourself.

How does your arduino talk to FSUIPC? And what is it connected to? If it talks to FSUIPC when connected to the PC which FSUIPC (and PROSIM) is running on, then it can talk to FSUIPC via WideFS when connected to a client PC running WideClient. Thats is what WideFS does/is, i.e. it allows FSUIPC clients to run on a networked PC separate to that of FSUIPC and the FS.

The functionality in this area should be the same between the different versions as nothing has changed. Are you saying this worked in previous versions but not in FSUIPC7? Why? It is good to report anything you find, to help other users. Just because, in this instance, I am not going to take any action (at the moment), it doesn't mean that such things shouldn't be reported. John

WideFS is the program used to allow networked clients to access FSUIPC offset data. Any FSUIPC client that connects to FSUIPC on the main PC can be moved to a client PC and used there using WideFS (composing WideServer, built into FSUIPC since FSUIPC4, and WideClient, the component that is ran on the client PC). You would still need an FSUIPC client to read the data though..

Then this is what to use! There may be an issue killing and restarting one of the scripts - you could try each individually to see which one it is. But its certainly better to just use Lua Kill All in this situation. There may be an issue somewhere if its hanging. But, as I'm very busy at the moment and you have a solution tp your problem, I don't think its worth looking into this any further at the moment. John

Button numbers used by FSUIPC are 0-31, while windows uses 1-32. Its not important - just assign to the button that is pressed. I don't know what you mean by 'not working'. You can obviously see the button press in the assignment, so do you mean the assignment isn't working? To see if you assignment is working, you can activate logging for Buttons & Keys and also Events, open the console window and press your button. You should see the button press and event assigned to that button in the console (or log file). If it isn't working, attach your FSUIPC7.ini file and a FSUIPC7.log file generated with the above logging activated and the log showing what happened when the button is pressed. John

You can set what you want on any condition you want. I have provided you with a simple script that you should be able to use and update, depending on the type and size of the offsets you are using. First, determine the types you need - as Pete says, probably a SW or signed word, rather than a double word that you originally set you were using to write to the offset. Update that small test script I provided accordingly, so you are reading the same type as you are writing, and try it. Add log statements to see the values if needed. Please try things for yourself rather than asking such questions all the time. We have given you the information you need to do what you want to achieve. Take time to digest and understand and try things out for yourself.

Yes, this is the way to go to control eyepoint and panning - assign to keypresses in MSFS (or use the default assignments if provided) and then assign your button to the keypress, using the left hand side of the button assignments dialogue panel.

If you are writing a double word (4 bytes) to 0x66E1. then that value is held in 4 bytes from that offset, so in 0x66E1-0x66E4 inclusive. However, you are overwriting that value here: ipc.writeUB (0x66E2, 1). Try using 0x66E5 instead. Also, is the value signed or unsigned? This is important when reading. I assume signed below - change to unsigned if needed. Using event.timer was also just an example to get you going. Its probably more efficient to use event.offset, and you can use the same handling function for multiple offsets. But that is one offset. What is the second offset you are using? And always specify the size of the value you are writing to that offset. If you are writing an axis value of as a dword, then it will take 4 bytes. If thats one axis, then you can write the second axis starting at 0x66E5. Which offset? If you want them consecutive, the next 'free\ one is 0x66E9, so why not use that? So, assuming your two axis values are written to 0x66E1 and and 0x66E5, and the flag we are using is in 0x66E9, try Later...I see Pete also responded at the same time!

And you also didn't read my first reply very well, or try what I asked. Please also re-read my first post. I can't help if you do not try what I ask and report back on the results.

That is from steam and nothing to do with FSUIPC7. First, re-install FSUIPC7 and uncheck the auto-start component. Installing FSUIPC7 like this does not touch or affect your steam installation in any way. If MSFS starts ok, then try manually starting FSUIPC7 to check if its all working. If that all seems ok, then re-install again with the auto-start option. I have steam install and it works just fine. There have been several steam client updates today and the past few days. Maybe this has caused an issue. Run your steam and check its all up to date. Not even via steam or using its own (i.e. not th FSUIPC one) icon? If so, then thats an issue with your steam install. The only file that FSUIPC7 changes (or usually creates as its not there by default) is the EXE.xml file. This cannot affect how MSFS starts steam. And you can stop this by deselecting the auto-start component when you install. Note also that the EXE.xml file belongs to MSFS not Steam. Steam starts MSFS, and then MSFS will load the EXE.xml (at some point, nearly 2 minutes into the start-up process) and start FSUIPC7 from that. However, your issue is with the first bit - steam starting MSFS. The only involvement with FSUIPC7 with that is if you use the MSFS desktop link that the installer (optionally) creates. Try starting MSFS in the usual way (i.e. via steam or the steam-created icon, not the FSYUIPC7 one) and see if that makes a difference.

Why don't you just try? If you try yourself and post if you have errors, you are more likely to get a response. Try something like: That will be called 5 times a second, and will change the value in offset 0x66E2 to match your criteria (i.e. values in the other two as-of-yet unspecified offsets are > 10000 then 1, else 0). Replace the ? with the correct offsets/types you are reading. Still don't know what those are. Can you see how that works? Also, note that you can use ipc.log to log a message, which can help you to debug and also see how your lua is working.

@ricktana Your EXE.xml is correct, and if its in the correct location I have no idea why its not being picked-up by MSFS and used. I don't have time to investigate MSFS anomalies. sorry. If you want to investigate further, ask on the Asobo forums why the EXE.xml file isn't being picked-up. Please report back if you find anything. John

No. For the last time, this is auto-generated. Just leave it alone. Why are you quoting the user manual at me? Ok. Which offsets? What do they hold? If you want to do this for two offsets, then depending upon how quick you want your offset to change, there are different methods you can use. The easiest way is just to use a timer (event.timer). In the timer, read the offset values, do the comparison and then write your value when needed. The second would involve to event.offset functions, each monitoring one of your 'read' offsets, and setting a global flag when your condition is true. Each offset function should then check both global flags, and call write to your offset if your condition is met. There are plenty of lua examples, both included with FSUIPC7 and available in the user Contributions sections here. I suggest you take a look at some. I really haven't got time for basic lua lessons, sorry. Just look at the documentation and examples and try things out.

Ok, thanks. Unfortunately as you aren't installing the auto-start component, the log doesn't tell me what type of install it thinks you have. If the installer thinks you have a steam install for some reason and its an MSFS install, it will crash when tryint to create the EXE.xml as the required folder doesn't exist. You could test this, by manually creating the folder: <USER>\AppData\Roaming\Microsoft Flight Simulator Then run the installer again, select to install the auto-start component, and see if it works. If so, you can then move the EXE.xml created in that location to the MSFS install location (and remove any folders you created). I'll update the installer to log the install type regardless of whether you opt to install the auto-start component. I have also had one (or maybe two) other confirmed reports of the installer not correctly detecting the install type. Can you also let me know the locatin of your MSFS UserCfg.opt file - is it in $LOCALAPPDATA\Packages\Microsoft.FlightSimulator_8wekyb3d8bbwe\LocalCache\UserCfg.opt ? Otherwise, this is what an EXE.xml looks like - replace the FSUIPC7.exe path with your own (highlighted in bold): John

Why? As I said, just don't touch that section. It is managed by FSUIPC - leave it alone! Why did you change it? What are you trying to read? You use the read function corresponding to the data type of the data held in the offset you want to read. Please see the lua documentation for event.offset, in the Lua Library document. Also, take a look at the example lua files provided - there should be a zip file containing examples in your FSUIPC documents folder.

Whats the issue? The log shows your lua is running ok. However, you are reading from 0x67E7, which is in a reserved area. Are you sure thats correct? Other than that, your lua is running ok - it will just run and exit. If you want to keep it running, and update an offset when another offset changes, you probably want to ne using the event.offset function. Then the lua thread will keep running, waiting for that offset to change, and then calling the event function, in which you can write to your other offset. If thats not what you need, then maybe activate the lua on a button or key press rather than have it auto-started. Don't write the [LuaFiles] section. This is constructed automatically from the lua files (old/removed and new) and shouldn't be manually changed. Just add your luas to the [Auto] section when you want them auto-started. John

The install log is written at the end of the installation process, so if it crashes no install log file is generated. Could you show me your install log for this please. Maybe it thinks you have a Steam installation? Yes, but I've no idea what at the moment. It won't be, if the EXE.xml file has not been created/updated. You can try manually creating the xml file if you like. Otherwise, you can go back to the old way of starting FSUIPC7 with MSFS, via the bat file. There is another post with the same issue, and there are also instructions on how to update to start FSUIPC7 from the MSFS.bat file (but make sure you use the correct replacement for INSTDIR, your installation folder): John

Very strange...but glad its now installed and working. Thanks, and enjoy the rest of the weekend as well, John

@giosuepirozzi Your EXE.xml also looks fine. Can you check the location is correct (see my previous comment for details). If the EXE.xml file is correct, and in the correct location, I do not know why it is not being picked-up by MSFS. You could go back to the old method of starting FSUIPC7. To do this, open the MSFS.bat file located in your installation folder, and change these lines: to