[Solved] XMLKeys for a joystick axis - proper usage?

Heretic

Heretic

Resource contributor
#1
#1
I want to extract values from a joystick axis with XMLTools' XMLKeys class, but it doesn't seem to work and the documentation and included examples are rather incomplete. Furthermore, the example containing the throttle control via spacebar and slider just won't work, no matter what.

Here's my code:
Code: 
'joystick:0:Slider:0' (>C:XMLKEYS:KeyName,string) (>C:XMLKEYS:KeyCaptureOn,bool)
(C:XMLKEYS:KeyValue,number) (>L:000 Slider Test, enum)
The axis is correct since movement is blocked in FSX with the key capture active, but the L: var is never updated.

What I eventually want to do with the values returned from the axis is processing for use in a custom L: var driven flap lever.
 
Last edited:
taguilo

taguilo

Resource contributor
#2
#2
Try assigning a script to the key controller:

Code: 
'joystick:0:Slider:0' (>C:XMLKEYS:KeyName,string) 
'  ' (>C:XMLKEYS:KeyString,string)
(>C:XMLKEYS:KeyCaptureOn,bool)
And the throttle control example works fine for me in FSX. Are you using the Boeing aircraft? or P3D v4?

Tom
 
Heretic

Heretic

Resource contributor
#3
#3
Seems I've run into the good, old "XMLTools stops partially working after 50 aircraft reloads" issue, because after a cold start of my PC, everything works again, including your 2D gauge example, my previously non-working key-based (e.g. Shift+F5) XMLKeys implementations and the code in my initial post.

Problem solved, I guess.
 
taguilo

taguilo

Resource contributor
#4
#4
Good to hear it works.
Actually aircraft reload is rather tricky, because all sim parameters are conserved but Lvars reset to 0, therefore some links between both vars might break leading to unwanted results. Besides, it seems memory data is not refreshed completely and this can make the sim hang or CTD after many reloads, like you can confirm.

Tom
 
spokes2112

spokes2112

#5
#5
Heretic said:
XMLTools stops partially working after 50 aircraft reloads
Click to expand...
From what I have tested and observed by logging is that simconnect kills itself after many reloads of the same aircraft..
I am assuming that XMLTools requires simconnect, so not a XMLTools thing. ;) A long standing "bug?" from MS.
 
ddawson

ddawson

Resource contributor
#6
#6
If you occasionally switch away from the subject aircraft, to another, rather than reloading the aircraft, does the countdown to self destruction get reset, or do you actually have to exit the sim?
 
spokes2112

spokes2112

#7
#7
Doug, will test thoroughly within the next few days..
IIRC many years ago when this cropped up (f-111 terrain following), once simconnect failed a restart was necessary,
nothing else helped.

Forgot to add - The FSUIPC control "restart simconnect" didn't work either.
So long ago, requires a new test.
 
Last edited:
Heretic

Heretic

Resource contributor
#8
#8
taguilo said:
Actually aircraft reload is rather tricky, because all sim parameters are conserved but Lvars reset to 0, therefore some links between both vars might break leading to unwanted results. Besides, it seems memory data is not refreshed completely and this can make the sim hang or CTD after many reloads, like you can confirm.
Click to expand...
Yup, got an outright corrupted flight situation after some reloads. Nothing but setting up the flight situation again helped.
Granted, this happens very rarely, but can be rather frustrating.



spokes2112 said:
Doug, will test thoroughly within the next few days..
IIRC many years ago when this cropped up (f-111 terrain following), once simconnect failed a restart was necessary,
nothing else helped.

Forgot to add - The FSUIPC control "restart simconnect" didn't work either.
So long ago, requires a new test.
Click to expand...
Same here. A sim restart is the only way to get SimConnect to cooperate again.

Since SC is nothing but a mere .dll somewhere in WinSxS, I wonder if it can be forced to start by anything else than the simulator at all.
 
ddawson

ddawson

Resource contributor
#9
#9
Heretic said:
...
Since SC is nothing but a mere .dll somewhere in WinSxS, I wonder if it can be forced to start by anything else than the simulator at all.
Click to expand...
Actually, you may have suggested a possible solution. It isn't the sim that will load the SimConnect dll, it is the add-ons that want to use it.
When I am testing my own stuff, I do so without loading anything else that will use SimConnect. I have all the modules that do set up in dll.xml to require confirmation before loading. I do this so that the SimConnect log file is not clogged with stuff I don't want to look at.
A bit of a pain, yes. However, what that means is that when I switch away from my test aircraft, there will be no SimConnect clients active, so the dll will be unloaded from memory. That's probably why I've never run into this issue myself.
I will also build an aircraft reload gauge that counts the number of aircraft reload events in a given session. At least you can know when you are getting close to a problematic number of reloads.
 
Heretic

Heretic

Resource contributor
#10
#10
I'm not sure about that. Since XMLTools are loaded at sim startup and therefor may use SimConnect at all time, loading a different (default) aircraft might not be a feasible fix.

Maybe reinitializing XMLTools after every aircraft reload might be a solution to the problem. Provided that it's possible in the first place...
 
ddawson

ddawson

Resource contributor
#11
#11
You're right, that wasn't it.
When SimConnect is initialized, there is a maximum number of clients value that is read from SimConnect.xml. It defaults to 64 if the value is not specified. This is the limit we're running into.
For IPv4 and IPv6 protocols, the maximum is 1000. I tried 1024 and the SimConnect log reported 1000 as the maximum value.
For Pipe, which local connections seem to use, the maximum value is 255. By setting this value at 255, I was able to reload a SimConnect gauge 255 times before it failed to connect.
Here is the SimConnect.xml file I was using:

Code: 
<SimBase.Document Type="SimConnect" version="1,0">
  <Descr>SimConnect Server Configuration</Descr>
  <Filename>SimConnect.xml</Filename>
  <Disabled>FALSE</Disabled>

  <!-- Example Global (remote) Pipe Server Configuration-->
  <SimConnect.Comm>
    <Disabled>true</Disabled>
    <Protocol>Pipe</Protocol>
    <Scope>global</Scope>
    <MaxClients>64</MaxClients>
    <Port>Microsoft Flight Simulator\sc1</Port>
    <MaxRecvSize>4096</MaxRecvSize>
  </SimConnect.Comm>

  <!-- Example Global (remote) IPv6 Server Configuration-->
  <SimConnect.Comm>
    <Disabled>TRUE</Disabled>
    <Protocol>IPv6</Protocol>
    <Scope>global</Scope>
    <MaxClients>64</MaxClients>
    <Address>fe80::f9a9:aed9:ca24:b3c1</Address>
    <Port>6112</Port>
    <MaxRecvSize>4096</MaxRecvSize>
  </SimConnect.Comm>

  <!-- Example Global (remote) IPv4 Server Configuration-->
  <SimConnect.Comm>
    <Disabled>false</Disabled>
    <Protocol>IPv4</Protocol>
    <Scope>global</Scope>
    <MaxClients>128</MaxClients>
    <Address>192.168.0.12</Address>
    <Port>6112</Port>
    <MaxRecvSize>4096</MaxRecvSize>
    <DisableNagle>True</DisableNagle>
  </SimConnect.Comm>

<SimConnect.Comm>
<Disabled>False</Disabled>
<Protocol>Pipe</Protocol>
<MaxClients>1024</MaxClients>
<Scope>local</Scope>
</SimConnect.Comm>

<SimConnect.Comm>
<Disabled>False</Disabled>
<Protocol>IPv4</Protocol>
<MaxClients>1024</MaxClients>
<Scope>local</Scope>
</SimConnect.Comm>

<SimConnect.Comm>
<Disabled>False</Disabled>
<MaxClients>1024</MaxClients>
<Protocol>Auto</Protocol>
<Scope>local</Scope>
</SimConnect.Comm>
</SimBase.Document>
The MaxClients tag for Pipe is listed as 1024, but the value that was used, according to the SimConnect log file, and my testing, was 255.
Still an improvement over 64.
Edit:
Here is the link to the aircraft reload gauge that will count your reloads:
www.douglassdawson.ca/files/dsd_fs_reload_count.zip
 
Last edited:
Heretic

Heretic

Resource contributor
#12
#12
That's extraordinarily great news 255 is quite an improvement indeed!

I gather that this is the make or break entry then.
Code: 
<SimConnect.Comm>
<Disabled>False</Disabled>
<Protocol>Pipe</Protocol>
<MaxClients>1024</MaxClients>
<Scope>local</Scope>
</SimConnect.Comm>
And what if there's an entry containing a protocol set to "auto", e.g.
Code: 
<SimConnect.Comm>
<Disabled>False</Disabled>
<Protocol>Auto</Protocol>
<Scope>local</Scope>
</SimConnect.Comm>
?
 
taguilo

taguilo

Resource contributor
#13
#13
Heretic said:
I'm not sure about that. Since XMLTools are loaded at sim startup and therefor may use SimConnect at all time, loading a different (default) aircraft might not be a feasible fix.

Maybe reinitializing XMLTools after every aircraft reload might be a solution to the problem. Provided that it's possible in the first place...
Click to expand...

Actually XMLTools uses kind of a singleton pattern for Simconnect. It means only one Simconnect link is open and used by all the gauges in a panel that need the connection. If a panel has no gauges calling SIMVARS class, there won't be anny Simconnect pipe open. When leaving aircraft's current session (by a/c reload, aircraft change, etc), Simconnect link is closed, Simconnect pointer released and object destroyed.
Problem is IMO (but I might be wrong) that FS does not actually free up memory used by the released SimCon pointer, so it remains taking place and therefore reducing VAS on each reload ; up to a point when there is not enough memory available for SimCon to open a new connection (though standard gauges may keep running).

Tom
 
ddawson

ddawson

Resource contributor
#14
#14
Bjoern: The 'Auto' entry will actually accept a maximum value of 1000, but the SimConnect client has to be coded to use it. In order to do that, one needs a SimConnect.cfg file, which of course, the end user can screw up.
I will think about this for some of my gauges.

Tom:
See my comments above. It's not so much running out of memory. The 'MaxClients' tag, to us, might suggest the maximum number of concurrent connections. However, it seems to specify the maximum number of connection attempts over the life of the FS session. I would be inclined to have XMLTools open a connection at module load time, and leave it open over the life of the session, rather than opening and closing with each instantiation of the SIMVARS class. Fortunately, this is likely a concern to coders and beta testers far more than it is to end users.
 
taguilo

taguilo

Resource contributor
#15
#15
Doug,

AFAIK, Simconnect is a Client-Server system, in which there is one server running and one to multiple clients connected to that server and requesting different type of info.

In a typical FSim session there is only one server running (simconnect.dll) and one to multiple clients - either individual gauges and/or modules- each one using a single connection at best, all running in the same machine.

If Simconnect is using a standard Client-Server logic, which I have to believe it is, there is a limit on the max number of concurrent connections the server can handle, and that seems to be managed by "MaxClients" tag; the server doesn't care about how many times a client connects/disconnects during a session (unless that particular client does have restrictions pointed out somewhere); it only controls that when a client request a connection there is a "slot" available for that.

Put into a basic example: You are at home and you need to work on a remote machine in your office using the Net; the remote machine is up and running from 9 AM to 9PM, and you want to log at 2 PM and work for 5 minutes, would you log to the server at 9AM, keep the connection open, at 2PM work for 5 minutes, leave the connection open and close it at 10 PM? I believe you'd rather connect at 2PM, do your stuff and disconnect immeditalely to free up your slot and used resources.

If, as you are suggesting, and it's probable that you are right, "MaxClients" is specifying the total connection attemps over the same session, that would be a serious bug in the logic of a C/S system.

Tom
 
Heretic

Heretic

Resource contributor
#16
#16
taguilo said:
Problem is IMO (but I might be wrong) that FS does not actually free up memory used by the released SimCon pointer, so it remains taking place and therefore reducing VAS on each reload ; up to a point when there is not enough memory available for SimCon to open a new connection (though standard gauges may keep running).
Click to expand...
In that case, SimConnect seems to use its own allocated memory since general FSX VAS is not the limiting factor when the connection fails.
 
spokes2112

spokes2112

#17
#17
Tom,

Not up my alley, based on what you wrote above & in a nutshell how I experience it.
On an aircraft reload it is not releasing it's slot, after the reload a new slot is opened.
1st load = 1 slot, reload = now 2 slots, reload = now 3 slots etc...
 
chris

chris

#19
#19
Can I assume the aircraft reload limit is related to the 'World' > 'Go to Airport' 50x bug/anomoly?
Before I do a country, I visit each airport checking for any problems that require me to fire up ADE.
On the 50th or 51st move, FSX first locks up, then CTDs.
 
spokes2112

spokes2112

#20
#20
Tom,

Hope this is what you wanted,
did a bunch of tests.

1) dll.xml unaltered, xmlTools loaded but not used by the test aircraft
2) the test aircraft (f-111) was used because it fails much earlier because of all other modules loaded by the panel
3) Doug created a specialty .dll for the 111, it has visual feedback in the panel to show that the system works - a fail lamp. ( IE reports a SC Fail )
4) logs were stopped right after SC fail
5) I do not have a simconnect.xml, running on default

tests 1 - 5 are simconnect logs and fsuipc logs - nothing really shows up there. Aircraft fails between 16 & 20 reloads. FSUIPC 1092 doesn't help.
test 6 - an aircraft reload, followed by a simconnect re-initialize (FSUIPC 1092) - after 10 of these a fail and FSUIPC menu disappears but continues logging, but shows connected!!?!! No controls thru FSUIPC work.
test 7 - just simconnect re-initialize (FSUIPC 1092) - after 25 of these the same as test #6

Again just assumptions since this is way over my pay grade.. I believe the "Client-Server system" is not releasing previously used slots on a reload.
Not really a problem since this mainly affects designers who are using the aircraft reload command.
Maybe will just help in understanding "what's going on".

Attached - SC Failure logs.zip (test #5 removed, "all FSUIPC offsets" for file size restrictions)
 

Attachments

Last edited:
You must log in or register to reply here.
Top