MG Patcher

Okay, so please ignore my first post with the big patches.
All fine.

My only question remaining:
Can you explain the difference between normal patches and rolling update patches?
And in what use case would you recommend which method?

 

Yes, start version means upload a full build, because this is the starting point for patches.

I suggest using rolling updates, then get to about 20 patches and make a new start version.

IMHO: If your start version uploads are more than 100mb your doing it wrong, you need to move the assets out and begin to use addressables.

 

The Poll on this thread - do you like MGPatcherTools?

I voted yes, but I rewrote most of the code. The most useful part is the creation and applying of the patch. The rest of the code is questionable.

 

Edit: read a bit about addressables now, did not know that tech, but I am stuck on Unity 5.67 with this , I don`t think it is available for that. Also my project is not fat enough, 600 MB is not big enough to justify a change of the whole structure to addressables I think. But sounds very useful for bigger and fresh projects.

//****Not sure what you mean by addressables, do you mean outsource all heavy assets to separate assetbundles?///




I am currently (pre alpha, need it mainly for testers) wrapping up the patcher and the game in one runtime, works fine.

Without the unneeded "start build" option my inital patches reflect only the actual changes I did to the project.
Depending on what I change this can be a few kb for mere code changes to hundreds of MB if I add heavier stuff like Videos.
Just the way I expected it to work.

I now have the source version and can see a bit better what happens and that also adds the handmade patch option. I have to better understand yet how to use patches efficiently.

 

Can you explain a bit what a rolling update actually does in contrast to the standard patch? I only know that term from web applications for "hot updates" without downtime.
The docs did not much to clarify.

 

Haha, I also voted yes, but if asked "Do you like MGpatcher documentation" I would vote "No".

This thing seriously lacks a structured documentation,
But I got it to work, it works well so far and the price is cheap so I don`t want to complain too much. It is easier with the source now to understand what is happening.

 

There are two update types. Rolling Update and Direct Update.
Rolling update -
You have a starting update, then small patches are created to move to the next version, so the server at the end of 20 patches contains 21 files (Start + 20 tiny patches) A new user will down load and install all 21 patches.

To get the program up to date, each patch builds on the previous one.

Direct Update -
For each version it creates a patch for each version to the current version.
V1.00 = 1 file start 1.00
V1.01 = 2 files start 1.01 and a patch from 1.00 to 1.01
V1.02 = 3 files start 1.02 and 1.00->1.02 & 1.01->1.02
V1.03 = 4 files start 1.03 and 1.00->1.03 & 1.01->1.03 & 1.02->1.03

so as it moves forward it keeps adding updates for each step forward and multiple files for each version's step forward.

Why addressables or asset bundles in 5.67 - the code for most programs is less than 50mb, you really only want to patch the code using MGPatcher and allow the addressables system to maintain the patches for the assets.

Why are you using 5.67??????

 

Thank you very much for the help and for the clarification, Mazak.
Now I understand it better.

Why I am using 5.67?
Why not?
It is an older complex project that I keep working on for years now and it works, 5.67 is a rock solid and stable Unity release and updating to 2017 breaks a lot of stuff and would gain me next to nothing for the project (well, maybe except addressables that I now know of, but I think I can live without that), Updating to 2019 is unfortunately a complete disaster (tried it) and would guarantee me weeks of work to get it running and breaks a lot of shaders (which I am unfortunately not competent with and have to rely on third party), so I won`t even consider that. Unity is not exactly mild with backwards compatibility.

Plus I have a perpetual commercial licence for Unity 5

And no, addressables are unfortunately 2017 ++.

If the starting rolling patches are always full size with the rolling Update I might just stick to non-rolling, as this seems to work really well and the patches are small so far .

 

Another question to fully understand the rolling updates:
I build a starting version (which is a copy of the whole build?) and then the rolling patches are created on top.

Is it possible to combine regular patches and rolling patches to cut short the update path after a number of rolling patches?

 

I do rolling updates with a start version at 1.02 - then I do rolling until I get about 20 or so

Then I do a 1.03 as a new start version since so much has changed and get all the players current at once.

www.galaxicus.com

 

Thank you, very helpful, now I understand how that works.

 

Hello. No that behavior is caused only by the "Direct" mode. Thanks!

 

Hello! If you use Unity 2018.4 and higher I highly recommend using SGPatcher - this is a modern solution from the SIDGIN team.

 

can u help me plz

 

my unity version es 2018.2.21f1

 

In case anyone else experiences the same:

I had MG pacther set up and working nicely in 2 Unity 5.6 projects.

Suddenly, I still do not know why, after not touching the project for a few weeks the patcher stopped working and yielded errors, pointing to the fact that it could not read version file on web server any more.

I fixed this yesterday by changing MG patchers code in 2 places.

I rewrote StartProcess() in MGPatcherControlVersion.cs to not run as a thread but as a coroutine and made the httpaccess code into Unity www.

The version file then could be read from the server again.

Nearly the same procedure with the filesize part of DownloadFile() in MGPatcherUpdater.cs.. Replaced the

HttpWebRequest
that puts the data into file_size with a UnityWebaccess (you need to convert the string value that UnityWebaccess provides for the filesize with lon.parse()).



Aftwer that I had a working patcher again.

It is a complete mystery to me why the httpWebsRequest did not work any more (worked before) and the HttpWebRequest a bit down in

DownloadFile()
that handle the actual patches download are not touched and work.

Maybe this helps someone.