Is there a 'Frame Complexity' limit?

It is really hard to say, we need more information.
What kind of events you have set up and how is the frame messed up etc.
I have noticed this as well when I created my player animations, there are quite a lot of conditions and it was pain in the ass to make them all work without interfacing other events.

But I think there should be no limitations, you just need to organize your code very well and if there is a bug, there is a bug also in code.

- Jesse

The short answer is no. The longer answer depends on what exactly you're doing and how you're defining things like "complexity" and "complicated." How many objects are in your frame? How many events? Are the objects doing anything out of the ordinary? Are you doing some unusual event editor practices?

You haven't told us outside of vague innuendos what the problem is, so how can we tell you if there's a way around it? I know that some users of Fusion 2 have had frames with upwards of 10,000 events in them with I don't know how many objects and they never encountered "frame complexity" that was more than user-error.

You might be exceeding the object limit for the frame. The default is 500. Try setting it to 2000 and see if that fixes anything.

I've seen some instances where your game just won't do what it's supposed to and there's really no good answer why that is. Try making sure your actives have "destroy if too far from frame" unchecked. Sometimes that helps. Also I've seen that if an active that now suddenly doesn't work that's outside the frame area is overlapping even a tiny bit of the frame it suddenly works again.

MMF is awesome, but it can act strangely on occasion. I still remember the weird errors I had where it was confusing values for 2 arrays I had going at once. Sheesh-KaBob!

Are you using behaviors, by any chance? "Putting events in objects" sounds like behaviors to me, though I'm not sure if that is what you meant. Also, do you have any global events or qualifiers?

Okay, then stop using behaviors, they can be buggy at times, which might explain all of your problems. Behaviors are only useful if you plan on re-using the code in another frame. Also, qualifiers should NOT be used in behaviors or global events, EVER. It will not let you use qualifiers in global events or behaviors in newer updates in MMF2, since they are horrendously buggy when used together.

/edit
on a closer inspection, it does appear that there are serious glitches when you exceed ~12800 events in a frame- this number was *supposed* to be 20000, but the maximum number of events is definitely not working where CT intended it to. I'll see if I can isolate this glitch in a reproducible .mfa

I'll post my results later, but oddly I experienced some heavy glitch outs around ~12800 LOC, but it went back to normal when at ~14000 LOC
Try making a group with 2000 dummy lines of code and sticking them in the beginning of your event editor, and see what happens

My suspicion based on what I'm seeing in my own project is that 20000 is still the 'cap', but around ~12800 LoC, events occur out of order. I have a big group at the bottom of my code that sets the animations for all objects, and when I buffer too many lines of code in there, newly created objects aren't given their animations on the same frame, but have it assigned in the next frame, so theres a 1 frame 'blip' of the wrong animation. That would make sense if the group had somehow been misplaced to the top of the event editor

check out my brief unscientific test:

Please login to see this picture.

Notice how the sparkly particles appear for 1 frame as (the default stopped direction = 0) blue smoke? Well the framerate was lower on the .gif than ingame so you only see a quarter of them, but its enough to get the idea (it was happening for all of them). Rearranging the order of my events had the same effect as adding 2000 events at the top, and I imagine yours will be the same symptoms.

I'll put some effort into isolating this and making an example file, hopefully CT will be able to address it

Heres an .mfa that reproduces this error, I'll post it to the bug tracker pretty soon, but I'd like to get a better grasp of exactly where the wrap-around occurs in the events that get out of order:

Please login to see this attachment.

I have confirmed with certainty that this occurs at event #8193, after you have subtracted all comments, group numbers, empty lines of events without actions, "never" events, etc- things that the compiler removes at runtime. The fact you and I both experienced it around 12000-13000 lines of code wasn't anything to do with the actual event editor number, but rather we both probably had about 3000-4000 group names, disabled code, comments, etc. Does that sound right, given your project?

Another thing I personally would like to note about the issue: Start copying and pasting those groups. At around 30,000 events, MMF2 flat-out crashes. EDIT: Another note: Start right before you hit 30,000, delete some of the groups, then start pasting them back in. You'll find it crashes before 30,000 events so long as you delete enough groups before then, meaning they might not be properly deleted. Maybe it has something to do with the issue?

EDIT 2: I personally have yet to reach even 1,000 events in my projects that are in my opinion basically my biggest (they're still quite advanced, though). Maybe this is a matter of the Please login to see this link.? After all, why do you need 12800 events for an RPG battle screen? There are almost certainly more efficient ways to do it, such as making it so that the attacks are as modifiable as possible outside of events (as opposed to hard-coding every last attack (E.G. storing damage output in an array or something like that)).

From what I can tell:

Events above #8912 will overwrite event #1+
For example, if you have 8912 events, all will work. If you have 8913 events, event #8193 will become event #1, and your *real* event #1 will no longer exist
The more events you go over 8912, the more events you erase.

Undoubtably, MMF2 is not using enough bits for the index of events in some way. Since 2^13 means theres a possible 3 bits reserved for flags about the events, which would add up to 2 bytes per index. And if thats the case, it might also cause a buffer overflow and change some flags for those events. I doubt that next bit is signed. So the obvious solution would be, MMF2 should use more bytes per index, 4 bytes would be logical (2^13 could become 2^29, giving us 536 million lines of code maximum). I don't know what other implications this could have in MMF2's structure, how difficult such a change could really be

Its in the bug tester forum and assigned, we'll see if its fixable, I'll make a note that it should be applied to 2.0 and not just 2.5

It's actually quite likely the index is signed. There is an action limit of 128 per event, which only happens when you cap out a signed byte. The condition limit is also 128 per event. This could easily be doubled by unsigning it, unless the leading bit is used for something else.