Hey guys -
pretty sure (90%) I found the issue with the false timeout dc's
Here's what's going on:
When I receive data on the socket it isn't perfect yet - I can see I made an error in regards to getting the packet size. I need to receive 4 bytes but there's no garuntee of getting all 4 at once, so I need to loop back until I get all 4 bytes. There's an error with my code though and if the data received was NOT 4 (anything less, which can happen and I have to loop back and do it again) the original data I received in the first pass was lost. This means that the packet size is then corrupted to some completely random number, and then the receiver tries to read millions of bytes from the socket. This would take a lot of time and during this time no "data" is received into the flow of the program itself - timing you out... So you sit in limbo until OYS kicks you from the main thread.
In laymans terms: Imagine the packet to receive is: "ABCDEFGH" and the size part of that is "ABCD", 4 bytes. Normally I try and get the size from the socket and it gives me "ABCD" which is right but sometimes I get "AB" and need to go back and get "CD". Problem is my code instead gets: "CDEF" as the size and that screws everything up.
TLDR: Size of packet calculations are corrupted in some circumstances, needs to be re-written.
Expect a fix tonight me thinks - not a major change as my method is correct just numbers are wrong.
---
In other news:
Experimented with ejection from aircraft - doesn't work very well as I have to wait for the user to return to the console screen before assigning them a new aircraft... it's not smooth and it just doesn't work well - might can the idea - sorry, I tried!
Fixed a bug where changing field renames the console as well... not sure how that line of code got in there to be honest.
Fixed a bug where aircraft spawning on the ground at certain airfields would immediately self destruct - GEAR needs to be DOWN by DEFAULT in YSF - in the STP definitions CTRLLDGR(?) can be true or false or NON EXISTANT, which i wasn't catching which is true. A boolean in C# defaults to FALSE so on a map like small_map, if you look at the STP lines there is no CTRLLDGR entry, and the bool was default false - gear must be up, which was wrong. fixed now.
Fixed a bug with packetlogging - was logging 4 instead of 5 packets - minor fix.
Added an emergency fix to the socket receiver - if the size is > 8192 or < 0, there is a corruption. I then receive ALL the data available on the socket as garbage so to flush it and try again. This DOES mean lost data but with YSF's redundancy methods it should be able to recover - at this point though it's much like CPR - the socket is so corrupted the connection may as well be dead, this it to try and get the data back on track. Success margin slim... I'll add a counter method for the corruptions as well and if 3 passes, kick the client due to fatal data corruption.
Another note: I
added a "loading screen" a while back to OYS so those running a corrupt version of OYS (lost dll's etc) you should get some resembalance of an error message now. Vic Viper this should help you especially.
--- whew. Lots of tech talk! Anyways, hopefully I can have a reliable solution for you all tonight.
After the update tonight I think we'll be in good standing in regards to stability again!
I am an accountant working full-time (and some). I'm not here as often as I would like to be. Send a message if you need me. There are a few people in the community who can get in contact with me urgently if you need - don't be afraid to ask. I just don't check here as frequently as I used to. Sorry!