Split versions

[klensy]

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

[gszabi99]

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.

[VitaliiAndreev]

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.

[gszabi99]

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?

[VitaliiAndreev]

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.

[gszabi99]

How/where can I check the name? In any case, I assume "origin" is the default one?

[VitaliiAndreev]

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.

[gszabi99]

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?

[VitaliiAndreev]

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.

[gszabi99]

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

[VitaliiAndreev]

You're still going to need the version number, but the script that you've got already covers it.

[klensy]

Strange, in 1.99.0.21 something triggered rebuilding all your png files. I checked few source ddsx - they didn't changed at all.

[gszabi99]

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.

[klensy]

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.

[gszabi99]

I use ImageMagick's mogrify tool, and I don't think I have such an option.

[klensy]

try -define png:exclude-chunk=date

[klensy]

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.

[gszabi99]

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.

[klensy]

Didn't remove -format png, just add that line.

[gszabi99]

Same result with -format png -define png:exclude-chunk=date. Lots of missing pngs.

[gszabi99]

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?

[klensy]

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.

[gszabi99]

MOGRIFY -format png -define png:exclude-chunk=date "D:\WarThunder\datamine\monitor\atlases.vromfs.bin_u\medals\*.dds" > NUL in a batch script.

[klensy]

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

[gszabi99]

Version: ImageMagick 7.0.10-6 Q16 x64 2020-04-06 Maybe this could be the problem?

[klensy]

I really don't know. You can send me files that didn't converted.

[gszabi99]

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.

[gszabi99]

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

[gszabi99]

Nope, doesn't want to work even through CMD. Strange, just yesterday it worked without a problem.

[klensy]

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.

[gszabi99]

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.

[klensy]

And no message about Can't unpack oodle compressed textures, until ...? Try newer version of wt-tools.

[gszabi99]

With the newest version:

[klensy]

Read the first line please, Can't unpack oodle compressed textures, until oo2core_6_win64.dll not placed to wt-tools directory

[gszabi99]

But it's there?

[VitaliiAndreev]

For me it needs to be where the executable is. In my case an exe I made calls WT Tools and the oodle assembly needs to be with that exe. I don't even have it in the WT Tools directory and it works.

I use this for unpacking. (There's a bug right now that causes an error if you don't launch the game before unpacking. I've fixed it, but it hasn't been made public yet. I can post a fixed version if you actually want to use it.)

[klensy]

Reproduced. That error because dll not in PATH from where you launch your bat file. cd into wt-tools dir and work from it.

[gszabi99]

Thanks. It works once again.

[klensy]

It seems like a few people use wt_tools but error reports so rare, even if there actually errors like that.

[klensy]

This error with path should be fixed now, but no new build for now.

[VitaliiAndreev]

It seems like a few people use wt_tools but error reports so rare, even if there actually errors like that.

I bet people are mostly interested in aces.vromfs.bin and char.vromfs.bin because stats. Everything else is more niche.

[klensy]

So, returning to dds to png convertation, is it works now?

[klensy]

Png metadata fixed, as i can see, but there still issues:

It seems that u don't clean folder before unpacking new version, but simply overwrite it: removed files in new version didn't removed in current folder (they simply didn't unpacked and file from old version still here), for example eula_ro.txt last changed long ago, but it added/removed quite often.

[gszabi99]

Yes, I did that, and you made me realise how wrong it is. I'm going to modify my script for deletion, and we shall see how it works out.

[gszabi99]

It would seem the png problem remains, although on a much smaller scale: latest commit Any ideas?

[klensy]

Somehow tIME chunk added, -format png -define png:exclude-chunk=date,time

[gszabi99]

@klensy It would seem all the issues have been ironed out. Or did I miss something? EDIT: Of course the moment I speak everything goes to hell: https://github.com/gszabi99/War-Thunder-Datamine/commit/296cfeb42fab1428edb83353c7700f1365d8f46e

[klensy]

You forgot to converted dds to png?

[gszabi99]

That part of the script did not change, so I don't know what caused it not to function.

[gszabi99]

And this time the conversion worked flawlessly! I haven't changed anything... https://github.com/gszabi99/War-Thunder-Datamine/commit/ee32939a6fdeb74c65192600ba141046601dc1fb

[klensy]

Try to save logs from all steps (unpacking, mogrifying, etc), there maybe answer.