VinVulpis
patreon
I quick news post and progress update.
🕑 Added 2023-03-01 02:41:33 +0000 UTCJust posting this in as a hold-over until my next playable update is ready. I've been tryin to make the end of the month dead line, but slightly shorter month and there were some major things I discovered about Mugen (with also applied to IkemenGo) that I've been goin over and checking EVERY MOVE to fix the issue now that I understand it well.
TL;DR version of what's ahead, I just need a lil more time before I drop in the monthly character updates. I wanna get these sweeping fixes out of the way before I continue. I will drop them before the end of the week. What follows are some of the details and some info about other characters I wanna add to the mix soon since most of my WIPs are almost fully functional.
APPARERNTLY I never realized that - for whatever goofy reason - "ground.slidetime" is linked vias a goofy chain of things all the way to "guard.ctrltime." I had no idea for the longest time and it explains why it seemed like certain character (AURUMO IN PARTUCULAR) were able to block-stun lock opponents when the data didn't make sense as to why.
Even if you set guard.hittime lower then guard.ctrl time (or ground.slidetime if omitted) it'd STILL guard-lock the target. I had left various moves with higher slidetime values thinking that it didn't matter as long as it covered the hitttime value, but nope, this is linked in a VERY odd way to guard's ctrltime and it has very odd side effects with guard.hittime, like still visually keeping the target in guard lock but being able to act out of it anyway. This feels so goofy and redundant. SOOOOO to make sure all of this is taken care of, I'm trying to go through every move and make corrections.
I've made a new debugger/trainer feature for IkemenGo users that also displays frame data, on both hit and block so I can better understand how to balance my moves without needing to test out every little thing dozens of times. This will be active in the next update.
I made some changes to Mango and gave him some actual throw animations, but he still needs a back and air throw. Feliro got a majo change to Dust Devil Dance which is a ton of fun. I'll go more into that details when I post those characters.
But here, a portion of def time when into settin up more character to join the WIP bundle soon. A brand new character, Rael, was made from an old Tails concept animation I did a while ago. I really liked the animation, so wanted to convert it into something I could use. So, I made Rael. She'll be a item/gadget user of sorts.
Athis is the ghost-lookin critter that will be a super tanky defensive type.
Tek, the blue boy, has been around for a while, but I've been wanting to add him into the mix for a while. He'll be likea heavy semi-ranged grappler type.
Sheth, who has no animation yet, will also be a fire/ice user like Aurumo, but with inverted buttons and a more mobile projectile based sort of all-rounder.
So, yeah, gimme a few more days and the next round of updates will be dropped.
Comments
VinVulpis
I don't really think it's a "limitation" I think it's kind of more of an oversight. Because you can also set a guard.slidetime, which does also link from ground.slidetime.... but for some stupid reason guard.ctrltime will befault to ground.SLIDETIME when omitted. People in discourd servers and fourums alike are all mystified as to why elecbyte linked guard.citrltime to that when it makes most sense to like it to ground..hittime. There's some MAJOR redundancy with guard data values you can set too, because not only is there a guard.ctrltime value, but there's ALSO a guard.hittime.... these are practically the same thing and it creates a lot of confusion. Guard.ctriltime seems to have ultimate control over the entire guard state, as you can make guard accidentally cancelable before the actually hit finishes, straight up canceling the animation. But if you set crtltime LONGER than hittime, the animation will finish, but keep the target locked in a guarding state, even tho the hit is over. It's very, very strainge. I I made sure to as a guard.hittime AND guard.ctrltime to every hitdef and made sure they were the SAME EXACT VALUES so the animations communicate when a hit is over properly. It's just so redundant. Hahah IkemenGO COULD fix this, but they are trying to keep generally backwards compatibility with MUGEN, so older mugen content works as it would in Mugen. They are basically remade mugen but are building more ontop of it. My only issue is that I'm fidning it hard to make all of MY ideas backwards compatible. Mango pretty much relies on IkemenGO to function properly now.. Mugen's just missing nice added features. Rip.
EmeraldDragon
That's a crazy revelation. Could it be that MUGEN/IKEMEN has a limitation that pauses anim frames during sliding and thus causes block stun lock?
