Reconnecting

[Aerospace]

Greetings,

What a brilliant piece of software! I am truly enjoying this community!

My only problem is when I lose my connection to the server, whether it be the Flight Monitor software crashing or my computer crashing, that's it. You lose all your progress and the flight that you've booked. Horribly frusterating at towards the end of a flight. I'd like to be able to reconnect within say a 5 or 10 minute window and continue my flight. There has to be a way for the server to see a broken connection (or recognize a connection that dumps during a phase where the aircraft is in the air) and wait for a period while it looks for a reconnection by the pilot client before dumping everything.

Just my $0.02 worth...

Cheers,
Jim

[cmdrnmartin]

Seconded.

[Matthew]

i third that!, would be very usefull

[Ionathan]

Actually the problem is not a connection loss to the server as you don't have to be online during the flight, but a bug of the client which causes the crash.
Being able to restart the client enroute is something I want as much as everyone since losing the whole flight is really frustrating but it leaves FlyNet vulnerable to expoitation. While the client is running, the "Aircraft" option is deactivated. After it crashes it becomes active again. During those 5-10 minutes period during which the pilot restarts the client to continue the flight, he could also refuel the aircraft on air even invent client crash events for that purpose...

In addition, when the client crashes, the aircraft continues its route, at least until you pause FS, restart the client (if the functionality suggested was implemented), un-pause and continue. This means the aircraft would "jump" on its route to a new position, according to the client. If sequential client crashes were "invented" by the pilot, the aircraft could reach to its destination in significant less time having burned significantly less fuel. Of course this would be reflected in the pirep and everyone could see it but who could we accuse of "facing many client crashes in a flight"?

I know I may look too suspicious but although we feel confident on our current members ethics as we virtually know each other more or less, we must be prepared for the future when (hopefully) masses will join FlyNet.

All in all I support some kind of solution to the problem of losing flights because the client crashed. Let' sjust try to find a secure method.

[Aerospace]

Actually the problem is not a connection loss to the server as you don't have to be online during the flight, but a bug of the client which causes the crash.
Being able to restart the client enroute is something I want as much as everyone since losing the whole flight is really frustrating but it leaves FlyNet vulnerable to expoitation. While the client is running, the "Aircraft" option is deactivated. After it crashes it becomes active again. During those 5-10 minutes period during which the pilot restarts the client to continue the flight, he could also refuel the aircraft on air even invent client crash events for that purpose...

In addition, when the client crashes, the aircraft continues its route, at least until you pause FS, restart the client (if the functionality suggested was implemented), un-pause and continue. This means the aircraft would "jump" on its route to a new position, according to the client. If sequential client crashes were "invented" by the pilot, the aircraft could reach to its destination in significant less time having burned significantly less fuel. Of course this would be reflected in the pirep and everyone could see it but who could we accuse of "facing many client crashes in a flight"?

I know I may look too suspicious but although we feel confident on our current members ethics as we virtually know each other more or less, we must be prepared for the future when (hopefully) masses will join FlyNet.

All in all I support some kind of solution to the problem of losing flights because the client crashed. Let' sjust try to find a secure method.

Ah, I didn't realize you could fly flights offline. Well, that's way better, but makes the suggested fixes client side based then.

You raise very valid points in your response, and I agree with them. I don't think you're being too suspicous since historically we know that there will always be a few rotten apples in the barrel and steps should be made to protect the ones who regard this hobby seriously from the ones who don't.

Perhaps there would be a way for the client software to establish some kind of a continuity check to allow a reconnection, for example, fuel, by constantly writing out a log file that contains all kinds of flight parameters and time stamps. One of your points is that the pilot could use the down time to refuel the airplane, which as we all know, if there is a way to exploit something, somebody will always try. So, somehow the log file should keep tabs on the fuel state of the aircraft while it's on it's journey, so when the pilot client crashes, the fuel state is somehow registered at the point of the crash. When the client tries to re-establish the connection, it would check fuel state. If the fuel amount is greater than what it was at disconnect, then the log file would tell the client to send up a warning and refuse the re-connect attempt, and if the fuel state is equal or less, then it would authorize the re-connect. The same could be done with other parameters, such as location, time enroute, altitude and distance from origin or destination.

To address the multiple pilot controlled "client crashes", if the above checks don't catch it, then perhaps there should be a limit on the amount of reconnects that any pilot gets. Currently since one crash is all we get, it's hard to know how many crashes one would experience over the course of a single flight. Perhaps a limit of three reconnect attempts would be all that is allowed for any single flight? Or, maybe depending on how long the flight is, there would be a number assigned to total distance, ie. a 300nm flight gets 2 reconnects while a 1600nm flight might get 5? That with say a 2 or 3 minute time limit on a reconnect attempt won't solve every issue, but it hopefully would at least narrow the window for cheating.

Another option, which is pretty intrusive to flightsim, although it's on Konny's To-Do list, would be to install a .dll file in the modules folder of flightsim that would be a way to communicate with the client software running in the background. You could use a dropdown menu to start and stop a flight. What this could do would be to allow Konny to put a checks and balance system in place between flightsim and the FlyNET client. The purpose for this would simply be this, if flightsim loses contact with the client software, for whatever reason, flightsim pauses and locks out all the dropdown menus with the exception of the Modules menu. In order to unpause flightsim, you would either establish a reconnection with the client or quit your flight. The downfall would be if one were flying online and the FlyNET client went away, then there you would sit on final approach, frozen in mid-air, in everybodies way.

Anyway, just some thoughts since no matter how bulletproof the software is, there will always be issues that would cause the pilot client to go away. For me, I run the FlyNET client on a second computer via WideFS. Works great, but my second computer crashed and took down all that I was running on it. That's not the fault of the software, and will always be a possibility for the future, so being able to reconnect in my opinion needs to somehow be addressed, and as Nikos has pointed out, also needs to be developed so that the system can't be taken advantage of. I don't think there is any "completely foolproof" way of locking the software from being completely cheatproof, but let's try and make it as hard as possible.

Cheers,
Jim

[cmdrnmartin]

Konny, could there be a "Fly Flight Offline" option where the program doesnt even try to connect to the internet after its been pushed? At the end of the flight, you could reconnect, then push Transmit and send the flight report in. It might solve some problems several users have been having.

[Konny]

Ok, I'll think about a good system to make it possible to resume a flight where something crashed. But as always, this will need some time

@Justin
It's already possible to fly completely offline. You just need to look up the flynet.ini in your windows directory and change the tracker value from 1 to 0. I think I already wrote this in the news forum some time ago.

[cmdrnmartin]

I must pay more attention to your posts Konny!

I'll put your snippet in the help post as well.

Cheers!

[cmdrnmartin]

No crashes with the client, but I just flew too flights, and although my aircfraft and pilot were moved respectively, there is no other indication that the flights occured... Ie no profit, no pirep, nothing. This has only happened since I changed the transmit options value to 0. Have any ideas as to what may be the cause Konny?

[Ionathan]

One of my pilots experienced the same in a flight. He had changed the transmit value to 0 as well.

[cmdrnmartin]

If you want a log.out Konny, i have one for you.

[Konny]

Ah, I got it. The client always gets the current timestamp-value from the database together with sending the tracking-data. When the tracker is off, it doesn't get the timestamp ( which is then set to 0 ).
The affect is, that you actually get the money and a flight report BUT the time is shown wrong ( 1.1.1970 I guess ). If you scroll back to your first flightreport and financial entry you'll see that.
I'll fix that with the next release.

@Justin
I already fixed your last flight.

[cmdrnmartin]

Oh, ok, wasn't asking for a fix (Im really not concerned with the profit aspect, just bug-finding right now) but thanks regardless!