SFF File Issues

[cl_conn1988]

Hello, it has been some time since I've been on this forum And by that I mean online I've just never signed out.

Some of the characters on my roster will crash the game if I try to use them. Most are Arc System Works characters and Orochi edits but not all, and the one thing that causes the crash happens to be a problem with the SFF file. While they don't always crash the game they will about 50% of the time.

The list below contains the characters and authors:

Akihiko Sanada by SXVector
Labrys by SXVector
Abel by Borewood
Rufus by Mr. I
Omni by Werewood
Red Arcueid by 9AACC
Blue the Dream(Orochi Edit) by an unknown author
Mysterious Green(Orochi Edit) by Siegfried8823
Albion by T-Jiro

Is it possible to edit an SFF file? I've searched other forums but with no luck. I've tried opening the files up with notepad but it takes way too long to load. Does it have something to do with local cord?

Oh and Cyanide and Warner if you read this I just want to say thanks for all the help with fixing characters for 1.0, I really appreciate it.

[Cyanide]

Yes, absolutely. But you need another program rather than wordpad. Find and download fighter factory 3. The sff should load in that OK. Finding the issue will be FAR harder. The things you can check for are

Sprites with either no palette, or a non 8bit/256 colour palette
Sprites which should apparently have a standard palette but have a strange mish mash of colours
sprites in a sequence that appear to be numbered incorrectly. For example it goes 1,2,3,4,83747634,6

Failing all of those, hop into the air file and make a copy into notepad of it, then delete anim 5300 (this can work at random because anything made with the elecbyte template will randomly break your mugen/character)

After that. All you can do is export the entire sff file, and then import it into a completely new SFF file. That will either expose the corruption or remove it from the original.

[cl_conn1988]

Thanks for mentioning this program. I've been experimenting with it for few minutes and found out how to view the errors. I actually found some errors in the SFF files and the CLSN files. Now my new question is about the errors list. I noticed some errors have an exclamation mark beside them and others have an X. I take that the exclamation mark is a minor error and errors with X's will crash Mugen?

On a side note: Albion alone has 40 errors, but my main focus for now is of course the SFF file.

It says: SFF(615): The group 5031, index 0 is already in use by sprite #614!

Here is more info: Albion's total frames is 3675
                             The problem is frame 615 as stated above.
                             X axis=160, Y axis=173
                             359x314, and he does have 8 bit

Thanks for mentioning Fighter Factory, and what should I do? Is changing the index number all that's needed or does this require something else?

[Cyanide]

I don't see why that would crash the character. First step, delete sprite 614 or 615, whichever it is. Export it first if you like, just remove it from the sff file and see if the character works after that. If it does, add it back in and give it a new number (this may require other fixes to reference the correct sprite

[cl_conn1988]

While I did not export the, I instead keep unaltered backup copies of all characters I download. But  I did delete the sprites and Albion runs much better now. So I deleted that character from the roster then copied and pasted the reserve file. and changed the number from 0 to 1. A slight delay loading him in the game but he works just the same.

So that's got Albion done, next is Akihiko. I was for sure his SFF file crashed the game, at least thats what the Mugen error said, but fighter factory can't find anything wrong with that file in particular. Mostly its the following St1, St2, St3, etc.

Not sure if this causes the SFF file to act in an odd manner, but here's what the major errors state:

Note: Not gonna list all issues since it's mostly the same. I am only listing each issues that are different from one another.


Some read: Unknown Parameter "pausemove" for explod controller,
Unknown Parameter "absolute" for the targetlifeadd controller,
Unknown constant 'velocity.runjump.y'
Unknown parameter 'id' for the reversaldef' controller
Unknown parameter 'supermovetime' for the destroyself controller
Unknown parameter 'pausemovetime for the destroyself controller
and Unknown parameter 'id' for the bindtoroot controller

Total errors = 63
1905 frames
359x378px(8 bit)
Localcoord = 1338,756 ; 1338. 75, 756
 

[Cyanide]

Pausemove is old, it's now pausemovetime. You shouldn't need to change this one but you can if you like.
it's not absolute, it should be abs. Also not overly important and can be deleted
Hopefully that's not in the constants itself, should be velocity.run.jump.y
For ID, remove it. I don't think you can ID your target in a reversaldef like that. It won't be actively breaking mugen though.
The supermovetime and pausemovetime, shouldn't be breaking anything, but don't belong there so feel free to pull them out.
You will need to show me the full code for the bindtoroot one. I don't know how ID is being used there to say what needs fixing.

[cl_conn1988]

Certainly, here you go:


[State 0, BindtoRoot]
type = BindtoRoot
triggerall = numhelper(2000)
trigger1 = root,pos x > helper(2000),pos x + 290
trigger1= root,stateno = 500
trigger2 = root,pos x  < helper(2000),pos x - 290
trigger2= root,stateno = 500
time = 1
id = -1
pos = -130,0
;ignorehitpause = 
;persistent =


Also will changing y = const(velocity.runjump.y) to y= -8 fix it as well?
After all  it worked with some of the other characters on the roster. Or will it break the character more due to having Hi-Res sprites?

[Cyanide]

If not -8, -16 instead.

For that one, just remove the ID line. They've taken bindtotarget and swapped the word over, lazy buggers.

[cl_conn1988]

Ok that's got all of Akihiko's errors fixed and I've tested him since, and I just have to say WOW, I've never seen Mugen load a hi-res character that fast. Thanks a million.

Also since Labrys was made by the same author she had mostly the same issues so I jumped the gun a fixed those problems accordingly like you mentioned. The SFF file however is a different story. Even though its listed as a minor problem it still occasionally crashes the game.
The primary cause is a complex animation in a hyper move sprite.
It states that numerous sprite #'s in group 6200 is used in index 1-20.
A similar issue with group 6129, index 18 uses #'s 1135, 1136 1137, and 1138 several times. However judging by the animations I viewed, one would expect this to work with no issues since this is an explosion animation and the other is what seems to be a black hole. Overall it looks like it should work.

 I still haven't fixed all the major errors yet, but it should be similar to fixing Akihiko except for the SFF.

What do you think? I'll provide more info if needed.

Thanks again.   

[Cyanide]

I would say export the whole sff file and look those sprites up in an image editing program. See what they look like. Then re-add them to the sff numbering them correctly and recreate the animation in the air with the new numbers. Delete the old sprites.

By the SOUND of it, this is caused by the person creating it using the link sprites check box in an older version of FF. Tended to mess stuff like this up.

[cl_conn1988]

Alrighty, I finally finished fixing most  Labrys's major issues.(SO MANY)

However these two i've never seen before:

Unknown parameter 'camerpos' for 'explod' controller
Unknown parameter 'down.type' for 'hitdef' controller

Here is the statedef for the down.type one as there is only error of that type:

[State 200, 1]
type = HitDef
trigger1 = AnimElemtime(12) >= 0
trigger1 = AnimElemtime(14) < 0
attr = C, NA
damage = ceil((ifelse(hitcount = 0,1390,690)*fvar(1)*fvar(2)*fvar(3)*fvar(4))*0.0912575) + ceil(var(11)*0.5),0
animtype = Up
ground.type = Low
down.type = Heavy
;air.type = High
guardflag = HA
hitflag = MAFD
priority = 7, Hit
pausetime = 10,16
sparkno = S6210+random%4
guard.sparkno = S6120+random%4
sparkxy = -40, -54
hitsound = S400,3
guardsound = S120, 2
fall.envshake.time = 20
fall.envshake.freq = 90
fall.envshake.ampl = 4
persistent = 0
palfx.time = (enemynear,movetype=A)*9
palfx.add = 100,-50,-50
kill=1
getpower = random%40+00,random%20+5

Also what would be the best program to export to or can Fighter Factory do this as well?

[Cyanide]

Just remove that line. Don't think that even exists. Camerapos is a new feature for 1.1,would need to see where that lived to know if it's necessary.

FF does the export. You then need to at least open everything and make sure it's OK. You can then use the ffd file created by FF to import it all again.

[cl_conn1988]

Here is the camerapos statedef:

[State 0, Explod]
type = Explod
trigger1 = var(11) >= 15 && var(11) <= 20
trigger1 = teamside = 1
trigger1 = numexplod(3001) < 1
anim = 3001
ID = 3001
postype = left  ;p2,front,back,left,right
facing = 1
vfacing = 1
bindtime = -1
removetime = -1
pausemovetime = 999999
scale = 1,1
pos = 0,ceil(gameheight - 173)
sprpriority = 6
ontop = 1
shadow = 0,0,0
ownpal = 1
supermovetime = 99999
ignorehitpause = 1
supermove = 99999
pausemovetime = 99999
ignorehitpause = 1
persistent = 0
camerapos = 0,0

This appears in 10 statedef blocks just let me know if you need to see the other blocks. Also, M.U.G.E.N. 1.1? I was just getting use to 1.0. Whats the difference between the two? Is this one reason why this particular character crashes the game, or are 1.1 characters meant to work 1.0?  On a side note the Mugen system I use is IMT(Blue) 1.0. Is their a 1.1 version encase an update is mandatory?  Sorry for barrage of questions.

[Cyanide]

The camerapos, and gameheight mentioned there are specific to 1.1 and won't behave in 1.0. They're to do with the zoom function.

You can probably remove camerapos altogether, swap the gameheight bit to just, i think -173 or 173 and you'll get the same result. Otherwise do the math for 240-173 and use the result of that in that line. He's used postype = left which means 0,0 is top left corner of the screen, positive integers counting towards the bottom of the stage.

Or use 1.1 and figure out how to turn off the zoom function in all stages because it's badly done.

[cl_conn1988]

Done, Ok I've been experimenting more with FF and finally found out what you mean about exporting the SFF. That puts it in a .FFE file. How do I turn that into the new SFF file? However when trying to import it to FF it will freeze up the program. What am I doing wrong? Thanks.