Limit-break idea

  • Thread starter Thread starter Gingercat
  • Start date Start date
Status
Not open for further replies.
G

Gingercat

Guest
Ok, so it's been found that the damage is found using a signed 16-bit integer right? I'm assuming that this is coded into the exe. Would it be possible to edit this particular property in the exe's raw code so that it is unsigned? Or is that simply too hard to do with an already-compiled exe?

Given the other wonders you guys are able to perform on the executable, I'm wondering if (just for example) the 9999-limit-break patch could rewrite not only what the game considers a maximum for damage dealt, but also the section that deals with damage calculation to change the computation from signed to unsigned.
 
Looks like massive amount of work :P Not only you'd have to find every single comparison which uses the HP / MP / Damage and change it to unsigned, but also find each and every variable that uses the HP / MP / Damage and also change those accordingly, and then find the variables that use those variables, etc. And you'll only get a boost from 32k to 64k.
 
Oh man. :-o That's definitely not worth the effort. The exe would basically have to be redesigned from scratch, with a 32-bit int in mind... And that's well beyond the scope of most reconstruction projects!

Oh well, 30k it is :lol:
 
Also remember that the first bit of this 16-bit integer is the "healing bit". This makes damage technically a negative value and heals the target of the attack. Take that away and there will be no more healing! D:
 
Last edited:
Tsk tsk, we'd have to change it to a long unsigned int.

Wouldn't it be interesting to be able to decompile the exe back to source code then modify a few things here and there? :lol:

To my somewhat limited knowledge though, decompilation of an exe is impossible.

Interesting use of the leading bit as a healing marker...
 
I wouldn't call it impossible, just inaccurate. Normally when you compile something that has multiple header files or dependent files, they all get embedded into the executable. When you decompile, all that info is there so the decompiler thinks it was all one file and decompiles it in one long code.
Also, it has no way of knowing what the variables were originally called by the developers so it'll have things like cvar1 and lvar3 as the variable names. Same thing with function and procedure calls. It gets real hairy trying to do all that.
 
That would be very... Difficult to navigate, heh.

That's probably why I'd heard it was impossible - The variable names wouldn't be overly meaningful.

Imagine changing every int to "long int" or even "long long int" - Apart from increased memory usage (which wouldn't really matter in the grand scheme of things), what would this break? I imagine (and might well be off-track) that this would leave the leading zero there that gets used for healing purposes. I'm quite curious, since it's only this year that I've jumped into C programming and I'm getting a pretty good grip on the basics.

This is one of my "I wonder what happens if..." moments :lol:

I have a lot of those :D

Now that I'm so curious, I'm gonna go look for a way to decompile an exe just to have a look at what programs that I've designed and compiled look like when they are broken back down to code.

Mmm, I should be studying my Calculus stuff for the upcoming exam but this is too interesting, heh :)
 
Status
Not open for further replies.
Back
Top