So, recently, I've been applying a guts system to all my characters as an attempt to balance out their combos on an internal level and that worked perfectly fine with a combination of lifeadd and defencemulset. However, I've ran into a small issue concerning lifeadd's effect during near KO conditions. Basically, MUGEN's default forced hitfall that occurs upon being KO'd kicks in whenever my characters take a hit while they're near KO range, yet they're not KO'd due to the lifeadd's effect. What I am looking for is a means to make it so that hitfall isn't forced in those situations unless the character is actually KO'd.
If you haven't already done so, you could try using the undocumented NoKo flag of the AssertSpecial controller, but you'd have to make sure it would disable itself whenever a situation would cause either player to be properly KOed as it affects both players, not just the one calling it.
Tried it and it didn't work. Actually, I'm surprised the lifeadd kicks in during this situation to begin with, although I suppose that means it's mostly working as intended to begin with sans to forced hitfall.
Can you adjust your 5000s to match what you want? IDK the exact numbers off the top of my head. But could you just FORCE mugen to switch the hit reactions? I'm not sure if you'll lose a tic this way, or see an animation pop to a 2nd one or whatever. Just go with it for time = 0 and changstate to what you need based off the sysvars+your lifeadd protocol?
Decided to rename the thread due to another issue I've encountered that's been bothering me more than the previous due to MUGEN's hardcoded nonsense. On top of the previous issue, I've come to discover that you technically can't calculate damage, only life loss. Why is this a big deal? Well, it interferes with my guts system's damage calculator. Example: if you have 1000 life and an attack does 200 damage, you can gauge the value as 200, right? Well, I've noticed that this is not true in sufficiently low life situations. So, if you have 100 life left and the opposing attack deals 200 or even 2000 damage, the calculation will still gauge that a 100 unfortunately. This leads me to believe that MUGEN only factors damage values based on total life than actual damage being dealt. With this in mind, it has lead to very inconsistent results that usually makes defence far higher than what the calculation should give. I am at a complete lost since I really have no idea how to go about this MUGEN limitation and not knowing how to solve it breaks my characters greatly.Odb718 said, July 03, 2019, 09:51:17 amCan you adjust your 5000s to match what you want? IDK the exact numbers off the top of my head. But could you just FORCE mugen to switch the hit reactions? I'm not sure if you'll lose a tic this way, or see an animation pop to a 2nd one or whatever. Just go with it for time = 0 and changstate to what you need based off the sysvars+your lifeadd protocol? TBH, I've never really messed with default hitstates before due to being so accustomed to only having experience with custom hitstates, so, I wouldn't really know how to go about what values and such for animations that are forced to be triggered upon KO.Edit: Here is a video to illustrate the problem.https://streamable.com/trtx3
2OS and I were talking about this in mugen.net discorder not too long ago, after I was trying to help someone else with the same issue. It is a huge bummer.If I remember correctly, he found that this does not happen in Training mode. Which is interesting.Actually, these last two posts sum it all up. http://mugenguild.com/forum/msg.2437356I’m gonna try some ideas for this later, seems pretty hopeless though. I do believe there could be a fix for this in a full game or with matches between your characters only, by writing the hitdef damage to a var that can be checked by the enemy. It would be a pain, since you would need to do that for every hitdef. Kind of curious if there would be enough time to use that code before dead.
If you manage to find a breakthrough, that would be extremely appreciated since while I am mostly striving for an internal balance foremost, I also want to at least retain some extent of external compatibility even if I know that such a thing is going to be very limited itself (why, just check out the recent outrage that my Miyako's caused... I guess people don't get mad at a character until it gets an AI). If I get this issue fixed, that will make it one less thing people will rage over.
Been experimenting with ideas to get around the lifeadd issue and, while it's far from perfect, is a better compromise over the previous problem I've been having.Spoiler, click to toggle visibilty[State -2, Guts]Type = LifeAddtrigger1 = alivetrigger1 = GetHitVar(damage) > 0 && life > 1trigger1 = gethitvar(hitcount) < 2Value = cond(life = GetHitVar(damage),1,floor(GetHitVar(damage)-GetHitVar(damage)*(fvar(20))))ignorehitpause = 1[State -2 Guts]type = DefenceMulSettrigger1 = movetype = Hvalue = fvar(20)ignorehitpause = 1[State -2, Guts]type = VarSettrigger1 = 1fvar(20) = ((LifeMax/1000.0)-((LifeMax-Life)*0.0005))/(LifeMax/1000.0)ignorehitpause = 1 Instead of eventually deducting half life for every first hit at a certain threshold, this will cause first hits to always leave life at 1 if current life is above 1. It's a bit wonky, but it's necessary so that damage can be calculated before the character is KO'd. Thankfully, this isn't too overwhelming of an issue since the lifeadd only triggers on the first hit and combos with hits above 1 will trigger damage calculations perfectly fine otherwise. I'm getting very close to solving one of my biggest issues. If anyone can refine my code above, that would be great. Otherwise, I'll move on to trying to solve the second problem in which low life thresholds force hitfall even from attacks that don't cause it.
