Aces High Bulletin Board
Help and Support Forums => Technical Support => Topic started by: airhog99 on April 12, 2007, 08:53:02 PM
-
And all this in a full screen window..
It's not exactly going quickly either.
You guys gotta look into incremental updates...
-
And it's getting better..
I got out of AH via the Windows key (ALT-Tab does it too), to do some other stuff in the meantime. But now AH is unresponsive. Not too nice.
I started a separate download instead, which is estimated at taking 5 minutes rather than the 20 estimated from within AH. And it seems to be on target.
-
The first couple of days of an update are rough. Over 5000 people trying to DL the update, most using the auto-update in stead of the linked update posted on the announcement.
Another "youth" expecting to get EVERYTHING, NOW ! jeez, ease up, give them a break!
-
OOOhhhhh man 5 minutes or 20 minutes , what do i do ??? I cant wait that long jeezzee!!!! Go take the trash out for your folks or pull up yer pants . Front wiper
-
Originally posted by The Fugitive
The first couple of days of an update are rough. Over 5000 people trying to DL the update, most using the auto-update in stead of the linked update posted on the announcement.
Another "youth" expecting to get EVERYTHING, NOW ! jeez, ease up, give them a break!
Glad to hear I'm still young, at 40+.
It's about giving a "professional" experience to the end user. If I had by chance started to use AH only a cople of day's ago I might just have put it in the "not a serious company" category and called it a day.
I actually reported the program going unresponsive (in NT parlance), which ought to be of interest.
So an estimated 20 minutes is more like.. forever.
It should be in the company's own interest to avoid these large downloads.
-
A single change, like adding a new plane/vehicle can result in a large patch. It is unavoidable. In this case, not only did we have a new vehcile, we also updated the terrain graphics.
Art asset updates take more space than code updates.
When we do have a large update, we always provide alternate download methods. A periodic large patch is unavoidable. And just FYI. All our patches and updates are incremental.
As far as the game going unresponsive. That is simply due to the network stack in the operating system. While the game is waiting for the operating system to hand a packet of data over, the game will be reported as being unresponsive by the operating system.
-
Originally posted by Skuzzy
As far as the game going unresponsive. That is simply due to the network stack in the operating system.
IPv4 was implemented on December 31st 1980 at midnight.
Microsoft used the xBSD TCP stack to implement IPv4 in Windows in 1991
16 years later the Windows TCP stack is STILL pathetically weak, non-standard, and barely functional. They have threatened to fix this since 1998, but nothing has substantially changed.
My advice is to download the patch from HTCs site on your Linux or xBSD box and copy it to your windows game machine from there.
-
Now there is a great idea! I'm toying around with PCLinux now and I can see a great use for it in the DL'ing department.
All the Best...
Jay
awDoc1
-
Thanks for the reply!
There is always a reason for everything -I'm merely reporting what it looks like from my side. Surely multithreading can be used to make the program respond even when waiting for an IP packet? How do browsers do it?
BTW, the patch downloaded in 5 minutes on my Win XP machine when doing it from a browser.
Regards
Originally posted by Skuzzy
A single change, like adding a new plane/vehicle can result in a large patch. It is unavoidable. In this case, not only did we have a new vehcile, we also updated the terrain graphics.
Art asset updates take more space than code updates.
When we do have a large update, we always provide alternate download methods. A periodic large patch is unavoidable. And just FYI. All our patches and updates are incremental.
As far as the game going unresponsive. That is simply due to the network stack in the operating system. While the game is waiting for the operating system to hand a packet of data over, the game will be reported as being unresponsive by the operating system.
-
The game will eventually time out on the connection, just like a browser will. We just wait longer.
-
I don't want to get into a lengthy argument about this, but I can assure you that neither Firefox or IE lock up because a web server doesn't respond. They both refresh their GUIs, and generally allow new windows to be created.
-
The game waits as it can't do much more than wait for the connection timeout.
Firefox and IE are not writting in DirectX. Behavior is going to be different.
There can be only one instance of a DirectX application running in full window mode.
-
Originally posted by airhog99
I don't want to get into a lengthy argument about this, but I can assure you that neither Firefox or IE lock up because a web server doesn't respond. They both refresh their GUIs, and generally allow new windows to be created.
Apples and Caribou. http is a stateless protocol.
-
Oh duh. Thanks Puck. I do sometimes miss the obvious.
-
Originally posted by Puck
Apples and Caribou. http is a stateless protocol.
HTTP runs on top of TCP/IP.
Stateful or not has very little to do with this.