Next Fusion update looks amazing

I don't think anyone begrudges them for doing diligent quality control. It's more about anticipating how long that work will take and managing expectations accordingly. Announcing something too soon can come from a place of well-meaning optimism, but ends up fostering impatience and disappointment in people. They've openly admitted to making the same mistake when announcing Fusion 3 features a few years ago. But it's a mistake I do not judge them harshly for at all, as it's an extremely common one, and I've repeatedly made that exact same mistake with the marketing of my own game.

It might have way more features and fixes than originally announced, they could have only showed what was working at the time of the video making..

Quote from Volnaiskra

I don't think anyone begrudges them for doing diligent quality control. It's more about anticipating how long that work will take and managing expectations accordingly. Announcing something too soon can come from a place of well-meaning optimism, but ends up fostering impatience and disappointment in people. They've openly admitted to making the same mistake when announcing Fusion 3 features a few years ago. But it's a mistake I do not judge them harshly for at all, as it's an extremely common one, and I've repeatedly made that exact same mistake with the marketing of my own game.

I fully agree. Well put!

Quote from NaitorStudios

It might have way more features and fixes than originally announced, they could have only showed what was working at the time of the video making..

Probably. They usually fit lots of previously unannounced fixes into even the 'smaller' updates. But a big part of the delay is surely due to how fundamental some of the changes are. When you overhaul something as all-encompassing as the UI or add a feature where one frame can feed off another, it's bound to break lots of stuff. And then you have to fix that stuff one by one, and some of those fixes break other things. And then someone tests it with an unusual resolution or a rare extension, and yet another problem is discovered...etc.

I was thinking the same. That would be nice. Frame Editor performance would be nice.

Dam it... we can't edit post still? I uploaded a file (above) I forgot to delete. LOL. I was going to make a point that for many, 2.5 problems are the interface but for me it's the way we handle instancing / scoping with FastLoops / ForEach. The very fact that Fastloops break scope causes some serious headaches

Quote from Edel

Dam it... we can't edit post still? I uploaded a file (above) I forgot to delete. LOL. I was going to make a point that for many, 2.5 problems are the interface but for me it's the way we handle instancing / scoping with FastLoops / ForEach. The very fact that Fastloops break scope causes some serious headaches

The easiest solution: split event to several child and put fastloop in a separate one. Then nothing will be broken.

Quote from Edel

Dam it... we can't edit post still? I uploaded a file (above) I forgot to delete. LOL. I was going to make a point that for many, 2.5 problems are the interface but for me it's the way we handle instancing / scoping with FastLoops / ForEach. The very fact that Fastloops break scope causes some serious headaches

If you start a fast loop in a child event, scoped objects in the main event will remain in scope for the other child events, I've been using this a lot and it seems to hold true for the most part (there is some limit when scoping gets lost after doing nested for each loops but that's another matter)

Trying to wrap my head around how you go about structuring that? I don't suppose you could whip up a little example MFA?

Quote from SirEatAlot

If you start a fast loop in a child event, scoped objects in the main event will remain in scope for the other child events, I've been using this a lot and it seems to hold true for the most part (there is some limit when scoping gets lost after doing nested for each loops but that's another matter)

I'm trying to wrap my head on how you structure that? I don't suppose you could whip up and example MFA? Still, you will have to use some foreach to sink up colliders, sprites. Creating an enemy using fastloop collision along with all its components can be messy? Unless I'm totally missing a better way of doing things than this example: Please login to see this attachment.

Quote from Edel

I'm trying to wrap my head on how you structure that? I don't suppose you could whip up and example MFA? Still, you will have to use some foreach to sink up colliders, sprites. Creating an enemy using fastloop collision along with all its components can be messy? Unless I'm totally missing a better way of doing things than this example: Please login to see this attachment.

I don't know how exactly it would relate to your movement system, but I think SirEatAlot was just referring to this specific statement you made:

Quote

The very fact that Fastloops break scope causes some serious headaches

If you really want fastloops that don't break scope, putting them inside child events does indeed achieve that. Below is the same basic event, arranged with and without child events. In Fred's case, the fastloop breaks scope. In Barney's case, it doesn't, because of child loops. I personally find that child loops can quickly make the code look cluttered and confusing, but the technique is there if we need it.

Please login to see this picture.

Yes exactly as vol said

Thanks Volnaiskra, SirEatAlot

It's taking forever man.
Watch it as this thread is locked and a new "no asking for 294's release state" rule comes out

I think it might come this week, at very least a beta
(Would be safer than going directly to stable because we don't know if the changes will cause problems on people's games)

Quote from NaitorStudios

I think it might come this week, at very least a beta
(Would be safer than going directly to stable because we don't know if the changes will cause problems on people's games)

Is that a hunch, or did you see Clickteam mention something about it (eg. on Discord)?

I hope it comes soon. My finger's getting sore from refreshing this thread every 2 minutes for the past few months X)

Well, I heard it was in the final steps of polishing it...
There might be other stuff related to other runtimes in the works as well, so that may come either in the first beta or the following ones.

I really wish there was more than 1 instance value. I can think of situations where having more than 1 would be really useful, for example a moving platform storing X and Y speed separately. Currently (and in 294 if there's only a single instance value), you have to have multiple moving platforms with the same graphics and different alt values for each combination of x/y speed you want. If there were multiple instance values (like Instance Value A-Z), you could store it in the instance itself without having to create duplicates.

Another example: Let's say you want to have 2 enemies, one is bigger and stronger, and the other is smaller, but other than the size there's no graphical difference between the two. Why not store in instance values scale, attack power, HP and speed (the smaller enemy would be stronger than the bigger one).

Again, with only a single instance value it's impossible to do any of those, but if there were multiple IVs, it would make things much easier and much more flexible.