Go with the eventhubs magazine in any of those situations. The tool atm is very much still a work in progress hence why he released it as “0.1”
The reason for the missing hurtboxes is that atm there are only a couple of hurtbox locations being read/displayed unless you go through all of those extra numbers and enable them. I believe only “head, stomach, waist” are being shown. Those are the most commonly used hurtboxes and most moves simply deform those hurtboxes to fit the needs of the move (many moves expand the “head” hurtbox for standing jabs for instance.)
However it’s not universally how it works. Using you profile pic of Sakura as an example, her F+MK overhead has the “right hip, right knee” hurtboxes enabled during the active frames of the move (not during the startup) at the moment the SF4BV wont show those 2 hurtboxes because it’s not set to do so.
This is also obvious with things like the recovery frames of a move, or during reeling animations. Those don’t use pre-set hurtboxes in most cases. Instead they use hurtboxes that use all of the body parts and procedurally generate a hurtbox based on the animation of the character (that is why reeling animations can sometimes cause moves to whiff.)
Not hating on the tool, it is amazingly useful for modders to get a more accurate idea of the position/size of hitboxes they modify even without looking at the hurtboxes just having the hitboxes is immensely helpful to me.
Spectacular work. Hitboxes in motion are much more telling than just the still pictures you get out of a magazine.
This is the kind of information that people need to know and developers need to give out. (I’m talking about you, Harada.)
I learned or confirmed a number of things just checking around. Like… Adon’s hurtbox contracts quite a bit in neutral, and expands when he walks (and of course when he crouches, as Xian has mentioned). You could spend a long time learning this organically through experience if nobody told you… with this tool I picked that up in like two seconds.
The reason stuff like this (and many others, including modifying health, stun, reversal window etc) isn’t done is because GFWL crashes (possibly an anti-debugging feature?) randomly when you hook into and trace through the EXE.
When I tried to modify the reversal window it kept crashing the debugger and/or the game.
Actually the reason is more to do with the fact people want to avoid potential piracy issues from releasing modified .exes if you spend ~10 minutes in google you’ll find that there is a work around to the GFWL anti-debugging issue that has been around for a few years now:
Speaking as someone who has been doing this for years (meaning I’ve probably far more time in Google than 10 measly minutes), no, it’s not because I’m afraid of releasing hacked exes -_- You can release a “trainer” that doesn’t modify the EXE in anyway. The problem is setting up a proper environment in the first place that allows you to figure things out.
It’s not just GFWL anti-debugging. There’s an entire host of issues. eg. If I use OllyDbg it will only allow me to trace and view certain things (because of bugs on in the debugger and other issues) before it crashes. If I use IDA I have to use an older version because the newer one is shipped with a DLL that’s detected as a trojan. I can workaround it easily at home, but not on my work machine, and I’m not about to install multiple copies of stuff everywhere just to debug 1 game. If I use Cheat Engine I have problems with anti-debugging. If I modify system DLLs so to defeat anti-debugging I’m stuck with a host of problems elsewhere (BTW, that IsDebuggerPresent trick is one of the first things you learn when hacking, and it’s also one of the most useless approaches). I have two versions of this game on PC. If I debug the Steam version I have to use a different approach to the disc version (I have two versions because the steam version refused to let me update - hence why I don’t modify system DLLs any more).
The GFWL bypass is well known. All you do is bypass the CRC check, and even then it isn’t necessary if you’re just doing a directX hook on Present() or Endscene() (Steam does this itself, how do you think you get a steam overlay in game?)
The array of bytes of the check is ‘8b ff 55 8b ec 83 ec 20 53 56 57 8d 45 e0’ inside of XLive.dll
I don’t really care enough to start hacking SSFIV again. It just irks me when people who don’t really do this type of thing think all you need is “10 minutes in Google”.
Even your post was not really that helpful considering what Lullius said (it was his first time doing 3D and how many iterations he’s been through). I could have told him the same thing, but why wouldn’t I just do it myself then? I don’t expect everyone to know about process hooking etc, how to do it, and then how to call/inject other routines. Remember, even though you might think all this is trivial, he is still the first person to release something like this.
I was simply letting him know it’s inefficient and not displaying all of the boxes, boxes were missing during frames and I told him a way to solve it. Never once did I claim the hook was easy, I said the bypass for GFWL was and that was directed to you not him. You have a reading comprehension issue.
No, you never touch the executable. You hook into D3D.dll. Reading memory from a EXE (to get positional data etc…) is never flagged, as anti-virus programs and other legitimate software does this.
Way to completely change the context of what I said to fit your view. It was directed at your statement about GFWL anti debuggers. I didn’t say that modifying the game / reading the assembly / whatever only needed 10 minutes on google. Merely that the solution to your problem only takes 10minutes to find and has been around since 2009ish so you didn’t look very hard to find that solution.
Also, just because YOU don’t give a fuck about releasing exes doesn’t mean everyone who does this sort of thing thinks that way. Hell, Lull even has a disclaimer right on the video and website saying if Capcom wants he’ll take it down right away. People have discussed editing the .exe before in the modding thread and one of the concerns that came up was piracy concerns regarding DLC and such.
Also I remember posting the work around in the modding thread at least a year or so ago.
That’s why your post is useless. You might as well have said “Your approach is inefficient. You should rather get a job at Dimps so that you can get your hands on the dev version”. It would have had the same effect. If you have a better of doing things, then do it.
I was referring to the stuff like health modifying/stun modifying that ilitirit was talking about. The stuff that (afaik) would actually require modifying the .exe or memory hacking.
However thanks for the info, regarding directx hooking. I’ve never really read up on that.
No, my post is insightful, it explains why the current method is not great for this application and what can be done to fix it. I’ve done these several times before and have already been down this path. From reading your replies, it’s no wonder you don’t find it useful.
I was working on this long ago and lost interest, especially after Combofiend hinted a viewer would be available in Ultra. I found the box data long ago, including the throw data, people that know me know that, so I really don’t care what you think nor do I care to argue any longer with someone who has no knowledge of this or debugging in general.
Anyways lulluis, if you need more information just PM me or something.
Maybe you can keep this elsewhere and respect the Op thread.
Ho wait, this is the internet…
Lullius, that hitbox bug I think is because of the landing animation cancelling recovery of an attack. Seems like it. Probably waiting to a data to erase the red box, but that data never comes when canceled with landing. Completely made this up from observation though…
wow I didn’t think this would actually happen. Very impressive.
Unfortunately all of those random numbered hitboxes appear to be joints in the skeleton, nothing looked like an invincibility box ( unless they are being drawn under the other boxes ).
invincibility normally works by labeling all the limbs you are turning off, ( or the limbs you are giving armor ) instead of drawing a box. FFFFFF applies it to everything for example.
Sf4 basically does hitable boxes two ways. They can be manually defined, or they can be procedurally generated. For the most part everything is manually defined except for move recovery and hitstun. Those just use the boxes around the limbs. Basically when that big box goes away during recovery the game is looking at the limb data.
Yeah I explained the boxes stuff to Lull in a PM when he first released. I found a couple of the hurtboxes that are based on the joints. One thing that makes it difficult is that the joints don’t swap sides so what is defined as left for hurtboxes has a different number when facing left than it does when facing right.
I did tell him to talk to you or hunterk about the joints because I noticed that there seems to be a bunch of extras that aren’t used in game like toes and the tip of Cody’s knife (which I guess is used for attaching the knife swing graphic effect?). There also seems to be some that appear to be just be the same thing but a different number and/or slightly moved.
Also I was wondering if maybe you knew what the hurtboxes that are deformed towards the origin point on the stage. I had no ideas about what that could be.
The other thing I noticed was missing was the origin point dot (or whatever it’s supposed to be called) the little white and pink dots that are used for where the animation will start when you cancel into a new script (either by being hit or performing a new attack). Those are shown in the old videos from super.
BTW Lullius I noticed that the tool doesn’t properly reflect that Cody’s Knife and Ibuki’s Kunai are strike hitboxes not projectile hitboxes. They still show up green.