Pages: 1 [2] :: one page |
|
Author |
Thread Statistics | Show CCP posts - 6 post(s) |
Miilla
Minmatar Hulkageddon Orphanage
|
Posted - 2011.06.01 15:42:00 -
[31]
Edited by: Miilla on 01/06/2011 15:42:37
Originally by: CCP Atropos Seriously though, we've been doing differential patches for a very long time. If you open one of the .7z that you get you'll see that it contains this:
These files are .rtp, which are generated by an application called RTPatch from Pocket Soft. We actually store the per file diff's generated by the software, on disk, and then combine them as needed into the patches that we then compress and distribute to you, the user.
Since the patches are made from a particular static point in the code base, any later fixes can't simply be added in, and must be patched separately in either a full patch, or the lighter client updates that you would have seen.
Because of this, we can't preload the data, and it's also why we discourage people from playing super sleuth and trying to find the patch early and patch up with it, since we might, as you say, change the patch at short notice.
We do have plans for pre-loading and making the patching/installing/fixing process more straightforward that I'd be happy to discuss, in some depth, if you're interested.
"Because of this, we can't preload the data"
>> Then you say...
"We do have plans for pre-loading and making the patching/installing/fixing process more straightforward that I'd be happy to discuss, in some depth, if you're interested."
>> Sounds like a blog item we could all read?
"change the patch at short notice"
>> can be done with a new build number and a small patch pushed out to correct the larger one prior as you already do this today with patches comming after the main patch is pushed out (even optional ones)
>> Still confused as both statements contradict.
|
|
CCP Atropos
|
Posted - 2011.06.01 15:43:00 -
[32]
Also I would like to point out that one of the shortcomings with the current patching paradigm is that it operates from a single source build to a single destination build. Tools such as the Repair Tool and Sisilauncher operate slightly differently in that they evaluate your local client before working out what it should pull from our content delivery network.
As such the Repair Tool and Sisilauncher can work for any source build, and take you up-to a given destination build.
Software Engineer Core Engineering |
|
|
CCP Atropos
|
Posted - 2011.06.01 15:49:00 -
[33]
Originally by: Miilla "Because of this, we can't preload the data"
>> Then you say...
"We do have plans for pre-loading and making the patching/installing/fixing process more straightforward that I'd be happy to discuss, in some depth, if you're interested."
>> Sounds like a blog item we could all read?
"change the patch at short notice"
>> can be done with a new build number and a small patch pushed out to correct the larger one prior as you already do this today with patches comming after the main patch is pushed out (even optional ones)
>> Still confused as both statements contradict.
Sure, I can write a blog.
We have plans to change our operating paradigm to allow the potential for preloading, which our current paradigm doesn't offer. As for making a secondary patch, sure that's possible, but it's also crappy; people have enough problems with the current patcher without having to run through it twice.
Software Engineer Core Engineering |
|
Barakkus
|
Posted - 2011.06.01 15:50:00 -
[34]
Edited by: Barakkus on 01/06/2011 15:52:20
Originally by: CCP Atropos Also I would like to point out that one of the shortcomings with the current patching paradigm is that it operates from a single source build to a single destination build. Tools such as the Repair Tool and Sisilauncher operate slightly differently in that they evaluate your local client before working out what it should pull from our content delivery network.
As such the Repair Tool and Sisilauncher can work for any source build, and take you up-to a given destination build.
Might be better to just migrate to something like the repair tools instead wouldn't it?
SOE's "patcher" for EQ2 works like the repair tools, while it initially takes a while to go through all the files, a botched patch job can just be re-run without downloading a whole bunch of stuff already downloaded, or you can cancel it and come back later without having to re-download a bunch of stuff depending on where the patcher stopped in the process. - [SERVICE] Corp Standings For POS anchoring |
Miilla
Minmatar Hulkageddon Orphanage
|
Posted - 2011.06.01 15:51:00 -
[35]
Edited by: Miilla on 01/06/2011 15:53:53
Still good to see something being done to the current patching system to improve it.
I have one request :) RESUME SUPPORT to handle interrupted connections (perhaps with user PAUSE too)
|
|
CCP Atropos
|
Posted - 2011.06.01 15:55:00 -
[36]
Originally by: Miilla Edited by: Miilla on 01/06/2011 15:53:53
Still good to see something being done to the current patching system to improve it.
I have one request :) RESUME SUPPORT to handle interrupted connections (perhaps with user PAUSE too)
That should be in the Sisilauncher already, you should try it out.
Software Engineer Core Engineering |
|
|
CCP Atropos
|
Posted - 2011.06.01 15:57:00 -
[37]
Originally by: Barakkus Edited by: Barakkus on 01/06/2011 15:52:20
Originally by: CCP Atropos Also I would like to point out that one of the shortcomings with the current patching paradigm is that it operates from a single source build to a single destination build. Tools such as the Repair Tool and Sisilauncher operate slightly differently in that they evaluate your local client before working out what it should pull from our content delivery network.
As such the Repair Tool and Sisilauncher can work for any source build, and take you up-to a given destination build.
Might be better to just migrate to something like the repair tools instead wouldn't it?
SOE's "patcher" for EQ2 works like the repair tools, while it initially takes a while to go through all the files, a botched patch job can just be re-run without downloading a whole bunch of stuff already downloaded, or you can cancel it and come back later without having to re-download a bunch of stuff depending on where the patcher stopped in the process.
That's kind of the idea; we handle each file individually rather than batching them up, and determine what needs to be done: * file doesn't exist? download it * file has a different checksum to what's expected? see if a patch is available * file has a different checksum to what's expected and there's no patch? repair it to the latest published version
It's still in planning at the moment, but as we move into the various alpha/beta testing stages it will be on Singularity, and there will be a round of user acceptance testing and feedback harvesting from the forums. I'm sure all you eagle eyed forum, uh, dwellers will see the thread when it appears.
Software Engineer Core Engineering |
|
ILikeMarkets
|
Posted - 2011.06.01 15:59:00 -
[38]
What about just having an alternative release of the patch through bittorrent? There are a few games that release their client this way, and it is VERY disconnect friendly.
|
Miilla
Minmatar Hulkageddon Orphanage
|
Posted - 2011.06.01 16:01:00 -
[39]
Edited by: Miilla on 01/06/2011 16:02:57
Originally by: ILikeMarkets What about just having an alternative release of the patch through bittorrent? There are a few games that release their client this way, and it is VERY disconnect friendly.
Bittorrents are not very friendly to mobile internet due to the connection endpoint churn even when the amount of connections is limited in the BT client. I know, I have tried.
I find firefox / downloadthemall more stable and faster than BT on mobile.
Plus you have the problem of ISP traffic shaping policy.
|
Barakkus
|
Posted - 2011.06.01 16:04:00 -
[40]
Originally by: ILikeMarkets What about just having an alternative release of the patch through bittorrent? There are a few games that release their client this way, and it is VERY disconnect friendly.
Torrents are not very friendly if you have Comcast as an ISP. It took me 10 hours to download Clear Skies 3 via torrent, where as if eve-files had the bandwidth available, it would have only taken me 20 minutes with the direct download. Comcast defers all torrent traffic, regardless...so it takes me 1000x longer than it should to download something via torrent. - [SERVICE] Corp Standings For POS anchoring |
|
Anddeh McNab
Cadre Assault Force
|
Posted - 2011.06.01 16:24:00 -
[41]
Originally by: CCP Atropos Sure, I can write a blog.
We have plans to change our operating paradigm to allow the potential for preloading, which our current paradigm doesn't offer. As for making a secondary patch, sure that's possible, but it's also crappy; people have enough problems with the current patcher without having to run through it twice.
Hurrah for Atropos \o/. The SiSiLauncher certainly does make bring a client up to date a lot easier. Set it going and wander off instead of continually having to boot the EVE client to get the next patch.
Originally by: ILikeMarkets What about just having an alternative release of the patch through bittorrent? There are a few games that release their client this way, and it is VERY disconnect friendly.
Poke Chribba, he usually hosts patches on eve-files. --- There are two sides to the EVE community; those that scream for change and those that scream against it. Often they are the same person. |
|
|
|
Pages: 1 [2] :: one page |
First page | Previous page | Next page | Last page |