Build 282.1 - beta

I'm not against sub-events but I would prefer something well-defined, robust and secure than having a bunch of new features not properly designed and integrated. Looking at the picture, it seems simple and easy to do. But then thinking about concept behind, I agree with Joshtek, it could easily become a mess and increase risk of programming errors due to specific language features to handle.

Quote from Konidias

People aren't going to just be adding sub-events without first learning what they do... just like anything in the program.

Unfortunately, people uses everything without taking the time to learn and then complain on the forum because it's not working.

> Looking at the picture, it seems simple and easy to do. But then thinking about concept behind, I agree with Joshtek, it could easily become a mess and increase risk of programming errors due to specific language features to handle.

I completely agree...

I don't see anything complicated or confusing about sub-events. From my perspective they simplify the visualisation of what you see in the event editor that would otherwise be quite complicated (and time consuming) to construct. I had the same solution in mind about how they would work, the fusion runtime would not need to change, just the way it is represented in the event editor and what fusion needed to do at build time.

I would love to see more features that help making games easier to do. I also have Please login to see this link. to do with Fusion. And Please login to see this link..

Really not understanding the logic with the negative posts about sub-events...

So you're saying something that makes your events easier to manage and read is going to be more difficult to use? The thing that baffles me about the negative comments is that it's not like you would be forced to ever use sub-events... You could literally never use them and it wouldn't change anything for you.

It's like saying there shouldn't be fastloops because fastloops can get messy and hurt performance if not used properly.

As for the software not being "secure".... well don't use beta builds then? That's kind of the point of beta builds... to be able to allow the developers to add new features that might be slightly buggy.

You have beta builds and stable builds... If you want a stable and secure program, then use the stable build. You can't have "robust" without having beta versions that add new features to make the software robust.

Been thinking about sub-events since click & create would be awesome to have something like this!

Sub events is the feature I never knew I wanted! (Just to be clear, I love the idea and would welcome the option whenever it materializes. Take your time, you are all doing a great job, and i love using what is available right now)

In addition to sub-events (which I agree are a needed feature) I came up with a feature myself that I would really like to be added (I already made a feature request in the bug tracker for it): The ability to control event position during runtime.

For example, since MMF2/CF2.5 reads the list from top to bottom (with a few exceptions such as fastloops), i'd like to be able to seek a certain line: if 2.5 hits event 12, and certain conditions are met, I want it to jump to 50, or maybe jump back to the top instead of going all the way to the bottom first.

This would prove very useful and has a lot of potential (especially for movement engines); allowing you to effectively skip chunks of code you don't want read unless they meet requirements without having to go through the hassle of putting together an intricate work-around. You could also essentially create loops without specifying a loop itself, and this whole feature might improve performance greatly in applications that contain many event lines.

This seems like it would be an easy implementation with little repercussions: at most the editor runtime would crash if you screw something up.

Quote

- Event editor: when you display the names of the alterable values/strings for a qualifier, it now displays the names of the alterable values/strings of the real objects (if these names are identical for all the objects). Same thing for the user animations.
- Windows runtime: you can now have an unlimited number of alterable values at runtime via indexes (named values are still limited to 26). We'll port this feature to other runtimes in a future build.

Please login to see this picture.