Best Method for Finding No Clip / Collision Hack

[live2play]

I am interested in figuring out how to get a no clip / no collision hack.  What are some of the best methods for finding this? I have noticed that several other no clip hacks are basically changing 000000FF to 00000000.  The trick is knowing how to find that word in memory.  Any help is greatly appreciated.

I'm assuming that I could start by setting read BPs on my coordinates and trace it through the ASM to find anything that is performing an fcmpo operation.  Seem reasonable?

[James0x57]

find your coords, stand still, do a bpw on them.
ignore or 'skip' any instructions that hit
once you start moving, there will be more, ignore those too
run into a wall, the ones that break are most likely your wall/door/object collisions

this is also a good way because it excludes the ground at the begining, you don't want to noclip through the ground

This is how I found it in a few games.

edit:
(when finding your coords, there are usually many copies of them, use the first ones you find that actually move your player when you poke them- most won't)

[live2play]

Great information.  Thanks!  When you're poking your coordinate values, what value do you find most useful to just see a reasonable change?  Also, am I correct in assuming that bpw is a write BP?

[dcx2]

bpw = WPB = write breakpoint, yes.

Look at the coords in memview with autoupdate.  Jump up and down a few times.  Make a guess about what the Z value is, and how big it gets when you jump.  Try to poke Z to twice that value.  If it works, you teleport into the air and fall back to the ground.

You may want to set a WBP on the coords, then step once to step over the write, and then go poke memory.  Depending on what the code handler hooked, the coords you poke may get over-written before they're read.  WBP -> step -> poke will ensure that you the next read will be the coords you poked.

[live2play]

Thanks for all the help.  As always, I appreciate it.

[wiiztec]

Forget about finding coordinates. Do a search walking unobstructed then walk into a corner and do a not equal search then change the search condition to equal & old column 1 and walk  unobstructed again then search walking into a corner again and repeat until your search is significantly narrowed down. set a write breakpoint on your best result something like 00/01 is preferable, go to the disassembler tab and call the stack go down through the list nopping the function calls until you can walk through walls

[live2play]

What do you mean by column 1?

[γRB]

Well I'd not expect boolean values only.
I guess by 'column 1' he means the results you previously got.

[James0x57]

Boolean searching for this not going to work in most cases because the collision needs to be handled quickly-- it's unlikely to get dumped off in ram as a means to stop the player later. Plus, collision in a 3D world is much more complicated than that. If there's a boolean at all- it would most likely be stored on the stack and only be there to trigger generic animations or, possibly, a more rigorous collision detection routine.

...if it's a 2d game, then that's a whole different ball game. You'll probably get simple booleans for each direction you can move.

That all said- it's not impossible to find a boolean related to collisions in ram, and to trace your way back if you do... but it's far less direct.

Also, it looks like Parasyte has the same tips as how I've been able to find them in the past:
http://doc.kodewerx.org/generic_code_hacking.html#walk_through_walls

It's possible he suggested it to me, but my first one was when GCN hacking was less than a year old... so I do not remember.

[James0x57]

One more note:
Some 3D games have primarily 2D collision systems for x,z and a mostly separate one for the up/down (y).
Examples include Simpsons Hit & Run and True Crime SoLA

[live2play]

One more note:
Some 3D games have primarily 2D collision systems for x,z and a mostly separate one for the up/down (y).
Examples include Simpsons Hit & Run and True Crime SoLA

Thanks for the great information.  I really appreciate it.

[wiiztec]

Every walk through walls code I've made besides the first one I ever made for FF4 I've made using the method I described it's almost foolproof

[Bully@Wiiplaza]

I haven't heard of wiiztec's solution yet and I had trouble with James' long ago.
Hopefully I'll be successful the next time I try. I don't always find the coords for every game therefore this sounds good.

[live2play]

I haven't heard of wiiztec's solution yet and I had trouble with James' long ago.
Hopefully I'll be successful the next time I try. I don't always find the coords for every game therefore this sounds good.

Finding the player coordinates is definitely not always easy.  I am usually able to find several addresses that only change when the player moves, but quite often these end up being values related to the player's movement but not the actual player coordinates.

[Bully@Wiiplaza]

Exactly, poking or freezing them does absolutely nothing.
Not even glitching the movements or so.

Can it be that the ram write gets overwritten rendering the code useless even though it was the right address?
A WBP should then take some effect or RBP at least.

Sometimes coordinates also change while standing still or decrease while jumping up (Goldeneye) and other mad things which may've prevented me from finding them at all. Unequal searches are a Sisyphus work since all you know is that it's different all the time even while standing probably. :(