Skip to content

Commit

Permalink
widescreen cheats_ws.zip: 6 removed, 49 changed, 452 new, 2440 total
Browse files Browse the repository at this point in the history 
This syncs the cheats_ws.zip widescreen patches archive with Devina's
archive from 2016-08-07.

The zip file is the zipped content of folder cheats_ws at the archive,
after removing the following 10 known WIP patches: 00000000 1771BFE4
C77AF2CA DA3DD765 07652DD9 FDA1CBF6 CC96CE93 2545CA71 1CE1DA8A CD787D68

Compared to the previous content of cheats_ws.zip:
- 6 files deleted (07652DD9 1CE1DA8A 44D23E5F CC96CE93 CD787D68 FDA1CBF6)
- 49 modified files
- 452 new files (w00t!)
- 1939 files identical to before

The zip now has a total of 2440 patch files, compared to 1994 before.
  • Loading branch information
@avih
avih committed Aug 8, 2016
1 parent 84f1b08 commit 8e8b8f8
Showing 1 changed file with 0 additions and 0 deletions.
Binary file modified bin/cheats_ws.zip
View file
Binary file not shown.

6 comments on commit 8e8b8f8

@turtleli
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

By the way, there's a duplicate 1429EB9F.pnach (named 1429EB9F (2).pnach) in the archive. Contents are entirely identical.

@avih
Copy link
Contributor Author

@avih avih commented on 8e8b8f8 Aug 8, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks. I'll let Devina know (it's at the original archive from the forum too), but I won't update it soon most probably, because it doesn't affect the game, and since this is a binary file and also not a tiny one, I prefer to update it relatively rarely (typically every 6 months or so) to not overwhelm the repo.

@avih
Copy link
Contributor Author

@avih avih commented on 8e8b8f8 Aug 9, 2016 •
edited

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@turtleli if you have an idea how avoid it being a binary entity, we should consider it.

The non-binary options IMO are:

  • Keep the files themselves at the repo and create the zip when building. That's almost 2500 files right now though.. a big bunch.
  • Concatenate them in a way such that textual diffs can be used. Either a home-baked format - like GameIndex.dbf is (which is how I approached this archive initially), or maybe a more standard format? tar? uncompressed zip? uncompressed something-else? (not sure whether or not that'd work as expected though).
  • Other ideas?

Also, if we want diff to work on some aggregated file, we'd have to make sure that we can produce exactly the same file on all systems. So the entries order should be well determined (alphabetically probably), CR/CRLF should be taken into account (probably use dos2unix or equivalent as part of the aggregation process), as well as file permissions or other properties which could make it accidentally into such archive and could create a different file on different systems, etc.

@turtleli
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, I can't think of any other ideas.

I suppose the first approach (create zip while building) wouldn't require changes to the widescreen archive handling. It'd probably be simple to build the zip on Linux (it might depend on cmake version). If the zip can be built without additional external dependencies on Windows too (some googling suggests powershell can zip stuff) then I think it might be worth doing (so long as nobody minds having a few thousands extra files in the git repo).

The other approach (concatenated file) sounds like a lot of work, since we'd need to do our own tooling and make changes to how PCSX2 handles the patches.

@avih
Copy link
Contributor Author

@avih avih commented on 8e8b8f8 Aug 11, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

so long as nobody minds having a few thousands extra files in the git repo

That's the main issue with it in my opinion. I'm not sure what effects it would have and where.

One thing I have in mind is that it might make git-prompt somewhat/much slower (especially on windows?). Another is possibly tortoise-git would get slow too with so many files, even if small. As well as windows explorer itself is not great with thousands of files in a single dir IIRC (can be split to subdirs, but.. effort..).

As for zipping on windows, and possibly on linux too, one option to not depend on external tools is build miniz ourselves and then use it, and it has a very liberal license. IIRC it builds on pretty much all platforms and can create zip files. Though zip is pretty common anyway, I think it wouldn't be a big issue regardless.

concatenated file sounds like a lot of work, since we'd need to do our own tooling and make changes to how PCSX2 handles the patches

The first commit of the widescreen archive actually worked like that IIRC, with a batch file which creates a simple concatenation with whatever separator, and then code which uses it. The zip only came later and was actually more work to get right than the concatenation.

So I don't think code wise it would be an issue. But what could be an issue is making sure that we can produce exactly the same file on all systems.

Another issue with such approach IMO is that it lets users edit it more easily, and I think we prefer them not to (we want them instead to use their own cheats_ws dir to override the zip).

Or.. we could leave it as is and keep updating it only every few months. It's not great but also not absolutely terrible...

@turtleli
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, I looked into the zip method on Windows because curiosity. I managed to generate a zipfile with the following powershell script:

Add-Type -AssemblyName System.IO.Compression.FileSystem
$compression = [System.IO.Compression.CompressionLevel]::Optimal

$source = $args[0]
$destination = $args[1]
if (Test-Path $destination) {Remove-Item $destination}
[System.IO.Compression.ZipFile]::CreateFromDirectory($source, $destination, $compression, $false)

and by adding a VS project that contains a custom build command like:

<CustomBuild Include="index.txt">
  <Command>powershell -executionPolicy bypass -file "$(ProjectDir)zip.ps1" "$(SolutionDir)cheats_ws" "$(SolutionDir)bin\cheats_ws.zip"</Command>
  <Outputs>$(SolutionDir)bin\cheats_ws.zip;%(Outputs)</Outputs>
  <AdditionalInputs>$(ProjectDir)zip.ps1</AdditionalInputs>
</CustomBuild>

I manually generated an index file with ls cheats_ws_folder > path/to/index.txt so Visual Studio can detect file changes and will rebuild the archive if necessary, though something like md5sum --tag cheats_ws/* might be a better idea in case no patches are added/removed but are improved instead. I checked that it works on AppVeyor.

Please sign in to comment.