Regarding items

[Pauer]

Has any work been done on creating custom items or resizing existing ones? I couldn't find anything on that subject, thanks in advance.

 

[Doq]

Crazy Mod has a weird Metal Cap block that acts as a POW switch.

 

[SinsOfApathy]

Has any work been done on creating custom items or resizing existing ones? I couldn't find anything on that subject, thanks in advance.

We've created "custom items" by hooking functions for original items, such as most of Crazy Mod's stuff. Though some of that is related to checking the character pointer for held items. We can't exactly create new ones, and as far as I'm aware, neither can anyone on Brawl yet.

Forcing the HALParser to load arbitrary files from the disk isn't a beast that we've managed to tame.

 

[Pauer]

Thanks for the quick replies!
I wanted to use custom sized items to try and see whether I could get approximations on hitbox size in relation to a character's position (TopN in Magus' "physics, input, etc. Display for develop mode")
However, I found this Excel sheet of hitbox data for ntsc1.0 posted by stratocaster in some thread:
https://www.dropbox.com/s/m1axvov6kvuk7jc/SSBM Hitboxes (NTSC 1.0).xlsx?dl=0
It contains data such as size, bone and offset of moves.
So my new question would be, to what extent are models figured out that you could make a meaningful approximation of the position of bones and hurtboxes at a given time in relation to their coordinate position(TopN)?

 

[SuperSmashNoob]

Magus' tool lets you view the x/y/z position and size of hitboxes directly. So if you subtract TopN from the hitbox x/y position, you can get the position relative to TopN (I think that's the first part of what you're asking).

At least from what I know, Animations/Models aren't really figured out yet (I wouldn't mind being proven wrong here, though). But using Crazy Hand and Magus' debug tool, you can find the exact position (well accurate to 5 decimal places) of bones, and thus their associated hurtboxes, during animations (I made about a post about it recently here: http://smashboards.com/threads/possible-brute-force-way-to-determine-character-animations.412037/ , long story short you use Crazy Hand to swap animations out and spawn hitboxes on bones so you can view their positions via the hitbox position display in Magus' debug tool, although as I mention in the post, I wouldn't be surprised if a tool like Magus' could directly display the bone positions at some point, I want to say that Achilles is working on a follow up version of it).

In addition to being a ton of work, there are a few other catches here, one is that some bones have jiggle properties during certain animations (i.e. their simulated via constraint physics rather than having fixed animations), Some of these only affect the game cosmetically (like Marth's cape bones, Zelda's dress, etc.) while others have hurtboxes attached to them (like Fox's tail and JIgglypuff's hair tuft thing), and I imagine the only way to figure ot exactly how that works would be to track down the associated assembly code in dolphin debug and analyze it (which is something I'd like to do but is way out of my league).

Another is that some animations (like GuardDamage and Run) can run at variable speeds, so if the animations were run at 60 fps when collected, the bone positions at decimal frames would have to be interpolated, although this would probably be a good approximation.

There's some other more specific things as well (like calculating how the character rotates during DamageFlyRoll and the fact that whether or not DamageFlyRoll even occurs seems random).

 

[SinsOfApathy]

So my new question would be, to what extent are models figured out that you could make a meaningful approximation of the position of bones and hurtboxes at a given time in relation to their coordinate position(TopN)?

The models don't stretch or do anything weird unless a some move swapping has taken place, AFAIK.

I'd been considering a method of approximating the max length of swords, legs, etc. by viewing position with Magus's debug or in-memory, using a simple sqrt((x2 - x1)^2 + (y2 - y1)^2 to approximate the distance of the hurtbox from topN, then pairing them with a lookup table for each character based on input state (A, B, B-Side, etc., since every character has that versus Jab 1-3, etc.).

That way, I'd have a simple "threat by distance" system, since I'd know something like, Marth's sword reaches 2.5m, so Space Furry Bot (It's a working title) would maintain a minimum safe distance, while using the known hitstun calculations and startup/endlag to predict possible openings.

It's a major work-in-progress and I've been stunted by a presumed Dolphin bug causing my SI-hijacking input system to **** the fan, so I may have a much better method when I devote the time to it. If so, I'll be sure to release it.