Possible solution for uncredited kills

[Buschwick]

I was over at the BMS forums and chimed in on a topic regarding logbook kills.  THIS post at BMS might explain it. 

Any way for the host to try to stay in 3d temporarily to see if that is, in fact, the reason that we only damage everything on the ground?

[Brain]

We had crazy warp issues and disappearing units before and it made playing almost impossible. I've heard about "force host ownership" (the host always calculating units instead of clients calculating in their own bubble) which might have caused the issue but never found the variable for it.

If we can find it and it turns out to be set to ON then we could test this, otherwise we would just be back to the warping thing again.

It's annoying but if you had a good mission the numbers in your logbook aren't going to change that.

[=VG= SemlerPDX]

The trade-off to forcing the host to stay in 3d cockpit would be extreme de-sync with other players and AI aircraft, as described by Brain.  I'm afraid we do not have the most powerful server out there, and we have to deal with what we have.  The way we have it set up now is the best that we can do as far as we know.  We are definitely open to suggestions and fixes that will improve this, but we have done a bit of testing on this, and the server runs it's best after launching by returning the host to the 2D debrief screen prior to it's scheduled takeoff time.

The "units only damaged in debrief" is a known issue, and it is known that the units are truly destroyed as shown by the 2D map after a mission. Brain mentioned a ownership variable but I it does not currently exist in the config file - I've had to add variables before that did not exist, but without the syntax of this var, I cannot add it.  If you find anything, let me know, we'd be happy to test something that might improve the server.

I've attached the VG BMS server config file if anyone wants to review it for options that may help.

falcon bms.cfg

[Buschwick]

I looked at it and found a line under "Dev Settings"

set g_bServer 0                 // This option puts FalconBMS into Multiplayer Server mode. A server mode session can't enter the 3D world

Wanna see what that does if you set it to 1?  It might simply force the server to only keep the connection open and  rely on clients' data for 3d action instead of the server being, technically, part of the action.

I've never messed with these setting as a host so I don't know what I'm talking about lol!

[Derk]

The BMS Manual lists two different 'server' type settings:

g_bServer

This option when set to 1 (enable) puts Falcon BMS into Multiplayer Server mode. A server mode session can't enter the 3D world. Available options: 0/1. Default = 0.

g_bServerHostAll

This option should always be set to 1 (Enabled). When enabled the MP host technically owns ALL units. When set to 0 the client requesting a unit to deaggreate will own it, making it responsible for distributing it over the network. Previous experience showed that this can minimize bandwidth demand on the host, but that it will create many more problems and sync issues. Options: 0/1.

***************

I've read various BMS postings about server and config settings enough to basically understand that trial and error may be the best method to solve a problem.   I'm up for whatever you want to try.  (Are we keeping a change log?  lol)

Also on a side note, for the past couple weeks the campaign has been void of Migs except for occasional pop-ups here and there.   Blue force seems to knock them down soon as they get up from the few bases left.   It is good for buddy lasing without interruption, but leaves missions a bit bland.  The overall campaign seems pretty stable now (except for the performance issues noted), but supplies seem to run low once it gets close to the end of week 2.  The human tanker squadrons have been fun - Thanks for the that addition.

Derk.

 

[Brain]

Thanks Derk for having a look at it!

g_bServer 
I think that's the option I read about being "not officially supported" either on BMS or FO. It shouldn't matter for us unless it frees up some resources (eg. not prefetching 3D data).

g_bServerHostAll
The description confirms that the server is supposed to be in 3D. You can only own a unit while in 3D.
I think this would be worth a try. With the server being on the map, clients have been "owning units" all the time and we hadn't had any game breaking issues. BW demand on the server shouldn't change too much either. Kadena is remote and only has the occasional support flights. There would also be a way to deactivate 3D rendering (2D still works I suppose).There would be this "player bump time" thingy as well that needed to be cranked up!

There is also mentioning of desync issues which is what I suspect is causing the issue in the first place. Just think about the crazy debriefings we have seen.

I'm not up to date on all the current settings but basically I'm a log with all the things we were able to dig up and change since .33
Agree on the tankers. Love seeing that KC-10 butt again! In a flight so much fun. So much eyecandy. So many screenshots. And it's more intense than most combat situations, because pressing pickle just doesn't help you much.

[=VG= BLuDKLoT]

I flew the other day and had to use the LAU HE rockets (because of my cursor slew problem) and noticed in the debriefing after my flight that I was rated excellent for destroying the target but had zeros for kills. Is this what you're talking about? I'm so out of the loop! ugh 

[=VG= SemlerPDX]

Yea, that's the issue... Debrief screen is not correctly showing units that the player destroyed as "destroyed", merely "damaged".  I believe this may be a core issue inside BMS itself, I've read about this problem on more than one server... It's not just us.

I also looked into all the server config variables when I set up the server, and afaik the settings are as good as they can get.  It's far better for the server plane to sit in the 2D map debriefing screen than to sit on the tarmac in a cold aircraft - far less rubber-banding and other lag issues.  For large flights with many pilots in different countries, on different continents, I suggest upping the max player bandwidth to 2048 instead of 1024, but truly we have not done any definitive testing on this - seems correct on paper, though.

[Brain]

The mission rating is something different. Say you do a SEAD mission, you take out all tracking radars along your route (successfully suppressing any AAA/SAM, accomplishing your mission goal) and still you would get a "horrible" rating. In case of SEAD (and others like CAS, AI ...) it seems to expect a certain kill count, not destruction of high value assets. This dates back to at least 4.33.6 but the problem at hand surely doesn't make it any better. Just mentally recap your flight and judge by yourself how well you did, then shout at BMS for simply being stupid.
 

On 7.9.2016 at 7:37 PM, Buschwick said:

[...] only keep the connection open and  rely on clients' data for 3d action instead of the server being, technically, part of the action

This is exactly what solved the lag/rubberbanding issue.

While the server is in 3D (assuming g_bServerHostAll = 1) it will calculate and distribute data about every active 3D object ("inside player bubble", 40nm or something) to every client in the area.
Think about a 1-ship flight along the FLOT early in the war: artillery guns on all HART sites, tanks, (mech) inf, command battalions, countless search radars, NOE scout helicopters and of course planes and any fired ordinance... on both sides. Even if you don't spot it visually, it's still all there and every single bit of it has to be dealt with by the server and sent to the client.
Next up a 2-ship in close proximity: The "bubbles" are mostly overlapping, so it's only a marginal CPU load increase at first, but BW usage doubles because of the 2nd client. I'm no expert but I suspect the OS/driver needs some CPU power as well to send data through the network adapter. Finally the AI has to take into account the actions of 2 players. Things start to pile up.
Just imagine 3 clients split into 2 packages, operating in completely different areas. And don't forget there is still a war going on in Korea. Hundreds of battalions have to move, flights have to fragged and flown ... yeah.

Currently (in 2D) the server simply can't do that, because the 3D part isn't running at all. It's "only" calculating the 2D campaign and sending updates about units that enter a client's bubble. From there the client himself will have "ownership" of the objects, calculating the AI and 3D coordinates, as well as distributing the data to others nearby*. There is some more traffic to and from the server (ie. campaign commander ordering a unit to retreat after taking fire) but it shouldn't be nearly as bad. It's server-ception!

*Note: that's why a P2P connection is so important. One CS player would relay ALL it's traffic through the server. When in doubt, reconnect.

Even though we drastically reduced server load there are still strange things happening like totally out of place battalions, particularly that one blue HQ. It seems its coordinates have been lost, causing it to spawn at the origin, in the center of the map. It happens in every campaign, could be just a minor save/load bug but shows that BMS has a black-out every now and then.
Which brings us back to our initial problem: what is happening with the data about destroyed units? -- I have no clue. Is the "owning client" struggling with the calculation? Is there kind of an invisible lag spike between server and client, causing data to be lost? Does the client send 'destroyed' and 'damaged' in quick succession and can the server not update fast enough? Any more questions?

As I said we could try the server in 3D with g_bServerHostAll = 0 set. Yes, it will increase resource demand on the server but as long as it can handle the traffic around Kadena and the 2D campaign it should be fine. Every "action scene" will still be handled by which ever client has "ownership" of the units involved. The whole point is to make sure the server "understands of the concept of 3D" or something. Maybe it fixes it, maybe it doesn't. Worst case: server crashes, probably only to 2D, at which point we are "back to normal". If it doesn't help, just leave it in 2D and restart as usual.

Just thought about a fast food chain for zombies called "Food for thought". It's stupid but kind of ironic, which could make it art with an uncertain level of comedic value.

EDIT: tried to get a flight in, did get "bad timing" on multiple F-16 squadrons at Osan and Seosan. No idea why, closed BMS in disbelief. Campaign is on day 26 so it's pretty much fighting for the left overs.

[=VG= SemlerPDX]

Okay, we'll try it.  

I've restarted the server campaign to Day 1, and altered the Day 1 ("new tankers by brain") save file.

I've altered the server config to turn  g_bServerHostAll = 1  to g_bServerHostAll = 0   and the server is now running from a 3D cockpit.  I can get into the server a number of ways, but using TeamViewer for example, the Task Manager shows BMS using around 20% CPU on the ramp in the cold cockpit but TeamViewer.exe is spiking the CPU to near 99% (using 55% +/- of the CPU) -- of course, logging out of TV and leaving the session should make it stable, as evidenced by the CPU usage track (set to slow update) in Task Manager.  I'll keep an eye on it, but even logging in to look at it could spike the CPU, so I will be doing so sparingly.

I'll check it this afternoon, and again in the evening.  Please keep a close eye on performance and issues while we test this, and report back here with anything (even seemingly inconsequential events) so we can review the data and make an evaluation of this test.

 

**I've also fixed the Tanker issue from before -- all 'Player Support Tanker Squadrons' no longer have HQ fragging, specifically the 908th.  Also, a small note - I thought 908th is out of Choongwon but I see it from Kadena as if it resides there.  Confusing, but a non-issue.

[Kaos]

Flew this afternoon as lead in a 2 ship package with AI wingman,  2 started the taxi out normally but after a few seconds it was warping and never got airborne.

[Brain]

First test flight with 4 JSOWs earned me the distinguished flight cross after 54 kills, so that went pretty well.
Second flight (quick SEAD) with AI wingman worked pretty well until I fired my first AGM-88. At this point I got a short time compression followed by a few second pause (blue message, server sided) and AI comms broke down completely. Didn't get AWACS (not even on UHF 13), tower, buddy calls, wingman, not even my own launch calls. Issuing orders however still worked (tested with "drop stores"). Engaged some bandits, checked on some Phantoms and none of them were lagging.
Talked to Kaos on TS and can't imagine why he had these issues. He's in Germany as well so we should have pretty similar connections. If there was a restart in between our flights, that might be why it worked OK-ish for me.

If you run into similar issues, try increasing your BW to 2048. If it still turns out to be unplayable ... well, at least we know how to theoretically fix the issue.

[Buschwick]

Glad it got looked into.  Been away for a while guys....it's a great sim and I hope the community stays patient while the smart ones get it figured out.

It's hard to express my appreciation of the hard work that's gone into F4.  It's absolutely incredible.

Thank you to all involved to bring this sim from microprose's release in '98 to what it is now nearly 20 years later.  Our community has set a standard in modern combat flight simulation that isn't rivaled and will, in my opinion, be the continuing and steadfast benchmark of what it takes to make a simulation of this magnitude into what we all love and continue to support.

P.S.  Is the sever down?  I can't join.  Pretty sure Brain crashed it if we're down.  He loads too many SDBs.

[=VG= SemlerPDX]

I just checked the server, it's up and running - Kaos was in-game at the time.
For the record, the server is once again operating from the 2D menu, our test from above did not work out.  A recent change was a config addition to try to force the server AI units to idle after 2 hours with no human player on the server.  It was restarted to Day 1 on Monday, so this is the first full test with the "idle" setting - we'll see if the campaign can get past day 12 now.