OpenCAGE icon indicating copy to clipboard operation
OpenCAGE copied to clipboard

Custom "patch file/script" for OpenCAGE

Open ProjectHSI opened this issue 7 months ago • 7 comments

Existing mod distributions are huge - see the Thomas the Tank Engine mod, a relatively simple (maybe not to create but premise-wise simple) mod. Maybe make it so that mod distributions are distributed via a "patch zip" which contains a script that a mod manager would be to use to replace the files?

The existing distribution method involves uploading all modified files, which is a copyright concern and also a size concern, compared to just storing the assets needed and using some kind of scripts.

Not sure how to solve these particular problems;

  • Determining which files need to be patched and how. Maybe some kind of diff w/ a backup?

ProjectHSI avatar Jun 21 '25 05:06 ProjectHSI

Yeah, I had a mod distribution system previously when it was just configuration files (it packed changes up to a little archive which you could distribute with metadata). It worked well for the configuration tweaks since they were tiny, but any level changes can get giant particularly when applied over every level.

The problem with just making an install script that mirrors the changes you made without shipping entire levels is that users might already have other tweaks or mods installed, and it's very easy for things to conflict. It's also not as simple as shipping 'some files' and not others, as every file in the level tends to depend on another, so if you rewrite one you also need to update about three more to remap indexes, etc.

It has been on my roadmap for a while and still something I intend on implementing before 1.0 - I think when I hit 1.0 I'll just require everyone uses the tools with 'vanilla' data, and then any changes from there on out can be logged to make merging mods possible.

MattFiler avatar Jun 21 '25 09:06 MattFiler

For ref this is somewhat tied to #356

MattFiler avatar Jun 21 '25 09:06 MattFiler

I think when I hit 1.0 I'll just require everyone uses the tools with 'vanilla' data, and then any changes from there on out can be logged to make merging mods possible.

That seems like an OK compromise in my opinion, although maybe just have a tool for transferring.

The unmodified ShortGuids shouldn't be changed with an old, modified vs. a new copy (i.e. the game logic is the same), so as long as we have a tool for

  1. diffing two commands/assets/whatever files
  2. merging the two together yet still keeping a log

i feel like this'd be a good compromise for everyone.

ProjectHSI avatar Jun 21 '25 10:06 ProjectHSI

I've worked a very primitive version of this sort of thing recently.

I sped up all the transit cars in the game so they arrive almost instantly. The parameters I used are lifted from another mod and since that mod works i did not have to reinvent the wheel for the delay values.

Anyway though, the only reason this works is that the composite ShortGUIDs are identical throughout the 8 misssion files targeted. When I began experiementing I thought I was going to have to track down every one of them.

Transit Car SpeedUpV1.txt

Tracking down composite and entitiy IDs would take a bit longer to do and be far more tedious. The above code was created by me and 'washed' through ChatGPT for optimization only.

But manually writing out C# script for complex mods would be more tedious.

ghramsey avatar Aug 18 '25 20:08 ghramsey

I've worked a very primitive version of this sort of thing recently.

I sped up all the transit cars in the game so they arrive almost instantly. The parameters I used are lifted from another mod and since that mod works i did not have to reinvent the wheel for the delay values.

Anyway though, the only reason this works is that the composite ShortGUIDs are identical throughout the 8 misssion files targeted. When I began experiementing I thought I was going to have to track down every one of them.

Transit Car SpeedUpV1.txt

Tracking down composite and entitiy IDs would take a bit longer to do and be far more tedious. The above code was created by me and 'washed' through ChatGPT for optimization only.

But manually writing out C# script for complex mods would be more tedious.

The main problem is (imo) pretty obvious - to install a mod would be having to run (untrusted) code on your machine, which isn't a great idea.

This does bring up the problem of how to then track the entities created by outside programs (maybe put the entity tracking logic into CATHODE?).

ProjectHSI avatar Aug 19 '25 22:08 ProjectHSI

Exactly deployment would be tedious unless one simply created the bare code verified it and expected everyone to just grab VS2022 and drop the raw code in there and that gets too complex for more than a simplistic mod such as what I pasted above. Add in the need for resources and we're on square one to just use the commands editor.
❤️ It's still the only way to be sure ;-)

ghramsey avatar Aug 20 '25 03:08 ghramsey

You can share executable along with the source code.

CATHODELib is what the Commands Editor uses under-the-hood - anything you can do in OpenCAGE you can do in CATHODELib - problem is doing it (hard).

Additionally, writing the mod deploy-er would be hard... Probably just wait until this issue is resolved for complex mods.

ProjectHSI avatar Aug 20 '25 10:08 ProjectHSI