YesNoOk

Show content

This section allows you to browse the content for this member. Note that you can only see content for which you have sufficient viewing permissions.

****
Алексей is Offline
Contact Алексей:

Алексей

Contributor

Messages by Алексей

    

Re: "Tractor Beam" attack - how to deal with axis

 December 29, 2014, 07:35:08 pm View in topic context
 Posted by Алексей  in "Tractor Beam" attack - how to deal with axis (Started by altoiddealer December 28, 2014, 04:55:13 pm
 Board: M.U.G.E.N Development Help

No problem man! The final result is going to be insanely awesome. I can't wait! XD
    

Re: "Tractor Beam" attack - how to deal with axis

 December 29, 2014, 05:52:58 pm View in topic context
 Posted by Алексей  in "Tractor Beam" attack - how to deal with axis (Started by altoiddealer December 28, 2014, 04:55:13 pm
 Board: M.U.G.E.N Development Help

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.
    

Re: Scale P2 to specific pixel size

 December 29, 2014, 04:31:03 pm View in topic context
 Posted by Алексей  in Scale P2 to specific pixel size (Started by altoiddealer December 28, 2014, 09:02:16 pm
 Board: M.U.G.E.N Development Help

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. :D

Mind = Blown.  ._.

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.
Oh yeah man. I was equally surprised when I found out about this. :) I can't take credit for it though. I believe it was Cyanide who I first saw this from.
    

Re: "Tractor Beam" attack - how to deal with axis

 December 29, 2014, 04:21:55 pm View in topic context
 Posted by Алексей  in "Tractor Beam" attack - how to deal with axis (Started by altoiddealer December 28, 2014, 04:55:13 pm
 Board: M.U.G.E.N Development Help

I have a custom get-hit anim for P2 using that sprite :)  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)
Ah okay. Good! :) 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.
    

Re: "Tractor Beam" attack - how to deal with axis

 December 29, 2014, 03:47:26 pm View in topic context
 Posted by Алексей  in "Tractor Beam" attack - how to deal with axis (Started by altoiddealer December 28, 2014, 04:55:13 pm
 Board: M.U.G.E.N Development Help

When the attack hits the opponent, make the screen flash white :P

Nobody will notice the sudden jump in anims

Lol, it wouldn't be the first time we've hidden mugen's flaws with aesthetics. XD
    

Re: Scale P2 to specific pixel size

 December 29, 2014, 03:46:04 pm View in topic context
 Posted by Алексей  in Scale P2 to specific pixel size (Started by altoiddealer December 28, 2014, 09:02:16 pm
 Board: M.U.G.E.N Development Help

Your logic should work here. One thing you have to understand about mugen is that if no floating point (float) numbers are within an equation, the result will be an integer. I can't remember if you need both the numerator and denominator as floats, but it doesn't hurt to make both:
Code:
Scale = (20.0/Const(size.height)*1.0),(20.0/Const(size.height)*1.0)

Quote
**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 Google
It'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:
In the HitDef, you take one of the unused (in your particular case) parameters and set it to whatever you want. For example:
Code:
fall.envshake.time = 0 ; To disable the fall.envshake entirely.
fall.envshake.freq = (20.0/enemynear(0),Const(size.height)*1.0)

Then in your custom state, you would access the "variable" using GetHitVar:
Code:
scale = GetHitVar(fall.envshake.freq)
    

Re: "Tractor Beam" attack - how to deal with axis

 December 29, 2014, 03:25:17 pm View in topic context
 Posted by Алексей  in "Tractor Beam" attack - how to deal with axis (Started by altoiddealer December 28, 2014, 04:55:13 pm
 Board: M.U.G.E.N Development Help

I believe that what you're looking for is within the common required sprites. I'm not sure if you've seen this or not, but I'll leave it here for you: http://elecbyte.com/mugendocs/spr.html. It's the list of all common required sprites with pictures near the bottom. Extremely useful. I use it for reference all the time. :)

In your custom state animation, you would use 5001,0 for example to center P2 in the middle. If you need both types of sprite-positioning, you can rely (usually) on const(size.height)/2 or const(size.mid.pos.y), though keep in mind these are based on how the author set them in their character. My idea is that you could use the offset of either of those values (or possibly the average of both :P) to make your centered sprite appear on the ground for the short time your need.

If I'm way off, let me know, lol. I think this is what you're talking about though.
    

Re: TechHit Question, custom state commands

 December 19, 2014, 01:04:08 pm View in topic context
 Posted by Алексей  in TechHit Question, custom state commands  (Started by Odb718 December 19, 2014, 11:24:46 am
 Board: M.U.G.E.N Development Help

I don't really know, but given the nature of custom states, I'd say it uses P1's commands. I guess you can do a simple test by first including a dummy command in P1 and putting your enemy in the custom state and then trying the same for P2 having P1 without the command.
    

Re: Evolving MUGEN

 December 19, 2014, 05:44:29 am View in topic context
 Posted by Алексей  in Evolving MUGEN (Started by delete my account November 29, 2014, 09:51:34 pm
 Board: M.U.G.E.N Discussion

    

Re: Can't seem to detect an enemy variable correctly for a special intro

 December 17, 2014, 09:17:02 pm View in topic context
 Posted by Алексей  in Can't seem to detect an enemy variable correctly for a special intro (Started by Víctorys December 17, 2014, 09:09:08 pm
 Board: M.U.G.E.N Development Help

Hmm, it's only a hunch, but I have a feeling that you're trigging your intro too early. Usually stuff like that should go in the intro or pre-intro state (190 or 191) and then be decided from there. 191 -> 194.
    

Re: Evolving MUGEN

 December 17, 2014, 09:02:35 pm View in topic context
 Posted by Алексей  in Evolving MUGEN (Started by delete my account November 29, 2014, 09:51:34 pm
 Board: M.U.G.E.N Discussion

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)

No worries. Your post still contributed to the thread topic because it's downright true. We're all basically saying the same thing here, but even with that knowledge, we, the creators are still making innovative things and keeping the community alive. Which, I think, at the end of the day is all that matters. Oh, and having fun with it, because it's a hobby after all. :P
    

Re: Evolving MUGEN

 December 17, 2014, 08:47:23 pm View in topic context
 Posted by Алексей  in Evolving MUGEN (Started by delete my account November 29, 2014, 09:51:34 pm
 Board: M.U.G.E.N Discussion

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.
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).
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.
    

Re: Evolving MUGEN

 December 17, 2014, 08:30:47 pm View in topic context
 Posted by Алексей  in Evolving MUGEN (Started by delete my account November 29, 2014, 09:51:34 pm
 Board: M.U.G.E.N Discussion

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.

Those countless bloody fingernails! The horror, lol. Excellent analogy, by the way.
    

Re: Evolving MUGEN

 December 17, 2014, 08:22:16 pm View in topic context
 Posted by Алексей  in Evolving MUGEN (Started by delete my account November 29, 2014, 09:51:34 pm
 Board: M.U.G.E.N Discussion

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.peace

ps: forgot about Electr0 stages,he's the shit.hahaha
Well, 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.

P.S.
There will be people who disagree with your opinions (generally speaking) no matter where you go. It's all about how you handle it. You can get offended and lash back or take it with a grain of salt and provide a valid rebuttal. It's up to you.
    

Re: How do you prefer to Mugen?

 December 17, 2014, 05:02:58 pm View in topic context
 Posted by Алексей  in How do you prefer to Mugen? (Started by Sheng Long December 16, 2014, 12:51:09 am
 Board: M.U.G.E.N Discussion

I don't play mugen, so my choice would be watch in SD. 640x480 just feels right.
    

Re: Evolving MUGEN

 December 15, 2014, 03:42:40 pm View in topic context
 Posted by Алексей  in Evolving MUGEN (Started by delete my account November 29, 2014, 09:51:34 pm
 Board: M.U.G.E.N Discussion

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 :P

I know your pain, dude. I have Sai for my game NZCR and he's got one sleeve longer than the other. In my case, I just compromised. It's not worth the stress, lol. XD
    

Re: Evolving MUGEN

 December 15, 2014, 01:46:55 pm View in topic context
 Posted by Алексей  in Evolving MUGEN (Started by delete my account November 29, 2014, 09:51:34 pm
 Board: M.U.G.E.N Discussion

How many 8-bit characters have you seen? 90% of the characters released use 16-bit sprites or higher. MVC, CVS and KoF are all examples this. Also, the size of the sprite doesn't always depict the bit-description of it. This is all your personal preference and pushing it on others isn't going to be evolving anything.

Quote
environmental hazards has to be possible but I haven't seen it yet
This 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.
    

Re: Shiyo Kakuge's coding?

 December 15, 2014, 01:12:05 pm View in topic context
 Posted by Алексей  in Shiyo Kakuge's coding? (Started by Mugenman2 December 13, 2014, 09:23:18 pm
 Board: M.U.G.E.N Development Help

It pretty much "takes coding" to do anything within a character. There are no free rides.
    

Re: Is this possible ?

 December 14, 2014, 09:23:42 am View in topic context
 Posted by Алексей  in Is this possible ? (Started by Kid-Ares December 04, 2014, 03:29:10 am
 Board: Development

Blizz, it's because mugen is not open source. We're given a proprietary language called CNS that can only control so much. Mugen is extremely limited in that sense.
    

Re: Do you even XMAS GIFTS?

 December 12, 2014, 08:11:37 pm View in topic context
 Posted by Алексей  in Do you even XMAS GIFTS? (Started by Bastard Walt December 12, 2014, 12:38:03 am
 Board: All That's Left

I'm getting a Wii U for which I've purchased Super Smash Bros. and Hyrule Warriors. Should be fun as I've enjoyed both series extensively over the years. HW being in the "Musou" category.