PATCH - Updating System

Thank you for your reply @ManHunterITA!

That's very interesting. Can you elaborate on the technical reason why this is the case? In the end it's just a configuration of files. Why couldn't the launcher organize the files in the way they're supposed to be? Why is the extra step needed?

All the best.

 

Normally PATCH works like this (as standalone):

1. run the Launcher application
2. check for Launcher update
   1. if any: apply the update, restart the Launcher
3. check for Game updates
   1. if any: apply the updates
4. run the Game application

The point 2 is the interesting one: basically it is a self-update, so the Launcher needs to update its own files. On the standalone version this isn't an issue: I coded a workaround to update locked files.

Inside Unity, instead, you face an issue on point 2.
Unity Player locks globalgamemanagers file (and maybe some other ones) on start, so they cannot be updated. When this happens, PATCH tries to run the workaround for locked files. Long story short, this is based on catching SharingViolationException, but for some reasons (a bug in the Unity runtime maybe?) that exception in the Unity Player is uncatchable.
If you put a try/catch block around it, that exception (thrown by a method in System.IO.File) will still bubble up and the application will crash.

That's the reason behind the Launcher - PreGame setting: Launcher updates Game's unlocked files, PreGame updates Launcher's unlocked files.

Anyway, I should test it against more recent versions of Unity: I've seen they upgraded the Mono runtime to the latest one in one of the latest Unity releases. Maybe this could fix the issue.
If that's the case, I can definitely get rid of PreGame.

 

Ah ok, so the launcher does upgrade the game fully, but cannot upgrade itself. That's what PreGame is for.

Thanks for the detailed explanation!

 

Hi there.

First of all, congratulations on the work done. I've tried other options and PATCH is hands down the best.

I have had some problems. Sure they are due to improper use, but I ask.

1- I have a "build" created with the game. The 0.1.1 in the Builds folder.
2- I upload to the server, inside a folder that I have called PATCH, the folders that are inside PATCHWorkspace
3- The launcher correctly downloads the contents of the \ Builds \ 0.1.1 \ Game folder and puts it in a folder called Game in the same path as the launcher executable.
4- At the end of the download (without errors) the automatic launch of the game occurs ... and it gives an error. "Failed to load PlayerSettings (internal index # 0). Most likely data file is corrupted, or built with mismatching editor and platform support versions"

I do another test

A- I copy and paste all the contents of the PATCHWorkspace \ Builds \ 0.1.1 \ Game folder into the "Game" folder in the launcher path. The content is the same as I uploaded in the previous step (2) to the server.
B- I run the launcher. It doesn't download anything, launch the game ... and it works fine.

My question, logically, is:

How is it possible that by making a "copy-paste" of the game, it launches well and does not do so if it is downloaded ... being the same content?

Thanks.

[EDIT]

Another test

- I delete the "level" and "globalgamemanager" files from the "game" folder that is in the launcher's path
- I open the launcher and they download.
- The game is launched ... and it fails.

- I "copy-paste" the files in which I generated the game executable ([] \ PATCHWorkspace \ Builds \ 0.1.1 \ Game) and put them in the "game" folder of the launcher.
- I open the launcher and it doesn't download anything.
- The game is launched correctly.

 

Hi,

thank you for your kind words!

About your problem: take a look here https://github.com/emanzione/PATCH/wiki/Recommended-softwares#hint

 

I test it right away.
Very kind and thanks for the speed.

I am going to buy the "PRO" version. I want to introduce a more protected, more encrypted system. That it is downloaded encrypted and decrypted at the destination with user keys with an activated license.

I report the results.
Thanks a thousand, again.

 

I have tried the solution, and it has been a success.
I have used WINSCP

There are small details that would be good to add. I propose it as suggestions.

For example, the initial download of the game could occur in a compressed file. If the game is 15Gb in size and the download is done by hundreds of users, there is a very large outgoing traffic that many server providers charge.

Reducing that download, downloading a compressed file and causing decompression in the player's computer, would greatly reduce that outgoing traffic.

Furthermore, if you have a windows server with IIS, the downloads of certain files generate problems and you have to know how to manage them. By downloading a single compressed file, these problems disappear completely.

Thanks

 

I'm glad it solved the problem!

Nice suggestions too! I already got some reports about this problem. I was already building the Enterprise version in this way, but I could consider if it's the case to add this feature to the Pro/Basic versions too.

 

The new 2.6.0 is out: https://twitter.com/MHLabSoftware/status/1449902830278615041

 

Hi.

Thanks for the new update.

I have a question. Sure it's in the documentation, but I can't find it.

The first build is always 0.1.1
How can I give it another number, for example 0.8.6?

Thanks.

 

If you are using Unity, just reach Assets/MHLab/Patch/Admin/Editor/Components/Contents/PatchBuildsContent.cs on line 337: change that line with the default version you prefer.

 

Hello,

I have built the game and made a patch for it, uploaded it all to server...
Now when I tested on my PC it downloaded and ran just fine, but on some other PCs it downloads 100%, it looks like it stops downloading (download speed decreases to zero) and a few moments it start downloading again and progress bar starts showing over 100%.

Any idea why this might happen?

 

Hi. Can you give me more information? Which PATCH version are you running on? Any log?

 

I couldn't find a version number anywhere but we are trying to update an older project, that is still using Unity 2019 so Patch version should be from around that time too. Is there anywhere I could look for exact version number?

As for the logs - it just said downloading patch 1.0.0 - 1.0.1 and nothing else after that.

 

Hi.

I have a problem that version 2.6.1 did not happen to me before.

I have made a new build of my game (the first one). I have uploaded it to the server and the launcher has downloaded it correctly and executed it correctly.

However, every time I open the launcher I get "Fixed metada for ...." over and over again, slowing down (for no apparent reason) the opening of the game for about 3-4 minutes each time.

As I say, this did not happen before this version.

Any suggestion?
Thanks.

PATCH Basic 2.6.1
Unity 2021.1.23f

Last log:

===> [Game updating] process STARTED! <===
Update context initializing...
Software version: 2.6.1
Update context points to [myurl]/Patch
Retrieved current version: 0.1.1
Workspace cleaned. Removed 0 files
No updater definition found on remote server. The Launcher update will be skipped. Problem reference: The URL [myurl]/Patch/Updater/updater_index.json generated an exception.
No patches index found on the remote server. The Update process will be skipped.
Collected information on 775 local files.
Retrieved definition for 0.1.1
Found 0 applicable updates.
Update context completed initialization.
Repairing process started.
Repairing process completed. Checked 620 files, repaired 0 files, skipped 620 files.
Update process started.
Update process completed. Applied 0 patches with 0 operations.
===> [Game updating] process COMPLETED! <===

 

SUSPECT....

Could it be a difference in date, caused by differences in date and time?

As a suggestion, if yes, UTC time could always be used as common (or any other, but common)

 

So it's < 2.6.0 (because with this release I introduced the VERSION.txt file and a log that prints the version number.
Try to update to the latest PATCH version (2.6.1).

 

It may be related to the new serialization/deserialization. The serialized LastWritingDate doesn't take into consideration milliseconds, I need to check if that's the reason.

 

Hello again.
I have already bought the PRO version

Sure enough, I have modified the Repairer file to convert the "LastWritting" dates to "ToUniversalTime" and the problem of repeating "fixed metadata" is gone.

But I have another problem ... or doubt.

The complete download of my game, from my server, takes about 14 minutes. I have tried to patch from one version to another. The size of the patch (of the compressed file in ZIP) is 17 MB. I have run the launcher, it has detected the patch and updated it. But the weather has alerted me ... more than 18 minutes !!

It surprises me that it takes almost the same time to "patch" a few megabytes as it does to download 15 Gb.

This is so?

Thanks.

 

Well ... I keep reporting ...

With the PRO version everything has stopped working. The initial downloads of the first BUILD and the patches, went perfectly with the BASIC version, but with the PRO ... errors.

LOG:

===> [Game updating] process STARTED! <===
Update context initializing...
Software version: 2.6.1
Update context points to http://[myip]/Patch
No current version found. A full repair may be required.
Workspace cleaned. Removed 0 files
No updater definition found on remote server. The Launcher update will be skipped. Problem reference: The remote server returned an error: (404) Not Found.
Collected information on 151 local files.
Retrieved definition for 0.8.4
Found 0 applicable updates.
Update context completed initialization.
Repairing process started.
===> [Game updating] process FAILED! <=== - One or more errors occurred. - at System.Threading.Tasks.Task.WaitAll (System.Threading.Tasks.Task[] tasks, System.Int32 millisecondsTimeout, System.Threading.CancellationToken cancellationToken) [0x001d1] in <695d1cc93cca45069c528c15c9fdd749>:0
at System.Threading.Tasks.Task.WaitAll (System.Threading.Tasks.Task[] tasks, System.Int32 millisecondsTimeout) [0x00000] in <695d1cc93cca45069c528c15c9fdd749>:0
at System.Threading.Tasks.Task.WaitAll (System.Threading.Tasks.Task[] tasks) [0x00000] in <695d1cc93cca45069c528c15c9fdd749>:0
at MHLab.Patch.Core.Client.Advanced.IO.Chunked.ChunkedDownloader.StartJobs (MHLab.Patch.Core.Client.Advanced.IO.Chunked.DownloaderSharedContext sharedContext) [0x00085] in <48c2b9105ea54a5e927c43c9e592f923>:0
at MHLab.Patch.Core.Client.Advanced.IO.Chunked.ChunkedDownloader.Download (System.Collections.Generic.List`1[T] entries, System.Action`1[T] onEntryStarted, System.Action`1[T] onChunkDownloaded, System.Action`1[T] onEntryCompleted) [0x00045] in <48c2b9105ea54a5e927c43c9e592f923>:0
at MHLab.Patch.Core.Client.Repairer.Update () [0x002e1] in <48c2b9105ea54a5e927c43c9e592f923>:0
at MHLab.Patch.Core.Client.Runners.UpdateRunner.Update () [0x0001d] in <48c2b9105ea54a5e927c43c9e592f923>:0
at MHLab.Patch.Core.Client.UpdatingContext.Update () [0x00006] in <48c2b9105ea54a5e927c43c9e592f923>:0
at MHLab.Patch.Launcher.Scripts.LauncherBase.CheckForUpdates () [0x00006] in <48c2b9105ea54a5e927c43c9e592f923>:0
One or more errors occurred.
at System.Threading.Tasks.Task.WaitAll (System.Threading.Tasks.Task[] tasks, System.Int32 millisecondsTimeout, System.Threading.CancellationToken cancellationToken) [0x001d1] in <695d1cc93cca45069c528c15c9fdd749>:0
at System.Threading.Tasks.Task.WaitAll (System.Threading.Tasks.Task[] tasks, System.Int32 millisecondsTimeout) [0x00000] in <695d1cc93cca45069c528c15c9fdd749>:0
at System.Threading.Tasks.Task.WaitAll (System.Threading.Tasks.Task[] tasks) [0x00000] in <695d1cc93cca45069c528c15c9fdd749>:0
at MHLab.Patch.Core.Client.Advanced.IO.Chunked.ChunkedDownloader.StartJobs (MHLab.Patch.Core.Client.Advanced.IO.Chunked.DownloaderSharedContext sharedContext) [0x00085] in <48c2b9105ea54a5e927c43c9e592f923>:0
at MHLab.Patch.Core.Client.Advanced.IO.Chunked.ChunkedDownloader.Download (System.Collections.Generic.List`1[T] entries, System.Action`1[T] onEntryStarted, System.Action`1[T] onChunkDownloaded, System.Action`1[T] onEntryCompleted) [0x00045] in <48c2b9105ea54a5e927c43c9e592f923>:0
at MHLab.Patch.Core.Client.Repairer.Update () [0x002e1] in <48c2b9105ea54a5e927c43c9e592f923>:0
at MHLab.Patch.Core.Client.Runners.UpdateRunner.Update () [0x0001d] in <48c2b9105ea54a5e927c43c9e592f923>:0
at MHLab.Patch.Core.Client.UpdatingContext.Update () [0x00006] in <48c2b9105ea54a5e927c43c9e592f923>:0
at MHLab.Patch.Launcher.Scripts.LauncherBase.CheckForUpdates () [0x00006] in <48c2b9105ea54a5e927c43c9e592f923>:0

 

... and deserialization does not work well.

The ENTRIES node is not considered as an array and does not read the files that it should in the patches.

I'm not going to investigate further.

I am waiting for news.

 

Applying a diff patch is not a trivial task, in some cases it may require long time. It highly depends on the patch and how it needs to be processed.
What I mean is: the patching time doesn't depend on the size of the patch (unless it's negligible, like 20KB, of course).

It could be optimized, anyway: at the moment, it runs on a single thread. In future I might try to move it on multiple threads.

 

This is a known issue, it has been resolved with 2.6.1:

fix(PatchDefinition): fixed a deserialization fail

In your logs I see you are running 2.6.1, then I suspect your package manager failed to update all files or something like that.

 

Thank you for your answers.
Attached a "screenshot"

- I made a new BUILD with the PRO version
- I have uploaded it to the server
- The LAUNCHER worked...

And it has stayed there. It puts 10 minutes, but it takes more than 30.

PATCH PRO 2.6.1

Thanks

 

From what I've been testing, the only way the system can be valid for me is to forget about patches and always update to the latest full build.

My question is:

If I have builds 0.8.4, 0.8.5 and 0.8.6 in the Builds folder, along with their json files and the builds_index.json file contains all of them ... will the system always update me to the latest one?

If not ... is there a way to achieve this?

Thanks.

 

So it's spending so much time on patching that file: how big is it?

The system works like this (in short): the Repairer repairs the files for the current version (the one it finds locally), then it tries to apply available patches. The only case when it performs a full repair (even in this case, it tries to recycle files as more as it can) is when the current local version is very old.
Very old is defined as:

• not contained in the builds_index.json
• < of the smallest version in builds_index.json

So, what you want to achieve can be done by having just a single build in your builds_index.json.

Anyway, this seems to be a very weird case and I would like to reproduce this issue on my end. If you want to, you can contact me on Discord (so we can have a real time chat on this).

 

Another test

- Installation of the game. First version. (well... 20 minutes)
- Installation of a 16mb patch (image attached)
- Attached image of the process.

EDIT:

after 60 minutes, I have stopped the process.
I have opened the log and this is the result:

===> [Game updating] process STARTED! <===
Update context initializing...
Software version: 2.6.1
Update context points to http://myip/wwwroot/Patch
Retrieved current version: 0.8.4
Workspace cleaned. Removed 0 files
No updater definition found on remote server. The Launcher update will be skipped. Problem reference: The remote server returned an error: (404) Not Found.
Collected information on 1389 local files.
Retrieved definition for 0.8.4
Found 1 applicable updates.
Update context completed initialization.
Repairing process started.
Downloaded and stored on disk [1166/1166] chunks in [1183,2358107s] on [32] threads.
Repairing process completed. Checked 619 files, repaired 8 files, skipped 611 files.
Update process started.
Applying update 0.8.4_0.8.6 [OknUxF8KNBpJrJXLUPoL+i2ATnE]
Downloaded and stored on disk [17/17] chunks in [1,6515044s] on [17] threads.
===> [Game updating] process FAILED! <=== - - at MHLab.Patch.Core.Client.Updater.HandleUpdatedFile (MHLab.Patch.Core.PatchDefinition definition, MHLab.Patch.Core.PatchDefinitionEntry entry) [0x000ba] in <a5038d0441c3473087d85781fc217ea8>:0
at MHLab.Patch.Core.Client.Updater.ProcessFile (MHLab.Patch.Core.PatchDefinition definition, MHLab.Patch.Core.PatchDefinitionEntry entry) [0x000fc] in <a5038d0441c3473087d85781fc217ea8>:0
at MHLab.Patch.Core.Client.Updater.PerformUpdate (MHLab.Patch.Core.PatchDefinition definition) [0x00107] in <a5038d0441c3473087d85781fc217ea8>:0
at MHLab.Patch.Core.Client.Updater.Update () [0x000c3] in <a5038d0441c3473087d85781fc217ea8>:0
at MHLab.Patch.Core.Client.Runners.UpdateRunner.Update () [0x0001d] in <a5038d0441c3473087d85781fc217ea8>:0
at MHLab.Patch.Core.Client.UpdatingContext.Update () [0x00006] in <a5038d0441c3473087d85781fc217ea8>:0
at MHLab.Patch.Launcher.Scripts.LauncherBase.CheckForUpdates () [0x00006] in <a5038d0441c3473087d85781fc217ea8>:0

at MHLab.Patch.Core.Client.Updater.HandleUpdatedFile (MHLab.Patch.Core.PatchDefinition definition, MHLab.Patch.Core.PatchDefinitionEntry entry) [0x000ba] in <a5038d0441c3473087d85781fc217ea8>:0
at MHLab.Patch.Core.Client.Updater.ProcessFile (MHLab.Patch.Core.PatchDefinition definition, MHLab.Patch.Core.PatchDefinitionEntry entry) [0x000fc] in <a5038d0441c3473087d85781fc217ea8>:0
at MHLab.Patch.Core.Client.Updater.PerformUpdate (MHLab.Patch.Core.PatchDefinition definition) [0x00107] in <a5038d0441c3473087d85781fc217ea8>:0
at MHLab.Patch.Core.Client.Updater.Update () [0x000c3] in <a5038d0441c3473087d85781fc217ea8>:0
at MHLab.Patch.Core.Client.Runners.UpdateRunner.Update () [0x0001d] in <a5038d0441c3473087d85781fc217ea8>:0
at MHLab.Patch.Core.Client.UpdatingContext.Update () [0x00006] in <a5038d0441c3473087d85781fc217ea8>:0
at MHLab.Patch.Launcher.Scripts.LauncherBase.CheckForUpdates () [0x00006] in <a5038d0441c3473087d85781fc217ea8>:0

 

Can you send me more information in PM (maybe your Remote URL, if possible)? I want to reproduce it and debug it on my side.

 

After much testing, I have come to a conclusion that repeats itself.

If LAUNCHER is compiled with PATCH BASIC it works fine. It can be improved in times (stream reading and writing code), but it works well. (It must be consider that it is UNITY who makes this very difficult since it seems that they have not keep in mind the updates of windows platforms at all. How can you have 7 Gb files instead of "splitting" them to handle them properly ?)

If the LAUNCHER is compiled with PATCH PRO, the problems that I have been posting will occur. I don't know why, since I can't run the code regularly at edit time either (another UNITY problem)

Perhaps (it is a suggestion, but I do not know it) you can consider making a specific version for PC. The PC can handle larger buffers and things like that. It is an opinion.

Putting comments in the code would also be important and would be appreciated. But it is also just a suggestion.

Thanks.

 

Maybe splitting the huge file with asset bundles could help. Let me know.

That problem is weird (in an interesting way): as I suggested before (and if you want/can), PM me with your Remote URL. I'll give it a test on my side, with a debugger attached.

You can already find a completely standalone version of PATCH in the package. It targets WPF, it's a Windows specific GUI framework and - most importantly - does not depend on Unity at all.
You can find it inside some 7zip archives.

I'm not a big fan of comments everywhere in the code. In my codebases, I only add comments where it is really needed: I avoid to comment the "what", instead I comment the "why". For example: explaining why some complex operations are needed, explaining the reason behind the specific order of some statements, explaining why a particular constant is set to a specific value, etc.
My opinion on that is: "make your code self-explaining". I would rather improve the code instead of adding unneeded comments.
Is there a part of the code that you feel it's not clear enough?

 

Thanks for all your replies.

If I start it up permanently, I will contact you.

Great job and thanks again.

 

Hello, is it safe to upgrade from basic to pro? Are there changes in which scripts are included scripts in the scene, or just changes inside of the scripts?

 

Normally it's safe, but always take a look if something is changed.

 

I have error from build empty project.

 

Checked your logs. Can I ask you which version of PATCH you are running on?
My guess is: your build definition has a wrong LastModifiedTime field (or the server didn't serve the build definition correctly) and the Repairer fails to apply the definition.

I'm sorry to hear that, but honestly I can't find any support mail I didn't answer. Not even in spam. Is it possible that you didn't send it to the right address? I normally answer emails in the first 24/48 hours and on Discord I am even faster.
On the forum I am a bit more absent, but I don't always receive the new message notification.
Said that, if you have any issue you can give me the logs and more details.

 

• Hello, I have an error
  System.MissingMethodException: string string.Trim(char)
  at ICSharpCode.SharpZipLib.Zip.ZipOutputStream.TransformEntryName (ICSharpCode.SharpZipLib.Zip.ZipEntry entry) [0x00035] in <1682d28795a44ad1bd3f1fc40213b4ed>:0
  at ICSharpCode.SharpZipLib.Zip.ZipOutputStream.PutNextEntry (ICSharpCode.SharpZipLib.Zip.ZipEntry entry) [0x00291] in <1682d28795a44ad1bd3f1fc40213b4ed>:0
  at (wrapper remoting-invoke-with-check) ICSharpCode.SharpZipLib.Zip.ZipOutputStream.PutNextEntry(ICSharpCode.SharpZipLib.Zip.ZipEntry)
  at MHLab.Patch.Core.Compressing.ZipCompressor.CompressFolder (System.String path, ICSharpCode.SharpZipLib.Zip.ZipOutputStream zipStream, System.Int32 folderOffset, System.Func`2[T,TResult] filesFilter) [0x00054] in <5af72e2493a3407598ca87350999d9ba>:0
  at MHLab.Patch.Core.Compressing.ZipCompressor.ZipFolder (System.String outPathname, System.String password, System.String folderName, System.Int32 compressionLevel, System.Func`2[T,TResult] filesFilter) [0x00043] in <5af72e2493a3407598ca87350999d9ba>:0
  at MHLab.Patch.Core.Compressing.Compressor.Compress (System.String folderToCompress, System.String outputFile, System.String password, System.Int32 compressionLevel, System.Func`2[T,TResult] filesFilter) [0x00000] in <5af72e2493a3407598ca87350999d9ba>:0
  at MHLab.Patch.Core.Admin.PatchBuilder.CompressPatch () [0x0004c] in <0fbef0648d134fd3b7c02409f197f39c>:0
  at MHLab.Patch.Core.Admin.PatchBuilder.Build () [0x00135] in <0fbef0648d134fd3b7c02409f197f39c>:0
  at MHLab.Patch.Admin.Editor.Components.Contents.PatchPatchesContent.TriggerBuilder () [0x00071] in E:\YangDemo\AFTask_2\Assets\MHLab\Patch\Admin\Editor\Components\Contents\PatchPatchesContent.cs:253
  at MHLab.Patch.Admin.Editor.Components.Contents.PatchPatchesContent.<Render>b__35_0 () [0x00009] in E:\YangDemo\AFTask_2\Assets\MHLab\Patch\Admin\Editor\Components\Contents\PatchPatchesContent.cs:225
  UnityEngine.Debug:Log (object)
  MHLab.Patch.Admin.Editor.Components.Contents.PatchPatchesContent:UpdateProgress () (at Assets/MHLab/Patch/Admin/Editor/Components/Contents/PatchPatchesContent.cs:116)
  MHLab.Patch.Admin.Editor.Components.Contents.PatchPatchesContent:Update () (at Assets/MHLab/Patch/Admin/Editor/Components/Contents/PatchPatchesContent.cs:173)
  MHLab.Patch.Admin.Editor.Components.PatchWindow:Update () (at Assets/MHLab/Patch/Admin/Editor/Components/PatchWindow.cs:24)
  MHLab.Patch.Admin.Editor.EditorHelpers.WidgetContainer:Update () (at Assets/MHLab/Patch/Admin/Editor/EditorHelpers/WidgetContainer.cs:79)
  MHLab.Patch.Admin.Editor.AdminWindow:OnInspectorUpdate () (at Assets/MHLab/Patch/Admin/Editor/AdminWindow.cs:139)
  UnityEditor.HostView:OnInspectorUpdate ()
• • How can I solve this problem
    

 

It sounds like your ICSharpCode.SharpZipLib.dll is not the one expected by PATCH. Probably you have another one in your project (maybe from some other plugins or package).

 

facing same issue.

I fixed it. I was putting whole build folder in the app to make a build version. I tried giving the all the folders in the build file where .exe and crash handler dll exists, and it worked.
Furthermore if you guys still face issue extract the error log and read it. It was helpful.

 

Faced this issue.

Fixed by downloading this file from internet. Extract it and replace file in the plugins.

 

Hello, is it possible to download the files required for the update from Google drive?

 

Hi,

There isn't a Google Drive downloader out of the box, but you can implement one on your own and inject it in PATCH. There is a section on the Wiki dedicated to custom downloaders!

 

Ok, thank you ! I will try to implement it using drive api.
If I can do it, I can send you the solution if you want.

 

Hi @ManHunterITA,
I am working on a project where I'm supposed to make use of both your asset and Obfuscator (https://assetstore.unity.com/packages/tools/utilities/obfuscator-48919). I haven't tried anything yet with one nor the other.
Is there any known issue using them together in the same project ?

Also, I'm afraid that the documentation about using the DropboxDownloader is a bit too summarized for me ' Is there any other source of information about it available ?

Thanks!

 

Hello,

there are no issues I am aware of between PATCH and Obfuscator. The only issue I can think about (but that's just my guess) is about the structure of an obfuscated file: if it's not deterministic (aka for the same input it returns the same output), your patches will be bigger every time.

About the DropboxDownloader: recently Dropbox changed the API, I need to find the time to update that downloader. However, I suggest to try the ChunkedDownloader if your web server supports ranged downloads: it can be really fast.

 

OK, thanks for your quick feedback !

We'll probably choose to work with a "real" server instead of Dropbox then.

Just to let you know, after I unzipped Dropbox.7z in my test project, I got the following compilation issue:

PrecompiledAssemblyException: Multiple precompiled assemblies with the same name Newtonsoft.Json.dll included on the current platform. Only one assembly with the same name is allowed per platform.

Then, after I removed the dll included in Dropbox.7z, I got this:

Assembly 'Assets/MHLab/Patch/Launcher/Scripts/Core/IO/Advanced/Dropbox/Dropbox/Plugins/Dropbox.Api.dll' will not be loaded due to errors:

Dropbox.Api references strong named Newtonsoft.Json Assembly references: 12.0.0.0 Found in project: 13.0.0.0.

Assembly Version Validation can be disabled in Player Settings "Assembly Version Validation"

I am running Unity 2021.3.11f1 for Apple Silicon on macOS 12.6.1, with Unity's package Newtonsoft Json 3.0.2 (which cannot be uninstalled AFAIK).

 

Yeah, Newtonsoft.Json is a Dropbox's API dependency, PATCH itself doesn't rely on it. You should be able to live with the Unity's one without any problem, just remove the one coming from the zip.

 

Hi i try to update launcher and upload the update to the server when i start launcher it launch the game then it give me a progress to update the launcher if i interrupt download by close the game then open the launcher again the launcher is freeze

 

Make sure the files on your web server are not corrupted and that are served in the correct format.

 

Hello there, congrats for P.A.T.C.H, that's a pretty cool piece of software.

Only one thing that wasn't entirely clear to me in the docs (I might have missed it): what's the proper process of updating the launcher ?
I have built my initial build of the launcher and archived it using the admin tools as advised, then posted the Updater folder to my server.
Now if I make changes to the launcher, what should I do ? The docs doesn't really say whether the launcher has a similar patch system as the game itself or whether it's just a brutal override of all files in the updater folder (tracked by the json you create next to it), which is fine too. I just want to make sure I'm getting that part of the process right.

Tks !

 

Hey!
Every time you need to publish an update, just put your built Launcher in the Updater folder, then run the proper command in the Admin Tool.
If the json file already exists, don't delete it: the Admin Tool will use the metadata to understand what's the proper operation to perform.
Anyway, the self-update for the Launcher just replaces files, without any binary diffing.