Damage calculator

[Holy_Diver]

Well yeah, single thread processors run one op at a time, but the code is still just going to reflect the sequence the programmers set up. ‎  Even if they ran a subroutine like "trigger Hit animation" between damage calculation and HP reduction, you should still be able to skip past that subroutine and get the damage calculation section without much searching. Anyways, it's pointless to discuss. It takes what it takes based on your skill level and game.exe's stupidliness.

See you seem to be basing your conception here on having some code injected somewhere. If that's the case you may as well inject the code anywhere; edited: as in, the best place possible. If there is no code injected however, it just runs where it runs.

I wonder too if you realize that the HP loss is just the final result of attack and defense with respect to eight variables, so you can't extract all of that from the HP loss. It's like being handed a 4 and being asked whether its 1+3 or 2+2. You can't say.

A quick look shows around 400 sub routines in game.exe; most of them quite short. Have you charted any of their functions?

After this next release SomEx.dll is going to standardize around som_db.exe, specifically the final patched version. Other exe files are no longer going to be supported. So if someone wanted to they could start documenting the subroutines of that image.

I think it would be useful to have a big graph of the EXE with curved lines linking call jumps that you can zoom in and out of in order to help visualize it. But I looked for a product like that yesterday and didn't find anything. I could probably make such a graph myself with a graphing library. I don't know if there would be too much program for it to be practical or not.

I know it pretty well instinctively. It just takes a few afternoons to do whatever I want to do with it when something needs to be done.

EDITED: Also just for the record. Even in multi thread applications, or a massively parallel architecture, things are happening at the rate of nanoseconds, so you just can't presume concurrency. Everything must be run in sequence. If two execution threads must interact that's an interlock point which can bring everything to a grinding stop. It's a miracle just to keep the concurrent tasks from clobbering one another at the speed of light.