WideClient ipc.read returns zero

[r2500]

I'm trying to write some lua code to be run in the WideClient environment. The problem I'm having is that all my ipc.readxx calls return zero. For instance, ipc.readSB(0x0238) should return the hour of the local time. I get zero (and it's only 9pm!). (WideClient connects

and that's evident in the log, and on the FSX window title).

Most of the read attempts have been within event handlers and I see the button presses and the code runs. I just get zero from the ipc read calls. I've tried setting the Log parameter in the WideClient.ini to "Yes", and while the button presses show up clearly, there's

nothing that suggests the ipc.readSB(xxxx) ran.

Is there some setup required before any ipc.readxx calls are made? ipc.log does run fine.

Richard

[Pete Dowson]

I'm trying to write some lua code to be run in the WideClient environment. The problem I'm having is that all my ipc.readxx calls return zero. For instance, ipc.readSB(0x0238) should return the hour of the local time. I get zero (and it's only 9pm!). (WideClient connects and that's evident in the log, and on the FSX window title).

Do other client programs work okay? Try FSInterrogate to read the same values -- that's the best test. Or even my TrafficLook or WeatherSet2 programs. Anything which reads FSUIPC offsets.

Close down FSUIPC and show me the FSUIPC Log file from the FS Modules folder.

Regards

Pete

[r2500]

Do other client programs work okay? Try FSInterrogate to read the same values -- that's the best test. Or even my TrafficLook or WeatherSet2 programs. Anything which reads FSUIPC offsets.

Close down FSUIPC and show me the FSUIPC Log file from the FS Modules folder.

Regards

Pete

FSInterrogate works fine both on the FSX machine and on the wideClient machine. I've discovered that my code will work correctly after FSInterrogate starts running. The sequence is 1) start FSX and wait until the default flight is loaded and running. Then start WideClient on the "slave" machine. This in turn will run the one lua file in that folder (gfDisplay.lua). This code seems work fine except that all ipc.readxx calls return zero. Then start FSInterrogate and when it finishes loading the database, my lua code begins to operate correctly. Exit FSInterrogate and my code continues to work. It's very much as if I'm missing a system call to unplug <g> the Server-Client connection.

WideClient logs "New Client Application: "FSInterrogate2std" (Id=7848) and the Individual client application activity section which contains just the Client 7848 summary with no other indication that there's other code wanting to talk across the link (but of course, it's a lua program run by WideClient so it's not really a client of WideClient).. WideServer log sees the connection and disconnection from WideClient. I've tried to attach the FSUIPC.log file, but the system says I'm not permitted, so here it is in-line:

********* FSUIPC4, Version 4.654 by Pete Dowson *********
Reading options from "F:\Flight Simulator X\Modules\FSUIPC4.ini"
Trying to connect to SimConnect Acc/SP2 Oct07 ...
User Name="Richard Wolff"
User Addr="rjwolff@gmail.com"
FSUIPC4 Key is provided
WideFS7 Key is provided
Running inside FSX on Windows 7 (using SimConnect Acc/SP2 Oct07)
Module base=61000000
Wind smoothing fix is fully installed
DebugStatus=255
  	156 System time = 06/02/2011 10:35:07
  	172 FLT UNC path = "\\GIUSEPPE\Documents\Flight Simulator X Files\"
  	172 FS UNC path = "\\GIUSEPPE\Flight Simulator X\"
  	952 LogOptions=00000000 00000001
  	952 SimConnect_Open succeeded: waiting to check version okay
 	9672 Running in "Microsoft Flight Simulator X", Version: 10.0.61472.0 (SimConnect: 10.0.61259.0)
 	9672 Initialising SimConnect data requests now
 	9672 FSUIPC Menu entry added
 	9719 \\GIUSEPPE\Documents\flight simulator x files\Bonanza in Tucson.FLT
 	9719 \\GIUSEPPE\Flight Simulator X\SimObjects\Airplanes\Carenado BONANZA F33A\Carenado_F33.AIR
	36738 System time = 06/02/2011 10:35:43, Simulator time = 10:35:16 (17:35Z)
	36738 Aircraft="BONANZA F33A BLUERED"
	43072 Advanced Weather Interface Enabled
   178809 Sim stopped: average frame rate for last 139 secs = 45.3 fps
   178809 Average weather filter write interval in that time = 1087.9 msecs

   185875 Weather Mode now = Custom
   185875 \\GIUSEPPE\Users\rwolff\AppData\Roaming\Microsoft\FSX\Previous flight.FLT
   477551 System time = 06/02/2011 10:43:04, Simulator time = 10:37:35 (17:37Z)
   477551 *** FSUIPC log file being closed
Average frame rate for running time of 139 secs = 45.3 fps
Average weather filter write interval in that time = 1088.2 msecs
Memory managed: 184 Allocs, 184 Freed
********* FSUIPC Log file closed ***********

Richard

[Pete Dowson]

FSInterrogate works fine both on the FSX machine and on the wideClient machine. I've discovered that my code will work correctly after FSInterrogate starts running. The sequence is 1) start FSX and wait until the default flight is loaded and running. Then start WideClient on the "slave" machine. This in turn will run the one lua file in that folder (gfDisplay.lua).

You can have WideClient running before FS is even started. In fact it tends to work better that way. On my Clients I have WideClient in the Explorer "startup" folder so it loads when the system starts.

Lua programs in the WideClient folder won't start until FS is "ready to fly" unless there's one called "Initial.lua" which will run when WideClient is started -- best not to do any ipc.reads or writes in such a file.

This code seems work fine except that all ipc.readxx calls return zero. Then start FSInterrogate and when it finishes loading the database, my lua code begins to operate correctly. Exit FSInterrogate and my code continues to work. It's very much as if I'm missing a system call to unplug <g> the Server-Client connection.

No, there's no such thing. I have several Lua programs on clients which read ipc offsets, and have not observed anything similar -- but then they are event driven, so would do things when offsets change. The PCs they run on also have several clients running, so I suppose they's help with the timing of data.

Note that there will always be all zeroes in the local WideClient data until WideServer has seen the read request and responded, but thereafter it will be kept updated. Maybe you are only reading once? For client programs, but not Lua, there's a hold-off parameter which stops WideClient returning to them within so many milliseconds when called to read a value for the first time. I think this is as much as 500 mSecs by default, but i'm not sure without looking. Because Lua plug-ins aren't clients they don't go through the same interface and instead simply read the memory direct -- it's a lot fast as you can imagine!

WideClient logs "New Client Application: "FSInterrogate2std" (Id=7848) and the Individual client application activity section which contains just the Client 7848 summary with no other indication that there's other code wanting to talk across the link (but of course, it's a lua program run by WideClient so it's not really a client of WideClient).

Correct. Lua plug-ins are just extensions of the program, and not visible as or counted as 'clients'. Their activities don't count in the application stats, only the overall performance stats there and in the WideServer log file.

I've tried to attach the FSUIPC.log file

That's why I always suggest pasting into a message, as you have done.

Anyway, the Log shows everything is fine.

If your program cannot handle initial zeroes in offsets I think you might want to code the first reads as "read all offsets wanted", "sleep(500)", "read them again". Or just use the offset event and ignore the first call.

Let me know. Incidentally, if you still have problems I could do with knowing what version number of WideClient you are using, please.

Regards

Pete

[r2500]

You can have WideClient running before FS is even started. In fact it tends to work better that way. On my Clients I have WideClient in the Explorer "startup" folder so it loads when the system starts.

Lua programs in the WideClient folder won't start until FS is "ready to fly" unless there's one called "Initial.lua" which will run when WideClient is started -- best not to do any ipc.reads or writes in such a file.

No, there's no such thing. I have several Lua programs on clients which read ipc offsets, and have not observed anything similar -- but then they are event driven, so would do things when offsets change. The PCs they run on also have several clients running, so I suppose they's help with the timing of data.

Note that there will always be all zeroes in the local WideClient data until WideServer has seen the read request and responded, but thereafter it will be kept updated. Maybe you are only reading once? For client programs, but not Lua, there's a hold-off parameter which stops WideClient returning to them within so many milliseconds when called to read a value for the first time. I think this is as much as 500 mSecs by default, but i'm not sure without looking. Because Lua plug-ins aren't clients they don't go through the same interface and instead simply read the memory direct -- it's a lot fast as you can imagine!

Correct. Lua plug-ins are just extensions of the program, and not visible as or counted as 'clients'. Their activities don't count in the application stats, only the overall performance stats there and in the WideServer log file.

That's why I always suggest pasting into a message, as you have done.

Anyway, the Log shows everything is fine.

If your program cannot handle initial zeroes in offsets I think you might want to code the first reads as "read all offsets wanted", "sleep(500)", "read them again". Or just use the offset event and ignore the first call.

Let me know. Incidentally, if you still have problems I could do with knowing what version number of WideClient you are using, please.

Regards

Pete

I understand that starting WideClient first is preferred, but for testing I need to stop, change code, restart and so it's convenient to let FSX just idle at the gate. Anyhow, WideClient is 6.841 and WideServer is 7.654. I've discovered that perhaps there's some merit in the notion that patience is a virtue: If I just wait for 22 seconds after WideServer/Client connect, everything starts working. I've measured it at 22 several times (ipc.read, if zero sleep 1000ms loop, if non-zero report loop count and exit loop), but I won't swear it's always that. Still, I can live with it though it would be nice to eliminate it, or at least know why it happens.

Richard

[Pete Dowson]

I understand that starting WideClient first is preferred, but for testing I need to stop, change code, restart ...

If you are doing this to test Lua plug-in changes, you can change the running Lua program whilst it is actually running, and when WideClient sees the change it will kill the running copy and load and run the amended one. This is a very useful and fast way to test things out.

If I just wait for 22 seconds after WideServer/Client connect, everything starts working. I've measured it at 22 several times (ipc.read, if zero sleep 1000ms loop, if non-zero report loop count and exit loop), but I won't swear it's always that. Still, I can live with it though it would be nice to eliminate it, or at least know why it happens.

There's a whole lot of initialisation of crucial values being requested and sent. If you've done a full log of the WideClient activities you'll have seen some of that. Whether it takes a few seconds or as much as what you are seeing tends to depend on the workload on the Server end. In my case, with 7 clients and FSX running on an i7 980X overclocked to 4.65GHz, it's about 5 or 6 seconds, though I' ve never timed it exactly.

Anyway, if the main reason this is an annoyance is because you keep restarting WideClient, don't. There's no need. It can run all day through any number of Lua changes and any number of FS restarts, as I do here on seven clients.

Regards

Pete