Github or other git service to efficiently track patches

Want hints or tips about creating textures or other resources? This is the place for you.
Post Reply
User avatar
24 Posts
 x 0

Post 30 Jan 2016, 08:58

I've always played really common modpacks so every time I needed a Sphax patch I just had to download the appropriate pre-made set and install it.

Now that I'm playing a custom modpack I realize how inefficient is the process of making a modpack patch, with an average of 70+ or 130+ mods, tackling down each and every entry in the WIP\Release for Mods subforum is time consuming.

Thus I'm wondering... why not building a repository for each (unzipped format) mod patch? So that when a modpack patch is needed you just need to click a couple of buttons to merge a given set into a new repository were all the patches coexist, furthermore when a mod patch is modified, the corresponding merged repo for the modpack can be rebuilt in a second. Having such structured organization can also make resizing existing texture damn easy with a couple of command line scripts (of course _only_ scaling down resolution to not loose quality):
- git pull
- imagemagick -resample\resize what fits best
- git commit
- git push
- git merge if needed

aaand mod patches are 5 commands away for every damn resolution and every damn modpack on earth.

I understand that I'm new in the field so does this sounds like something doable and does it have sense for you guys out there that have been doing mod\modpack patches for years before me? :D

Assuming it has sense doing it a preliminary workflow could be as such:
  1. Create an organization profile on github so that all mods\modspack repos are child of it
  2. Create a repo for every single mod patch out there with branches for different resolution *see later suggestion* (easy but damn boring I know)
  3. Create a repo for every modpack as a merge request from every mod patch needed
  4. Use built-in github repo download as zip to publish on the forum the ready to go and use package
Every patch comes in multiple resolution, my suggestion to optimize the described workflow is to have repos _only_ for the highest resolution version available of the patch and then resize it down to the different standards only when "compiling" the final zip archive using imagemagick batch command. This way however we will have a scaled version from the image itself and not the vector shape IMHO the quality difference of scaling the vector instead of scaling the image isn't a big deal.

Feedback of course is welcome but please be constructive.

Meanwhile I thought that all of this could also be done server-side without having to download\modify\upload.
User avatar
BDcraft Web Admin
5539 Posts
 x 151

Post 30 Jan 2016, 09:13

It's actually a good idea... and I think an idea that has been tentatively suggested before and then had nothing done with it because of your second point... it's boring to initially setup (also ignoring the obvious mild learning curve of users using git).

The issue with the "only upload the highest resolution" is that to process the patches in imagemagick you'd need to create a resizing control file as GUIs and their elements don't scale down linearly (i.e. 512x-64x are all the same resolution) and quite possibly other files. Also the issue of people getting IM installed properly and workable across Windows, Mac and Linux (with a singular script plus whatever control file you have to define for "do not resize/resize special circumstances").

I just don't know how versions of mod patches will work with numerous resolutions on git... Some mods change structure a lot and to keep a useful repo you might have a lot of branches (or numerous repos just for one mod...).

I will say though that I personally have no time to set up repos for all of my patches (I am responsible for A LOT of patches) and no desire to either, but if someone else wanted to set up repos and give permissions I'd use them.
If you like a post give it a diamond! :arrow_heading_up:
User avatar
24 Posts
 x 0

Post 30 Jan 2016, 09:51

Well I could pick up the initial job to setup a startup tree on github taking the latest version I can find of the patches. It will surely take time but I think there is no hurry either considering that given the huge initial effort, once stuff is done it will be way easier to do all the others jobs.

Regarding the resizing procedure I might haven't explained myself right or I misunderstood your reply. I do not by any mean intend to involve the end user with all this procedure, it should stay "under the hood" and used by actual patch maintainers\creators, whereas they don't know how to do it because they are skilled only on the designing side of the process I could offer myself to also aid the process of updating the repos given that I receive correctly built patches because I don't know much, almost nothing on how a patch inside structure is made except that I can see tons of subfolders and a bunch of png images.

So as stated if I can receive properly built patches I can keep the repos updated.

Regarding the automated process of resizing I should indeed learn a bit of how a patch folder tree is made, but I guess GUIs elements are in their subfolder and I bet they are all called the same across mods patches? So an hypothetical script that batch resizes the images could properly skip GUIs elements given that it knows as you said what to skip.

Hence a patch maker should only care to built an high-res, properly structured zip, then I and maybe if someone else would like to help, would take care of updating the repos. Sounds as a doable workflow to you?

Regarding the repo organization it could be built as follow:
  • One repo for each mod
  • One branch for each mod version
  • (if the imagegaick auto-resizing process can't be made) further sub-branches for each resolution. But I firmly believe there is a way to automate the resizing.
Where instead a patch maker wants\know how to use git he could take care of its own patch repo with eventual aid from me or hypothetical others supporters.

I think this kind of workflow will be an huge improvement but I'd like to know that the time involved in setting it up won't be wasted.
User avatar
BDcraft Web Admin
5539 Posts
 x 151

Post 30 Jan 2016, 10:01

Sadly mods don't have to follow a strict structure. Some mods place things in gui and others in guis and then some are outside the textures folder... Also some mods place elements for guis in the items folder. For you to figure that out would either require a lot of time to look at each delivered patch or just ask the patch creator to tell you and you to modify a script in kind.

You wouldn't even be able to think you're safe once you've made that script initially as things might change within the mod between versions.

It'd be easier for the patch creator to push all resolutions to git really ^.^;; Not that we currently have many people working on patches... I try to find time, Novamanga does a lot (but I'm not sure how he'd feel about using git) and Sillyman is doing Thaumcraft (which already has a git).
If you like a post give it a diamond! :arrow_heading_up:
User avatar
24 Posts
 x 0

Post 30 Jan 2016, 10:14

Well if the patch creator can provide all (or a few) resolution than the git workflow is damn more easy. It will just be matter of uploading the proper version in the proper branch and keeping it updated, more like a managing job than a developing one xD

I would like to also hear the opinion of the others package maintainers 'cause at the moment seem more an issue determining if this method is wanted to be used because if it's just a few people to handle the updating process of the repos will be damn easy even if no one can use git.
User avatar
Patch Creator
127 Posts
 x 2

Post 17 Feb 2016, 19:41

I'm massively in favour of having patches tracked via Git, I'm also in the process of shifting over the patches I've made over to GitHub (I currently have them stored away in private BitBucket repos).

There are 2 downsides to using Git to manage graphics work I can think of right now (whilst half-asleep on the train):

- There's a huge learning curve to Git flow for people who aren't very technically minded, which if it was enforced in some way could potentially put off a lot of contributors
- Depending on how efficiently the source designs are set up (vector vs bitmap layers/masks, tons of smart objects, etc) repos can get pretty huge

I'd say #1 is the biggest issue. As long as there are some fool-proof 'Git-for-dummies' guides written for newcomers available however this can be minimised. But my prediction would be that you'd get less people overall engaging with patches because of the entry barrier.
MC U/N: Grumpy_Pirate
Post Reply