Sky Blue Flyer

I'm sure my scenario is pretty rare but an update as you suggest would make it fool proof. Thanks for taking the time to look at this John. best Martin

Yes I agree John it is strange because although the install log shows the correct steam location for the usercfg.opt, if you look at the fsuipc7.log whenever I ran fsuipc7 it was looking for the store usercfg.opt defined FS install location 47 System time = 25/02/2024 17:54:29 47 FLT UNC path = "\\MGS-SIMPC1\AppData\Local\Packages\Microsoft.FlightSimulator_8wekyb3d8bbwe\LocalState\" 47 Allowing calibration when not assigned with 'Send direct to FSUIPC Calibration' 63 ------------------------------------------------------------------- 78 Preset file 'C:\FSUIPC7\myevents.txt' not found [info only] 78 13965 Calculator Code presets have been loaded and are available for use 110 Registered HotKey 'InvokeFSUIPCOptionsKey' (key=0x46, modifier=0x1) 125 FS UNC path = "E:\MSFS\Packages\" Once I realised there were some legacy Store version files inc the usercfg.opt from a previous installation pointing to the old package folder location. I pointed it to the new package folder location and everything was then fine. Obviously I couldnt leave it like that so I removed the Store legacy files, reinstalled fsuipc7 and it correctly identified the steam usercfg.opt and FS UNC path. FSUIPC7 did what it supposed to once the confusion of having a steam and a legacy store version of the usercfg.opt was rectified. kind regards Martin

Solved - I appear to have legacy msfs files in a microsoft store version of msfs even thogh I am now using a Steam version so I have two usercfg.opt files. FSUIPC7 was looking at the legacy usercfg.opt for the package location which was still pointing at the old location. After I updated the location in thus usercfg.opt file the WASM module was found. Not sure why fsuipc7 was looking here as everything plays nicely when I load the normal steam msfs. It all works now so am happy.

Hi John I am having trouble loading the WASM Module after moving my MSFS installation to a new M2 drive on my sim pc. I updated the Usercfg.opt with the new MSFS folder location and MSFS loads and runs normally except for no WASM Module. A quick look at the fsuipc7.log seems to show that the FS UNC Path is still showing the old MSFS installation folder path and not the new one. I have tried re-installing fsuipc7 (I'm on the latest version) but the FS UNC path is unchanged. How can I update this please? fsuipc7.ini, fsuipc7.log and installfsuipc7.log files attached. regards Martin FSUIPC7.ini FSUIPC7.log InstallFSUIPC7.log

Hi John Thank you for the revised beta .exe file. I have just tested it with success. I set all three [Program} entries in the .ini file with both the READY option and varying DELAY time options and all three worked perfectly, i.e. the programs started in DELAY time order after the FS main screen appears, a departure location selected, custom flight loads and 'Ready to Fly' is initiated. Thus can clearly be seen from the attached log file. For info, I did also test without the 'Ready' option. Each of the programs started with the respective 'Delay' options but before the FS initiated. Which is fine for most, but I require ProSim to start after FS starts. Thanks for your help with this John. Will your modified fsuipc7.exe be incorporated into the next release? FSUIPC7.ini FSUIPC7.log

Hi John I tried without the 'READY' option for 2 of the executables and inserted a 'DELAY' option, fsuipc7.ini file attached. The first executable with 'READY' and no 'DELAY' option started on FS start. The other 2 did not start either on FS start or 'Ready to Fly'. Log file attached as requested. FSUIPC7.ini FSUIPC7.log [Edit 1] A bit of further info after more testing John. It seems that any changes in the fsuipc7.ini (in the Programe section) require a pc reboot to become effective. I tried adding the changes without a reboot and it didn't work. After I rebooted I did get some success as follows. So, with the 'ready' option included, any delay time inc default does not work at all and the program starts on FS start. Without the 'ready' option and 'delay' included, the programme doesnt start on FS start but does start when 'ready to fly' is clicked after selecting departure. However not with the delay seconds, either as "=n" or default. Just to confirm, whenever I make a change to the [program] options in fsuipc7.ini I have to reboot the pc for the changes to be effective otherwise there is no change to behaviour.

Hi John I have installed the 7.3.25 beta exe and I am not getting any delay write back to fsuipc7.ini. However I am still unable to get the delay function to work. I have tried using "DELAY" which I believe has a default 10 secs. and also tried with the syntax in the advanced manual i.e."DELAY[=10]" Without success. I did try removing the parentheses but again no joy. If I remove the "DELAY" function completely the .exe start immediately so the 'run' syntax is correct. FSUIPC7_prev.log FSUIPC7.ini

Hi John Thanks for getting back to this and for the beta. I will give this a try this evening and report back. Regards Martin

That's great John, no rush. Thank you.

Just a bit of feedback John following more testing. I spoke too soon and I am still getting a "Delay=x" writeback to the fsuipc7.ini file after which the exe files do not then start as before. If I remove the 'Delay' function from each of the strings it works and there is no writeback and has continued to work perfectly during numerous startups. The problem by elimination appears to be the Delay function. I am happy to leave it out as the 3 prosim programs work fine when started simultaneously. regards Martin

I updated to latest supported version of fsuipc7 and changed the WideClient.ini to kill and everything worked as it should. I am yet to check if the fsuipc7.ini file was written back to but at least the programs were all started and closed. Thanks for your help on this one John

Thanks John. I'll update to the latest version of fsuipc7 first then try the changes you recommend to the Program section of the ini. I do always close fsuipc7 before making changes to the ini file. Strange that the extra line keeps being inserted. Similarly I'll try the WWideClient ini changes and report back. I will remove the ipc reads & writes from future logging. One final thought, I am starting msfs2020 from within addon linker rather than from within Steam or using the fsuipc msfs bat file. Would this make a difference?

Hi John Sorry for the late feedback. I have checked the fsuipc7.ini entries and amended the WideClient.ini with the suggested [User] entries checked against the WideFS Technical document. I now have had a chance to test the new configuration and am happy to report that the 3 programs in the [User] section are starting when the WideServer connection is made. There does however remain a problem with the fsuipc7.ini programs starting. The first in the [Program] list starts but not the second and third. Interestingly you will see from the attached fsuipc7.ini file that a delay line is always written to the [Program] entry despite being deleted each time I check the fsuipc7.ini file. Could this be linked to start problem that I am seeing? Also I am not seeing the 3 x WideClient started programs close when Wideserver disconnects. Am I missing something? Thanks in advance John for your time looking at this. FSUIPC7.ini FSUIPC7.log WideClient.ini WideClient.log WideServer.log

I see now, thanks John. I made the mistake of assuming that the same format for commands for the fsuipc.ini and wideclient.ini would apply. Once I used the correct syntax from the WideFS Technical document it worked perfectly. Lesson learnt. Thanks again

I cant seem to get programs to start on my client PC running WideFS7 using the Run or RunIf commands. I am doing the same thing on the main MSFS sim pc using the same syntax and it works fine. I am showing that WideClient connects on both the server and client when I spawn at gate and other software on the client pc requiring fsuipc is working correctly. I am trying to get various ProSim modules to start on both the msfs server and client pc's when msfs starts. I have attached logs Any help would be greatly appreciated. FSUIPC7.ini WideClient.ini FSUIPC7.log WideClient.log WideServer.log

That's really helpful John. Thank you for taking the time to look at thus in detail. It is very much appreciated. Interesting to note your thoughts on the lvar bits and possible implementation in the future. It would be much cleaner to eliminate the DLight lua completely. If you are able to simulate the broadcast send and receive later this week that would be great. Will be intetesting to see if the tcp protocol brings any improvements. I will unify the bits/ words syntax if only for consistency. If that does improve lag then all well and good. Thanks again John.

Hi John I dont believe I have sent you anything that relates to Wideview other than the word appearing in the text file description. All of the files relate to fsuipc on a server pc and client pc's. I understand your point about WidevieW but it is a red herring in the context of this problem and can be ignored. The original issue with lights happens irresepctive of whether WidevieW is used. If fsuipc7 on either the server or client pc's doesnt run the lights on the client pc's do not work. FSUIPC7 is installed on both server and client pc's. It is my understanding that the broadcast lua on the server pc sends light offsets to the network when a light switch in the cockpit is operated. The broadcast lua in the client pc's listen on the network for the offsets and when it hears them translates them into the appropriate light lvars as described by the DLight lua which turns on the light in that client sim pc. All WidevieW does is synchronise the time and position of 3 identical sim pc's in my system, one being the lead (server) and 2 following (clients). Apologies if the use of the term WidevieW has mis-led you. Thank you for the suggestions regarding delay. I will experiment with the initial lvarscandelay and time between scans.

Hi John Please find attached 2 file archives. For clarity, 'server' refers to the WidevieW server 9i.e. the sim pc and 'client' refers to the WidevieW clients i.e the view IG pc's. The server archive contains the zipped lua files that are to be installed in the fsuipc7 root of the Wideview (msfs sim) server pc. Also included in the archive are the log sets and fsuipc.ini files for each of the 3 fsuipc7 versions installed in order, starting with v7.3.11. Similalrly, the client archive contains the zipped lua files that are to be installed in each of the fsuipc7 roots of the Wideview msfs IG client pc's ( I have 2 pc's dedicated to generating the forward looking cockpit view). Also included in the archive are the log sets and fsuipc.ini files for each of the 3 fsuipc7 versions installed in order, starting with v7.3.11. There are no Wideclient logs as Wideclient is not used in this part of the network setup. The offsets 5301 and 5303 you will see broadcast from server to client are the free offsets used as user gates in ProSim for the light switch actions. I have also attached the setup instructions and the list of lvar instructions to be added to the fsuipc7.ini general section of each client (they are also in the server). By way of an update, my client light setup is now working on all versions of fsuipc7 including the latest version. I dont know why it now works on the latest version, it didnt previously. The only remaining problem I have is that there is a 4 to 5 second delay between the server lights turning on and the client lighst turning on. The serever lights respond instantly to light switch operation (as you would expect). GSalden still has the problem using this setup and offer these files as much to assist resolving his ongoing issue. My only request is that you are able to offer a resolution to the response lag betwen the server aircraft and client aircraft light operations which wasnt evident previosuly and now remains regardless of fsuipc7 version installed. Your continued help is appreciated. Add to end of General_fsuipc_ini .txt Server.rar ReadMe_WidevieW_Client_Lights.txt Client.rar

Ok John thank you. I will gather the required information. Edit: the BCastMemServer. lua and DLight.lua files run on the server pc and BCastMemClient.lua and DLight.lua run on each of the clients.

Hi John I am one of the ProSim users that GSalden referred to in his OP that experienced recent problems with WidevieW Client aircraft lights. The system setup consists of an msfs WidevieW server with fsuipc7 and second networked pc with mobiflight and widefs7 into which is connected the sim hardware. The Wideview server connects over the network to 2 x msfs wideview client pc's both with fsuipc7 generating the fixed forward cockpit view. The ProSim flight model is used on the server and clients. The ProSim server and hardware switches control all of the WidevieW server aircraft lights. There are 3 fsuipc server lua files (BCastMemSvr.lua, DLight.lua and IPCReady.lua) that in essence send free offsets to the clients which set the client aircraft light lvars by means of a BCastMemClient.lua, DLight.lua and IPCReady.lua files together with lvar identifiers in the general section of the client fsuipc7.ini files. Please excuse my poor use of terminology here. I am by no means experienced or knowledgeable with either fsuipc or lua files to understand how this all works. It is a derivative of a system originally setup for use with P3D to achieve a similar outcome. I and others have merely adapted it to work with the msfs lvars. Basically the arrangement worked very well until it stopped working very recently. In my system, this happened when I installed su12 but also at the same time updated my server and client pc versions of fsuipc7 to the latest version 7.3.19. Im afraid I do not know which version I updated from sorry, but it was either 7.3.11 0r 7.3.12 as I have both in my download backups. I have rolled back to version 7.3.11 and reinstalled the lua files and the client lights are now working again albeit with a few seconds delay in operation (where previously it was pretty much instant). I did try re-installing 7.3.19 before rolling back to 7.3.11 but this made no difference. I am happy to post the fsuipc7.ini and log files for both server and clients together with the lua files and the various lua logs if you have the time to look at them. This may take a day or so. I also intend updating to 7.3.12 to see if that breaks it again, if it doesnt I will try 7.3.19 again and post the associated logs. Should I attach everything here or by direct message?

You were correct John, it was indeed the default lua scripts in the Wideclient root folder that were causing the screen anomaly. I had inadvertently extracted them to the root. Once they were removed all was well. Thanks for your help.

Ok John. Thanks for the suggestions. I will give those a try and report back. I believe there are some lua scripts in the Wideclient root folder so will disable those.

Thanks John. I will feed back to Lapi. Sorry I didn't get chance to check if there is a process/program owner for the rogue window. Will have a look this evening.

Yes if I move the Wideclient away from the screen area occupied by the boxes before they appear, I can then see it on screen after they appear, so it is manageable. I did a little more testing John. With no other addons running (i.e. Spad.next), with MSFS started without launching WidevieW and not ready to fly with Wideclient open and not connected there are no boxes. When I select an aircraft and move to ready to fly Wideclient connects and then the boxes appear a few seconds after connecting. I can work around it so it doesnt affect anything but it would be nice to understand what and why. On another topic John, I am trying to turn on the lights of my ProSim737 aircraft on my 2 forward cockpit view MSFS IG client pc's. These are time and position sync'd using WidevieW which works well. It is extremely unlikely that WidevieW itself can or could in the future do this from the serving aircraft. I have contacted Lapi who produced the ProSim737 flight model who has confirmed that the FM lights are LVAR driven. I understand from him that lvars are not network capable on their own. He did indicate that fsuipc has full lvar capability but was unsure if Wideserver was capable of transmitting them and suggested asking yourself. If so, then according to Lapi we are in business. This is all beyond my capability but I thought I would ask the question.

Thanks for the prompt reply John. I will update to the latest version of FSUIPC7 as you suggest. I am running mobiflight on the client connecting all of my cockpit hardware to tge msfs server together with spad.next so that I can use logitech devices during the build transition so would want fsuipc on the msfs server. I have tried installing widefs7 on other client pc's that are running cockpit fixed views using WidevieW. I get exactly the same strange boxes on those pc's too. I did turn off WidevieW on the server but that didn't make any difference. I'll keep trying different server addon combinations to see if that makes a difference. Intriguing indeed.