Board: M.U.G.E.N Development Help



Алексей is Offline
Contact Алексей:
I get the concept here, but I'm clueless on calculating the necessary offset. I can make this work for one specific state against one specific opponent, but I'm totally lost on how to do this against any opponent, in any anim.The only thing I can think of is to rely on the enemy constant (const) values. You'll be jumping from center to origin (or vice versa) right? Regardless of enemy size, if they have properly set size.height in their character, then half of that would be your offset. You can try to account for if it's not set by providing some sort of fallback value to minimize the jump.
Hmm... I understand! I'll give this a shot when I get home from work. Thanks man, I'd never think of this.Haha, no problem.

Mind = Blown.Oh yeah man. I was equally surprised when I found out about this.
I know not to try setting/changing vars within a custom state, but I've been racking my brain, and searching high and low on Google, on how the hell to read P1's vars from within a custom state. This is awesome information right here.
I can't take credit for it though. I believe it was Cyanide who I first saw this from.
I have a custom get-hit anim for P2 using that spriteAh okay. Good!But the issue is that the animation jumps depending on where P2's axis orientation is when touching the light.
I'm hoping to have the animation behave as I envision, with P2 freezing immediately when he touches the light, whether standing, crouching, in mid-air or whatever, then flying directly into the center of Jailbot's face. I have a basic understanding of throw mechanics, but I'm not keen on changing the axis orientation smoothly between frames (or in this case, States)
Really, it's just a matter of offsetting the extra distance by calculating how much the sprite is off. You would just trigger that on the frame/state/whatever that you need it to. The sctrl would probably be Offset. I've had issues with PosFreeze in the past, but I think it was just my situation. See how it works for you though.When the attack hits the opponent, make the screen flash white
Nobody will notice the sudden jump in anims
Scale = (20.0/Const(size.height)*1.0),(20.0/Const(size.height)*1.0)
**EDIT** Is there any way to set this calculation as a var, and have it recognized by P2 in the custom state? I've tried all the redirections I can think of without success, and can't find anything about it through GoogleIt's actually better that you don't in this case. While you can read vars from the enemy, in a custom state "var(0)" refers to the var of P1, not P2. Making changes to player vars within custom states is frowned upon because it can cause strange issues with code from the player's State -2 that you couldn't be aware of on a per-character basis. However, there is one way that you can have the player in your custom state read a "variable" of yours. It works like this:
fall.envshake.time = 0 ; To disable the fall.envshake entirely.
fall.envshake.freq = (20.0/enemynear(0),Const(size.height)*1.0)
scale = GetHitVar(fall.envshake.freq)

) to make your centered sprite appear on the ground for the short time your need.wait i know what needs more priority than what all of you said
ELECBYTE COMING BACK.
Sorry, I deleted that post because I figured it didn't add that much of interest.
(but don't let that stop you from responding anyway)
That'd be true if we actually had a say in Mugen's evolution. We don't. We can post on elecbyte's forum, but if there's something that really can't be done right now AND Elecbyte just won't fix it because reasons, you're still shit out of luck in spite of any ideals of a perfect world.I meant more from the developer's design choices, not necessarily our own as mugen devs/users. You're right though. Even in full games, you still may not to have everything you want due to engine limitations, especially in the screenpack department of things.
The only thing we can discuss is community standards, but history shows that there simply isn't enough people who follow them for it to make any sort of difference, even on forums with an active community that actually bothers to try and set up some new standards. So in practice, the best you can hope to do is a full game for yourself where you're the one who can make sure everything works the way you want it. ... That also almost never happens (proportionally speaking).
mugen is a hammer, and it's lacking the little bit on the back that is used to take nails out. someguys use mugen as a paper weight and it being a hamemr it works, other guys use it as a screwdriver which requires a lot of work, but hey, more power to them, and some guys get pissed off because when they want to use it as a proper hammer to take some nails out, it's lacking the bit and they have to do a lot of extra work.
Hard work pays off. I have ridiculously complex chars waiting to be tested & assure you there's no limit to what MUGEN "allows". I'm also getting disrespectful comments from people who appear to have been doing this for a while but are clearly limited artistically & mentally. ill try to push MUGEN forward through my little website. at least this way i wont have to worry about strangers attacking my opinions. you all have an idea of what ill be releasing from my previous post & I appreciate the awesome advice. use this discussion to build each other.peaceWell, yes, in most cases, hard work does pay off, however people do this for a hobby. Nothing is more frustrating than realizing that you can't do something or have to jump through hoops to do something that's seemingly simple, all because the original developers didn't implement it naturally. These are basic things we'd expect from a fighting game engine. In my opinion, that's taking a step backward in the evolutionary chain, which leads to the conclusion that since we can't expand upon the engine itself, there's nothing we can do to evolve it more. That's not to say that implementing these features in your characters is discouraged, but that it "shouldn't" be necessary. The community really does welcome creativity of all kinds, believe it or not.
ps: forgot about Electr0 stages,he's the shit.hahaha
I once created a double sided K' for mugen. Custom states fucked me over even in a fullgame environment with stuff that range from animations taking the wrong "animation side" during the first element of an animation all the way to both hitdef enemy facing and changestate facing parameters fucking the entire animation for no reason because MUGEN.
...Never again I said and ditched the entire thing and reused the second side sprites for his EX mode
environmental hazards has to be possible but I haven't seen it yetThis is possible already as well. Electr0 is responsible for making a few packs of interactive stages. However, you should know, many, myself included, are discouraged with the way that mugen "allows" you to do these things. In this case, they have to be coded into the characters. Super custom life-bars also have to be coded into the characters. Tag teams need to be coded into the characters. Because of this, no one is going to be relying on these methods as it takes lots of manual work to even have a controlled roster with all those features. It's just not worth it in the end unless you're making a full game. Things like stage-interactivity should be available to code within stages first and characters second. Seeing how this isn't something that you have any control over, DKDC's post holds truth.