I went the HDDHackr route for a 120gb drive. It wasn't as straightforward as I was hoping. Initial format went alright, but I had to do a lot more steps to get the backwards compatibility partition mirrored over from the old drive to the new one. Until I did that right original Xbox games could not be played.

As a client no ports need to be mapped. I could only see setting your PC to DMZ on the router as helping if it is a crappy router that for some reason is more stable if that is done. The only times I've had issues is when the servers are having issues. Other nights with no problems I've played for 4+ hours straight with no disconnects or issues.

Dev wrote on Mar 4, 2010, 08:00:
Prez:

Based on comments I think many people (including ubi execs) were assuming that since it saved on internet, there's no possible way it could save local if crack just skipped internet entirely since the code wasn't there. So people were assuming crack would have to emulate server, and hack together a disk IO workaround.

This was obviously incorrect from the start (I think I even mentioned it in a random thread). Why? Because in the pc gamer info, it said that if the internet connection was gone, AC2 saved at last savepoint (losing progress since then). That means the possability of saving local (not on internet) is already CODED IN. The hackers just had to find that part of the code and use that instead of screwing with the internet save portion.
So the ubi execs are just really clueless

Except, if the game constantly saved progress to the servers, then no local saving is required. Basically, if connection is lost, then the last synchronized savepoint is already on the server, and not locally.

Dev wrote on Mar 4, 2010, 08:00:
Prez:

edit: And the really funny part I just thought of. This patch will probably make it EASIER for hackers since it can save at any point without internet, so they just need to activate that part of the code to save anywhere and give the game better save flexibility than the retail release has (which I believe is based on checkpoints)

Not really, everyone is assuming this to be something it isn't. Before this patch if you lost connection then basically the game ended. You were forced to quit and had to start at last checkpoint. Reading what they're saying, it sounds like the new behavior is that it lets you keep the game running and retrying to connect rather than forcing you to quit. If it reconnects, then you resume right where you were. What I'm sure it does NOT do, is let you quit and later return to the same point. Basically, you have to leave the game running till your connection returns, or the servers come back. Otherwise, just like before you lose all progress since it last sent save data to the server.

This is an improvement over the prior behavior but still means with the official game, progress can be lost if their servers go down or your connection is lost and you can't leave the game running until they are working again. It's still overly draconian DRM.

That just means the Phantom raised the bar in how much you have to do to scam a lot of investors. At least phantom was a more reasonable project.

And do you remember how much people complained when they were 20+ms about how they were unsuitable for gaming? Though that was often more of a problem of ghosting. Still, it's a big concern for people for LCD's to have low latency when used for gaming, to the point where 8ms difference can be huge. We're talking about adding 20-120ms.

Fang, I understand all that but I just don't see it being a simple 20ms of additional latency That seems to be an absolute best case. On top of the normal latency you'd have client side they'll be adding compression latency, transmission latency, and a quasi additional display latency.

8.33ms First, the fact they likely only poll and transmit an image at 60fps. We'll ignore the end display device refresh time as that exists in both but this is still something additional added. 16.67ms as you said, average of 8.33ms delay added. It is possible they've got a solution that knows every time the graphics card finishes rendering and only starts compressing then, in which case they could even transmit a variable bitrate stream, but nothing they've said so far seems to indicate this.

1-16.67ms Next, the encoding. The data has to be compressed, even using hardware compression if they reached 1000fps speeds it'd be a huge breakthrough and useful elsewhere. It's far more likely this is going to be much closer to the 16.67ms.

4.17-16.67ms Bandwidth, the video data has to be transmitted. Both network latency and bandwidth will affect this. They've mentioned 5mbps of bandwidth. If a user only barely has enough bandwidth to cover this then it'll incur a 16.67ms of latency, if they instead have a connection capable of say 20mbps and the data was capable of using all of that in bursts this could add as little of 4.17ms of latency.

5-40ms Network Latency, the time it takes the input packet to hit the server and the time it takes the data to cross the network. The longer the path the greater the latency. This one unfortunately varies drastically based on connection users have and where the servers are situated. Best case I'm thinking they can get this down to 5ms when colocating on every users ISP and the user is on a low latency connection to their ISP. More likely is 40ms but varying on users connections could easily be more.

1-16.67ms Decoding, as you mentioned they then have to decode the frames on the client end. I doubt they'd put as expensive of hardware into decoding but since decoding is easier maybe it could accomplish 1ms. At worst though it has to manage 60fps.

Total 19.5-116.84ms

At 19.5ms, this could actually work. At 116.84ms that's almost 6x the normal input lag and would not be enjoyable to most players. If there's latency induced through any other part of the setup or the servers have even more network latency between them and customers then it could get really bad. It is possible that initial 8.33ms delay I put in there could be removed but I'm less inclined to believe they accomplished that when they spout so much other crap.

It'll be interesting if they ever open this up to beta testing and we get actual real user reviews on it. Even then though, what are they going to have to charge to make a profit off this?

This comment was edited on Mar 27, 2009, 16:48.

"I believe latency is being overblown as a problem by those who don't know much about internet topology."

Client-side prediction, ever hear of it? It's why your lag to servers doesn't show up as input lag. When you move your mouse left in an FPS the client tells the server to turn you left but also does it immediately client side, predicting the server will accept it. This cause the 18-50 or whatever ping time you have to a server to not affect your input lag.

Because this will be a thin-client, there will be no client-side prediction. Your inputs will be lagged at the time it takes for them to be sent to the server and for the encoded video to be sent back and displayed. For input lag it starts becoming noticeable around 10-20 ms and gets progressively worse. By 100ms many users will find it unbearable. I was playing rockband and we had the video latency setting off by 20ms and it was noticeable and annoying to everyone playing, now imagine if we had it off by 100ms? Then imagine if instead of a predictable shown sequence to offset our input for it was an FPS with human opponents?

Go find one of those crappy wireless mice with high input lag, that'd give you a good preview of what this service is going to be like.

This is not the first Windows game to get Amazon's day-of release policy. I used the day-of release policy for Fallout 3 and received it the day of release on October 28th. They ended up shipping it next day delivery on Monday, and I did receive it on the 28th. I don't know if any releases prior to this were available via the day of release policy.

Sigh, that's why I always find the use of personal firewalls amusing. Most people are ignorant of valid connections and kill them. Those connections to crl.microsoft.com are there to validate the signatures used to sign the installer. They want to authenticate the file is from who it is. Nothing malicious about them, quite the opposite. Without those checks, someone could modify the installer to include trojans or other fun stuff and sign it with an invalid signature. You blocking the check could mean installing virii as long as it is newer than what your virus scanner knows about.