Manhunt (NTSC-U) [SLUS-20827] - Crane freeze only on right side of the crane

[soultoyo]

PCSX2 version: v1.5.0-dev-3203-g56b861250

PCSX2 options: Safest preset.

Plugins used:

gsdx dump - https://drive.google.com/open?id=1wf4suqqfktZckkAj3UWsl7T9N59HXiqs

Description of the issue: https://youtu.be/x0tcr4aLWss

If you get into the crane on the right side, it will freeze and you have to either wait to get killed or restart the emulator. If you get into the crane on the left side or the front you'll be fine. I have included a video to demonstrate this issue.

How to reproduce the issue: Please look at the video to reproduce the issue, the mission is "Fueled by Hate".

Last known version to work: I'm not too sure the last version as I've been using this version to get around the lighting bug.

PC specifications: CPU: Intel Core i7 4790K, GPU: AMD Radeon RX 590 OS: Windows 10 64-bit (For example: CPU: Intel Core 2 Duo E4600 GPU: Gigabyte GTX 750Ti OS: Windows 10 64 Bit)

[ghost]

Is timing issue, but more game bug than pcsx2 issue. Reducing wait time for m instruction exec seems to fix it. But there is a catch. I described that below, proper patch should be totally fine to use.

Proper patch, highly recommended to use that one.

patch=1,EE,001D70F8,word,0803FFE0 // j       sub_FFF80           (jump to our hook s0 = wait time)
patch=1,EE,000FFF80,word,26737333 // addiu   $s3, 0x7333         (s3 seems to be always unused/zeroed earlier when we jump here, in worst case hook just will do nothing. That why add, not li, we can restore it later without issues.)
patch=1,EE,000FFF84,word,16700002 // bne     $s3, $s0, loc_FFF90 (if value in s0 is not 0x7333 return to original runtime)
patch=1,EE,000FFF88,word,26738CCD // addiu   $s3, -0x7333        (restore s3 to previous value, just in case.)
patch=1,EE,000FFF8C,word,2610D1CD // addiu   $s0, -0x2E33        (set s0 to 0x4500)
patch=1,EE,000FFF90,word,08075C43 // j       loc_1D710C          (jump back to original runtime)
patch=1,EE,000FFF94,word,00000000 // nop                         (just in case)

There is alternative way of patching, but that can break something, as value is set in very complicated way i assumed that something else can be stored there. patch=1,EE,00548F24,word,00004500 // store 0x4500 to 0x548F24 (alternative patch, can break other stuff)

For devs that eventually want to look into that. Value 0x7333 is set from 0x269380.

li      $v1, 0x48000
jr      $ra
sw      $v1, dw_549198 // bss

then at 0x1D5198 is left shifted by one, then multiplied by 0xCCCCCCCD, and hi is moved to v0. Finally right shifted by 4, and stored at 0x548F24.

lw      $v1, -0x4ad8(gp)=>DAT_00549198             // 0x48000
lui     v0, 0xcccc
ori     v0, v0,0xcccd                              // v0 = 0xcccccccd
sll     $v1, 1                                     // 0x90000
multu   $zero, $v0, $v1                            // 0x7333333350000
nop
nop
mfhi    $v0                                        // 0x73333
srl     $v0, 4                                     // 0x7333 finally...
sw      v0,-0x4d4c(gp)=>DAT_00548f24

[prafullpcsx2]

I thought setting ee timing to - 2 or - 3 fixed this bug?

[ghost]

It does. But lowering the cyclerate also cause hanging in cutsceens.

[ZT-1]

Is timing issue, but more game bug than pcsx2 issue. Reducing wait time for m instruction exec seems to fix it. But there is a catch. I described that below, proper patch should be totally fine to use.

Proper patch, highly recommended to use that one.

patch=1,EE,001D70F8,word,0803FFE0 // j       sub_FFF80           (jump to our hook s0 = wait time)
patch=1,EE,000FFF80,word,26737333 // addiu   $s3, 0x7333         (s3 seems to be always unused/zeroed earlier when we jump here, in worst case hook just will do nothing. That why add, not li, we can restore it later without issues.)
patch=1,EE,000FFF84,word,16700002 // bne     $s3, $s0, loc_FFF90 (if value in s0 is not 0x7333 return to original runtime)
patch=1,EE,000FFF88,word,26738CCD // addiu   $s3, -0x7333        (restore s3 to previous value, just in case.)
patch=1,EE,000FFF8C,word,2610D1CD // addiu   $s0, -0x2E33        (set s0 to 0x4500)
patch=1,EE,000FFF90,word,08075C43 // j       loc_1D710C          (jump back to original runtime)
patch=1,EE,000FFF94,word,00000000 // nop                         (just in case)

Working for me with this patch. And since v1.5.0-dev-3211, the camera static effect sound plays correctly, thanks to the noise generator fix. The lighting issues still requires auto flush/half-pixel offset hacks.

[kidhudi]

is there someplace to download the patched emulator?

[ZT-1]

I found that every dev build after v1.7.0-dev-680-g083380297 freezes at the first cutscene of the first level. v1.7.0-dev-683-g4a90499ec was the first to introduce this. It was last working in 680. Something introduced in between 680 and 683 caused this.

[refractionpcsx2]

I found that every dev build after v1.7.0-dev-680-g083380297 freezes at the first cutscene of the first level. v1.7.0-dev-683-g4a90499ec was the first to introduce this. It was last working in 680. Something introduced in between 680 and 683 caused this.

Does enabling the Fast CDVD speed hack resolve it?

[ZT-1]

Yes it does. Seems it requires that now.

[refractionpcsx2]

Possibly, it's a bit of an ongoing battle. I'll add it to our list #4117

[ghost]

Now that the game is fine CDVD wise, I highly sugest testing the game with instantVU1 disabled, that seemed to fix that bug on my end without the game needed the patch.

[ZT-1]

Now that the game is fine CDVD wise, I highly sugest testing the game with instantVU1 disabled, that seemed to fix that bug on my end without the game needed the patch.

This is correct with instantvu1 disabled. But for some reason the second crane later in the level locks up the game when you enter it, leave, then enter it again. This also happens with the patch.

[5d-0]

Now that the game is fine CDVD wise, I highly sugest testing the game with instantVU1 disabled, that seemed to fix that bug on my end without the game needed the patch.

This is correct with instantvu1 disabled. But for some reason the second crane later in the level locks up the game when you enter it, leave, then enter it again. This also happens with the patch.

Yeah, can confirm.

[ghost]

That's very interesting indeed, can you send me a blockdump + savestate of the area where the softlock happens with the latest dev build please?

[ZT-1]

That's very interesting indeed, can you send me a blockdump + savestate of the area where the softlock happens with the latest dev build please?

https://mega.nz/file/ewwk1LqI#Vahu4OO-C7iNhGNbOw7W8ia_FC5puCVvTZ8lDwntBKw

[MrCK1]

Is this still an issue on latest master?

[5d-0]

Is this still an issue on latest master?

Yes.

[sinisterseed]

Apologies if this isn't the proper way of reporting the issue, but to avoid duplicate reports I thought I should just reply here instead.

This still seems to be an issue as of version 1.7.3069 (x64, AVX2). I started playing the game for the first time today and while everything else thus far appears to be working correctly (except for the lights, I've noticed there is a separate report for those), things took a turn for the worse once I reached the first crane in Fuelled by Hate and refuelled it.

Jumping into the crane from any side (the original issue mentions only the right side, but I have not managed to make it work from either side/back/front) seems to just cause the controls to lock up (I'm using an Xbox One controller, if relevant). I tried spamming all its buttons after entering but nothing works, the scene proceeds as usual and enemies spawn and kill me as I'm completely defenseless. I'm using manual save states in PCSX2 and reloading the save (which is right before jumping in) restores my ability to play as normal, but as soon as I jump back into the crane, I can't do anything anymore.

I've tried some of the settings recommended in this issue, such as disabling instantVU1, enabling Fast CDVD, restarting the emulator and trying again after applying the settings, but nothing really seems to be working (unless whatever caused the issue translated into my save state and it's now doomed?) I've also tried reloading from the last regular save point in the game, in front of the garage holding the gas canister, to no avail. I always lose the controls once I jump into the crane, from both regular in-game saves, and emulator save states.

I'm happy to provide more information about my configuration if necessary, I'm using a fairly stock config overall, apart from choosing the DX12 render, upscaling the game to 3x native, enabling GPU Palette Conversion, and using widescreen hacks (which shouldn't even be necessary here, as the game offers a Widescreen toggle in its menu), I've not messed with anything.

[hammerfist]

I can confirm that this is still an issue as of 1.7.4254. The patch/cheat still fixes the issue though, thankfully.

It's also good to note that if you exit and reenter the SECOND crane that you have to use - the game will also soft-lock, with and without the patch/cheat, but the section is still completable given that you don't leave and reenter, which you have no reason to do unless you hit triangle by accident.

The first crane can be exited and reentered without any issues when using the patch/cheat. Without the patch/cheat, the section is incompletable. When entered from any side it will soft lock.

[judesaurio]

v1.7.5251

i toggle on the patch but now it doesn't do anything if I press triangle