Fusion 2.5+ DLC Official pre and post-launch Thread

Please ask about Fusion 3 in the Fusion 3 thread only [MENTION=11451]Dobermann[/MENTION]

Will it be possible to set the rendering mode via an event? I would love for users to be able to choose between DX9/11 instead of having to save out two separate EXE's.

not through events, but you can do this now using command line arguments, it has not changed in the plus version as far as I know.. make a separate simple launcher app that launches the main exe in two modes..

the problem is that shaders work differently in DX9 and DX11 so if you use a lot shaders, some of them might not look or work correctly in the other mode

I was planning on building a launcher anyway as the game is very reliant on both Read & Write functionality and we've had some trouble with users on heavily locked-down systems even writing to the AppData folder. Meanwhile, many distro platforms do not support Fusion's setup file format, so creating a separate app that can place the game files where they need to be is going to have to happen. I'll just make sure it also includes runtime modes.

Luckily the only shader the game is using is Invert so it should be A-OK, just hopefully faster and potentially even more stable in gigantic levels on DX11.

[MENTION=7886]dsilvers[/MENTION] you should check out the launcher creation tool made by [MENTION=7049]Danny[/MENTION]
Please login to see this link.

Yup, I've had my eye on that one!

Excited to learn more tomorrow!

I just read the blog about child events, and it's very exciting. It's clearly a must-have feature. I can't wait.

But, the interface designer in me sees problems with how it seems to work at the moment, by potentially muddying up the clarity that Clickteam Fusion is famous for. There would be a few ways you could tweak the UI to prevent this, so please consider taking the time to do so.

Here's an example of what I mean. The next 2 screenshots show some regular (non-child) events.

Please login to see this picture.

The 2 above sections are similar, but have different conditions. Now, if we move those conditions into a parent event, the above screenshots look like this:

Please login to see this picture.

The global value = .... conditions have moved off-screen, into a parent event, which introduces some obfuscation into the user experience. When we glance at this section of our events in list mode, we have three problems now, all tightly related:

Problem 1: it is impossible to know by looking at them whether these are child events or not. Sure, they are indented 12px to the right, but that could just be because they're inside a group - we don't know. Besides, our events are already indented several times from being in groups and subgroups, so it's hard to even tell just how many levels of indentations there are.

Problem 2: We can no longer see the whole events, which could lead us to misunderstand how they work. What was once a neat, self-contained event with conditions and actions shown side by side in readable format is now splintered, with 1 condition somewhere off-screen. This wouldn't be a big deal if we knew instantly and unambiguously that we're looking at a child event, but we don't (problem 1)

Problem 3: The two sections of code (ie. the two screenshots) look virtually identical. We could easily mistake one section for another, leading us to erroneously work on the wrong events, creating bugs in our code.

You might say, 'but wait, groups already work just the same way, and no one complains about them. Groups get indented and if a group header goes off the page you don't know whether an event is nested or not'. But the important difference here is that groups can be closed! In fact, you can currently use groups as a kind of 'poor man's child events', as shown below. Here we have a scenario very similar to the above scenario, but using groups. Because groups can be closed, the result is much less ambiguous:

Please login to see this picture.

For all of these problems, the only solution is to be on alert for them, and keep scrolling up and down to check whether the events you are looking at are parented or not. This might sound trivial, but it's not. I want to stress this point, because I really believe it's important. This creates busywork, and also requires you to use more of your working memory while browsing your events:

-you need to keep an event in your memory, while you scroll up to see if it has a parent.
-if it has a parent, you need to commit the parent condition(s) into your working memory, while you scroll down back to the event
-You need to keep that parent condition(s) in working memory the entire time you work on the event, or else scroll back up manually to check for it.

All this extra load on your working memory adds up eventually, and is a tax on the pre-prontal cortex, which is the most neurologically expensive part of our brain, and so is preciously limited. The more stuff we need to keep in our working memory, the less bandwidth our pre-frontal cortex has for problem-solving and focusing, which we obviously need for our eventing.

I don't want to sound overblown with all this pre-frontal cortex stuff, but I think it's really important to point out that one of the reasons Clickteam Fusion is so fantastic and has been so loved for so long is precisely because of how efficiently it lets us manage our pre-frontal cortex resources. We might not think of it in those terms, but that's absolutely what's going on.

People who do syntax-based so-called 'real programming' need to keep masses of information in their working memory: a vocabulary of functions and methods, how to spell them, how to punctuate them, and so on. By giving us a syntax-free programming environment where our available options are shown in neat drop-down menus instead of stored in our working memory, Clickteam Fusion is dramatically cutting down on how much our pre-frontal cortex has to do, which leaves us with more bandwidth to devote to the logic side of it. That's why Fusion is so easy to use for people who feel otherwise intimidated by programming. It requires us to juggle with far fewer balls.

There would be a number of ways you could tweak child events to avoid the problems I'm talking about. A few ideas off the top of my head:

A. color or otherwise mark child events differently (make it skinnable please!)
B. reproduce a reference of the parent conditions (somehow formatted differently than real conditions), either at the top of each child event, or else appearing at the top row whenever the parent disappears off-screen
C. make child events closeable, just like groups are.

My preference would probably be for a combination of A and C

Please login to see this attachment.
I was saying the same thing on Discord [MENTION=15682]Volnaiskra[/MENTION]

Please login to see this attachment.

This is a set of child events to a parent... it is completely obvious that it's nested, even when you don't have a return to previous indentation afterwards:

Please login to see this attachment.

Frankly, if you start colouring things differently rather than just using nesting as Fusion always has, you're breaking with the UI rules we've set out and giving people a whole extra set of rules to learn, which is actually much more of a no-no in HUI/GUI realms. I really don't see the issue here, at all.

Really excited about Fusion 2.5+ release for 31th march! But what about the price? Don't want to see it as a surprise, can't you just speak about it now so we know how much we will spend for this extension?

And to answer [MENTION=15682]Volnaiskra[/MENTION]
You could use groups to group your sub-events When they are too long.
Something that could be useful for you i guess, is to be able to check an option that stick on top the primary event When it has too much sub-events. That could be useful in some case and a problem in others (ex. too much conditions in the primary event).

I agree with [MENTION=15682]Volnaiskra[/MENTION], I had the same impression while reading the blog.
I suggest you make child events at least skinnable, so that a user can customize their look if he wants.

After reading the blog, I think for now I'd like to join the polite voices saying a bit more visibility would be great, at least as an option for the more senior users who might use it. That way newbies wouldn't experience the UI faux pas/confusion that Simon mentioned. A Fusion-esque light blue in that grey margin just to make it pop a little would do wonders for readability. I'll reserve final judgement for when I've had 2.5+ in my hands for a good while, of course.

Readability improvements such as color coding are really a thing. As a side note, I still prefer the old For Each extension over Fusion’s built-in äquivalent, just because the readability is much better when scrolling quickly through huge walls of code.

I don't know how to do it, but some clarity with how child events are presented would be helpful. It looks clean with just simple events, but for sure it can get quite messy at times... have a look at the following; it's a bit hard, for me at least, to pick out which events are at the same "child level" here:

Please login to see this attachment.

an ability to collapse and uncollapse at each level would also be nice.

but hey, all of these discussions are nitpicking really, the feature is already super useful regardless

I do understand the request and I am all for it too.

However, remember, you can nest as deep as you want and you can also group:

Please login to see this attachment.

This allows for collapsing and expanding then (just like nodes):

Please login to see this attachment.

Very exciting stuff! I can't wait to find out the cost for this upgrade. Hope it fits in my budget.

Quote from Danny

I do understand the request and I am all for it too.

However, remember, you can nest as deep as you want and you can also group:

Please login to see this attachment.

This allows for collapsing and expanding then (just like nodes):

Please login to see this attachment.

That's exactly what i was saying in my post, there is enough Tools to clarify our code, we can color comments, collapse groups (and color them). Even if i Don't use any color.. lol

Are variables also fixed in this update, moving/sorting and deleting them?

the subevents are a game changer. Thank you for making this available in f2.5, rather than leaving it promised for 3.

If sales on f2.5+ turn out to be successful, would you consider doing a 2.5++ ?Or even a 2.5+++++?

Why not simply call it 2.6? You got plenty of numbers to 3