[Question] Drive On Walls

[jaguaraxxemaster 0]

if you could get a drive on wall codes from lcs and changed the address for the car could it work for vcs? Sorry if this is a n00b question but i am afraid that i myself am a noob lol

[xFinch713x 0]

well since its actually coded into lcs cd, it wouldnt be easy for one of us average cheat users to port it. edison or vette, if vette has the source of lcs cd (probably not) or knows how to extract the data, would have to do it. but then would have to find all the data for vcs and match it up, so its highly doubtful at the moment. remember, vette broke his psp, and who knows where edison is

[jaguaraxxemaster 0]

yeah thats true... thanks for the reply finch =]

plus i realised when i played my lcs cheatdevice orx that it also has no drive on walls cheat 0.o

 

meh ive given up lol

[xFinch713x 0]

youre welcome for the reply, lol.

 

ya, who knows tho. maybe ec has secretly been working on the next cd. dont give up

[edisoncarter 9]

I'm poking my head out of my cave for a minute but I see there's no IV coming this month so maybe I'd better go back into hibernation until spring.

 

Here's the code if someone wants to convert it to script. The reason I left it out is drive on walls needs very precise forces to keep you from slipping and falling off the wall, especially with a motorcycle. With the PRX, the timing is sloppy. You can see it in the difference between hovercar in the LCS savegame version and the PRX versions. In the savegame you can hover perfectly still, in the PRX it drifts but it's good enough. I didn't think it would be good enough for drive on walls.

 

 

        //       // Drive on walls       //       {           // Cancel out gravity           if (pcar->z < 200.0)               pcar->zVelocity += 0.0068;           // Add our own gravity           NewGravity = -0.0068;           pcar->xVelocity += NewGravity * pcar->xUpVector;           pcar->yVelocity += NewGravity * pcar->yUpVector;           pcar->zVelocity += NewGravity * pcar->zUpVector;       }

 

[Vicecitystories 25]

hey edison! come out of Hibernation lol good to see your back!!

[jaguaraxxemaster 0]

:0

 

Thanks edison!!! Glad to see youve come out of hibernation temporarily

Unfortunately I'm a noob so i dont know how to do this right now... Methinks me needs a lesson in cheat creating!!!

 

To the GOOGLE!

[AndyGanteks 12,756]

I'm poking my head out of my cave for a minute but I see there's no IV coming this month so maybe I'd better go back into hibernation until spring.

 

 

You are back.

 

A little offtopic q

 

Will your IV cheatdevice be for ps3 or for 360?

 

now back on-topic

 

Will you maybe make some more codes for VCS or even LCS on the ps2 version?

 

Answer me those please before you go back to hibernation.

 

 

 

 

[vettefan88 0]

I'm not sure he's making a IV cheat device.

it was only possible on the psp because of homebrew, I'm not sure the ps3 or 360 support homebrew during actual games.

[emcp 0]

OMFG

 

heres actually alive

 

lol good to see ya

[makaveli 7 0]

edison damn havent seen you in a while we need help with getting the cheatdevice to work on the slim

[Durka Durka Mahn 0]

Good to see you Ed, thought you might have fallen off the face of the earth!

 

Wish you were here to stay, though..

[edisoncarter 9]

Good to see you guys still here.

 

Yeah I don't know what the future holds for IV. I haven't been watching the PS3 and 360 hacking scene, but if they're not cracked, I ain't gonna be the one to crack it this time like I did with the GTA exploit. It's not a given that they'll ever be cracked. Sony and MS have tightened things up after experience with the PSP and original XBox.

 

Here's the finished code and it works perfectly fine. Stick it in your /cheats/vcs/cheats.txt file.

 

 

#cheat Drive on walls// Cancel out gravityif (getfloat(pcar + 0x0038) < 200.0)   setfloat(pcar + 0x0148, getfloat(pcar + 0x0148) + 0.0068);// Add our own gravityNewGravity = -0.0068;setfloat(pcar + 0x0140, getfloat(pcar + 0x0140) + NewGravity * getfloat(pcar + 0x0020));setfloat(pcar + 0x0144, getfloat(pcar + 0x0144) + NewGravity * getfloat(pcar + 0x0024));setfloat(pcar + 0x0148, getfloat(pcar + 0x0148) + NewGravity * getfloat(pcar + 0x0028));

 

 

edit:

It would work well with Vette's monster quad, except I forgot to classify the Quad as a motorcycle for the never-fall-off cheat. Do we have any other monster-vehicles?

Edited October 9, 2007 by edisoncarter

[creeepers 0]

 

Do we have any other monster-vehicles?

OMG its edison.

i never get to met you though but i got my opportunity to meet you.

 

and there's vette's rockcrawler and my pimped mesa-grade.

pimped mesa grande

rockcrawler

 

btw guys im working on something:

Edited October 9, 2007 by creeepers

[edisoncarter 9]

That works good, I was driving over entire buildings with the Rockcrawler.

[emcp 0]

btw vcs pmg was released a week or 2 by me ( ade didnt have homebrew, and vette broke his psp so he gived me the addresses although top speed and acceleration is needed also i hoping to include default vehicle values)

 

it now called Sunshine Customs and you can find it here

 

http://mcpdev.co.nr

 

in the downloads section

 

or

 

http://dl.qj.net/Sunshine-Customs-PSP-Home...14660/catid/195

 

also the people mentioned the speed of the vehicle choOser etc and its fixed ( ONLY AVAILABLE ON MY SITE )

+

documentation included

 

Please Register

Thanks

Edited October 9, 2007 by emcp

[Durka Durka Mahn 0]

Hey, EC, any chance me and Waterbottle could get our hands on that source code?

 

I'm getting good at C, and maybe Waterbottle and I could make some custom changes ourselves..

[emcp 0]

yeah i would like the source released to some other developers who have time to update it

 

also ddm you do know c on the pc is nothing like c on the psp in my opinion

 

 

[Waterbottle 0]

 

yeah i would like the source released to some other developers who have time to update it

 

also ddm you do know c on the pc is nothing like c on the psp in my opinion

It's the exact same language, how can they be nothing like each other?

 

If you can code in C it doesn't matter what console you are coding on. Obviously if all the C you know is how to use the most basic functions, from the windows header and what not, then you might feel it's different. But the only difference between them is that you have to use some other functions. But the standard libraries are included, so I don't really see how it's different to code C on the psp.

 

Of course doing changes to the memory takes a decent amount of C syntax knowledge, but if you were to modify the memory of a PC program that wouldn't be any easier.

 

Please elaborate on how they are completely different.

[makaveli 7 0]

damn man that stuff looks cool but i cant use it yet cuz the slim cant use cheatdevice yet cuz i dosent have a 1.50 kennel so but its sopose 2 have it soon then i can use cheatdevice again i hope

 

 

emcp-i tryed to register for that site and it was all saying i already had acount when didint and it was all messed up

[vettefan88 0]

makaveli, it'd take more than the 1.50 kernal to get cd working on the slim.

Since cheatdevice doesn't work on higher firmwares the cheatdevice cant' even run on the slims firmware.

 

cheatdevice would have to be made to work on higher firmwares first. I think it's the size of the cheat device that prohibits it from working on higher firmwares though.

[makaveli 7 0]

makaveli, it'd take more than the 1.50 kernal to get cd working on the slim.

Since cheatdevice doesn't work on higher firmwares the cheatdevice cant' even run on the slims firmware.

 

cheatdevice would have to be made to work on higher firmwares first. I think it's the size of the cheat device that prohibits it from working on higher firmwares though.

oh yeah i know but as long as devhook can work then im ok and devhook can work on a 1.50 kernal so yeah all i need is devhook to work

[vettefan88 0]

 

makaveli, it'd take more than the 1.50 kernal to get cd working on the slim.

Since cheatdevice doesn't work on higher firmwares the cheatdevice cant' even run on the slims firmware.

 

cheatdevice would have to be made to work on higher firmwares first. I think it's the size of the cheat device that prohibits it from working on higher firmwares though.

oh yeah i know but as long as devhook can work then im ok and devhook can work on a 1.50 kernal so yeah all i need is devhook to work

but, will devhook work on a slim?

all the lower firmwares are for the phat, and the slim has new functions and a enw firmware.

the firmware may not even load on the slim.

[emcp 0]

Its fix now

 

an email was to be sent out for you to activate but theres a problem with the emailing service and it wont work so i manually activated all current users

 

and disable activation this means it will work for new users

 

thanks for the heads up

[hax0rofl 2]

If edison released a fixed CheatDevice, it would work just fine on the Slim.

I've been messing with the PRX under 3.71.

 

First I wrote a small PRX loader which loads the PRX 30 seconds into VCS, because my first suspicion was that after 3.10, VCS + the cheatdevice loading at once crashed. It turns out that its just a coincidence. No matter when I load the cheatdevice, it crashes around 10-20 seconds after loading.

 

To make it appear on 3.71 I had to update the following NIDs (numeric IDs for the firmware functions) using a hex editor:

 

0xEEDA2E54 (sceDisplayGetFrameBuf) at 0x11700 -> 0xE56B11BA0x984C27E7 (sceDisplayWaitVblankStart) at 0x11704 -> 0xB685BA360x3A622550 (sceCtrlPeekBufferPositive) at 0x11710 -> 0xC4AAD55F

 

 

There are another two NIDS which CheatDevice uses but have changed in 3.71, however they are actually unnecessary and do not need to be updated, but I did it for completeness.

They are

 

0x6A2774F3 (sceCtrlSetSamplingCycle) at 0x11708 -> 0x6D74BF080x1F4011E6 (sceCtrlSetSamplingMode) at 0x1170C -> 0x28E71A16

 

 

If I update all the NIDs and set the one for sceDisplayGetFrameBuf (used for obtaining the framebuffer and blitting the menu to vram) to 0x00000000 (thus preventing the function from being called), there are 2 effects:

1) the PRX loads but doesn't ever crash

2) the cheat menu doesnt appear

 

So, my conclusion is that the problem lies in the CheatDevices blitter function. Complete speculation, but it seems to have some sort of memory leak which crashes it within a few seconds of loading. Due to changes in 3.10, this leak causes a crash, and for whatever reason, it never affected =<3.03.

 

edisoncarter, hopefully you can fix this, I'm sick of using DevHook

 

 

Regards.

Edited October 10, 2007 by hax0rofl

[makaveli 7 0]

If edison released a fixed CheatDevice, it would work just fine on the Slim.

I've been messing with the PRX under 3.71.

 

First I wrote a small PRX loader which loads the PRX 30 seconds into VCS, because my first suspicion was that after 3.10, VCS + the cheatdevice loading at once crashed. It turns out that its just a coincidence. No matter when I load the cheatdevice, it crashes around 10-20 seconds after loading.

 

To make it appear on 3.71 I had to update the following NIDs (numeric IDs for the firmware functions) using a hex editor:

 

0xEEDA2E54 (sceDisplayGetFrameBuf) at 0x11700 -> 0xE56B11BA0x984C27E7 (sceDisplayWaitVblankStart) at 0x11704 -> 0xB685BA360x3A622550 (sceCtrlPeekBufferPositive) at 0x11710 -> 0xC4AAD55F

 

 

There are another two NIDS which CheatDevice uses but have changed in 3.71, however they are actually unnecessary and do not need to be updated, but I did it for completeness.

They are

 

0x6A2774F3 (sceCtrlSetSamplingCycle) at 0x11708 -> 0x6D74BF080x1F4011E6 (sceCtrlSetSamplingMode) at 0x1170C -> 0x28E71A16

 

 

If I update all the NIDs and set the one for sceDisplayGetFrameBuf (used for obtaining the framebuffer and blitting the menu to vram) to 0x00000000 (thus preventing the function from being called), there are 2 effects:

1) the PRX loads but doesn't ever crash

2) the cheat menu doesnt appear

 

So, my conclusion is that the problem lies in the CheatDevices blitter function. Complete speculation, but it seems to have some sort of memory leak which crashes it within a few seconds of loading. Due to changes in 3.10, this leak causes a crash, and for whatever reason, it never affected =<3.03.

 

edisoncarter, hopefully you can fix this, I'm sick of using DevHook

 

 

Regards.

dang u smart well if you right then thanks for the find on that i hate useing cheatdevice too but i dont care no more now as long as i can use it on the slim then im ok

[vettefan88 0]

If edison released a fixed CheatDevice, it would work just fine on the Slim.

I've been messing with the PRX under 3.71.

 

First I wrote a small PRX loader which loads the PRX 30 seconds into VCS, because my first suspicion was that after 3.10, VCS + the cheatdevice loading at once crashed. It turns out that its just a coincidence. No matter when I load the cheatdevice, it crashes around 10-20 seconds after loading.

 

To make it appear on 3.71 I had to update the following NIDs (numeric IDs for the firmware functions) using a hex editor:

 

0xEEDA2E54 (sceDisplayGetFrameBuf) at 0x11700 -> 0xE56B11BA0x984C27E7 (sceDisplayWaitVblankStart) at 0x11704 -> 0xB685BA360x3A622550 (sceCtrlPeekBufferPositive) at 0x11710 -> 0xC4AAD55F

 

 

There are another two NIDS which CheatDevice uses but have changed in 3.71, however they are actually unnecessary and do not need to be updated, but I did it for completeness.

They are

 

0x6A2774F3 (sceCtrlSetSamplingCycle) at 0x11708 -> 0x6D74BF080x1F4011E6 (sceCtrlSetSamplingMode) at 0x1170C -> 0x28E71A16

 

 

If I update all the NIDs and set the one for sceDisplayGetFrameBuf (used for obtaining the framebuffer and blitting the menu to vram) to 0x00000000 (thus preventing the function from being called), there are 2 effects:

1) the PRX loads but doesn't ever crash

2) the cheat menu doesnt appear

 

So, my conclusion is that the problem lies in the CheatDevices blitter function. Complete speculation, but it seems to have some sort of memory leak which crashes it within a few seconds of loading. Due to changes in 3.10, this leak causes a crash, and for whatever reason, it never affected =<3.03.

 

edisoncarter, hopefully you can fix this, I'm sick of using DevHook

 

 

Regards.

try devhooking firmware 3.10 and seeing if it'll load.

I think the 3.71 kernal changes something with the screen,which may be why it's not showing up.

 

also, if the menu isn't up, do the cheats still run? that'd be another thing to check.

I can't remember if any cheats are on by default, I don't think so, so as soon as the game starts, press "X" to activate where the health cheat would be, then do the button combination that would normally remove the menu and try to hurt yourself. if you don't get hurt then the cheats are still running, and it's just the menu isn't displaying.

[hax0rofl 2]

The cheats are pre-activated in CheatDevice 2.3, and are definitely working for the few seconds that it works for.

I'll try with the version that doesnt actually show the menu and report back when I have a minute.

 

edit: I haven't tried Devhook yet. It would probably work, but as with CheatDevice I'd have to update all the NIDs that have changed, and that'd take a long time. Anyway, Devhook is not a permanent solution, and a 2.71 dump is a waste of space on the memory stick.

Edited October 11, 2007 by hax0rofl

[vettefan88 0]

I'm saying try to devhook a firmware between 3.03 and 2.71.

I think the kernal in 2.71 changed the screen somehow so that things for the 1.50 kernal don't display. like it changes the dimensions or coordinates or something.

the menu could end up being drawn outside of the screen.

 

if you try something like 2.10, which we all know cheatdevice doesn't work for, but still supports the appropriate kernal, and the menu pops up then you know it's the 2.71 kernal and it can be an easy fix.

[hax0rofl 2]

The 3.71 kernel has not changed the display drivers at all, it just has an extra one for the Slim.

 

My manually-patched up CheatDevice works fine on 3.71, but not on previous firmwares, because 3.71 uses a new method of storing internal function "names" (actually 32-bit numbers) which makes the old ones invalid.

-> Sidenote: The old internal numbers were the first 32 bits of the function names SHA-1. Therefore sceDisplayGetFrameBuf used to be 542edaeeda618e3f079ac74692246df12aa8f7c7 -> 0xEEDA2E54 (bytes reversed due to little endian-ness of the PSP's processor)

The number (actually called a NID) for this function is now 0xE56B11BA which is pseduo-random rather than based on the function name.

 

The functions themselves have not changed, which is why I only had to update the u32s referring to functions and not the code which uses them.

 

Not much more can be done by patching the PRX, the only solution is for EdisonCarter to fix it, or release the source (after all, its only a memory patcher with an onscreen menu). Unless he doesn't want to in which case I shouldn't have wasted my time

Edited October 11, 2007 by hax0rofl