• All, I am currently in the process of migrating domain registrations. During this time there may be some intermittent outages or slowdowns. Please contact staff if you have any questions.
Street fighter 89

In Progress Street Fighter 89 The Final Fight by Machok v3.7

No permission to download
Overview Updates (2) Reviews (8) History Discussion
The project is currently under development.
Kratus said:
@machok @O Ilusionista Some time ago I accidentally discovered when reading the source that the custfade also controls the level transition.
Click to expand...
😮 will try it asap

Kratus said:
Not exactly, I mean all the running attacks specially for Cody the front running attack (I saw that there's a down/up running attacks too). Look at my video how many times I abused it to avoid taking damage.
Once these new moves are not present on the original, you can create any system you want. Example, it could be a cost (mp maybe) or you could add a long delay at the end to make players vulnerable, so they will think twice before abusing it and will try to use it only at the proper time.
Click to expand...
I see I understand now, I'll try experimenting
maybe I will try to add more delay if the first attack does not hit the enemy or reduce the speed so it doesn't move too far forward

Kratus said:
It sends me to another idea I had now. Maybe you could move all the running attacks, counter attacks and eventually any super move to a 4th separated button. This way people who do not want to use any new feature can simply skip the button and play using the classic commands only.
I know that the classic has only two buttons in most arcade machines, but some of them (at least in my country) had a 3rd button to escape from Andore grabs and perform special moves. So we can consider those three buttons as a classic mode too.
Click to expand...
It's an easy edit and adding 1 extra button won't hurt but I need to think more about this whether it will feel comfortable with separate buttons or not 🤔

Kratus said:
I never tried to change it because I think it's good engine behaviour to avoid entities getting stuck. I need to look in the source to understand what happens when you are near the wall/edges in order to create a way to prevent it.
As soon as I have any results I will post here.
Click to expand...
🥰

O Ilusionista said:
If I am not mistaken, when you put Z as 0, the engine revert to the default value. As it does with a lot of stuff, like "agreession 0".
Click to expand...
how much is the default value?
I can't remember since I change it long time ago but I remember changing to 0 value has an effect

O Ilusionista said:
wow, custfade works in a very strange way.
Click to expand...
This strange behavior does it affect the music too?
 
@Kratus,

The engine prevents grabbing unless the entity is actually moving (not just walking). You could add a script that overrides this by using dograb() function to force engine to run its grab routine.


Later I will add flags to enable grabbing when not moving, but I want to do that myself to integrate with other additions properly.

DC
 
machok said:
I did design it that way with z depth 0
Click to expand...
I was under the impression that you might take it into account for you next update but if you design it that way by choice then cool,what does z depth 0 actually do though?
machok said:
yes I've added a lot but not all of them since I don't like some enemies fall looks weird when using -1
this one for example, I want enemy fall stay like this
Click to expand...
You right,not every attack requires it.
It's more about knowing where to apply it so they don't fall in the opposite direction of certain attacks.
Like for me the Shoryuken always knocked the enemy in the opposite direction when the sprite overlap each other so fordirection -1 fixed it.
Jumpforward kick is another.
Your game is in a good state and the audience wouldn't know the difference since they caught in the game.
 
DCurrent said:
The engine prevents grabbing unless the entity is actually moving (not just walking). You could add a script that overrides this by using dograb() function to force engine to run its grab routine.
Click to expand...
I did some tests and it seems that this is more perceptive against walls, the screen edge looks more flexible because I can grab enemies even if moving only in Z axis.
Maybe adding a script in the onblockW can bypass the engine behaviour, I will keep testing.
 
Last edited:
Kratus said:
I can grab enemies even if moving only in Z axis.
Click to expand...

That's allowed, so it makes sense. You just have to be moving along either X or Z. Otherwise, grabbing is blocked.

The check is rather tricky to locate, because it's hidden in a place you wouldn't expect. In order for a native grab to activate, the adjustgraposition() function has to return true. However, adjustgraposition() has this logic in it:

C: 
if(0 >= testmove(ent, ent->position.x, ent->position.z, x1, z1) || 0 >= testmove(other, other->position.x, other->position.z, x2, z2))
{
    return 0;
}

So if the attacker or target can't move into correct position on X or Z axis, then adjustgraposition() returns false and the grab fails. There's no shunting away from the wall/screen like in SOR2 - the grab just doesn't happen at all. The dograb(<acting entity>, <target entity>, <adjust>) will also fail if you enable the adjust flag, because it performs the same check. Setting the flag to 0 will bypass, but then it's your responsibility to adjust positioning and make sure there's no wall issues.

HTH,
DC
 
DCurrent said:
So if the attacker or target can't move into correct position on X or Z axis, then adjustgraposition() returns false and the grab fails
Click to expand...
Hmm this explains the wall behaviour, because for screens the enemy can move outside but for walls he will always be stopped and even if the player is moving, the testmove will return false due to no enemy velocity.
Thanks for the clarification, now I understand better.
 
Been meaning to mention that I'm loving the new knock down fall animation added to when Guy does that round house heel kick if that is what it's called.
The super meter looks spot on.
It's cool that a person can tell the difference between it and the arcade game until you play it.
 
I have a suggestion: Damnd could show up in later stages as a generic enemy under the name “Thrasher” much like the SNES version.
 
I prefer the name "Damnd" in game as a boss, even though I'm familiar with the SNES version. Damnd has already got two names combined in Street Fighter 6.
 
machok said:
how about using the name when Damnd is available as a player?
Click to expand...
Sounds nice. Also, Uncle and Grandpa Andore, in their official art and SF6 models, have more distinguishing traits not reflected in their sprite sets. Grandpa’s sunglasses and Uncle’s mustache, they also had a different hairstyle from their in game counterparts.
 
Miru said:
Grandpa’s sunglasses and Uncle’s mustache, they also had a different hairstyle from their in game counterparts.
Click to expand...
mustache and sunglasses can be done using smartpal. but the hairstyle no. I think its a bit waste of resources to have a duplicated set of sprites just for that. But that is me
 
You must log in or register to reply here.
Back
Top Bottom