v0.1.2

Project Pyrrhus 0.1.2, a pre-release: partly playable, see docs/RELEASE-CRITERIA.md.

New in 0.1.2:

• A decrypted disc image (.iso) can be picked instead of a dump folder ("Browse for ISO file" in the setup, or the path in the console). The first run checks the disc inside it, then copies its game files (about 7 GB) into the install folder once; the ISO itself is only read. An encrypted ISO is refused with "this ISO is encrypted; use a decrypted dump".
• The setup reads the disc's title id and shows what it found under the folder ("Found: BCUS98116 (Killzone 2, US disc)"). Another game is refused by its title id and name. The Killzone Trilogy disc, whose Killzone 2 is the same title id, is named and allowed as untested.
• The game window shows the project's icon in its title bar and taskbar.
• Picking the PS3_GAME or PS3_GAME/USRDIR folder of the dump, or the USRDIR folder of the update, works: the setup and the first run use the folder above.
• When the first start asks for the decrypted EBOOT, a folder is accepted too: it looks for EBOOT.elf in it and in its USRDIR folder, and says where it looked when it is not there. The setup's EBOOT page does the same.
• The update must carry the same title id as the disc; the setup and the first-run check say so when it does not.

Fixed:

• The folder hints of the setup and the first-run check offer only Killzone 2 dumps (other games' dumps on a drive are not named) and name up to three .iso files in the folder (or one level down on a drive) beside the folder hints. When no more input comes (a closed console), the first-run check stops with its FAIL lines instead of asking again. The same fixes as Project Helghast PR #17.
• Installing into a OneDrive folder is refused, as a precaution taken from a problem reported on Project Helghast: OneDrive synced the build's thousands of files while they were written and locked them. The first-run check also stops when the install or build folder is inside OneDrive (O1), or when a game file is only online in OneDrive (O2, before anything is read, so nothing is downloaded); right-click the game folders and choose "Always keep on this device".
• When the first-run console window is closed with its X, the launcher says so ("its window was closed before it finished; finished steps are kept") instead of showing an error code. It names the first-run log only when the log exists.
• When the setup or the first run stops, the setup's message box, the launcher's dialog and the portable zip's console say why (the same reason the log has). The next start checks your files first and asks again only for the one that was wrong. The setup's EBOOT page refuses the disc's 1.01 EBOOT and names the update's USRDIR folder, where the 1.29 one is; a silent install with /EBOOT= stops with the same text. Adapted from Project Helghast's fix for the same mix-up (its PR #11).
• When a check of your game files fails, the setup's message box, the launcher's dialog and the console say which input failed ("Disc dump", "1.29 update" or "EBOOT"), the path, what is there and what it must hold, and which inputs passed. A disc dump and an update given the wrong way round are named as such, a drive picked instead of a folder gets a pointer to the folders on it that look like the disc or the update, and the disc's PS3_GAME folder given as the update fails its check. Adapted from Project Helghast's fix for the same mix-ups (its PR #14).
• The setup's disc page says what a folder without PS3_GAME holds and where PS3_GAME is when it is one folder down; the update page names the path and the missing files, or says the folder is a disc dump.
• With a decrypted ISO as the disc, the first-run check could not load its ISO reader under the bundled Python, which does not look in the check's own folder; it now does.
• Getting your files ready lists what each input must contain, says that the update does not hold the disc archive, and warns against picking a drive instead of the dump folder or the .iso file.
• Uninstalling removes the whole install folder: the first-run logs and their earlier copies no longer keep it behind.
• "Verify and rebuild" counts only the files it checked.
• The game window's messages (input and window events) are now handled on every frame tick, the same fix as Project Helghast 0.1.4. In our tests a 3.7-second stretch with no messages handled, during a busy catch-up, is gone.
• The game's disk cache is rebuilt once when the installed build changes, so the first start after an update loads a little slower. This is a precaution taken from Project Helghast 0.1.4, where a cache left by an older build ended a level with error 20000; it has not been seen on Killzone 2.
• Files the game opens to create or append to are now opened the way the console does (the toolkit read three of the open flags with the wrong values). In our tests no visible change yet: the opens seen at start are read-only.
• The game window keeps responding while the game builds its graphics pipelines on the first start of a level, which can take several seconds with an empty shader cache: the window now has its own thread, so Windows no longer marks it as not responding. In our tests the longest stretch without an answer went from 7.9 s to 0.05 s; the first start of a level is still slower than later ones.

If you have an earlier version, install this one over it: run the new setup and pick the same folder. The first start then translates and builds the game again where this version changes how it is built.

See CHANGELOG.md for the full list.

Windows installer (Project-Pyrrhus-setup.exe, recommended) and portable zip. You need your own Killzone 2 disc dump (US, BCUS98116), the 1.29 update and a decrypted EBOOT made from your own copy; none of them is included or downloaded. What each must contain: docs/GETTING-FILES.md. SHA-256 sums: SHA256SUMS (and the .sha256 files). See the README for what it does and what goes online.