War-Thunder-Datamine
War-Thunder-Datamine copied to clipboard
Split versions
Hi. Split prod\dev to different branches, as its hard to see diffs in one branch when they mixed. Tag versions, so you can compare releases directly, for example https://github.com/klensy/wt-tools/compare/v0.2.2.3...v0.2.2.4
Sorry, by prod you mean the live client? I'm not sure what you mean. Only the dev client's updates are uploaded here*, so with what are they mixed?
*EDIT: Not true since 2020-06-15.
I reckon it's situations like this that cause complications when checking diffs.
I used to do revert commits before pushing actual patch changes to maintain change set consistency when I had branch resets for whatever reason.
But I do like the tag approach more. Though it's a bit more of a fuss when everything's in order, which can be alleviated with a bit of automation.
Currently these are the git commands I use to automatically push stuff to Github. 2-click git.sh
#!/bin/bash
VER=`cat D:/WarThunder/datamine/char.vromfs.bin_u/version`
git add .
git commit -am "$VER"
git push
How could I modify this to also make tags and assign them to the commits?
Try
git tag $VER
git push origin $VER
That should tag the current state of the repo, i.e. the latest commit, and push the tag to GitHub (assuming your local repo uses the "origin" alias for the remote repo).
You can find more info here.
How/where can I check the name? In any case, I assume "origin" is the default one?
git remote -v
It will be "origin" unless you specifically changed it. You might have to if you have several remotes to push to - in which case, add more lines.
D:\WarThunder\datamine\GitHub repo\War-Thunder-Datamine>git remote -v
origin https://github.com/gszabi99/War-Thunder-Datamine.git (fetch)
origin https://github.com/gszabi99/War-Thunder-Datamine.git (push)
Thank you, so it's origin in my case.
You might have to if you have several remotes to push to
Is a "remote" a local copy of the branch that is on my PC?
It's what it says on the tin - a remote repository, i.e. not near you. In your case it's on GitHub (https://github.com/gszabi99/War-Thunder-Datamine.git). What you have locally is, well, a local repository only users on your machine can work with. Somebody else can fork your remote into a new remote, or clone it as a local repository. Local repositories need to be synced with their remotes to stay up-to-date if there's more than one contributor.
If you create a repo on, say, BitBucket, you might need to push to both to keep them updated. Some sites (like GitLab) have a mirroring functionality that nicks any new commits from a specific remote.
The local-remote model applies to branches the same way it does to repositories.
Thank you for the lengthy explanation. So I believe the example you gave here is going to work for me, as I only upload them to GitHub and I'm the sole contributor.
git tag $VER git push origin $VER
You're still going to need the version number, but the script that you've got already covers it.
Strange, in 1.99.0.21 something triggered rebuilding all your png files. I checked few source ddsx - they didn't changed at all.
Yes, I was perplexed as well. I have no idea what caused it, we shall see if it's also going to happen next time.
Only thing that changed in pngs (not source ddsx) is create and modify ext info. I've saw this few times in your repository. Try to change your dds to png convertor to not to write this info.
I use ImageMagick's mogrify tool, and I don't think I have such an option.
try -define png:exclude-chunk=date
You tried that IM option? It works.
Master branch without latest commits, try to add git push origin master
after last line, maybe it will fix this issue.
It's fun: you wrote about romanian eula, but it absent from commit history, check @VitaliiAndreev repo for example.
Nope, it doesn't want to work. Many dds files were not converted by this, while with the -format png
I used earlier, they were. For example the entirety of the atlases/medals and atlases/units folders remained dds.
Didn't remove -format png
, just add that line.
Same result with -format png -define png:exclude-chunk=date
. Lots of missing pngs.
You tried that IM option? It works. Master branch without latest commits, try to add
git push origin master
after last line, maybe it will fix this issue. It's fun: you wrote about romanian eula, but it absent from commit history, check @VitaliiAndreev repo for example.
So I should push twice?
Try manually git push origin master
to see if it fix the things.
What exact command you use to convert? ./magick mogrify -format png -define png:exclude-chunk=date a-20g.dds
works good. Or send files that fails.
MOGRIFY -format png -define png:exclude-chunk=date "D:\WarThunder\datamine\monitor\atlases.vromfs.bin_u\medals\*.dds" > NUL
in a batch script.
MOGRIFY -format png -define png:exclude-chunk=date "D:\WarThunder\datamine\monitor\atlases.vromfs.bin_u\medals\*.dds" > NUL
in a batch script.
Used this command, all good.
Version: ImageMagick 7.0.10-14 Q16 x64 2020-05-23
Version: ImageMagick 7.0.10-6 Q16 x64 2020-04-06
Maybe this could be the problem?
I really don't know. You can send me files that didn't converted.
Oooooookay, this problem runs waay deeper than I ever imagined. Tried to manually go through the steps, and of course I ran into a problem. Using the wt-tools_windows-2019/ddsx_unpack.exe (v0.2.2.2), it fails because of the oodle compression type. Which is funny, as until days ago it had no problem unpacking them in a script.
Oh wait, I had this problem ages ago. For some reason manually it doesn't work, but if I call it in cmd it does. So it's not a "new" problem, just a forgotten one. :D
Nope, doesn't want to work even through CMD. Strange, just yesterday it worked without a problem.
Oh wait, I had this problem ages ago. For some reason manually it doesn't work, but if I call it in cmd it does. So it's not a "new" problem, just a forgotten one. :D
Don't work how exactly? There should be some errors printed in console.
Oh wait, I had this problem ages ago. For some reason manually it doesn't work, but if I call it in cmd it does. So it's not a "new" problem, just a forgotten one. :D
Don't work how exactly? There should be some errors printed in console.
unsupported compression type: oodle
Very strange, just yesterday it worked flawlessly.