Mortal Kombat Revival

[BeRB]

CLSN Still looks off to me when scorpions hitting

 

[Bleed]

You are right about the collisions, I still have no way to see what they are actually like in MK official games. It would be cool if someone could help out with this some how.

All I have is MKT for the Play Station, so it doesn't have the collisions view as an option. The only MKTN64 Roms I found don't have the code working either, so I'm pretty much stuck without a clue on that end...

Unless I buy a used copy of MKT and an N64, I wish there was some way to view that on mame.

 

[Shock]

I tried explaining how they work but I can understand it's difficult unless you see it. N64's collision detection feature is the greatest thing about the whole game, but remember these collisions are not always absolutely 100% accurate, but this is how they work. They are definitely a great start however.

http://www.ultimatemk.com/tempmatt/mktcollisionex.avi

Just right click and save as, and make sure you have the techsmith video codec.

 

[LI Maverick]

Hi guys

<3 you all, just wanted to throw this out here

Just wanted to mention that here in FL we're having a tournament called CEO2011 (June), we had one last year that had plans to try and get UMK3 as an event but had no support.

I'm looking to do this again, If i manged this- how likely is it that we could see players travel for it?

I haven't played in so long and miss the competitive community ;(

 

[Lucky Day]

I'm looking to do this again, If i manged this- how likely is it that we could see players travel for it?

You could start by posting in a relevant thread.

To answer your question you may want to talk to Juggernaut who is running at Final Round, and if you're going to that, recruit and get interest going there in March.

 

[Shock]

Hi guys

<3 you all, just wanted to throw this out here

Just wanted to mention that here in FL we're having a tournament called CEO2011 (June), we had one last year that had plans to try and get UMK3 as an event but had no support.

I'm looking to do this again, If i manged this- how likely is it that we could see players travel for it?

I haven't played in so long and miss the competitive community ;(

There is a thread for the tournament, they said they are trying to do UMK3 and MKII.

http://ultimatemk.com/vForum/showthread.php?t=4883

 

[Bleed]

Great that video helps a lot, thanks for the link.

 

[LI Maverick]

I was on my way out the door when I posted that message, I didn't look around the site- just went to general and figured the most bumped thread wouldn't be a bad place to post.

asdf

 

[Shock]

I was on my way out the door when I posted that message, I didn't look around the site- just went to general and figured the most bumped thread wouldn't be a bad place to post.

asdf

That is some logic! Let us know when you'll be around again man, get some games in.

And Bleed, if you want character specific examples, let me know but that alone should be enough to help you with a great deal right now.

 

[Bleed]

That should be good for a while, I'm trying to find a good way to implement the collision changes vs certain moves. I have some ideas that I think will work, just need to get them running in the game.


[Edit]

I got it working now, I made an animation file with every frame as a different size hit box.

I'm using a helper, like a striker in Marvel vs games.

The helper is invisible, only having the animation file with the collision boxes. The animation locks to a single frame, depending on what the enemy's state is. The helper is also linked to the enemy's position at all times.

If the enemy is standing, the collision box will play the frame with the large collision for standing. If the enemy is crouching, the animation changes to the frame that has the crouching size collision box.

So it changes with the enemy's movement in position and scale.

Having it hit the enemy is a matter of calculating the parent's distance from it's helper and what state and frame they are in.

Say Scorpion is doing the Sweep vs a standing enemy. The collision box turns big, and Scorpion has to be within a certain distance from his helper and in a certain frame of animation for the helper to activate it's hit properties.


If Scorpion touches his striker in the set distance, the striker will hit the enemy.


So that's how it works right now.

The hit box size can be altered by enemy name, I can have several frames in the hit box animation that have different size hit boxes for different characters.

When scorpion does the sweep, the specific hit box will display and the distance for interaction will be changed.


Scorpion doesn't actually hit his helper's hit boxes. They are only used like a ruler, so I can see the hit boxes in the game and adjust the distance for the interaction to happen.

The Root's hit properties are turned off if the helper is activated, so you don't get a 2 hit combo because of dual hit boxes from the Root and it's helper.

Either the Root can hit or the Helper, not both at once.

 

[Bleed]

I think I found an easier way to do the collisions, that is to make the difference in the attack it self.

Instead of making the enemy's collision box grow, and leaving the attack's collision box normal size. I do the opposite, make the attacks hit box larger and create the difference, leaving the enemy's hit box normal size. The collision still happens at the same distance.

Like the sweep's hit box would extend past the foot just enough so it will hit, by visually clipping the enemy's toes.

This way is less prone to errors, and a lot easier to code.

I made a couple helper states that let me pause the character at any frame and move them around the screen like with Rain's water ball. I'm using this to calculate the collision distance to the pixel.


The collisions video from MKT is helping a lot, but it would be better if I could see the hit and hittable boxes.

For that I think you can play the same moves on both characters at once. Maybe you can just jab with one character while doing moves with the other.

For the sweep... I see the attack area on the leg, but where can the character take a hit while doing a sweep? MK collision's are not so obvious, so It would be good to see what this is like in MK.

;--------------------------------------------------

I found a simple way to make the push effect separate from the collision area. Since mugen uses the hittable area for push back, what I'm doing is making the MK thin collision boxes on top of the character's sprites. Then adding a wider collision box far below the floor. This allows the push effect to work at the right distance, but doesn't change MK collision area because it's out of harms way.


Looks like this, the thin box on the player, the wide box far below for push but not getting hit.

|

__

 

[Shock]

Instead of making the enemy's collision box grow, and leaving the attack's collision box normal size. I do the opposite, make the attacks hit box larger and create the difference, leaving the enemy's hit box normal size. The collision still happens at the same distance.

I really don't think that will work well at all. The collision is so specific and concrete for things. Push boxes will need to be scrutinized that's all.

Like the sweep's hit box would extend past the foot just enough so it will hit, by visually clipping the enemy's toes.

How can you possibly govern this? For example, in MK you can juggle sweep airborn opponents and it has a different reaction than being swept on the ground.

This way is less prone to errors, and a lot easier to code.

I don't know how it could be less prone to errors, you'd have to explain.

I made a couple helper states that let me pause the character at any frame and move them around the screen like with Rain's water ball. I'm using this to calculate the collision distance to the pixel.

That's very interesting, I'd like to see examples.

The collisions video from MKT is helping a lot, but it would be better if I could see the hit and hittable boxes.

For that I think you can play the same moves on both characters at once. Maybe you can just jab with one character while doing moves with the other.

For the sweep... I see the attack area on the leg, but where can the character take a hit while doing a sweep? MK collision's are not so obvious, so It would be good to see what this is like in MK.

Collision boxes universally are centered, 100% the height of the sprite, as in the cropped area, and then between 25% and 30% the width. So it's like a pillar in the middle. I can make a demo tomorrow perhaps of moves being done while other moves are being done like you said, so you can see more variation. But like for example with the sweep, it's just like anything else. Maybe you aren't seeing the differences in the stance frames because it's so subtle, but it is there. Every single frame that has different width has a different size collision width, but all collision heights are top to bottom exactly.

;--------------------------------------------------

I found a simple way to make the push effect separate from the collision area. Since mugen uses the hittable area for push back, what I'm doing is making the MK thin collision boxes on top of the character's sprites. Then adding a wider collision box far below the floor. This allows the push effect to work at the right distance, but doesn't change MK collision area because it's out of harms way.

This has been suggested in the past as a method for sweep accuracy, and I'm sure works. The problem is figuring out what the push box size is, and if it's the same for every sprite of every character.

 

[Bleed]

For the hit box size, you see in the video the character's hit box grows wide, and the attacker's hit box stays the same size.

The difference the wider hit box added to the victim can be added to the attacker instead for the same effect.

Grow from To here <-------------------------- from here

or grow from here --------------------------> To here

It's the same distance, only that it's easier to change the sweep's collision box to reflect this than finding some overly complicated way around mugen's limits.

The hit distance can be altered in the HitDef, for the sweep. If the enemy is in the air, I can say p2 must be within a certain distance for the move to hit, without actually changing the size of the hit box.

I can simulate the box changing size like that.

I have two sweep reactions built in to my sweeps right now, if you tried the link I sent in the different play modes, you can see this. In the MK modes I have it so the sweep fall only happens if p2 was standing, and the normal fall if juggled.

In my mode I have the sweep fall happen vs enemy on the ground or in the air. Only that the one in the air has further push back, like a normal fall.

I can change the Hit distance and hit animation with those options.


I think it's less prone to errors, because it's not as complicated to set up. The more complex I get with stuff the better chance of a screw up. I found one already with the Hit box helper I had first, on cross ups.


The freeze states are just that, I can select the sweep animation and pause it on the hit frame. Then slide the character toward the enemy and see when the move hits. Telling me if I need to make the hit box bigger or smaller on X and Y.


To clip the enemy's toes, that's how I can see if it's touching at least one pixel of theirs. I can set that as a default distance, then add some distance triggers for other situations.

I can say...

Trigger1 = enemy,statetype = A and enemy,movetype = H, p2bodydist x < 60 && enemy,pos Y > -60.


If the enemy is in the air, if they are in a hit state, if they are closer than 60 pixels, and if they are lower than 60 pixels off the ground, this move can hit.


I can add enemy's name or state to that trigger to get more specific.

To test that out, I would use the pause states, and pause the enemy in a juggle or whatever. Then move the Sweep on the hit frame, and move the enemy around till the collisions are working at the right distance. If not, tweak the X and Y values.

Say if P2bodydist x < 60 is too close, use P2bodydist x < 65.... etc.


For character specifics

Trigger1 = name = "kabal" && p2bodydist x < 60....

Trigger 2 = name = "sheeva" && p2bodydist x < 65....




For the next link I may leave these testing states on, so you can see how it works.

 

[FrozenWorm]

Here's Cage's MKDA Split Uppercut:

 

[Bleed]

Here's a video of the collision check state I have now. You can see how that works..


http://www.youtube.com/watch?v=OLDsMVCy2Zg

 

[Bleed]

New update for download.

http://www.sendspace.com/file/4fjkhd


;--------------------------------------------------------------

Some update notes:


Combo input was made smoother, and I added the input delay to a few more moves like the Knee, low kick... the Jabs.


Some work was done on the collisions, more like roughed out a lot of the animations with the vertical bar, instead of covering the full body with collision boxes.

Added the Push box to these too, it's a wide box below the ground, you can't see it in the game. You can check this stuff with Fighter Factory.


I started making the collision helper that changes size but it was becoming too much of a mess to deal with. You can see the example of the other method on the sweep's collision box.


The collision check state has to be enabled by taking out the comment marks from the code.

If you look in any of the basics files Search for [Statedef -2] and a little way's below that you'll see this.

Remove the semicolons from where the text is, and it will be enabled when you run the game. To use it, just do any move and press "Run"

The move will be paused, and you can use the buttons and D.pad to scroll through the animation and move the character around.

Press Ctrl+C A few times to view the collision boxes.
Press Ctrl+D to view the Debug Info

To get out of the Collision check state, press start.

I would comment this out again when playing the game normally, because it'll turn on by mistake, so just enable it if you want to mess with the collisions.

;-------------->
;-------------->
; [State -2, Collision Check];Comment this out when not testing collisions.
; type = VarSet
; trigger1 = var (0) != 100;Collision Check is on.
; v = 0
; value = 100
;-------------->
;-------------->

;------------------------------------------------------


I was tweaking the speed of some animations like the uppercut. Made some changes to the blood...

I made a new hit state for the far hit slide, like from the High kick and crouching moves.

You can change to Human Smoke now, if you "hold back" during the start of the round. The change isn't saved in memory yet, so you will need to do this for every round.

I added a new variable to change the Ninja to another, so that's the first test.

On My mode I made a change to the wall slam, so it happens near the real ends of the stage, not just anywhere.

 

[Shock]

OK, we can try out the enhanced collision you showed in the demo but perhaps only for sweeps, combos, Mileena's Roll, etc, for now. Moves that change your opponent's hit box. Otherwise, all normal collision detection should stay that way until we can totally verify that this will work. There's a lot of extremely specific things that have a need for specific collision.

 

[Bleed]

You can check here some of the updates in the video, It's feeling pretty different now.

http://www.youtube.com/watch?v=MoyD5q0mdAM


[EDIT]

A note about the sound effects in Mugen, if the sound is going out when doing combos, you need to up the wave channel limit in mugen.cfg



Data/mugen.cfg


WavChannels = 12

Change it to 16.

 

[Bleed]

Some progress on the system...

The more obvious changes are the round transition, working sort of like MKDA.

This can be turned off to use normal rounds.

Another thing is some pretty heavy changes to my mode. I want mine to be pretty unique for every character, so that includes giving them their own basics.

The UMK3 mode is like UMK3 and the MKR mode has more to do with special moves.

So here's a video of Bleed mode vs what I have so far of the UMK3 mode.

I think I can start separating the features for MKR mode now. Get that blocked in some what, then keep working the basics.

http://www.youtube.com/watch?v=tDJjVO-P6mA

 

[FrozenWorm]

Here's is something I'm working in right now:

Scorpion's Spear Stance:

I'm not posting much animations in any forum because I want to show the progress in videos.

 

[FrozenWorm]

...

This is Scorpion's new outfist concept for MKR:

The concept uses ideas and work from Tetra Vega, MKOW, Shyn and myself, I think it's a lot better than the one I posted before; I'll be working on this after finishing the moves for Scorpion, Jax and Cage.

 

[Shock]

Any more updates on gameplay?

 

[FrozenWorm]

Bleed is working in Mode 3 at the momment.

 

[Bleed]

Yeah, I've been making a lot of changes all over the system, and I'm moving some of the 3d art work along. I'm working on this almost every day.

We may end up with an option of two sprite styles, because I want to make the 3D models and FW like to use the original sprites.

Here's a normal mapped model I'm working on now...

 

[Shock]

Just a couple examples of combo animations in my head for an old school character that never made it to MKT:

I don't know how far you're digging into the 2D to get characters from, but I've always wanted to give them combo treatment that looked more like MK3, and not MKT. Some UMK3 combos and many MKT combos just look hacked together with no flow or purpose, so I tried to give some to Johnny Cage here. Right now I'm not looking into editing sprites but rather finding existing frames that have substance from which to make combos. Here I use part of Cage's throw (looks a little hackish) and his swing from his projectile, which looks pretty good. Then I did a standard cycle of kicks to finish his 7 hit. Obviously you guys know there's tons you can do with their existing animations, like creating knee lifts from part of the roundhouse, reversing roundhouse animation, all special moves can basically be combo hits with the effects or projectiles, some fatalities, etc, and perhaps even doing a few special move links like Nightwolf's Axe and Raiden's Superman, where it's logical.

If I were to assign combos to old characters, I'd go through MK3, UMK3 and MKT, to see what percentage of characters have pop up combos throughout each game, look for patterns, and then how many 2, 3, 4, 5, 6, and 7 hit combos there are, specifically how many have the 3 hit kick combo, and then distribute those amongst the characters who never made it far enough to get combos, and try to come up with which character would benefit from what. For example, I wouldn't want to give every single old school character a pop up, or a 7 hitter. I'd also go through and check damages to basically stay within reasonable range, not going over or under the maximum and minimum damage combos for the hit counts, for example Sheeva's 7 hit 42% and Sektor's 2 hit 15%. And of course directionals involved in performing combos, maybe add some characters that use block in their combos. This again, all applies to the MK3 engine part of the game.