2013-03-29, 09:08 PM
I've had some ideas about how to implement this stuff. The ATK/DEF bit would be pretty straight forward to do. But I am not sure it is even necessary to...
At first I thought the model could be done by adjusting the monsters' attack/defense whenever the player changes equipment, but I quickly realized that that would not cut it.
But it made me hopeful to keep thinking. I think what should be able to work is to simply precompute the results for all of the attacks/defense pairings whenever the player changes equipment. Same thing pretty much.
Except never really letting SOM do anything. So just do something like zero out the stats for the monsters, and just put the resulting damage in the first affinity and have it deal direct damage to the player. And more or less the same for defense, though its more complicated.
But I realize just now that the trouble with this is monsters can hit other monsters, or at least their magic can. So I think the only way this problem can possibly be approached assuming SOM does the hit detection, is to just try to find the bits of the game that identifies the attacking/defending parties and scoop it out, or if it goes through a subroutine, send it to one of our subroutines instead. And if it doesn't well then fill the scooped out bit with a subroutine call that does.
So more or less the way I probably would've opted to implement the formula calculator. Just at a higher level (assuming that's even possible)
I try not to go about reprogramming SOM this way if I can help it. But I am damned near convinced this is the only way in this case. I did a job similar to this for the first time a little while back in order to decouple the look axes so turning could be faster during fast turns without also speeding up the vertical axis.
That is enabled by extension. The only difference in this case is rerouting or injecting a call jump. It will be new territory. But I intend to look into equipping items here in a bit, and I assume that is done as a subroutine because it just isn't the kind of thing that is done in a main loop. It feels like the time is right to bump things up to this level of tampering even though I am pretty sure the EULA expressly forbids disassembly
At first I thought the model could be done by adjusting the monsters' attack/defense whenever the player changes equipment, but I quickly realized that that would not cut it.
But it made me hopeful to keep thinking. I think what should be able to work is to simply precompute the results for all of the attacks/defense pairings whenever the player changes equipment. Same thing pretty much.
Except never really letting SOM do anything. So just do something like zero out the stats for the monsters, and just put the resulting damage in the first affinity and have it deal direct damage to the player. And more or less the same for defense, though its more complicated.
But I realize just now that the trouble with this is monsters can hit other monsters, or at least their magic can. So I think the only way this problem can possibly be approached assuming SOM does the hit detection, is to just try to find the bits of the game that identifies the attacking/defending parties and scoop it out, or if it goes through a subroutine, send it to one of our subroutines instead. And if it doesn't well then fill the scooped out bit with a subroutine call that does.
So more or less the way I probably would've opted to implement the formula calculator. Just at a higher level (assuming that's even possible)
I try not to go about reprogramming SOM this way if I can help it. But I am damned near convinced this is the only way in this case. I did a job similar to this for the first time a little while back in order to decouple the look axes so turning could be faster during fast turns without also speeding up the vertical axis.
That is enabled by extension. The only difference in this case is rerouting or injecting a call jump. It will be new territory. But I intend to look into equipping items here in a bit, and I assume that is done as a subroutine because it just isn't the kind of thing that is done in a main loop. It feels like the time is right to bump things up to this level of tampering even though I am pretty sure the EULA expressly forbids disassembly