Question on Initial.lua I(Widefs)

[Pete Dowson]

The first sound is executed, but the offset in not set back to 0, and also the macro and the other offset read into the script are not executed.

I don't know what is going on with your system. I don't have your sound or your macros, so I adapted your Lua. I have this:

Aiuto=0
--------------------------------------------------------------------------------------------
function SOS(offset,value)
   if value == 1 then
	  ipc.writeUB(0x66c5,0)
	  sound.play("d:\\fsx\\sound\\geardown.wav")
	  ipc.sleep(50)
	  sound.play("d:\\fsx\\sound\\gearup.wav")
	  ipc.sleep(50)
	  sound.play("d:\\fsx\\sound\\geardown.wav")
	  ipc.sleep(100)
	  gnd=ipc.readUW(0x366)
	  ipc.log("gnd = " .. gnd)
	  if Aiuto == 0 then
		 sound.play("d:\\fsx\\sound\\gearwarn.wav")
		 Aiuto=1
		 ipc.macro("wilcoseat:ON")
		 return
	  end
	  if Aiuto == 1 and gnd == 0 then
		 sound.play("d:\\fsx\\sound\\GPWS_sink_rate.wav")
				 ipc.macro("wilcoseat:ON")
	  end
	  if Aiuto == 1 and gnd == 1 then
		 ipc.macro("wilcoseat:OFF")
		 NoAmbience=1
		 sound.play("d:\\fsx\\sound\\GPWS_pull_up.wav")
		 ipc.keypress(69,1)
		 sound.play("d:\\fsx\\sound\\GPWS_Dont_sink.wav")
	  end
	end
end
-------------------------------------------------------------------------------------------
event.offset(0x66c5,"UB","SOS")[/CODE]

The macro calls in this won't actually do anything, but the sounds I substituyed are from an FSX installation on my client. I added a log for "gnd" to make sure that was seen (it s -- see log below).

On my server I assigned "TAB+S" to set 66C5 to 1, like this:

38=83,24,x010066C5,x01

Then, when I press TAB+S I get this log in FSUIPC:

[CODE]
820766 KEYDOWN: VK=9, Waiting=0, Repeat=N, Shifts=16
820766 .. Key not programmed -- passed on to FS
821141 KEYDOWN: VK=83, Waiting=0, Repeat=N, Shifts=16
821141 IPC Offsets Control: Ctrl=x0100, Length=1, Offset=66C5, Param=x1
821141 .. This key is programmed in FSUIPC4 'Keys' options
821172 Monitor IPC:66C5 (U8) = 1
821250 KEYUP: VK=9, Waiting=0
821297 Monitor IPC:66C5 (U8) = 0
821297 KEYUP: VK=83, Waiting=0[/CODE]

and the assorted sounds play (the geardown/gearup/geardown\gearwarn ones more or less play al at once since the 50 msec sleep is so short compared to their length).

On the next time I press TAB+S, the same initial sounds occur but with "pull up" and "dont sink" also played simultaneously. Every time after that it's the same, of course, because your code never resets Aiuto to 0.

Here's the log form the Lua program on the Client:from several separate loads:

[CODE]********* LUA: "test" Log [from WideClient] *********
Date (dmy): 14/01/12, Time 00:19:29.437: Client name is FSXBEAST
784313 LUA: beginning "D:\WideClient\test.lua"
820407 LUA: gnd = 1
1227657 LUA: gnd = 1
1253094 LUA: gnd = 1
1384750 LUA: ended "D:\WideClient\test.lua"
********* LUA execution terminated: Log Closed *********

********* LUA: "test" Log [from WideClient] *********
Date (dmy): 14/01/12, Time 00:29:29.921: Client name is FSXBEAST
1384797 LUA: beginning "D:\WideClient\test.lua"
1406860 LUA: gnd = 1
1510813 LUA: gnd = 1
1570344 LUA: ended "D:\WideClient\test.lua"
********* LUA execution terminated: Log Closed *********

********* LUA: "test" Log [from WideClient] *********
Date (dmy): 14/01/12, Time 00:32:35.515: Client name is FSXBEAST
1570391 LUA: beginning "D:\WideClient\test.lua"
1574219 LUA: gnd = 1
1584907 LUA: gnd = 1[/CODE]

At no time did anything go wrong. It is 100% consistently working!

All this stuff is rock solid in many applications I have in my own cockpit, which uses 8 client PCs and lots of little plug-ins all over. i really don't understand what is going on on your setup.

BTW, you Lua script contains the line "NoAmbience=1" which doesn't appear to relate to anything else at all.

I launch the script and the first sound is executed, no offset write,no offset read, no macro,no ipc.display (that I have put to better test).

After that if I manually set in fsx the offset again to 0 and click the key the next correct sound is played,the write offset,the read offset,themacro and the display are correctly executed.

What can this mean?

Sorry, I've no idea. I think you should do two things:

1. Add logging to each path through your Lua,

ipc.log("message")

to tell you it's been through that path. You can log variables, as I did for 'gnd':

ipc.log("gnd = " .. gnd)

Also, add logging in your WideClient.INI file. I assume you ARE using WideClient version 6.90? Please double check -- look in its log.

set

Log=Yes

in the [user] section of the INI -- it will log all offset reads and writes.

Regards

Pete

[Pete Dowson]

At no time did anything go wrong. It is 100% consistently working!

I managed to make it go wrong by trying to trigger the action (pressing the keys on the server) before the sounds etc had finished.

The problem then is that the event for the offset never triggers because by the time the Lua plug-in has finished, the offset is 1 again -- no change from last time.

Once it is tested as being 1 twice it can never re-trigger the offset event, so your routine can never reset it to 0. The whole idea is really rather frail when you think about it.

I think that rather than test for 1 and reset to 0 you should simply increment the offset, and act on any value once it changes. The only problem then is that it will be triggered initially without you doing anything on the server. The way around that is to do this:

firsttime = 1

function SOS()
    if firsttime == 0 then
       .... all your actions (no need to test 'value')
   end
   firsttime = 0
end[/CODE]

BTW, additionally, when you read an offset for the first time in a client, there could be up to 500 mSecs delay whilst the client asks the server for it. Thereafter it is very fast -- the server simply keeps the client up to date. Some of your apparent ground reading problems may have been due to this delay. You can get around this by deliberately reading any offsets you want at the start, ignoring the values.

i.e. add

ipc.readUW(0x366)

to Aiuto=0 and firsttime=1 at the beginning.

Try it. Use "offset ubyte increment" with a parameter of 1 and your offset as needed. This is just to make it change. It doesn't matter about the actual value of course.

Regards

Pete

[cellular55]

Hi Peter,

thanks again for all your support and attention.

I do not know if this can make sense to you, but (crossing my fingers) it seems that the issue has been solved putting as first command of the script an ipc.sleep that I have now fixed at 20 seconds.

The strange thing is that if Ido not put that command, even if I wait still longer time before to push the first key activating a function in the scripts, the script has the usual bad behavior.

With the ipc.sleep as 1st command the script goes fine and also other functions that I have put there reading and writing different offsets or executing different macros.

I will try to experiment shorter sleeping (10 or 5 second for example), but I would like to know your point of view.

Thanks again abd best regards

Joe

[Pete Dowson]

I do not know if this can make sense to you, but (crossing my fingers) it seems that the issue has been solved putting as first command of the script an ipc.sleep that I have now fixed at 20 seconds.

The strange thing is that if Ido not put that command, even if I wait still longer time before to push the first key activating a function in the scripts, the script has the usual bad behavior.

No idea why that should be. Did you not try my suggestions which I think would be much more reliable?

Regards

Pete

[cellular55]

Hi Peter,

also your suggestion is creating strange behavior on the scipt (and anyway also the delay I put).

I'm deciding to manage things through a VB program using and adapting the interfaces for VB that are in the download links.

For what you know those interfaces are valid also through widefs? In other words I can read and manage offsets in a VB program running on the client PC?

Thanks and best regards

Joe

[Pete Dowson]

also your suggestion is creating strange behavior on the scipt (and anyway also the delay I put).

I don't see the delay as any sort of solution in any case. But the solution I suggested works 100% here.

For what you know those interfaces are valid also through widefs? In other words I can read and manage offsets in a VB program running on the client PC?

Yes. The FSUIPC interface is replicated by WideClient on the client PCs. That is exactly what it is for!!

Pete