Is it possible to dl v7.3.11 ?

[GSalden]

Goodevening,

Is it possible to DL v 7.3.11 ?  Several Prosim users use a WidevieW setup and with FSUIPC files ( lua , Lvar etc ) to have the external lights working over the network.

Recently it did not work anymore and one of the users found out that with FSUIPC 7.3.11 it is working again and with higher version not.

Thanks in advance.

 

[John Dowson]

56 minutes ago, GSalden said:

Is it possible to DL v 7.3.11 ?

No, only the latest version is ever provided and supported.

56 minutes ago, GSalden said:

Recently it did not work anymore and one of the users found out that with FSUIPC 7.3.11 it is working again and with higher version not.

What about the versions between 7.3.11 and 7.3.19? e.g. was it working in 7.3.12? Knowing the first version in which this stopped working would help narrow down the problem.

Can you please provided more details on the actual issue - how are the external lights controlled? And please also attach a FSUIPC7.ini file and a FSUIPC7.log file generated with appropriate logging enabled (i.e. Buttons & Keys and Events).

Please also review either the changes.txt file or the History document, which detail the changes between each version, to see if you can identify any possible changes that could cause this issue.

If this proves difficult to track down, I may provide some early versions for you to test to try and track down the issue, but I don't like providing an earlier version because something has broken - it must be fixed in the latest version and the patch/update released in the next version.

John

[Sky Blue Flyer]

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?

[John Dowson]

14 hours ago, Sky Blue Flyer said:

Im afraid I do not know which version I updated from sorry,

The UninstallFSUIPC7.log file should tell you which version was uninstalled when you install a later version.

Are these lua files running on the clients or server PC?

14 hours ago, Sky Blue Flyer said:

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?

I would like to see the FSUIPC7.log and FSUIPC7.ini files for when this is working and also when not working in the latest version, as well as the lua files. For now, jut set logging for Events and, if the lua plugins are running on the server also logging for Lua Plugins, otherwise set logging for IPC Writes. If the luas are running on the client PC, I will need to see the WideClient.log and WideClient.ini files. I don't think there is any lua plugin logging on WideClient - I may need to add some offset logging to WideClient, but I will need to see the files first to see what, if any, additional logging is required.

[Sky Blue Flyer]

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.

 

[GSalden]

Hi John,

In addition to what Sky Blue Flyer wrote : it worked on my system with the version that he mentioned till I upgraded my Left View client to W11 (coming from W10) . My Server already was W11. Even with the Firewall disabled, Defender disabled and ports open on both pc’s, it will not work again. Doing the LVAR test on the client ( see Readme file ) shows that the external lights go On/Off.

Here a link to the complete set with LUA files too incl Readme  :

https://wetransfer.com/downloads/d3860ea6e14e5c186fd81bc546705c6720230423081252/1b10defee308e52fb8e46bf797ab18bd20230423081330/893bef?trk=TRN_TDL_01&utm_campaign=TRN_TDL_01&utm_medium=email&utm_source=sendgrid   

Sky Blue Flyer can show the requested files when it is working and when not. 

 

[John Dowson]

2 hours ago, GSalden said:

Here a link to the complete set with LUA files too incl Readme  :

https://wetransfer.com/downloads/d3860ea6e14e5c186fd81bc546705c6720230423081252/1b10defee308e52fb8e46bf797ab18bd20230423081330/893bef?trk=TRN_TDL_01&utm_campaign=TRN_TDL_01&utm_medium=email&utm_source=sendgrid   

Not sure what I am supposed to do with that - looks like something to do with WidevieW. I have never used and don't know much about this software, so cannot help with that.
I can only help with FSUIPC and WideFS.

2 hours ago, GSalden said:

In addition to what Sky Blue Flyer wrote : it worked on my system with the version that he mentioned till I upgraded my Left View client to W11 (coming from W10) . My Server already was W11. Even with the Firewall disabled, Defender disabled and ports open on both pc’s, it will not work again. Doing the LVAR test on the client ( see Readme file ) shows that the external lights go On/Off.

So you issue started when upgrading windows, not when upgrading FSUIPC7? Or did you upgrade both?
Is WideClient connecting ok, or are you saying that you now gave a connectuin issue with WideClient?

I am getting confused by this topic, and would like to see the files I requested (i.e. logs, inis and luas) to see what is happening.

[GSalden]

WidevieW is a program where an outside view client is slewed by a server so the outside views connect.

The package was made to have external lights function over a network. So when I press the runway take off lights  light on my Overhead I can see the light on the server and the client. The package works independently from WidevieW but they are both used. 
WidevieW for the outside views position and the package for the external lights on the clients aircraft.

In February it all worked for all of us. Than several MSFS updates and FSUIPC updates later it stopped working. As we do not make nightlights each week it is impossible to pinpoint exactly when it stopped working.

Sky Blue Flyer found out that going back from FSUIPC 7.3.19 to 7.3.11 it started working again on his W10 pc’s with current MSFS version.

People with W10 have it working up to FSUIPC 7.3.11. 
Myself I had it working on my W11 server and W10 client with FSUIPC 7.3.11. After upgrading the client to W11 it stopped working.

Wideserver / Wideclient is not needed when Prosim and MSFS are installed on the same pc.

However, I do have Wideserver installed on my Server and Wideclient on my Client pc’s to have working hardware gauges with SIOC ( OpenCockpits hardware ).

Imho finding out how it will work again with Sky Blue Flyers setup and a current FSUIPC is our main goal. After that why it works on W10 and not on W11.

Thank you for your help.

[John Dowson]

3 minutes ago, GSalden said:

WidevieW is a program where an outside view client is slewed by a server so the outside views connect.

I know what WidevieW is and does, I just have never used it and do not know anything about the configuration of this software, It is completely independent of FSUIPC and WideFS.

6 minutes ago, GSalden said:

The package was made to have external lights function over a network. So when I press the runway take off lights  light on my Overhead I can see the light on the server and the client. The package works independently from WidevieW but they are both used. 
WidevieW for the outside views position and the package for the external lights on the clients aircraft.

What is the "package" you are referring to here? Do you mean the lua scripts, used by WideClient and FSUIPC?

7 minutes ago, GSalden said:

Myself I had it working on my W11 server and W10 client with FSUIPC 7.3.11. After upgrading the client to W11 it stopped working.

Then this sounds like a communication/network issue due to the W11 update, as you are using the same version of FSUIPC7. If the communication issue is with WideClient/WideServer, check those logs. Maybe the workgroup name has changed due to the update? Either way, if its a network error, then the WideClient / WideServer log files should report this.

10 minutes ago, GSalden said:

Wideserver / Wideclient is not needed when Prosim and MSFS are installed on the same pc.

Of course.

11 minutes ago, GSalden said:

However, I do have Wideserver installed on my Server

You don't need the separate WideServer any more, as its part of FSUIPC7.

12 minutes ago, GSalden said:

After that why it works on W10 and not on W11.

There is no change or difference when running either FSUIPC or WideClient on windows 10 or 11. Any differences encountered after such an upgrade must be due to the upgrade itself.

14 minutes ago, GSalden said:

Imho finding out how it will work again with Sky Blue Flyers setup and a current FSUIPC is our main goal.

And for which I need to see the files I have requested...

John

[GSalden]

The package are the files needed to get the external lights to work ( see DL link ) , like LUA scripts. 

I am using the same FSUIPC version on server and client pc’s.

All instruments work using Wideserver/client and WidevieW also works correctly over the network. All pc’s are using the same workgroup.

Sky Blue Flyer will probably post the requested files tomorrow.

Thank you for your help.

regards, Gerard 

 

 

[Sky Blue Flyer]

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

[John Dowson]

24 minutes ago, Sky Blue Flyer said:

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.

I don't want to see anything related to WidevieW. I have said this several times now - FSUIPC and WideClient have nothing whatsoever to do with WidevieW. I have never used this and know next to nothing about it. Please restrict your questions and attached files to those that I need to see, i.e. those relating to FSUIPC and WideFS.

29 minutes ago, Sky Blue Flyer said:

There are no Wideclient logs as Wideclient is not used in this part of the network setup.

Ok, so its either a WidevieW issue, or something related to how WidevieW uses/interacts with FSUIPC? This sounds more like an issue for WidevieW...

31 minutes ago, Sky Blue Flyer said:

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).

So there is now no issue apart from the delay? And this is on a client, but the client doesn't use FSUIPC or WideClient, only Wideview? Then this again sounds like an issue for WidevieW.

33 minutes ago, Sky Blue Flyer said:

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.

I don't see how I can help here, as the issue is on the client and that isn't using either FSUIPC or WideClient. And id this is present regardless of FSUIPC version, what has changed that has caused this issue?

As this set-up seems to be using lvars, it could be related to the delay in initial lvar scan and the automatic re-scan for new lvars, although I doubt this very much if the issue is present regardless of version. You could try with the FSUIPC7 logging console window open (Log -> Open Console), and/or monitor the number of lvars available in the message in the FSUIPC7 main window. If you see this continually increasing, performance issues can be seen if new lvars are continually found amd reloaded - but this should affect both server and clients. For complex aircraft, you may need to increase the WASM ini parameter LvarScanDelay  so that more time is allowed before the initial scan for lvars is performed. You can also adjust or disable the time between scans to detect new lvars. See the WASM section in the Advanced User guide for details.

But, if the issue is on a client that is not using FSUIPC or WideClient, then I'm not sure I can help.

In FSUIPC7 on the server, you can also enable logging for IPC Writes and IPC Reads, and again keep the logging console window open. This may help identifying when any request from an external application (i.e. WidevieW) is received.

50 minutes ago, Sky Blue Flyer said:

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. 

Interesting. That offset area is actually documented as being assigned to "Mark Hastings B777 Systems Simulator", not that it matters...!

You could also monitor those offsets using FSUIPC7's offset monitoring facilities, and send the monitoring to the normal log file. Again, with the logging console window open, you should be able to see when FSUIPC7 receives these requests, and be able to determine where the delay is coming from. I suspect that this is a network issue, or maybe related to anti-virus or firewall software somewhere in the mix...

John

[GSalden]

Hi John,

FSUIPC is used on both server as client. The server sents the lights info ( on / off ) to the client.

The issue on my W11 setup exists also when WidevieW is not running. And WidevieW uses Simconnect.

I will try your suggestions to see if the server is sending data from the external lights to the client and if the client is receiving any data.

[Sky Blue Flyer]

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.

[John Dowson]

13 hours ago, GSalden said:

FSUIPC is used on both server as client. The server sents the lights info ( on / off ) to the client.

Not sure that I understand this... If you are running FSUIPC on both server and client, these are both full instances of FSUIPC with their own offset area and there is no communication between them  FSUIPC running on a client PC receives all data via simconnect, as does FSUIPC on the server.

13 hours ago, GSalden said:

I will try your suggestions to see if the server is sending data from the external lights to the client and if the client is receiving any data.

I thought the only issue now  was that there was a 4-5 second delay when turning the lights on via the client PC, which is not present when done in the server PC. Or maybe this is the issue for @Sky Blue Flyer and @GSalden does not have it working at all on the client?

11 hours ago, Sky Blue Flyer said:

If fsuipc7 on either the server or client pc's doesnt run the lights on the client pc's do not work.

But if FSUIPC7 on the client isn't running, the lights still work in the server? If so, then it is the server PC that is controlling the lights.

And I now assume you are also running MSFS on both client and server PCs, no? I am not sure how this type of set-up works...
For example, the client and server logs you posted show different numbers of ;vars received: from the server:

Quote

   267469 Lvars received: 181 L:vars & 0 H:vars now available
   267516 Lvars/Hvars received - checking aircraft autos....

and from the client:

Quote

   233797 Lvars received: 278 L:vars & 0 H:vars now available
   233860 Lvars/Hvars received - checking aircraft autos....
...
   235860 Lvars received: 280 L:vars & 0 H:vars now available
   238000 Lvars received: 286 L:vars & 0 H:vars now available
...
   348828 Lvars received: 288 L:vars & 0 H:vars now available

Note that as more lvars are being received after the initial set of lvars is being received, you should increase the LvarScanDelay WASM ini parameter by 5-6 seconds, However, this is only really relevant if the lvars the lua scripts are using need those lvars - if it is the lua scripts that are creating the additional lvars, then no need to increase this delay.

And I don't understand what the lvar lines in the [General] section of both client and server ini files is doing - what reads these:

Quote

1=L:B738_Taxi_Light =UB0x5303.4
2=L:B738_Landing_Light_Left =UB0x5301.0
...

?

If something in your set-up is using that, then it should be in a separate file and not in the FSUIPC7.ini file...

You also have WideServer running on both the client and server PCs. This is a bad idea - you should only have one copy of WideServer running on a network. I am not sure what will happen with two instances of WideServer running, so maybe disable one of those - or both if not using WideClient (which you shouldn't anyway as you are running FSUIPC7 on both server and clients).

12 hours ago, Sky Blue Flyer said:

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). 

Ok, this helps...although it is still not 100% clear. The offset areas in the client and server PCs will be distinct, with each being populated from the MSFS instance it is connected to. And the available lvars are also different and independent on the client and server PCs. I do not know how WidevieW syncs these two instances of MSFS...
Maybe you could show me the lua files which would help: BCastMemSvr, BCastMemClient, Dlight, ipcReady (for both client and server, although I assume that this just starts the other lua files).

Note also that you can run FSUPC7 in a client PC and have it connect to the server MSFS instance. This is what I assumed you were doing when you said that FSUIPC was running on a client PC. Doing it this way, the lvars (and most offsets, but not user ones) would be the same on both client and server. 

John

 

[John Dowson]

19 minutes ago, John Dowson said:

Maybe you could show me the lua files which would help: BCastMemSvr, BCastMemClient, Dlight, ipcReady (for both client and server, although I assume that this just starts the other lua files).

Sorry - these are available in the link to download. I will take a look...

John

[John Dowson]

Ok...so the server lua is sending the offset changes via a udp socket, which is picked-up by the client and duplicated, and then the offset changes are picked up by the Dlight.lua and the corresponding lvars are set.

For @GSaldenwhere this isn't working, I can only assume that this is a network issue and the client is not receiving the broadcasts. Check the host and port are correct in the BCastMemSvr.lua, and that firewalls are either disabled (I know you said they were, but please check again on both client and server PCs, as well as in any routers) or have an exception to allow the host/port to be accessed. You could also try using a different port number. May also be related to your router config - check any UDP related settings there.

For @Sky Blue Flyer, where this is working but there is a 4-5 second delay, I don't know what to advise really...not sure what could be causing such a delay in sending/receiving UDP packets. It could be a general UDP issue relating to ARP message exchange, but I am no network expert (maybe try google), Have you thought of switching to TCP instead?

One thing that strikes me as strange is that you are using the lights offsets 0x5301 and 0x5303 as unsigned bytes (UB), but have set events and are broadcasting them as unsigned words (UW). Not that this should make much difference...but maybe better to use UB throughout.

And I really don't understand why you have this in the [General] section of your FSUIPC7.ini files (both client and server):

Quote

1=L:B738_Taxi_Light =UB0x5303.4
2=L:B738_Landing_Light_Left =UB0x5301.0
3=L:B738_Landing_Light_Right =UB0x5301.1
4=L:B738_Retract_Left =UB0x5301.2
...

This is similar to what goes into a [LvarOffsets] section, which adds lvars to offsets for both reading and writing. However, you cannot currently do this for specific bits - but I like this idea and may implement this in a future release. Note that if the lvars were added to the offsets (bits), then you wouldn't need the Dlights.lua as any offset change would automatically trigger the corresponding lvar to be updated. 
I can't see how this is needed and should be removed - unless you can explain to me what this is doing (and by what)?

I don't really have experience in such a set-up and so cannot really advise on this any more at the moment. I will try and duplicate a similar set-up here, with one PC on windows 11 and another on windows 10. However, I cannot duplicate exactly as I only have one license for MSFS, and so would have to run FSUIPC on one PC as a client version, but the lua socket communication between the FSUIPC versions should be the same. I will try and similar offset exchange (broadcast and receive) via UDP to see what delay I experience, and will also try with TCP to see if that gives better performance.  I won't have time to do this until later this week though. I will report back once I have done this.

John

[GSalden]

Hi John,

After a lot of testing and trial and error I finally have the lights working again on the Left View pc.

What I did :

- Uninstalled FSUIPC 7.3.11

- Reinstalled FSUIPC 7.3.19

- Downgraded Prosim from 3.25b9 to the official 3.24.2

Since a couple of weeks the external lights on the Server only worked with MSFS running as Admin but Prosim not as Admin. Before I always ran Prosim as Admin too.

When enableing the Write/LUA/Lua separately Logs and looking at the Console nothing happened and the window stayed empty.

After doing the above I was able to run Prosim again as Admin and have working external lights.Then I did the above test again and all data appeared on the Console window.

Then I started the Left View Client and the external lights worked right away. They only react with a 5 sec delay like Sky Blue Flyer stated.

Is there anything that can be tried to eliminate the delay ?

Thank you again for your great help John.
You pointing out to use the Console helped a lot,

[John Dowson]

17 minutes ago, GSalden said:

After doing the above I was able to run Prosim again as Admin and have working external lights.Then I did the above test again and all data appeared on the Console window.

Then I started the Left View Client and the external lights worked right away. They only react with a 5 sec delay like Sky Blue Flyer stated.

Is there anything that can be tried to eliminate the delay ?

Ok, thanks for the update. As I said (or hinted at) in my previous post, I do not know what could be causing such a delay. I will emulate your lua broadcast/server and reception/client scripts here to see if I also get such a delay. However, looking at the lua client script log, it seems  that the issue is not with the UDP broadcasts itself (although adding additional logging after the udp2:receive call would confirm this) but is taken up by the vstruct.unpack call:

Quote

   325407 LUA: C:\FSUIPC7\BCastMemClient.lua:24
...
   328360 LUA: C:\FSUIPC7\BCastMemClient.lua:29
...
   328547 LUA: C:\FSUIPC7\BCastMemClient.lua:24
....
   331266 LUA: C:\FSUIPC7\BCastMemClient.lua:29
...

So that is around 3 seconds to unpack the received data....I am not sure why this is so slow...I will investigate, but those are standard lua libraries and not provided by me so i am not sure if anything can be done. I will investigate later this week and report back, as I said.

John

 

Edited April 24, 2023 by John Dowson
Posted accidentally before finished

[Sky Blue Flyer]

4 hours ago, John Dowson said:

Ok...so the server lua is sending the offset changes via a udp socket, which is picked-up by the client and duplicated, and then the offset changes are picked up by the Dlight.lua and the corresponding lvars are set.

For @GSaldenwhere this isn't working, I can only assume that this is a network issue and the client is not receiving the broadcasts. Check the host and port are correct in the BCastMemSvr.lua, and that firewalls are either disabled (I know you said they were, but please check again on both client and server PCs, as well as in any routers) or have an exception to allow the host/port to be accessed. You could also try using a different port number. May also be related to your router config - check any UDP related settings there.

For @Sky Blue Flyer, where this is working but there is a 4-5 second delay, I don't know what to advise really...not sure what could be causing such a delay in sending/receiving UDP packets. It could be a general UDP issue relating to ARP message exchange, but I am no network expert (maybe try google), Have you thought of switching to TCP instead?

One thing that strikes me as strange is that you are using the lights offsets 0x5301 and 0x5303 as unsigned bytes (UB), but have set events and are broadcasting them as unsigned words (UW). Not that this should make much difference...but maybe better to use UB throughout.

And I really don't understand why you have this in the [General] section of your FSUIPC7.ini files (both client and server):

This is similar to what goes into a [LvarOffsets] section, which adds lvars to offsets for both reading and writing. However, you cannot currently do this for specific bits - but I like this idea and may implement this in a future release. Note that if the lvars were added to the offsets (bits), then you wouldn't need the Dlights.lua as any offset change would automatically trigger the corresponding lvar to be updated. 
I can't see how this is needed and should be removed - unless you can explain to me what this is doing (and by what)?

I don't really have experience in such a set-up and so cannot really advise on this any more at the moment. I will try and duplicate a similar set-up here, with one PC on windows 11 and another on windows 10. However, I cannot duplicate exactly as I only have one license for MSFS, and so would have to run FSUIPC on one PC as a client version, but the lua socket communication between the FSUIPC versions should be the same. I will try and similar offset exchange (broadcast and receive) via UDP to see what delay I experience, and will also try with TCP to see if that gives better performance.  I won't have time to do this until later this week though. I will report back once I have done this.

John

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.

 

[John Dowson]

1 hour ago, Sky Blue Flyer said:

Will be intetesting to see if the tcp  protocol brings any improvements. 

I don't think this will help much as, as I said, the delay seems to be with the lua unpack call. To confirm this, could you provide another log file for the client lua script, but this time without the lua plugin logging enabled (and don't run with lua debug) and amend the script slightly as follows to log in the scrip itself:

Quote

...

while 1 do
    ipc.log("Waiting for data...")
    raw = udp2:receive(nil)
    ipc.log("Data received...")
    data = vstruct.unpack("u2 u2", raw)
    ipc.log("Data unpacked...")
    --print( data[1] )
    --print( data[2] )

    -- write to local memory
    ipc.writeUW(data[1], data[2]);
    ipc.log("Data " .. data[2] .. " written to offset " .. data[1])
end
 

The time it takes for the UDP packet to be received is difficult to measure though. But if you keep the FSUIPC logging console window open on the client and monitor this, you should be able to gauge how long it takes between the button press to change the lights state on the server, and the data being received in the client. You can also add similar logging to the server broadcast lua, and also turn off Lua Plugin logging there.

However, looking at the server log, it also seems that the lua pack call is also taking around 3 seconds:

Quote

...
    20203 LUA: C:\FSUIPC7\BCastMemSvr.lua:20
...
    23484 LUA: C:\FSUIPC7\BCastMemSvr.lua:21
...
    23547 LUA: C:\FSUIPC7\BCastMemSvr.lua:20
...
    26656 LUA: C:\FSUIPC7\BCastMemSvr.lua:21
 

So that is roughly 3 seconds to pack the data, and 3 seconds to unpack the data. Given this, I don't think switching to TCP would help, especially as UDP is generally considered faster than TCP.

So I think it would be better to see if it is possible to eliminate or find an alternative to using those pack/unpack calls from the vstruct library.

[GSalden]

Hi John,

After shutting down the pc’s and later restarting them and MSFS with Prosim and SIOC again it did not work .

Sometimes after shutting everything down and restarting out of a sudden ( 1 out of 9 times ) it suddenly works. All programs need to run as Admin.

I found out that I have to run Prosim not as Admin to see all external lights working. When running Prosim as Admin the Taxi Light and RW TO lLights do not work in MSFS.

But FSUIPC only sees the switches moving when Prosim is running as Admin ( the occasional time it suddenly works )….  Otherwise nothing on the console window …

Reinstalled Prosim, FSUIPC, SIOC and the Prosim Flight Model.

 

[John Dowson]

You need to run everything at the same privilege level - if one program needs to be ran as admin, then you need to run everything as admin.

12 hours ago, GSalden said:

I found out that I have to run Prosim not as Admin to see all external lights working. When running Prosim as Admin the Taxi Light and RW TO lLights do not work in MSFS.

Even when MSFS is ran as admin? if so that is strange - I would ask about that on Prosim support.

[GSalden]

Thanks John. 
I have posted it too on the Prosim forum.

This morning after restarting Prosim and FSUIPC several times, once as Admin and another time not as Admin, it suddenly worked.

Restarting Prosim as a test and it did not work again as Admin.

[John Dowson]

Sorry for the delay - I had some windows issues with my external displays to my development laptop not being recognised via its docking station...

I have set this up on my network now - and I don't see any delays! The client FSUIPC version picks-up the offset change pretty much instantaneously (or at least in < 1s). I have no issues with the pack/unpack calls taking so long...

Are you running the luas in debug mode? If so, please don't do that. Also, can you turn off logging for Lua Plugins, and also turn off Log Lua Separately. Modify your lua client/server scripts to add logging using the ipc.log function, e.g. client

Quote

...
 

while 1 do
    ipc.log("Waiting for data...")
    raw = udp2:receive(nil)
    ipc.log("Data received: " .. raw)
    data = vstruct.unpack("u2 u2", raw)
    ipc.log("Data unpacked: " .. data[1] .. ", " .. data[2])
    --print( data[1] )
    --print( data[2] )

    -- write to local memory
    ipc.writeUW(data[1], data[2]);
    ipc.log("Offset updated")
end
...

server:

Quote

...
function OnMemoryChanged(offset, val)
    ipc.log("Offset " .. offset .." changed: " .. val);
    local datagram = vstruct.pack("u2 u2", {offset,val})
    ipc.log("Data packed: " .. datagram)
    udp2:sendto(datagram, host, port)
    ipc.log("Data sent")
end
...

Then show me/attach the FSUIPC7.log files from both client and server.
This is what I see in the logs, using offset 0x0264 (the pause indicator offset):
Server:

Quote

 ... 
3230453 LUA.1: Setting up UDP socket
  3230453 LUA.1: ServerTest lua running - monitoring pause indicator offset 0x0264
  3230469 LUA.1: Offset 612 changed: 0
  3230484 LUA.1: Data packed: d
  3230500 LUA.1: Data sent
...
  3311359 LUA.1: Offset 612 changed: 4
  3311375 LUA.1: Data packed: d
  3311390 LUA.1: Data sent
  3323625 LUA.1: Offset 612 changed: 0
  3323640 LUA.1: Data packed: d
  3323656 LUA.1: Data sent
  3628828 LUA.1: Offset 612 changed: 4
  3628844 LUA.1: Data packed: d
  3628859 LUA.1: Data sent
  3634578 LUA.1: Offset 612 changed: 0
  3634594 LUA.1: Data packed: d
  3634609 LUA.1: Data sent
  3848047 LUA.1: Offset 612 changed: 4
  3848062 LUA.1: Data packed: d
  3848078 LUA.1: Data sent
  3891469 LUA.1: Offset 612 changed: 0
  3891484 LUA.1: Data packed: d
  3891500 LUA.1: Data sent
...

Client:

Quote

...
    76297 LUA.1: beginning "E:\FlightSim\FSUIPC7-Client\Lua\ClientTest.lua"
    76312 LUA.1: Waiting for data...
...
   122218 LUA.1: Data received: d
   122218 LUA.1: Data unpacked: 612, 4
   122234 LUA.1: Waiting for data...
   165625 LUA.1: Data received: d
   165640 LUA.1: Data unpacked: 612, 0
   165656 LUA.1: Waiting for data...
   189078 EV_KEYDOWN received: 0x1B ()
   189078 KEYDOWN: VK=27, Waiting=0, Repeat=N, lParam=0 (0x0), Shifts=0
   189078 .. KeyDown received from FS but not programmed 
   189109 LUA.1: Data received: d
   189125 LUA.1: Data unpacked: 612, 4
   189140 LUA.1: Waiting for data...
   202828 LUA.1: Data received: d
   202843 LUA.1: Data unpacked: 612, 0
   202859 LUA.1: Waiting for data...
...

John