-
Which the release of FS2020 we see an explosition of activity on the forun and of course we are very happy to see this. But having all questions about FS2020 in one forum becomes a bit messy. So therefore we would like to ask you all to use the following guidelines when posting your questions:
- Tag FS2020 specific questions with the MSFS2020 tag.
- Questions about making 3D assets can be posted in the 3D asset design forum. Either post them in the subforum of the modelling tool you use or in the general forum if they are general.
- Questions about aircraft design can be posted in the Aircraft design forum
- Questions about airport design can be posted in the FS2020 airport design forum. Once airport development tools have been updated for FS2020 you can post tool speciifc questions in the subforums of those tools as well of course.
- Questions about terrain design can be posted in the FS2020 terrain design forum.
- Questions about SimConnect can be posted in the SimConnect forum.
Any other question that is not specific to an aspect of development or tool can be posted in the General chat forum.
By following these guidelines we make sure that the forums remain easy to read for everybody and also that the right people can find your post to answer it.
Detecting *Remote* FSX state
- Thread starter ZG862
- Start date
- Messages
- 112
- Country
Just as an addendum, it seems to me that for the 1st part (determining if FSX is running) I could use the Windows "Tasklist" command to return the process ID etc of any program running on a remote machine but my code would have to include an administrative password for that remote machine. I don't want to put that in a configuration file or hard code it but can't think of an elegant approach. After all, there's no getting away from the fact that I'm asking for privileged information...
Having established that FSX is running the next step is to establish its state and I haven't been able to find anything in the SimConnect documentation to help me with this.
Cheers,
Z
Having established that FSX is running the next step is to establish its state and I haven't been able to find anything in the SimConnect documentation to help me with this.
Cheers,
Z
I don't know if there's a "best practice" for that, but I'd suggest having an addon on the remote machine communicating with your main machine over some port. If the main machine queries the remote and gets no response, FSX isn't running. Then your remote addon would subscribe to SimStart and SimStop events and track which mode FSX is in. If it's stopped, the user is either paused or in the menus.
For detecting multiplayer mode, if that's not available through SimConnect you can maybe have the addon create a socket and try to bind it to the port FSX uses. If binding fails (socket in use) that should indicate the user is in multiplayer.
For detecting multiplayer mode, if that's not available through SimConnect you can maybe have the addon create a socket and try to bind it to the port FSX uses. If binding fails (socket in use) that should indicate the user is in multiplayer.
- Messages
- 112
- Country
Thanks Kabekew!
I've no idea why I failed to see SimStart and SimStop before now. However on looking up the syntax I also see MultiplayerClientStarted, MultiplayerServerStarted and MultiplySessionEnded functions that I'd also missed and they look like they are going to be useful for my project. I also discovered that there are Windows API functions (in PSAPI) that can return modules running on the local machine (which may be faster and a lot less faff than shelling the Tasklist command and parsing the response) but I can't find out how to query a remote machine with these functions. I suppose your idea of running something on the FSX machine could get around this but (for reasons I can't really articulate yet) I'm reluctant to add anything "non-stock" to FSX. Am I right in thinking that by running the code as an FSX addon it can only be running if FSX has started?
Very helpful thoughts though and I suspect that I'll end up down the socket route if I can't get any joy out of the Multiplayer_ functions.
Off to play with SimStart and SimStop,
Z
I've no idea why I failed to see SimStart and SimStop before now. However on looking up the syntax I also see MultiplayerClientStarted, MultiplayerServerStarted and MultiplySessionEnded functions that I'd also missed and they look like they are going to be useful for my project. I also discovered that there are Windows API functions (in PSAPI) that can return modules running on the local machine (which may be faster and a lot less faff than shelling the Tasklist command and parsing the response) but I can't find out how to query a remote machine with these functions. I suppose your idea of running something on the FSX machine could get around this but (for reasons I can't really articulate yet) I'm reluctant to add anything "non-stock" to FSX. Am I right in thinking that by running the code as an FSX addon it can only be running if FSX has started?
Very helpful thoughts though and I suspect that I'll end up down the socket route if I can't get any joy out of the Multiplayer_ functions.
Off to play with SimStart and SimStop,
Z
ddawson
Resource contributor
- Messages
- 862
- Country
Using SimConnect to connect to an FSX session on a remote computer is a matter of making sure that the setting specified in SimConnect.xml on the remote machine match the setting specified in the SimConnect.cfg file being used by the application on the client machine.
If the numbers match up correctly, then the ability, or lack thereof, to connect to the remote machine will tell you whether FSX is running on that computer or not.
The only configuration value that will likely be an issue will be the IP address of the remote machine. If the remote machine is an FSX server, then the users will need to have its IP address anyway, so it is just a matter of writing a small configuration utility to update SimConnect.cfg with the required values, including the current IP address of the server.
If you create an addon module for your FSX server, then yes, it will only be running if FSX itself is running on the host. If such a dll were in the business of accepting socket or named pipe connections, then the ability to establish such a connection would also indicate the presence of an active FSX session on the host.
In single user mode, the ObjectID of the user aircraft will be 1. In multiplayer mode, this value will always be greater than 1.
Doug
If the numbers match up correctly, then the ability, or lack thereof, to connect to the remote machine will tell you whether FSX is running on that computer or not.
The only configuration value that will likely be an issue will be the IP address of the remote machine. If the remote machine is an FSX server, then the users will need to have its IP address anyway, so it is just a matter of writing a small configuration utility to update SimConnect.cfg with the required values, including the current IP address of the server.
If you create an addon module for your FSX server, then yes, it will only be running if FSX itself is running on the host. If such a dll were in the business of accepting socket or named pipe connections, then the ability to establish such a connection would also indicate the presence of an active FSX session on the host.
In single user mode, the ObjectID of the user aircraft will be 1. In multiplayer mode, this value will always be greater than 1.
Doug
- Messages
- 112
- Country
Thanks Doug - great info.
I should explain my architecture:
My assumption is that on starting the simpit, it will always attempt to rejoin the simulation as though it had remained in session since it's last participation. If the Environment Server is not running FSX at that point then the simpit will start it. Code on the simpit will calculate the aircraft state then modify a template .flt file, load it on the server and then we're off, with the aircraft providing control inputs via SimConnect. (I've got this bit working nicely in prototype. Somehow it's weird that you can fly an aircraft from a machine not running FSX). Incidentally, the design abstracts the flight dynamics engine so that I could (at some future point) just feed the server with the 6D position of my aircraft - so I separate the control inputs from the instructions to change the visual state (e.g. elevator angle, flap position and so on).
I've also made provision for connection of this set up to an external multi-participant server which will (theoretically) allow interconnection of FSX and non-FSX clients. Lots of ambition, words and diagrams, no code yet beyond config file entries.
My original question stemmed from the desire for the simpit to work out if the ES machine is up, then if FSX is already running, then if FSX is in a state to load my .flt file. Arguably I could just remotely kill FSX regardless and start it with the flt file as a parameter but this lacks elegance and potentially increases the load time (the ES could already be sat is session waiting for the SimPit to return - in which case there would be no need to reload).
When it comes to using the IOS to change the simulation, I'm not sure yet whether I should have the IOS talk to the ES directly or do this via the aircraft. More thinking to do there.
The suggestions and comments are very useful though - keep them coming!!
Z
I should explain my architecture:
- There will be a multi-processor simpit (separate machines representing the various different processors of the real thing) which incorporates a SimConnect client machine. Processors will have access to configuration files that provide the IP and port details of other relevant machines.
- The FSX machine, primarily responsible for outside environment display. This dedicated Environment Server (ES) is the primary SimConnect server.
- There will be an instructor operating station (IOS) which will be able to control the simulation state (fundamentally the simulation time and object positions) and also talk directly to various aircraft components as required (e.g. to fill fuel tanks). As well as being a client to the ES, it is potentially another FSX station so that it may have a monitor to view the simulation. I figure that this is going to require operating in multiplayer mode so I can control the IOS camera independently from the (fixed) simpit display.
My assumption is that on starting the simpit, it will always attempt to rejoin the simulation as though it had remained in session since it's last participation. If the Environment Server is not running FSX at that point then the simpit will start it. Code on the simpit will calculate the aircraft state then modify a template .flt file, load it on the server and then we're off, with the aircraft providing control inputs via SimConnect. (I've got this bit working nicely in prototype. Somehow it's weird that you can fly an aircraft from a machine not running FSX). Incidentally, the design abstracts the flight dynamics engine so that I could (at some future point) just feed the server with the 6D position of my aircraft - so I separate the control inputs from the instructions to change the visual state (e.g. elevator angle, flap position and so on).
I've also made provision for connection of this set up to an external multi-participant server which will (theoretically) allow interconnection of FSX and non-FSX clients. Lots of ambition, words and diagrams, no code yet beyond config file entries.
My original question stemmed from the desire for the simpit to work out if the ES machine is up, then if FSX is already running, then if FSX is in a state to load my .flt file. Arguably I could just remotely kill FSX regardless and start it with the flt file as a parameter but this lacks elegance and potentially increases the load time (the ES could already be sat is session waiting for the SimPit to return - in which case there would be no need to reload).
When it comes to using the IOS to change the simulation, I'm not sure yet whether I should have the IOS talk to the ES directly or do this via the aircraft. More thinking to do there.
The suggestions and comments are very useful though - keep them coming!!
Z