Claude Troncy Posted February 16, 2016 Report Share Posted February 16, 2016 Hello Pete, I need to initialize a data in the 66C0 free zone when my lua script starts from the WideFS client. I noticed I have to wait 18 seconds before the ipc.write succeed. After that each ipc.write is immediuate. I read that the write request from the client is not controled by wideserver, so I think there is something outside which cause this delay. It is not important, but you certainly have an explanation. The lua script init. print ("start") t = ipc.readUD(0X66C5) while t ~= 150 do ipc.writeUD(0X66C5,150) t = ipc.readUD(0X66C5) end print ("end") The log 5835 LUA: start 24321 LUA: end Cheers Claude Link to comment Share on other sites More sharing options...
Pete Dowson Posted February 16, 2016 Report Share Posted February 16, 2016 I need to initialize a data in the 66C0 free zone when my lua script starts from the WideFS client. I noticed I have to wait 18 seconds before the ipc.write succeed. After that each ipc.write is immediuate. Is this Lua script saved as "Initial.lua"? If so then it is run when WideClient is started, which could be long before there's even a connection. If you have named it something else, then whilst 18 seconds seems a long time, it can be significant. There is always a lot of things being exchanged between Client and Server when things start up and the connection is made. On top of that the Server is struggling to get enough time to run because FS signals that it is "ready to fly" quite early, before things have really finished fully loading. If you want to see all the things happening in WideClient when it connects, set Log=Debug in the [user] section of the WideClient.ini file. For you need to have 66D5 initialised to 150 at the start, I'd strongly recommend you do that on the Server, in the ipcReady.lua plug-in, which is automatically run. I do all of my offset and other initialisations there. This simplifies matters for all Clients. Pete Link to comment Share on other sites More sharing options...
Claude Troncy Posted February 16, 2016 Author Report Share Posted February 16, 2016 Is this Lua script saved as "Initial.lua"? No it is not. For you need to have 66D5 initialised to 150 at the start, I'd strongly recommend you do that on the Server Yes that's why it is not a big problem... But during the development process I thought it was easier to do it from the client. Claude The log After startup, during 18 seconds I have repeatedly this in the log file. 24320 MyReadStateData succeeded <M0:L0:C1:H253> 24320 MyWriteStateData failed all retries! <M0:L0:C1:H253> 24320 LocalReadWrite Entry <M1:L0:C1:H253> 24320 Local message entry <M1:L0:C1:H253> 24320 Processing request now ... <M1:L0:C1:H253> 24320 Exiting ProcessRequestData <M1:L0:C1:H253> 24320 FS6IPC message Exit2 <M1:L0:C1:H253> 24320 MyReadStateData succeeded <M0:L0:C1:H253> 24320 MyWriteStateData failed all retries! <M0:L0:C1:H253> 24336 LocalReadWrite Entry <M1:L0:C1:H253> 24336 Local message entry <M1:L0:C1:H253> 24336 Processing request now ... <M1:L0:C1:H253> 24336 Exiting ProcessRequestData <M1:L0:C1:H253> 24336 FS6IPC message Exit2 <M1:L0:C1:H253> And suddenly 24336 MyReadStateData succeeded <M0:L0:C1:H253> 24336 LocalReadWrite Entry <M1:L0:C1:H253> 24336 Local message entry <M1:L0:C1:H253> 24336 Processing request now ... <M1:L0:C1:H253> 24336 Exiting ProcessRequestData <M1:L0:C1:H253> 24336 Adding Request Block now ... <M1:L0:C1:H253> 24336 Exiting ProcessRequestData <M1:L0:C1:H253> 24336 FS6IPC message Exit2 <M1:L0:C1:H253> 24336 MyWriteStateData succeeded <M0:L0:C1:H253> 24336 MyReadStateData met from local memory <M0:L0:C1:H253> 24351 In MessageLoop <M0:L0:C1:H256> 24351 MYSENDREQ Entry <M0:L0:C1:H255> 24351 MYSENDREQ [ok=1] send() done: 27 of 27 bytes <M0:L0:C1:H255> 24351 MYSENDREQ Exit <M0:L0:C1:H255> 24351 In MessageLoop <M0:L0:C1:H255> 24351 WSA_READ Entry <M0:L1:C1:H255> 24351 WSA_READ FD_WRITE <M0:L1:C1:H255> 24351 WSA_READ Exit1 <M0:L1:C1:H255> 24367 In MessageLoop <M0:L0:C1:H255> 24367 WSA_READ Entry <M0:L1:C1:H255> 24367 WSA_READ FD_READ <M0:L1:C1:H255> 24367 GetRecv() gets 47 <M0:L1:C1:H255> 24367 GetRecv() packet 47 <M0:L1:C1:H255> 24367 WSA_READ ProcessResponse <M0:L1:C1:H255> 24367 GetRecv() done, zero <M0:L1:C1:H255> 24367 WSA_READ free buffer <M0:L1:C1:H259> 24367 WSA_READ Exit2 <M0:L1:C1:H259> Link to comment Share on other sites More sharing options...
Pete Dowson Posted February 16, 2016 Report Share Posted February 16, 2016 After startup, during 18 seconds I have repeatedly this in the log file. 24320 MyReadStateData succeeded <M0:L0:C1:H253> 24320 MyWriteStateData failed all retries! <M0:L0:C1:H253> That can really only mean that it is getting no answer from the Server. It's probably simply because things are still pretty busy at that end. You could do similar logging in WideServer too (the parameter goes into the WideServer section of FSUIPC4.INI in that case), but I'm not sure how much you'd learn from it. Pete Link to comment Share on other sites More sharing options...
Claude Troncy Posted February 16, 2016 Author Report Share Posted February 16, 2016 but I'm not sure how much you'd learn from it. You are right... Just for info I can see all my read Read: Offset=66C5, Size=0004 and 18 seconds after the first one Write: Offset=66C5, Size=0004 between each read a lot of 43150 WM_MYSEND: Sent 46 bytes (timectr=0, i=1, blocked=0) (skt=5476) TCP 43150 LAN Data Sent (skt=5476) TCP PREQ ulSize=35, ulTime=121, uSum=3281, fUsed=0 60 05 00 FE 0C 00 E4 12 E2 09 72 A1 52 00 50 AC 62 3C FC 0F 00 FE 01 00 C2 24 C8 00 FE 04 00 C2 FA 0C 00 and no error... So as you said certainly a lot of things to do on the server side Claude Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now