Author Topic: Help/Advice With Coding Questions for W.I.P.s (Read 2855 times)

Playing Enemy · « **on:** July 26, 2015, 03:51:39 AM »

Alright guys, so I've begun the process of learning how to code characters, but instead of only reading the DOCs and studying the sh*t out of KFM simultaneously which I am doing, I'm also watching all Ryon's and Buckus's videos, and reading every little tidbit I can from code archives and whatever I can find on any forum, but there's still stuff that isn't covered at least in ways that make sense to a somewhat beginner, so if it's cool, I'd like to post questions I have strictly relating to what I'm working on into this thread only, instead of forming numerous threads whenever I have a question. I apologize in advance if they're idiotic, but I promise, I do everything I can to figure out the answer first on my own, then ask when all else fails. If anyone chooses to offer help or advice, I will be eternally grateful. Oh, and if it matters, I'm sticking to WinMugen only for now, not 1.0 or 1.1. I need what I make to run on WinMugen.

1.

(click to show/hide)

Anyways, to start off and cover some of the small little things that are escaping a remedy as far as I know, but are bugging the crap out of me, is, what do the green and purple hitboxes indicate in this screenshot? From what it looks like, it's the players width (I guess), maybe, but wth is the purple one? I've spent a lot of time tweaking all of the clsn's and those boxes don't exist in any of the work I've done.

2.

(click to show/hide)

Is there anyway to get rid of what seems like Mugen created dust effects when you land a jump or get hit to the ground from a fall state? I've looked at a lot of characters and they seem to be present on all of them, which makes me think you can't get rid of them, but figured I'd ask to be sure.

I have a lot more questions, but I also have the will to learn and figure it out the best I can on my own, then ask for help after I feel I've done all I can or just get over my head and confuse myself, so if I ask something here, it's only after I've spent at least a week straight trying everything that I can understand at this point in the game. Please don't think I'm just diving in, not reading and learning, trying and failing, then saying "Wtf, it's not working, fix it for me," like some square. That is not the case at all, I assure you.

-Whiplash- · « **Reply #1 on:** July 26, 2015, 02:11:33 PM »

May I ask WHY you want to use WinMUGEN instead of Mugen 1.0?

For question one I have no Idea, I've never seen those hitboxes before.

For two, those dust effects are from the Common Files, two option, you can replace the dust effects in the common.sff and common.air.

They are generated wither by a "gamemakeanim" in a state (probably jump land or dash ending) in either common or batman, or an explode using FX (if the Letter F is in front an animation's Number, it will play an animation from the common files instead of the character's files) where x is whatever the standard number for the dust effect is.

Playing Enemy · « **Reply #2 on:** July 26, 2015, 10:59:21 PM »

I tend to write a lot when I post, sorry in advance. I'm working on it.

I only want to keep using Winmugen over 1.0 or 1.1 because I mainly use Xmugen, which is Linux Winmugen ported to Xbox, and doesn't have any support for 1.0 and up content, which sucks, but I manage. I just want to make sure that if I make something cool, I can actually use it.
At least I know I'm not going crazy for not recognizing those weird hitbox colors at all, if you say you have never seen them either. Alucard, you wizard you. What the heck is causing them, and why are they even there (asking self)? It's so odd. I'm sure it'll be figured out eventually though.
As for the dust, it makes sense that it could be created from the common1.cns file like you said, because I checked a lot of other characters and they all had it present when they land as well. I don't know why I didn't think about the file that is constantly being used by most characters being the culprit. Either way though, I went through and nulled all instances of "gamemakeanim" from the common1.cns file just to see if it had any effect, sadly it did not, and did the same with Batman, but he didn't have any anyway. That dang dust is still there. Batman doesn't have that dust anim anywhere in his files either, and I've never seen a common.sff or a common.air file anywhere ever, so I am truly stumped on what's causing it or how to remove it.

Small potatoes in the big picture, but improvement is improvement even if it's just cosmetic.

I appreciate the response a lot too Whiplash. you've given me more to look into and consider. The greatest things have small beginnings, so bare with me while I learn to walk.

-Whiplash- · « **Reply #3 on:** July 27, 2015, 01:49:20 AM »

Quote

I only want to keep using Winmugen over 1.0 or 1.1 because I mainly use Xmugen, which is Linux Winmugen ported to Xbox, and doesn't have any support for 1.0 and up content, which sucks, but I manage.

As long as it's something like that and not something stupid like you would rather downgrade characters then upgrade one.

Quote from: Playing Enemy on July 26, 2015, 10:59:21 PM

I've never seen a common.sff or a common.air file anywhere ever, so I am truly stumped on what's causing it or how to remove it. Small potatoes in the big picture, but improvement is improvement

Sorry my bad, FIGHTFX.air and FIGHTFX.SFF they have them in the data folder.

Cyanide · « **Reply #4 on:** July 27, 2015, 05:04:04 AM »

Those dust clouds have a few ways that they are formed.

Some have actually used code to display them, in other situations it's hardcoded, ie the engine does it for you and there is no way to remove them short of creating your own states (sometimes not even then) Hop back for example, it's coded with makedust. Jump land is hardcoded and all you can do is remove the sprites from the fightfx if you want it to vanish. Find the anim. Swap all the frames for a single -1,0, 0,0, 1

The green clsn is a DEFAULT clsn2. In the air file in txt form it is denoted with
clsn2default = 1 They tend to display even if they're not involved in the current frame.

This means you set up the clsn boxes once, and they will apply to every frame in the animation until another clsn box is defined, or another clsn default of the same sort is defined. Great for animations like stand or walk where the hitboxes shouldn't change.

The purple one is i THINK a clsn1default (the red version) although it could be a very specifically placed blue and red clsn over the top of each other (blue + red = purple) only way to tell that would be to actually look at the animation in something. And... kinda a bad clsn if that's the case. I'm hoping it's just a default.

-Whiplash- · « **Reply #5 on:** July 27, 2015, 04:47:06 PM »

Clsn1defaults are yellow.

It could be a blue and red together as that would make purple, but I don't understand why they would be there at all.

Though it's weird, the hitbox viewer usually just shows even the clsn2defaults as blue normally, and I'm curious as to why Batman would have a green box only on his feet like that?

Playing Enemy · « **Reply #6 on:** July 28, 2015, 01:52:09 AM »

@Cyanide
Thanks for all the input with this. The 2 instances where the dust IS present where I don't want it, is the hop back and the jump land, but only on forward and backwards jumps, it doesn't happen on neutral jumps. Like you and Whiplash said, I'll check the fightfx.sff, and see if it's in there cause that is one thing I haven't done yet.
About the CLSN's, I believe I understand what the colors of each one dictate, but here's his animation coding for his standing weak punch,

(click to show/hide)

and there is no defaults present. I should mention also that I'm using winmugen for testing also, not 1.0, so maybe it's just a winmugen thing. I say that because, I'm a moron and before asking this question in the first place, I failed to check another character, and I just checked Sagat by DivineWolf, and he's got them on all his attacks as well in the same exact way. I apologize for not thinking to do that before asking. Still, it's weird they're there? They don't effect the animations they appear in though, so I don't know if it qualifies as a problem, rather than an annoyance.
@Whiplash
My response to Cyanide can also apply to your last post, and thanks again for the info too. I appreciate everyone's help with this big time.

Edit:
Thanks guys, I did locate the dust sprites in the fightfx.sff like you both suggested. I kind of knew I would after you guy's mentioned it, cause it's pretty obvious if all characters are being affected, then it's probably a fightfx or common file cause. Thank you very much again for helping me figure this one out.

Cyanide · « **Reply #7 on:** July 28, 2015, 03:58:09 AM »

The only other possibilities for the green box (it is absolutely a clsn2default, this isn't in question) is that there's a helper hanging out behind batman to display stuff. Or at least sitting there during attacks. It shouldn't have a clsn box though, especially not a hittable green one.

Umm, your screenshot shows s.LK, not s.LP. Look out the animation for s.LK and see what that has in it.

Playing Enemy · « **Reply #8 on:** July 28, 2015, 01:28:35 PM »

Oops, sorry about that. Here's the correct animation coding for his s.LK, so you can see it if you want.

(click to show/hide)

I don't see any references to him using default clsn's in his .AIR file, but I'll go through and check out all of his helpers like you suggested, and see if I can find something funky going down with one or more of them. Still, I've noticed other characters have the boxes there as well. Here's 2 screenshots.
Sagat by DivineWolf

(click to show/hide)

KFM by Elecbyte

(click to show/hide)

Similar to the dust being in the fightfx.sff, could this be something related to the common1.cns maybe?
Side note, managed to remove those dust sprites like I wanted, thanks a lot guys. That was really bugging me.

Cyanide · « **Reply #9 on:** July 29, 2015, 06:40:24 AM »

I have... never noticed that before. Probably nothing to worry about. It's bound to be a weird mugen display thing. Could be related to version of mugen, or localcoord or all sorts. If it has no effect, ignore it.

It's absolutely not related to common1.cns. Doesn't look like a helper either, the lettering under the name would look mangled while it tried to put both in the same spot. It's mugen being its incomplete self.

Playing Enemy · « **Reply #10 on:** July 29, 2015, 11:31:10 PM »

Lol, sounds good man. If they aren't effecting anything other than visual aspects under rare conditions like playing with clsn's visible, then whatever. I'm kind of relieved anyways, cause it was starting to demotivate me, and I'd rather move onto more interesting aspects of character creation, then trying to fix a "bug" that has no real relativity. This, and those dust sprites were my first 2 small problems that I wanted to fix before really diving in, and both you and Whiplash helped me address both. Thank you very much for the help, and I'll be back to this thread soon seeking more wisdom I'm sure. I know you have a pet peeve with people not wanting to help themselves first or even bothering to really try before asking for help Cyanide, so I promise I will do my diligence first before making any future posts. I'll try to make sure all questions or issues are at least derived first from extensive research and application being met with failure or confusion. Anyways, thanks again for the help. Truly grateful for it as I can now move on to the good stuff.

Playing Enemy · « **Reply #11 on:** April 16, 2016, 03:44:10 AM »

Hey guys, I have some new questions I'm struggling with that I would very much appreciate answers for if anyone can offer them. I'm sure it's not a hot topic, and possibly frowned upon, and if so, I apologize and assure you my intentions are pure and necessary. My questions pertain to converting Mugen 1.0 code to Winmugen. I can for the most part convert any 1.0 character, and usually with no errors, but there are a few sections of code I struggle with that plague me greatly and are keeping me from converting a few of my favorites. If anyone can offer solutions to how to recode some of these tidbits of code, I would be extremely grateful.

1 - My first question, is there anyway to know what the simple numerical values should be for when replacing the "const()" trigger? Like this string for example.

trigger1 = abs(vel x) < Const(movement.crouch.friction.threshold)

I usually can find the numbers I seek in the winmugen common1.cns, but sometimes it doesn't have the answers for some of the areas some authors use the Const trigger for.

2 - Winmugen seems to have a problem with there being too much code/text per 1 line, so is there another way to format a line of code, such as this one, to be contained to 2-3 lines instead of 1 long one?

In Notepad, this is just one long single line of code --->

var(10)=ifelse(prevstateno=1251131,2,ifelse(prevstateno=1251132,2,ifelse((command="2qcb2p"||command="2qcbz"||command="2qcfz"||command="2qcf2p"||command="qcbqcfz"||command="qcbqcf2p")&&power>=3000,3,ifelse((command="2qcbz"||command = "qcbqcfz"||command = "2qcb2p"||command="2qcfz"||command="2qcf2p"||command="2qcfy"||command="qcbqcfy"||command="qcbqcf2p"||command="2qcby")&&power>=2000,2,1))))

If anyone can answer just one of these questions, you would be helping me out unbelievably. I only convert 1.0 characters so that they can be used on Xmugen since it unfortunately is just a linux mugen port, and can't support the new generation of characters, and I love using Xmugen.

Cyanide · « **Reply #12 on:** April 16, 2016, 05:26:18 AM »

const() refers to the constants at the top of the cns file power, life, attack, that sort of thing.

The line you see there is "new" and does not exist in winmugen. You would have to swap it for a basic number. Look at what KFM uses for his crouch friction, put that number in there. Not perfect, it'll do.

Uh, for the second one, who wrote THAT. Wow that's a mess, and hard to read, and ugly, and a variety of things i don't like about optimisation when it's taken too far.

All we can do here is break it down between the ifelses and see if we can do something more sensible.

First 2
ifelse(prevstateno=1251131,2,ifelse(prevstateno=1251132,2
Those both set the variable to 2.
Next one
ifelse((command="2qcb2p"||command="2qcbz"||command="2qcfz"||command="2qcf2p"||command="qcbqcfz"||command="qcbqcf2p")&&power>=3000,3,
That sets the var to 3
ifelse((command="2qcbz"||command = "qcbqcfz"||command = "2qcb2p"||command="2qcfz"||command="2qcf2p"||command="2qcfy"||command="qcbqcfy"||command="qcbqcf2p"||command="2qcby")&&power>=2000,2,1
That sets it to 2 as well.

If it's neither state was previous, all the commands are false and your power is less than 2000, it sets the variable to 1. What do the actual triggers for the varset look like. Honestly here, stuff doing it as an ifelse string and just break it down into 3 sctrls

varset
trigger1 = prevstateno = blah
trigger2 = prevstateno = blahy
trigger3 = power = [2000,2999]
trigger3 = command="2qcbz"||command = "qcbqcfz"||command = "2qcb2p"||command="2qcfz"||command="2qcf2p"||command="2qcfy"||command="qcbqcfy"||command="qcbqcf2p"||command="2qcby"
var(10) = 2

Do similar for setting it to 3. For the one that sets it to 1, just use power < 2000, and make sure neither state mentioned is prevstateno, for the trigger.

More lines, but you can read it. And so can anyone else. If you get stuck post the entirety of what you have.

Playing Enemy · « **Reply #13 on:** April 16, 2016, 07:47:57 AM »

Thanks for the help man, you're awesome. I usually do refer to KFM or the common1.cns file for getting somewhat accurate numbers to replace the "Const" trigger with, but sometimes a character will use it in their coding for a special move or a custom falling/hanging state, and I'm not sure what to put there. I guess a good question would be, what exactly does the Const trigger do, or why has it replaced using basic numbers? If I knew what it was actually doing, it would be easier to know what should replace it.

As for the other thing. I think I understand what you're saying, but I'm still kind of confused, I think. I wasn't sure if I should put "power = [3000,3999]" or "power > 5000" for the section that sets the var to 3, because the character maxes out at level 5 special bar. This is what I have, including the beginning of the move and the original coding, so you can see what's going on.

(click to show/hide)

My knowledge on coding is still pretty slim, but I get by okay. I can understand pretty good as I go, but I don't know enough to look at something right away and know exactly what's going on without some guidance. That said, hopefully I did the above correctly.

Cyanide · « **Reply #14 on:** April 16, 2016, 11:20:56 PM »

People use the const values because they want to refer to or otherwise make the character act LIKE the character. It's why you should take the time to set headpos or midpos correctly, some characters use that to position things.

Ugh, is that why it was like that. Hardcoding for AI. No, it's not quite right. For one we can probably take the AI stuff out of it, it all does exactly the same thing whether it's AI or not, so you don't need 6 varsets.

Do them in order first is for value 1. Do that if power < 2000 and neither of the prevstatenos are true

trigger1 = prevstateno != 5 && prevstateno != 6
For example.

Then do the next one. that checks BOTH prevstatenos and sets it, or it checks if power was > 2000 and any of those commands are true.

For the last one, same thing, but you're checking if power is > 3000 now. And making sure it's not those 2 states again. I actually think these are just in here because of AI and for no other reason.

Playing Enemy · « **Reply #15 on:** April 17, 2016, 10:46:14 PM »

I'm sorry Cyanide, I'm kind of confused as to what you are suggesting I do here. I'm still extremely limited in my coding knowledge, so I'm not totally following what you're saying in your last post. I'm guessing that when you said I didn't need 6 versets and to remove the ai parts, you meant to remove the bottom 3 varsets I had in there, so I removed them. I'm not exactly sure about what to put for the "prevstateno =" parts either. Should I put the original numbers from the original coding; "1251131 & 1251132"? I think you using different numbers, and me not really knowing that much, is what's throwing me off. This is what I got so far, but I already know it's wrong.

(click to show/hide)

I hate to suggest it, and only if you're willing to, but it might be easier if you just wrote it out for me so that I could see what it should look like compared to how it currently looks, then I could examine it and make sense of the conversions you made (basically, reverse engineer). I'm not usually one to ask "can you do it for me", but I'm stumped and confused in this scenario, and I don't want you to write it due to me being lazy or something. It's only because I can't figure it out, and I have a few other characters to convert with the same issue that'll need this same treatment.

I'm positive you'll look at what I got, and immediately know that it isn't correct, but just for the heck of it, here's the error message mugen gives me.

(click to show/hide)

Cyanide · « **Reply #16 on:** April 18, 2016, 04:29:14 AM »

I CAN do that, and probably will, but what you showed me in code, and your error message don't match up.

It is having issues with [State 3000,Strength1]

And none of the code there is actually labeled with that. So your code is potentially correct, and there is something else in that state breaking it for you.

Playing Enemy · « **Reply #17 on:** April 18, 2016, 05:37:05 AM »

It's still the same section of code we've been working on. The reason it says "Strength1" now is because that same Strength code is used about 21 more times in his coding, so I went through and numbered each occurrence of it after I posted the code here, that way once we were able to fix the first occurrence of it (with your help), I would know that it is actually fixed once Mugen crashes and says there is now an error with Strength2. At that point I'll just be able to copy and paste over the other 20 occurrences with the corrected code knowing it's safe to do so now.

Cyanide · « **Reply #18 on:** April 19, 2016, 04:24:23 AM »

Uh, we won't know it's fixed until you replace all of it. Mugen will crash every time until all of them work. So, what we can say is the code for StrengthNew, is fine, as mugen hasn't crashed on it. Or if not fine, it is at least not causing crashes which will do for the moment.

Every time mugen finds something it can't work with, it crashes. Doesn't matter how much before or after that is correct.

If you want to follow the path you're going down now, you have to delete all the other instances of the strength code and add them back when we're done testing this one. Otherwise mugen will say "This is bad" and crash and you never get to test anything.

Playing Enemy · « **Reply #19 on:** April 19, 2016, 11:47:12 PM »

Okay, I did what you suggested and removed all instances of that code except for the first occurrence of it which is the one we've been working on. I also renamed it so that there would be no question as to what section is causing the crash, and was able to pinpoint it to the 3rd varset. Somehow I forgot the very last quotation mark to close off the string. You can see it for yourself in my last post. Idiot mistake.
Thanks a lot for helping me rewrite that code too. I sincerely appreciate it a lot.

He is still crashing Mugen though, but now it's being caused by this piece of code right here.

(click to show/hide)

I usually have no problem converting "Gameheight/Gamewidth" coding, but in this instance I'm not sure what the X value should be. I know I could just replace that part with just a number, but I want to make sure I put the correct number so that it works as intended for the most part. Is it as simple as doing the equation? Meaning 320/2 - 240 = -80. That just doesn't seem correct to me.

Cyanide · « **Reply #20 on:** April 20, 2016, 02:02:03 AM »

Gamewidth is new, doesnt' exist in winmugen.

So, i think what that's doing is putting the helper on the right side of the center of the screen (based on the docs) and then i am assuming the character is a 640x480 character, so it see's the space as 480, and is possibly placing the helper back 240, ie half a screen width. Back of the screen is pretty standard positioning

Easy way of course, play it in the correct version of mugen. Look at where the thing appears, replicate that. No math involved.

Playing Enemy · « **Reply #21 on:** April 20, 2016, 03:54:12 AM »

Okay, you just cleared that up for me. For some reason I thought the characters were 320x240, not 640x480. That makes a lot more sense now. I was able to convert those sections of code, and now he loads and plays in Mugen just fine. Thanks again for helping me out with these things. I've been trying to get him going for almost 2 weeks now. I learned a lot too from this, which is awesome. I'm glad you didn't just post some working code, and say "here", and not explain anything so I can't do it myself in the future. Appreciate it a lot.

Cyanide · « **Reply #22 on:** April 21, 2016, 02:49:56 AM »

Very rarely will i simply post code for people. Sometimes, because it's blindingly simple code they get a pseudo version of it. Most of the time, better you learn how stuff works and actually figure it out yourself. Then when it reoccurs, i don't have to help, and nor does anyone else.

The idea is that once you've helped someone, you never need to help them again. Doesn't always work.

Playing Enemy · « **Reply #23 on:** April 21, 2016, 06:45:32 AM »

I definitely prefer to be taught how to do something over just having it done, just like learning to do brakes and oil changes on my vehicles. There's not really a point in bothering to ask a question if you have no intention of knowing the answer to it. I plan on surviving the zombie apocalypse and I'll need to know how to do stuff if that's gonna happen. That said, your words aren't falling on deaf ears.

DEMONKAI · « **Reply #24 on:** April 21, 2016, 06:41:48 PM »

And don't forget, trial and error also is a key thing of learning. Challenge yourself. If you ever took apart toys as a kid and put em back together again then youll know exactly where I'm coming from

News:

Author Topic: Help/Advice With Coding Questions for W.I.P.s (Read 2855 times)

IMT Facebook

Help us by Donating!

IMT Discord

Join us at our Discord! Click the image below!

IMT Shoutbox

Recent Posts

IMT Calendar