YesNoOk
avatar

Fighter Factory Studio 3.5.3 (UPDATED June, 16) (Read 953418 times)

Started by VirtuallTek, April 04, 2018, 02:43:30 pm
Email this topic
View printable version
Share this topic:
« previous next »
Page 7 of 22← First < 1 ... 4 5 6 7 8 9 10 ... 22 > Last →   Go Down

Jesuszilla

Re: Fighter Factory Studio 3.5.1 (UPDATED April, 07)
#121  April 15, 2018, 10:44:14 pm
  • ******
  • Loyal to the Game
    • USA
    • http://jesuszilla.trinitymugen.net/
That tutorial is old but a lot of its criticisms still apply. The only thing that doesn't is "infinite priority" since that's antiquated BS based on the concept that all CLSN1 should be covered by CLSN2 and use the MUGEN priority system to define priority, which is simply incorrect. All fighting game hitboxes primarily use the hitboxes to determine which attacks should out-prioritize others, with rare exceptions such as SF3 where some hitboxes (which are specially denoted) use a priority system when they come in contact with another of the same type.

This thread, however, is for Fighter Factory feedback, so I won't go into more detail and simply say this: we've had this discussion many times, and VirtuallTek has stated he's not bringing it back because:

1. It's tricky to implement; there is no perfect method as you think there is.
2. It was bad in the first place because it is bad design.

Odb718

Re: Fighter Factory Studio 3.5.1 (UPDATED April, 07)
#122  April 15, 2018, 11:32:22 pm
  • *****
  • Shame on you!
    • USA
I wont go in on hitboxes, we all know I have my own idea about how Mugen's hitboxes should be set up.
But I will say, the auto-hitboxes would be a blessing if you could control How Many hitboxes are used.
If you could define it as 2, 3, 4, or 5, It'd make editing those boxes soooo much faster. You'd only have to pull one or two corners a frame.
One of the main reasons I stopped work on Roberto from Rival Schools is how many thousands of hitboxes I was making.
On average I use 4 hitboxes per sprite. He's got 2,287 sprites for his body alone.
8,000 hitboxes takes a little while to drag into position. Even at 1 hitbox a second it's over 2 solid hours of drawing hitboxes.
and I still have work on Akira and Hyo......

The 20 hitboxes used in that one frame is excessive. You could use 6 or 7 and cover it just as tight. Which most devs would only use 2 or 3.
To me, that's antiquated laziness.
vVv Ryuko718 Updated 10/31/22 vVv

ZolidSone

Re: Fighter Factory Studio 3.5.1 (UPDATED April, 07)
#123  April 16, 2018, 12:20:00 am
  • ****
  • I'm 100% Team OHMSBY now.
    • USA
So I happen to found another crashing issue by accident. I was just trying to test a character, I clicked OK too quickly without picking an engine to run and the program decided to crash. This only happens if you have multiple engines installed as FFS asks you which one you want to use to test the character. I happened to have 2 so it crashed when I accidentally picked nothing. I manage to replicate this a few times. Although it's a rare bug and you will unlikely encounter it if you only have one engine, thought I might report it.
I will still do detail and aesthetic feedback for the rest.

Ryutaro

Re: Fighter Factory Studio 3.5.1 (UPDATED April, 07)
#124  April 16, 2018, 01:24:20 am
  • **
  • WOLUFUFUFU♪
    • Thailand
    • sryutaro.wixsite.com/ryutarofuture
I'm very proud for FFS  :nuttrox:
but it's little problem.

Mazter Arzate

Re: Fighter Factory Studio 3.5.1 (UPDATED April, 07)
#125  April 16, 2018, 05:34:52 am
    • Mexico
Anyway, I think that people like you are not interested in stagnating us, follow their obsolete methods that only bring problems of transparency and advantages in many characters as it takes a lot of time and that is a mediocre job when it comes to properly carry the boxes correct collision, in short this is mugen and will make my game with my own collision boxes to not have advantages of transparency of the characters as they have their obsolete method, continue using the classic name to do it and your time to waste it so do it, do not know the concept of a program or what it is for, keep using the mcm in my opinion, do not know what updates, if it is a program to avoid work or in a more effective way with the tools it gives us the user the comonidad and the time in which it does, also if you do not like you do not like anything of what there, for people who use it, but in order that we do ...

Darkflare

Re: Fighter Factory Studio 3.5.1 (UPDATED April, 07)
#126  April 16, 2018, 07:04:28 am
  • *****
    • Puerto Rico
    • www.youtube.com/user/Darkflares
If you don't have the time to make proper hitboxes, you don't have time to code a proper character anyway.

David11

Re: Fighter Factory Studio 3.5.1 (UPDATED April, 07)
#127  April 16, 2018, 05:03:56 pm
  • *
  • --
    • Brazil
    • psychoctrl@gmail.com
I just think that people care a bit too much about hitboxes and the amount of them. Of course you shouldn't use more than 4 or 5 per sprite... but, just for science:



I summoned 30k projectiles in the same tick (with empty animations, just the collision box itself), mugen was surprisely stable. it didn't crash or anything, didn't make my cpu go crazy or anything of that sort. then I looked at the cpu usage and discovered that mugen uses just 1 core at a time (at least I didn't knew that lol). Also, not all of those hitboxes registed hit in the same tick (see the 54 hits as there's at least 1000 of them on top of the other player).

The thing is, the automation that the hitbox tools provides while is good for some people is the worst thing ever for those who understand why it's bad, and why you should use it.

The more collison the less FPS you get.

Remember thar each collision box has 4 coordinates, and they are calculated every tick and while more boxes makes it for more precise hits, it also puts unecessary stress on the engine. I can see why VirtuallTek removed and I kind of aprove that.

And, if I had a single core while doing that test, i'm sure my pc would stop responding because of all the thousands of calculations and if by any chance Mugen did use all the available cores, + more ram/vram, then that would crash even modern computers. (provided you mess with mugen.cfg values and make it possible to summon that many projectiles).

Also if that didn't convince you, take a look at old arcade games Collisions boxes. Newer games of course have better optimized engines, so they can have precise hitboxes.

Long story short:
Just don't.

VirtuallTek

Re: Fighter Factory Studio 3.5.1 (UPDATED April, 07)
#128  April 16, 2018, 07:16:29 pm
  • ***
  • www.virtualltek.com
    • Brazil
    • www.virtualltek.com
Thanks for all bug reports.

I'm solving them all. In the next version I will introduce some things people requested, as empty project, open single file, and option to disable the lock to save SFF if it has errors.
But disabling this is very dangerous. This was made to prevent user mistakes, as some are critical like trying to save SFF v1 with 24/32bit images or wrong sprite order (in SFF v1, wrong ordering will change the sprite's palette). These are real errors and saving SFF without fixing them will lead to data loss (you can't simply fix it later). Don't ask me after!

EDIT: I'll' add an option in the error window to let FF fix them by sorting sprites and converting 24/32bit images to 8bits, warning about possible data loss, and change the error about same group/index to warning. This way people can save the SFF more safetly with less error messages, but still, with some data loss.
Last Edit: April 16, 2018, 07:37:43 pm by VirtuallTek

PlasmoidThunder

Re: Fighter Factory Studio 3.5.1 (UPDATED April, 07)
#129  April 16, 2018, 08:12:17 pm
  • *****
  • Resident Tosspot
  • Pftheh
    • UK
    • plasmoidthunder.neocities.org
VirtuallTek said, April 16, 2018, 07:16:29 pm
EDIT: I'll' add an option in the error window to let FF fix them by sorting sprites and converting 24/32bit images to 8bits

I swear FF3 did this already...? Seems odd that Studio doesn't.

Iced said, July 24, 2013, 01:25:14 am
Oh, I want a diagram. I fucking love diagrams.

VirtuallTek

Re: Fighter Factory Studio 3.5.1 (UPDATED April, 07)
#130  April 16, 2018, 10:59:30 pm
  • ***
  • www.virtualltek.com
    • Brazil
    • www.virtualltek.com

Odb718

Re: Fighter Factory Studio 3.5.1 (UPDATED April, 07)
#131  April 16, 2018, 11:00:21 pm
  • *****
  • Shame on you!
    • USA
@David11: It seems your player 2 died. Is the projectile doing less than 19 damage? Try testing with the damage set to 1,0 and try blocking it. You basically said that anyone running mugen 1.0+ wont feel the effects of 30,000 projectiles and 30,000 hitboxes. I doubt 20, 30, or even a whopping 35 collision boxes per tic could influence the game.  I still dont get why people act like it's 1999 and PCs can't handle more.

@Darkflare: I hope you're not taking potshots at me. 2,200 sprites is 3 characters worth of hitboxes. That's just the sprites. Not multiple animations per special or anything else.

For the people who argue against this, What if VirtuallTek figured out a way of putting a hitbox on the head and 1 for the body. Would you be anti-automation then?
vVv Ryuko718 Updated 10/31/22 vVv

Ryon

Re: Fighter Factory Studio 3.5.1 (UPDATED April, 07)
#132  April 16, 2018, 11:20:18 pm
  • *****
  • "The Future is Now"
Odb718 said, April 16, 2018, 11:00:21 pm
For the people who argue against this, What if VirtuallTek figured out a way of putting a hitbox on the head and 1 for the body. Would you be anti-automation then?

What if your character is Kirby and your head is your body?
Or if your character is headless?

as Jesuszilla said.

NO.
Just learn to make hit boxes the proper way.

Odb718

Re: Fighter Factory Studio 3.5.1 (UPDATED April, 07)
#133  April 16, 2018, 11:28:09 pm
  • *****
  • Shame on you!
    • USA
Not sure how you're not getting the point at this point...
It's not about learning how. It's about the physical time that it takes.
But you did answer NO. to my question so I guess you're not opposed to it.... . .  .
vVv Ryuko718 Updated 10/31/22 vVv

David11

Re: Fighter Factory Studio 3.5.1 (UPDATED April, 07)
#134  April 17, 2018, 01:08:21 am
  • *
  • --
    • Brazil
    • psychoctrl@gmail.com
Nah, I don't think that would be an option. Not all mugen chars have humanoid form.
Hell, definitly NO to ANY kind of automation when it comes to mugen. Would you use sprites/codes/sounds that were generated through an algorithm from a 3rd party program? what is this? Drag and dop shit? outta here.

@Odb, that's kind of what and I said but not really, mugen won't crash trying to renders those frames but it will take a while for it to process all the info, but eventually it will get there. it might take years for it to happen tho. I won't sit here to what this happen. I was impressed while stress-testing Mugen, it is like an old car that refuses to die or break lol

And no, the player didn't die because of the noko flag. Testing with a computer with integrated graphics I got stabble framerates up to a 1000 different projectiles/collisions per tick (the mugen freezes for a second in the tick that they're summoned tho, but then it resumes after it like nothing has ever happened). More than that you just increase the time of the lag spike. imagine 30k of them.

Now back to the subject.

There are some syntax problems with the new ff version. The same happened with the 3rd FF version.
XAngle, YAngle, etc.. are not recognized as explod arguments, even tho they were implemented in mugen 1.1

FF3 with fixed syntax:


FF Studio:


Its not a priority, but that just makes my OCD kick in.

Using nulls as a mean to set Vars now looks 10x uglier hence the fact that they have a different kind of color with non bold fonts:

It kind of makes sense and it kind of doesn't. People that arent familiar with Null will just assume that the code won't work, since it looks like it's disabled or something.

Interpolated animations do not animate. FF3 did it in it's quircky way but at least it was something. But FF Studio just don't animate the interpolation between frames. (I've just tested with 8bit Png images).

The rest was already mentioned in this thread. There's a really RARE bug that I found with the interface that I wasn't able to replicate, but the menus on the top of the program ("Project, Edit, View, Definitions...") stoped working for some stupid reason. it happened right after I had tested a char and closed down mugen.

That's about it. Great job so far I really like some aspects of FF Studio, it's a step forward for sure.

Darkflare

Re: Fighter Factory Studio 3.5.1 (UPDATED April, 07)
#135  April 17, 2018, 02:29:58 am
  • *****
    • Puerto Rico
    • www.youtube.com/user/Darkflares
Odb718 said, April 16, 2018, 11:00:21 pm
@Darkflare: I hope you're not taking potshots at me. 2,200 sprites is 3 characters worth of hitboxes. That's just the sprites. Not multiple animations per special or anything else.
I wasn't, but now I am.

VirtuallTek

Re: Fighter Factory Studio 3.5.1 (UPDATED April, 07)
#136  April 17, 2018, 03:35:30 am
  • ***
  • www.virtualltek.com
    • Brazil
    • www.virtualltek.com
David11 said, April 17, 2018, 01:08:21 am
Now back to the subject.

There are some syntax problems with the new ff version. The same happened with the 3rd FF version.
XAngle, YAngle, etc.. are not recognized as explod arguments, even tho they were implemented in mugen 1.1

FF3 with fixed syntax:


FF Studio:


Its not a priority, but that just makes my OCD kick in.

Using nulls as a mean to set Vars now looks 10x uglier hence the fact that they have a different kind of color with non bold fonts:

It kind of makes sense and it kind of doesn't. People that arent familiar with Null will just assume that the code won't work, since it looks like it's disabled or something.

Interpolated animations do not animate. FF3 did it in it's quircky way but at least it was something. But FF Studio just don't animate the interpolation between frames. (I've just tested with 8bit Png images).

The rest was already mentioned in this thread. There's a really RARE bug that I found with the interface that I wasn't able to replicate, but the menus on the top of the program ("Project, Edit, View, Definitions...") stoped working for some stupid reason. it happened right after I had tested a char and closed down mugen.

That's about it. Great job so far I really like some aspects of FF Studio, it's a step forward for sure.
I will check this.
About syntax, again, Studio is based entirely on Mugen docs, and only stuff from there will be highlighted as right code. If FF3 accepts your code not means it's fully Mugen "standard" compliant. Exploiting Mugen parser bugs is not an option on this version.
Thanks for reporting.

---------------------------------------------------------------

New SFF error message and Issues list relocated.


Thanks!

JustNoPoint

Re: Fighter Factory Studio 3.5.1 (UPDATED April, 07)
#137  April 17, 2018, 05:36:16 am
  • ******
    • www.justnopoint.com/
Would it be too much trouble to add a toggle to allow MUGEN parser bugs like FF3 did?

cidiego

Re: Fighter Factory Studio 3.5.1 (UPDATED April, 07)
#138  April 17, 2018, 03:07:09 pm
  • **
    • Spain
    • cidiego@gmail.com
Odb718 said, April 15, 2018, 11:32:22 pm
But I will say, the auto-hitboxes would be a blessing if you could control How Many hitboxes are used.
If you could define it as 2, 3, 4, or 5, It'd make editing those boxes soooo much faster. You'd only have to pull one or two corners a frame.


Absolutely agreed. I hope they include this option.
Thank you all for sharing!

VirtuallTek

Re: Fighter Factory Studio 3.5.1 (UPDATED April, 07)
#139  April 17, 2018, 04:01:05 pm
  • ***
  • www.virtualltek.com
    • Brazil
    • www.virtualltek.com
cidiego said, April 17, 2018, 03:07:09 pm
Odb718 said, April 15, 2018, 11:32:22 pm
But I will say, the auto-hitboxes would be a blessing if you could control How Many hitboxes are used.
If you could define it as 2, 3, 4, or 5, It'd make editing those boxes soooo much faster. You'd only have to pull one or two corners a frame.


Absolutely agreed. I hope they include this option.

As I said before, is unlikely that Elecbyte comes back and fix the parser (even KFM exploit undocumented behavior), but there's one thing every coder must keep in mind: exploiting parser bugs and/or undocumented things isn't good practice. If bugs get solved or undocumented stuff changes, your code won't work anymore.
The biggest changes from FF3 are stuff like Heavy, Med, ..., are gone. Even FF3 don't like Hamburger and things like this, and everything else Jesuszilla pointed out. That's not too much change from version 3.0.1 (of course, I missed some stuff people reported here and I'm adding that to the syntax database).
Replicating Mugen bugs will be more work than replicating FF3, as it accepts lots of "grammar errors". You can see the changes from FF3 to FFS looking at syntax.xml inside engines/mugen folder. FF3 was a great improvement but it fails on reporting errors with the precision level FFS aims to reach (there's, still, things I need to implement and/or fix).
It's unbelievable why people want to write, technically, grammatically incorrect code instead of good code that is fully guaranteed to work in every possible way.
Another thing to note, people seems to be scarry of their own mistakes, they don't like the program pointing out things they should fix. If you're editing SFF 1.0.1 or 2.0.0, why you want to save it after inserting 24/32bit sprites. If you do something wrong, it's best to KNOW WHY, so you won't repeat the same mistake again, than expecting the program to fix it some way, that probably, solves the problem (by brute force) but isn't the best solution. The next version will be less intrusive, so warnings that can be ignored and fixed later aren't treated as errors. This is happening in all Mugen forums. Some poeple said they will go back to FF3 because they don't want to fix their own mistakes in SFF and want a way to get rid of the error message. UNBELIEVABLE! Just fix your damn mistakes! :D

Someone can tell me why?

cidiego said, April 17, 2018, 03:07:09 pm
Odb718 said, April 15, 2018, 11:32:22 pm
But I will say, the auto-hitboxes would be a blessing if you could control How Many hitboxes are used.
If you could define it as 2, 3, 4, or 5, It'd make editing those boxes soooo much faster. You'd only have to pull one or two corners a frame.


Absolutely agreed. I hope they include this option.

It's planned for future versions.

Thanks!

JustNoPoint

Re: Fighter Factory Studio 3.5.1 (UPDATED April, 07)
#140  April 17, 2018, 05:36:13 pm
  • ******
    • www.justnopoint.com/
I can tell you I don't want to go back and change Hamburger to H in 100s of lines of code. If you have a ton of chars that FF3 didn't say had errors and this one is now telling you you have all kinds of errors you can't expect ppl to want to go back and fix all them when doing so is merely to appease the FFS. Now on future chars there is less excuse. You can fix them as you code (unless you use templates you'd already made like I do) but even then the NEW code can be more accurate.

You shouldn't be forcing such strict coding guidelines on a hobby engine. Most of us that use this to code will NEVER code in anything else, Anyone that goes into real coding will find out very quickly how coding in bad syntax can bite them later on. This hobby app shouldn't be so strict! MUGEN was made for ppl that have all ranges of coding knowledge.
Page 7 of 22← First < 1 ... 4 5 6 7 8 9 10 ... 22 > Last →   Go Up
« previous next »