Renzo [a.k.a. Sachavaca Salvaje] said, September 22, 2007, 04:26:03 pm@THH: Not really, P.o.t.s interpretation is the correct for my post.I see. Sorry about that Renzo.P.o.t.S. said, September 22, 2007, 04:23:19 pmBtw HitDefs activate and hit in the exact tick you tell them to, the only delay there is is in the hit char, he only goes to the get hit animation one tick after being hit.I don't know why but for some reason that is not the case for me.On estimate maybe 10% of teh time the hitdefs I code for do not activate properly.In one situation it WILL activate most of the time. BUT sometimes when teh same situation arises, it does not.Hold on while I find a video please
Really waiting for that... because in my eraly days of coding characters I had a lot of animations frames with time=1 and never noticed strange behaviors like that.
Here we are:NHK's - MakotoSenind's - AI coding:My (THH) - CNS, AIR (clsns), and CMD edits http://www.youtube.com/watch?v=TgH-mch1u48Notice at: 3:41The Last Hit of Makoto's Hyper Combo does not connect (Please read the two notes below)Note:I expanded the AIR Attack CLSNs "GREATLY" and I know they should have hit. (Between -43 and 58)The trigger coding I edited for her to use was:Quote[Statedef 3272]type = Smovetype= Aphysics = Svelset = 0,0ctrl = 0juggle = 1anim = 3272sprpriority = 2...[State 3000, 2]type = HitDeftrigger1 = animelem = 6...The problem... animelem lasts for only 1-tickYou would, and should, be tempted to say the distance factored into the equation, but it did not.I tested this many times on my own and found that the hit was not triggering appropriately EVERY time, but instead, again by rough estimate, only about 90% of the time did it trigger approriately...NO MATTER WHAT THE DISTANCE WAS
What about the opponent's Clsn2?Meh, there's a hundred things that could make the attack miss, but I assure you that that trigger alone isn't one of them.
P.o.t.S. said, September 22, 2007, 05:06:08 pmWhat about the opponent's Clsn2?I'm going to need you to explain that.CLSN2 has always been a tricky subject for me because of some Edge business involved with it, but in this situation, I know that at least Makoto's CLSN Attack should have gone farther than the edge of Kyosuke's CLSN Collision or CLSN2 Collision.Also, I had tested this myself, in other situations.The two that I believe should most effcetively highlight my point would be these.1st:I selected the two same opponents each time (Makoto and Alex by GM). I selected the same stage (Chun-Li's SF3 stage). I began the round with the power bar full and triggered the move immediately while both AIs were deactivated.MOST times the attack hit, but sometimes it did not.2nd:Makoto vs. AlexChun-Li's SF3 stageAIs DeactivatedI put Alex in the Right Corner and had Makoto stand right next to him in some trials, and as far from him as possible in others, then triggered the move.MOST times the attack hit, but sometimes it did not.
Hm, the Clsn on the original version are pretty funky, I can easily picture them missing the target since they barely hit Alex and KFM:The black square is where the Clsn intersect eachother, just recolored it to make it more visible.Can you take a screenshot like this, but with the version you modified and a char you say it misses?Anyway, this is really derailing the topic, need to split it later.
P.o.t.S. said, September 22, 2007, 05:34:51 pmCan you take a screenshot like this, but with the version you modified and a char you say it misses?I always wondered how people did that. I will need to know how to reveal the CLSNs. I'm assuming that it's something in the mugen.cfg? I can't take a PCX image, but I can take a picture of Mugen using and outside source. Well... I can take a PCX image from Mugen, but my comp doesn't recognize it. I don't know how to color yet, and I'm pretty sure that I do not have any programs that color pictures
Tee Hee Hee said, September 22, 2007, 05:39:44 pmI always wondered how people did that.I will need to know how to reveal the CLSNs, I'm assuming that it's something in the mugen.cfgEnable the debug mode in mugen.cfg then press ctrl+C while playing.QuoteI don't know how to color, and I'm pretty sure that I do not have any programs that color pictures I used mspaint, and you don't need to color anything. Edit: Nevermind, just noticed that using the medium kick version and hitting from as far as possible makes it miss:So yeah, not a trigger issue.
How would I make up for the fact that this takes place within 1 tick (I don't know if I could get lucky enought to take a pick at the exact time the scenario comes up)?Also Should I take the picture using the outside source, which doesn't save as PCX??orShould I make a PCX image and open it with FF to view it??orShould I make a video. Isolate the frame then take a picture using teh outside source ??
Tee Hee Hee said, September 22, 2007, 05:47:08 pmHow would I make up for the fact that this takes place within 1 tick (I don't know if I could get lucky enought to take a pick at the exact time the scenario comes up)?Pause the game and press ScrollLock to advance one frame at a time. You should've known all the debug features by now. And the second option. Not that it matters now, see the edit on my previous post.
P.o.t.S. said, September 22, 2007, 05:42:06 pmAnd the second option. Not that it matters now, see the edit on my previous post.Edit: Nevermind, just noticed that using the medium kick version and hitting from as far as possible makes it miss:So yeah, not a trigger issue.Tee Hee Hee In Previous Post said, September 22, 2007, 04:58:05 pmNote:I expanded the AIR Attack CLSNs "GREATLY" and I know they should have hit. (Between -43 and 58)The trigger coding I edited for her to use was:....................You would, and should, be tempted to say the distance factored into the equation, but it did not.I tested this many times on my own and found that the hit was not triggering appropriately EVERY time, but instead, again by rough estimate, only about 90% of the time did it trigger approriately...NO MATTER WHAT THE DISTANCE WAS
Umm... My experience tells me that there's nothing wrong with HitDef controller and its triggering. There can always be factors that make things look like it's HitDef's fault.Tee Hee Hee, I see you've found quite a bunch of 'mugen errors'. I write it in inverted commas because in fact (in most cases) there are no such errors in Mugen engine. I understand that your experience says so, but your experience might come from bad-doubting your own conclusions. When I face some irregular problems I take as an axiom "mugen engine is working fine" and search for my mistakes. Even when you can't find a solution at first you should't just give up and state "I can't do anything because the engine is wrong".
Elix said, September 22, 2007, 11:26:37 pmUmm... My experience tells me that there's nothing wrong with HitDef controller and its triggering. There can always be factors that make things look like it's HitDef's fault.Tee Hee Hee, I see you've found quite a bunch of 'mugen errors'. I write it in inverted commas because in fact (in most cases) there are no such errors in Mugen engine. I understand that your experience says so, but your experience might come from bad-doubting your own conclusions. When I face some irregular problems I take as an axiom "mugen engine is working fine" and search for my mistakes. Even when you can't find a solution at first you should't just give up and state "I can't do anything because the engine is wrong".I share that same mentality.I look for my own mistakes as well, FIRST, and do that for a few hours.My coding is organized in such a way that you can see every element of the code clearly. I fix all my mistakes, then come to conclusion, never teh opposite.Check the Haohmaru AI Patch.I left some note in teh CMD file about randomly activating triggersAlsoThere are a few more glitches I noticed with the fvar and the default AI becoming dominant. It wasn't a bad thing and I didn't consider it worthy of discussion because they both can easily be avoided (or should I say avoided 99% of the time).
This didn't feel like help, aside from anything else, no question was really asked. Possibly belongs here anyway.Teeheehee: You seem to find a number of issues to present as "errors" yet you don't know the debug commands? That kinda sheds new light on a lot of what you say.
Cyanide said, September 23, 2007, 01:29:15 amTeeheehee: You seem to find a number of issues to present as "errors" yet you don't know the debug commands? That kinda sheds new light on a lot of what you say."PotS" moved the topic with particular posts because he said we were getting sidetracked.Please Notice that this starts with a quoteThe original topic that he moved it from was here:http://mugenguild.com/forumx/index.php?topic=65633.0Cyanide said, September 23, 2007, 01:29:15 amThis didn't feel like help, aside from anything else, no question was really asked. Possibly belongs here anyway.I never even knew there were debug "commands" until now.The things that I was talking about were just absolute codes; BUT, if Debug commands factor into this in any way, then I am probably wrong
More a comment on your percieved grasp of the engine itself. You say a lot of things "happen" yet haven't made use of frame skip debug or clsn display to check why.For eg, your comments on AI activating moves that it shouldn't be able to. Turning on debug and framestepping would show you whether the AI actually had control. Making use of displaytoclipboard in this instance would also give you some idea of when an attack activates properly via AI.
Cyanide said, September 23, 2007, 04:01:46 amMore a comment on your percieved grasp of the engine itself. You say a lot of things "happen" yet haven't made use of frame skip debug or clsn display to check why.For eg, your comments on AI activating moves that it shouldn't be able to. Turning on debug and framestepping would show you whether the AI actually had control. Making use of displaytoclipboard in this instance would also give you some idea of when an attack activates properly via AI.Well because that is new to me, I'll be using it.But, I know absolutely what I had coded and it was not being followed based on what I could check using my method. I didn't only check MY OWN AIs, but I also checked other creators chars (about 20 or so more others) and EACH AND EVERY ONE OF THEM HAD THE SAME GLITCH.My Method Again:Recording at 35 or more FPS, then isolating each frame in a frame by frame checkCyanide, I really want to ask you.Do you have a YouTube account?
Nope, i don't see the point in general. The big issue about your ai glitches is noone else gets them. Or if they do they know why they're getting them and fix it.I've never had anything do anything i haven't told it to. Priorities or otherwise. I've had some things acting incorrectly but that was always my fault rather than anything the engine did.
Cyanide said, September 23, 2007, 05:59:42 amThe big issue about your ai glitches is noone else gets them. Or if they do they know why they're getting them and fix it.I was waiting for that."noone else":You'd be very suprised. As I said, I tested this on other creator's chars and the ALL of them (100%) had the glitches.It stinks that you don't have a UTube account, so I guess I'll just have to show you the vids publicly.R[E]ika said, September 23, 2007, 06:06:31 amyou must record at exact 60 fps if you want to have frame accuracySuprisingly you really don't have to. That just creates a whole mass of extra frames @_@.You'll see what I mean tomorrow... that is if I don't break a rule by then (that doesn't have to do with the forum though )
Quote"noone else":You'd be very suprised. As I said, I tested this on other creator's chars and the ALL of them (100%) had the glitches.Have said creators mentioned them as issues? Or is it just you that spots them and believes them to be glitches.I wasn't speaking of characters. Noone coding an AI, which are usually tested pretty thoroughly to make sure the moves activate when they are supposed to even if they aren't even slightly balanced. Are checked for strange behaviour. I've never heard of anyone complaining that their AI isn't doing what it's supposed to. It either doesn't work, or does something too much.
Cyanide said, September 23, 2007, 07:07:43 amQuote"noone else":You'd be very suprised. As I said, I tested this on other creator's chars and the ALL of them (100%) had the glitches.Have said creators mentioned them as issues? Or is it just you that spots them and believes them to be glitches.I wasn't speaking of characters. Noone coding an AI, which are usually tested pretty thoroughly to make sure the moves activate when they are supposed to even if they aren't even slightly balanced. Are checked for strange behaviour. I've never heard of anyone complaining that their AI isn't doing what it's supposed to. It either doesn't work, or does something too much.If not slowed down, in the frame by frame method I mentioned (i.e. my method), then indeed that AI does appear to be doing everything you tell it to.At first I didn't even have this issue.I only managed to see it while creating a video of my own of a match between two CvS/CvS2 creators.Sending a PMTee Hee Hee said, September 22, 2007, 04:58:05 pmHere we are:NHK's - MakotoSenind's - AI coding:My (THH) - CNS, AIR (clsns), and CMD edits http://www.youtube.com/watch?v=TgH-mch1u48Notice at: 3:41The Last Hit of Makoto's Hyper Combo does not connect (Please read the two notes below)Note:I expanded the AIR Attack CLSNs "GREATLY" and I know they should have hit. (Between -43 and 58)The trigger coding I edited for her to use was:Quote[Statedef 3272]type = Smovetype= Aphysics = Svelset = 0,0ctrl = 0juggle = 1anim = 3272sprpriority = 2...[State 3000, 2]type = HitDeftrigger1 = animelem = 6...The problem... animelem lasts for only 1-tickYou would, and should, be tempted to say the distance factored into the equation, but it did not.I tested this many times on my own and found that the hit was not triggering appropriately EVERY time, but instead, again by rough estimate, only about 90% of the time did it trigger approriately...NO MATTER WHAT THE DISTANCE WAS OMG I was wrong about that video.I went back and checked the CLSNs Collisions for Kyosuke and saw that they did not encompass all of his legs, only most of them.Makoto's CLSN Attack and as it turns out, the CLSN Collisions, not the entire body, were actually outside Makoto's range.The issue with Alex, however, is still valid. @_@ I still haven't gotten the picture I needed yet, but I'm confident it will come.
I decided to make this a video:I found that making the video was far easier than trying to capture the single frame and a whole lot less time consuming http://www.youtube.com/watch?v=jsbFbYQcsYoVideo Info:Note: - The scenes that illustrate my point are AT THE END OF THE VIDEO.Scenes 1-4 are simply to illustrate that the video did consistently capture the CLSN Attacks and serve to verify that the CLSNs were legitimately activating (with no tampering with at all).Scenes 5 and 6 - Illustrate where the CLSN Attacks were not activated properly, with the same code and no tampering with at all.What went into the video:Recorded at 65 Frames Per SecondThe coding for the Hitdef activation was the same as what I posted in this MFG forum topic. The CLSN Attack is the same as what I said it was earlier.There are no edits to the specific scenes in the video that highlight my point.THERE IS NO BULL SH@T IN THIS VID!!!!I have other vids that support some of my other points as well but I am not sure I should publicly post them. I did get permission to publicly post one of the two vids, however.
The last one was very weird indeed. It never happened to me though And what I see is not HitDef problem, but the lack of CLSN1. If it were the HitDef problem, the attack wouldn't hit with CLSNs overlapping.Tee Hee Hee said, September 25, 2007, 10:58:58 pmI found that making the video was far easier than trying to capture the single frame and a whole lot less time consuming
the second to last one can be caused by juggle points, they sometimes even interfere on ground combos, and yeah, i also consider that a bug.
Elix said, September 26, 2007, 12:09:19 amThe last one was very weird indeed. It never happened to me though And what I see is not HitDef problem, but the lack of CLSN1. If it were the HitDef problem, the attack wouldn't hit with CLSNs overlapping.Yay, someone agrees I didn't make the title to this post actually... LOL.PotS moved it because it was getting sidetracked, Cyanide moved it back for being in a different maybe wrong section, and moved it to the same section that PotS had disconnected it from. Then I think Cyanide saw that it had the same title as PotS's and changed the title, maybe based on what I suggested in the "technically" introductory post(s) @_@CONFUSING!!! - I couldn't explain that situation well sorry Elix said, September 26, 2007, 12:09:19 amTee Hee Hee said, September 25, 2007, 10:58:58 pmI found that making the video was far easier than trying to capture the single frame and a whole lot less time consuming I feel as though it's just as effective.But that's just my opinion. R[E]ika said, September 26, 2007, 12:19:20 amthe second to last one can be caused by juggle points, they sometimes even interfere on ground combos, and yeah, i also consider that a bug.Score. Mugen indeed does have its bugs.There is another video I have, that I want you all to see, but I feel as though it would be appropriate to re-request permission for viewing it.There is also a third (made for a different purpose), but in which, other Mugen bugs are displayed... alongside its true meaning.
That last punch. It's obvious why it misses, there's no red box. I would query WHY there's no red box. Even when an attack has used up all it's juggle points the red box still displays. Or if there's no hitdef it still displays. Or even when the state you're in isn't classed as A but I or H you'll still get the red box. Why it's not showing on that one frame is rather confusing. Not saying you're wrong here but i think you have the wrong end of the stick. There's no reason hitboxes shouldn't display unless you haven't put them in, or are using a helper for the attack and it doesn't show up. Non activating hitboxes != non activating hitdef.A lot of your misses on that uppercut are more p2 than p1, person has gone for a too accurate idea of them. Not the general lines. Thats not so much mugen as it is whoever's making the character.The standing heavy step forward kick. THAT one confuses me, i could attribute it to the inherent nothitby on getup except for the fact his clsn2 doesn't change to pale blue. Not sure, would need both characters. Oh and he's not getting up.
Cyanide said, September 26, 2007, 01:29:40 amThat last punch. It's obvious why it misses, there's no red box. I would query WHY there's no red box. Even when an attack has used up all it's juggle points the red box still displays. Or if there's no hitdef it still displays. Or even when the state you're in isn't classed as A but I or H you'll still get the red box. Why it's not showing on that one frame is rather confusing. Not saying you're wrong here but i think you have the wrong end of the stick. There's no reason hitboxes shouldn't display unless you haven't put them in, or are using a helper for the attack and it doesn't show up. Non activating hitboxes != non activating hitdef.A lot of your misses on that uppercut are more p2 than p1, person has gone for a too accurate idea of them. Not the general lines. Thats not so much mugen as it is whoever's making the character.I'm not too sure what you meant by the lines that I bolded from your post in the quote.. I don't know if you did, but I'm not sure you read my full posts, BUT, as said before, I don't quite understand what you're saying.I am tempted to respond with these two posts, based on my, most likely incorrect interpretation.Tee Hee Hee said, September 22, 2007, 04:58:05 pmNote:I expanded the AIR Attack CLSNs "GREATLY" and I know they should have hit. (Between -43 and 58)The trigger coding I edited for her to use was:Quote[Statedef 3272]type = Smovetype= Aphysics = Svelset = 0,0ctrl = 0juggle = 1anim = 3272sprpriority = 2...[State 3000, 2]type = HitDeftrigger1 = animelem = 6...The problem... animelem lasts for only 1-tick[glow=red,2,300]The full hitdef was is this:[/glow];---------------------------------------------------------------------------[State 3000, 2]type = HitDeftrigger1 = animelem = 6attr = S, HAanimtype = hardair.animtype = backdamage = 85guardflag = Mhitflag = MAFpausetime = 12,12sparkno = s66guard.sparkno = s49sparkxy = 20,-90hitsound = s5,9guardsound = s6,1getpower = 0,0ground.type = highground.slidetime = 12ground.hittime = 30ground.velocity = -.7,-12air.velocity = -.7,-12;fall = 1;fall.recover = 0p2stateno = 8000yaccel = 0.53Tee Hee Hee said, September 25, 2007, 10:58:58 pmVideo Info:Scenes 1-4 are simply to illustrate that the video did consistently capture the CLSN Attacks and serve to verify that the CLSNs were legitimately activating (with no tampering with at all).Scenes 5 and 6 - Illustrate where the CLSN Attacks were not activated properly, with the same code and no tampering with at all.
Red clsns = clsn1's = what hits in an attack.There is no reason for the clsn1's not to appear. Nothing you do can cause that. Setting juggle points too high, an impossible trigger. If the clsn boxes have been placed ON the sprite, that's where they stay. They don't just vanish is my point. I'm not saying it's not wrong. I'm just wondering why it's occuring. I've had my share of wierd shit from mugen but that's not one of them.Even if an attack has no hitdef it doesn't make clsn boxes vanish. If they aren't there there must be a reason for it, even if said reason is mugen's broken.Actually, all i can think of is he's set it up so a 1 tick frame has those hitboxes and your video capture hasn't captured them so it makes them appear missing.Just to give you a better idea of what i'm talking about. Take any character, load it up in fighter factory. Then draw a clsn1 (red) box above the characters head on his standing animation. Set it up as a default box. Then test it, you'll see the box is always there even though stand is a non attack state and has no hitdef associated with it.
Cyanide said, September 26, 2007, 02:29:04 amEven if an attack has no hitdef it doesn't make clsn boxes vanish. If they aren't there there must be a reason for it, even if said reason is mugen's broken.YESSSS!!!. I know I wasn't crazy.Hmmm... if a creator had given me permission to make a video public but that was way in the past, but for a different reason (or should I say, one of the reasons that involved one of the glitches I was talking about was brought up in the vid) do you think it would be appropriate of me to re-open that video for viewing if that creator hasn't been on in a while (or at least I haven't caught up to him for a few days).
Is it a public character? I mean if it's private and he doesn't want people to know about it, keep it that way so he doesn't get annoyed. If it's online and readily available then you're being useful providing feedback.I'm personally of the opinion it's a 1 tick hitbox. I suggest you open the animation and check how long the frame is that has the red box on it.
Cyanide said, September 26, 2007, 03:31:26 amIs it a public character? I mean if it's private and he doesn't want people to know about it, keep it that way so he doesn't get annoyed. If it's online and readily available then you're being useful providing feedback.Public so... I'll put up the vid.Cyanide said, September 26, 2007, 03:31:26 amI'm personally of the opinion it's a 1 tick hitbox. I suggest you open the animation and check how long the frame is that has the red box on it.Tee Hee Hee said, September 22, 2007, 04:58:05 pmThe problem... animelem lasts for only 1-tickThat's actually why this whole thread was started. or should I say, why PotS seperated it.We were originally on opposing ends involving this (thread reference at teh bottom):QuoteRenzo [a.k.a. Sachavaca Salvaje] said, September 22, 2007, 03:41:22 pmFor all this time, my general rule was assigning higher priority values for weaker attacks; the logic behind that was exactly:QuoteThe hitting portion of the animation comes out quick enough (many attacks actually only hit a tick or two after the char has reached the animation frame that appears to hit)Finally Someone Understands My Pain.: Tee Hee Hee (myself) in "Your Problems with Mugen Creation" said, September 22, 2007, 03:41:22 pmTriggersTriggers are largely reliable when you are generally coding, but they can encounter problems when you are coding specifically for CLSN Attack activation for the hitdef. Juggling in particular holds this problem up front and center.There are many times where I have realized, that a ton of the things I was absolutely coding for in the hitdef, weren't activating properly (I.E. Time = 1; Time = 0; or an animelem that lasted for less than 2 ticks). If you place the CLSN Attack in an animation, where the attacking frame only lasts for 1 tick, or else directly code the hitdef to activate within 1 tick (i.e. time = 6), then only sometimes, you will notice, that the hit will not make contact . If you're not going for accuracy, or whatever, code it for something that activates for a period of 4 ticks, thereby increasing your chances of having the attack properly activate and connect with the opponent.Movehit activation within specific animelems can also be a pain in certain cases. If that animelem lasts for less than 2 or 3 ticks, quite frequently you'll notice that the char won't activate the hitdef that you defined, meaning, again, that it will not make contact. Make sure the animelem lasts for maybe 3 or more ticks, or else code for more than one animelem.http://mugenguild.com/forumx/index.php?topic=65633.msg541809#msg541809
Scratch previous gibberish.Made a 3 frame, 3 time attack. Quite simple nothing wierd. Tried triggering on both animelem = 2 and time = 1 and time = 0. Punched p2 about 80 times in all situations. Didn't miss once. Well aside from when cornerpush sent me out of range.How many variables are you adding. Like is this standing vs standing? Or part of a combo.I'm happy enough to believe you but i'm going to need to experience it first.
Newly Re-Made Public Video:http://www.youtube.com/watch?v=QWTPVkemiXQThe Specific Flaws:1:33 - roll break flaw2:36 - roll break flaw3:26 - roll break flawNote there are times in the video where Yuri COMPLETES the roll.Note: I didn't check teh coding on the current Yuri but it is still the current one. I doubt though, that PotS would have coded this specifc flaw into Yuri and I do believe that the roll would have required ctrl.
You mean yuri breaking OUT of it into a parry correct?If no human can do that it's an AI flaw. Or pots wanted his AI to do that, for some reason. It won't be a bug with mugen code, it'll be bad triggering.
QuoteHowever in the hitdef (dunno if you've tried this) but using time = 0 and having teh hitframe on animelem 7 will still functionSpent so much time trying to recover this. What you said here was and is right. At the time I had said that a "time = 0" set wouldn't necessarily work, I was referring to a char that had a 1-tick hit box after it also.I was mistaken when I typed that, back then.Cyanide said, September 26, 2007, 03:58:58 amYou mean yuri breaking OUT of it into a parry correct?If no human can do that it's an AI flaw. Or pots wanted his AI to do that, for some reason.I mean Yuri breaking out of it into the parry and Vica Versa (apparently it's supposed to be Vica Versa. 'Latin Class' is a lie if that is not so.)I also noticed similar instances in Waru's Ken (which I have a vid of but never got permission from Waru to show... it was originally meant to highlight some AI advantages so I doubt it would be allowed)Then I put my own and qwer's codes to the test and found that even ours had a few attack breaking into attack, flaws, even though we specifcied "ctrl" for each of the commands that registered some flaws. We also saw from our (PotS, Waru's, and ours) chars, that there were some unregistered vulnerabilities and higher priority overrides that occured very rarely.
There's no Clsn1 on that last one because it only lasts one tick and you clearly didn't record at 60fps, so it can't be captured by the video 100% of the time. Next case.
P.o.t.S. said, September 26, 2007, 11:19:49 amThere's no Clsn1 on that last one because it only lasts one tick and you clearly didn't record at 60fps, so it can't be captured by the video 100% of the time. Next case.Tee Hee Hee said, September 25, 2007, 10:58:58 pmWhat went into the video:Recorded at 65 Frames Per SecondAlso, that didn't answer the question though.How did the attack miss at all? The CLSN did not activate properly and no hit was registered, even when it was in range. This is what is confusing me.R[E]ika answered my other question though about the scene before the last:R[E]ika said, September 26, 2007, 12:19:20 amthe second to last one can be caused by juggle points, they sometimes even interfere on ground combos, and yeah, i also consider that a bug.What's your take PotS?
Tee Hee Hee said, September 26, 2007, 11:28:54 amTee Hee Hee said, September 25, 2007, 10:58:58 pmWhat went into the video:Recorded at 65 Frames Per SecondAlso, that didn't answer the question though.Recording software easily skips frames PLUS there are clear frame gaps between each frame you paused.Stop blaming Mugen/Elecbyte for it, only happens because NHK didn't use large enough Clsn1, when auto-combos should use the kind that never misses (in KOF games that means boxes covering half the screen).QuoteR[E]ika answered my other question though about the scene before the last:R[E]ika said, September 26, 2007, 12:19:20 amthe second to last one can be caused by juggle points, they sometimes even interfere on ground combos, and yeah, i also consider that a bug.What's your take PotS?Assuming you mean the kick, yeah it's caused by a custom juggle system that only resets when P2 stands up. Since the attack started before that happened, the HitDef never activated.
P.o.t.S. said, September 26, 2007, 11:59:13 amTee Hee Hee said, September 26, 2007, 11:28:54 amTee Hee Hee said, September 25, 2007, 10:58:58 pmWhat went into the video:Recorded at 65 Frames Per SecondAlso, that didn't answer the question though.Recording software easily skips frames PLUS there are clear frame gaps between each frame you paused.Stop blaming Mugen/Elecbyte for it, only happens because NHK didn't use large enough Clsn1, when auto-combos should use the kind that never misses (in KOF games that means boxes covering half the screen).Sorry if I'm annoying you PotS. I really would never intend to.So by my interpretation I guess you are saying that the frame was skipped anyway, and the attack missed because the CLSN box still wasn't large enough. I'll try a faster FPS and running Mugen at its slowest speed as well as widening teh CLSN even more.Thanks for teh info PotS.
Try pausing the game when she hits P2 up and then use ScrollLock to advance Mugen frame by frame, better than making videos.
P.o.t.S. said, September 26, 2007, 12:13:31 pmTry pausing the game when she hits P2 up and then use ScrollLock to advance Mugen frame by frame, better than making videos.Will do Hopefully it won't take too much time r too many trials
Cyanide said, September 29, 2007, 02:43:54 amSo, we seen any results from this? Who's right I'm betting that vanished hitbox was a skipped frame.To tell you the truth, I haven't been focused on it. I've actually been more focused on a discussion about what chars to code next LOL.Back to the issue:I'm still trying to determine whether it was actually in range or not ??? , but I'll be trying to get the picture later... I'm just scared of how much time it might take. I have some other glitches as well that I want to figure out too, though.
