Page MenuHomeFeedback Tracker

v2.04 "receiving data" progress bar gets stuck early
Closed, ResolvedPublic

Description

Aside from "Why A3 doesn't support HTTP-download? Half-Life came with this feature back in 1998." and "Why downloading MP mission starts slow and speeds up over time?" this is some actual bug report:

The "receiving data" progress bar gets stuck rather early (for a 45MB mission (quite a lot of custom content) around the 3MB mark) and the GUI "hungs up" while the game in fact is still downloading the mission from the server, there's just no graphical representation of it.
The "issue": As the GUI "hangs" when clicking a few times the "application stopped responding" pops up until the mission is downloaded and loaded - then the game gets back to normal behaviour.

Yes, I did used the search function with both "progress bar" and "receiving data" - but couldn't find any existing report - so apologies if this is a duplicate to some other report - I wasn't able to find it.

As just a side note, not actual part of the report: It always bothered me why A3 doesn't support mission loading via HTTP(S) - even Half-Life1 supports it (although only HTTP - HTTPS only came with rather recent Source updates) - and this game is back from late 1998. Also: Although I'm aware of Nagle's algorithm this only affects TCP - but as far as I understand the mission is loaded over UDP game port - so it doesn't make any sense the first couple MB takes forever cause it loads with only a few kb/s - and when you pass the 100MB mark you already load with over 1MB/s+ - WHY? Aside from "intended throttling" to me there's no real explanation. Either go full speed from the start or throttle it to a fixed speed.
And as A3 is closing in its 10th anniversary it's maybe too late for this engine (although I guess A3 is still played even when the next major game comes to stores - so even a late addition would be beneficial) this should considered to be an option in the new engine / netcode from beginning.

Details

Severity
Minor
Resolution
Open
Reproducibility
Always
Operating System
Windows 10 x64
Category
Multiplayer
Steps To Reproduce
  1. start A3 v2.04
  2. join some server with a big mission file (like 50BM+)
  3. see how the progress bar gets to about 3mb - and then just "freezes up"
Additional Information

Mission size doesn't matter - it happens to small (about 3mb-5mb) missions as well as to rather large ones (50mb+) - progress bar gets stuck somewhere in the first quarter.

Event Timeline

you would need to upload your server configuration (server.cfg, basic.fg, etc) plus sample missions without mods to be able to reproduce this

Well, I had to cut it down to stay in the "not polite - but not yet aggressive enough to reason for a ban"-realm:

I will not start to try to argue about why this "I've just copied over this line from the guide"-line doesn't make sense here at all - I don't know how much you know about basic coding practices when dealing with GUI and long term network traffic - but someone responsible for this bug surely should have another couple of reads of some "one step above beginner level"-style of books for the used language.

If you really insist on some samples: You could either a) go the easy route - just fire up the game and join ANY RPG server not require additional mods ... or b) do the hard way by download dedicated server - copy sample sever.cfg and basic.cfg from the biki - and come up with your test mission about 5mb+ in size ... the results are the same cause it's nothing network related - but an incorrect (or better: complete lack of) de-coupling of the GUI code from the long-time network task.

It's explained in tens of thousands of beginner-threads over on coderanch - and that's just for Java - same goes on for C/++ and C# respectively - how to do such correctly by explictly de-coupling the main gui render thread from the long-time network code thread - and how to periodically update the gui from the netcode ... but hey, ok, I got it ... it's my fault caused me myself ...

feel free to close if you don't want to invest even half a minute into just thinking what I'm talkin about ... how someone else put it in another task where others were talking nonesense cause they didn't even had a clue about what the topic was about ... hmm, let me try to re-phrase it: "if you don't know it - just leave it"

just trying to convey to you how to get BI to look into reported issues - without a simple reproducible repro, the chances are low [unless it effects a lot of people in a big way]

you may not like it, but either you want the issue fixed and thus increase chances for BI to look at it, or not

dedmen closed this task as Resolved.Jun 4 2021, 1:28 PM
dedmen claimed this task.
dedmen added a subscriber: dedmen.

Performance/Profiling branch has updated default network bandwidth values, installing that on your server will make mission downloads quite a bit faster.

so it doesn't make any sense the first couple MB takes forever cause it loads with only a few kb/s

Part of why the very first mission download takes quite a while is because your mission download starts, but then the server starts loading the mission, and is busy with that and stops sending you the mission file, until the server loaded the mission where then the download continues

Either go full speed from the start or throttle it to a fixed speed.

Thats just bad default network settings. Arma estimates your network bandwidth, so with more time it adjusts further up making the download go faster.
As i said profiling branch has adjusted defaults that are better (the old ones were still 2006 level internet speeds)

"not polite - but not yet aggressive enough to reason for a ban"-realm:

If you continue like that I might just disable your account, cause frankly your behavior is becoming pretty annoying and you're producing more frustrating passive-aggressive garbage than actual bug reports.

but an incorrect (or better: complete lack of) de-coupling of the GUI code from the long-time network task.

It is decoupled.
I cannot reproduce your game freeze,and haven't heard of that before. I know that the download stops until the server has finished loading the mission but that happens once at server startup, so is pretty irrelevant.