Build 294.14 - Release version

Quote from endloz

Why is it not possible to opt out of using this new UI engine (for example, some kind of switch in the settings)?

Reason: The entire UI library has been replaced, because the previous one was abandoned by Microsoft decades ago and couldn't be further used because it wasn't flexible enough to add anything new to the interface.
This took over a year for Clickteam to accomplish, to allow dark mode which was a rightly requested feature since forever, and since the new library uses SVG (vector based) icons, the old icons are not compatible.
The UI library in question is a fork of the original library, one that is continuously updated.

But, there is kind of a workaround, which is using a custom skin with a broken setting, forcing it to use the 16bit icons (from before MMF2, something between MMF1.5 and MMF2), I can provide the skin.
One warning is that it causes the close button etc become white on light skin.

Unfortunately the skinning doesn't allow custom icons on toolbars for the moment, but you can use the legacy toolbar customization to make your own icons but limited to a 16 color palette.
Just right click any toolbar icon, choose customize, after it opens a new window, completely ignore that and right click the icon you want to customize from the toolbar itself, then a Button Appearance... option will appear.

Anyway, I'll leave the skin as well if you want to check that.
After copying it to the skins folder, either in Fusion's path or Roaming, you'll need to enable the new Skin toolbar on View menu, and select the custom skin there.

Quote from endloz

I've reinstalled steam and fusion three times, but it doesn't help. All other versions work very well, but version 294 with the damn new UI engine looks really bad. Essentially I have to use a lame product. I know that many scolded fusion for its outdated interface, but I really liked it, it was cozy.
Why is it not possible to opt out of using this new UI engine (for example, some kind of switch in the settings)?

Something in Fusion has obviously broken on your system. Maybe it's because of Wine. When Yves comes back, maybe he can help you.

You can try NaitorStudios' suggestion. Hopefully that will let you replace some of the broken icons. From your screenshot, it looks like some of them are being drawn only partially, while some are being replaced by black blocks, while others are completely missing. That would make Fusion borderline unusable and must be extremely frustrating.

endloz ah, I've missed the part you are using Mac Fusion (which is WINE based).
So I need to ask since I've talked with Yves about this issue before, do you happen to be using an ancient installer instead of downloading it from Community Passport?
For example the installer from Humble Bundle, or one that you have downloaded years ago and still keep it.

Because Yves has tested on his Mac and it worked fine with latest installer... Perhaps some configurations have changed there.
I believe the old installer has issues with SVG images.

you can change your UI if you dont like it. easy.

Anyone else targeting higher refresh rate monitors (higher fps)? I noticed that an active object's animations are not truly frame independent!! As a result, a 4-frame animation at 60fps is noticeably faster than 144, 240+. Regardless of implementing delt time throughout my game, I can't seem to get around this one. It makes targeting higher refresh rate monitors pointless in Fusion (even though Fusion is perfectly capable of running those higher fps). The movements for the built-in movements (except for the pinball movement! it has issues) seem to work as expected. Seems 'timer-bases-movements' don't quite work right in regard to the animations...?

I found this post talking a bit about it: Please login to see this link.

Also, the physics just don't work properly at higher fps when vsync is checked (maybe that's related somehow)! I posted about it here: Please login to see this link.

It's just too bad I upgraded to a 144hz monitor!!! Sometimes I think I was better off being in a 60hz bubble! But displays, from monitors to cell phones, are getting faster and smoother.

(image removed - a better showcase will be back in Build 295 topic)

I had an idea how Clickteam could further enhance the UI appearance in the Toolbars area.
It lead to this result after combining what was definitely good in the UI presentation before Build 294.3 with several adjustments -
including some positioning changes, some bug fixes with too large or missing UI elements and a few design conceptions.
For my montage I recorded some screenshots within Fusion 2.5 using Greenshot (in Windows 11 Pro for Workstations)
and puzzled it together in GIMP version 2.10.34. It shows not all, but a great part of the available Toolbar elements.
What's your opinion (anybody) - do you think this looks worth / better?

Apart from this - could someone explain this behaviour to me?:
I think even in older Fusion 2.5 Builds I noticed that a specific line/divider element pops up exclusively for the Main Toolbar if it's currently the very top row - directly located under the Window title.
With the recent UI adjustments I thought now the main purpose for this horizontal divider is for the accessibility - that it is visually easier to avoid that you accidently open general window options
if you quickly plan to open |View - Toolbars →| per right click. I wonder if it's actually intended to disappear when a different Toolbar block maintains the top position.

I like the idea but I think it should be optional.

I always had the assumption that from the programmer's perspective our treasured animation system is stubborn and inelastic like an old donkey - living in a doghouse.
I seem to remember many requests years ago asking for allegedly simple features, for example a 200 animation playback speed upgrade - or inbetween 0.5 speed steps etc.
A framerate independant option specifically for animations could be a solution. The possibility that even this is not realizable would be no surprise.
One can argue that improvements like this in Fusion 2.5 are not completely unresolvable - at least it seems hopeless to expect improvements anytime soon I guess.
Still - let's hope for the best.
Otherwise I think we can be grateful that suddenly other things began starting to move.
For example I personally hope the final word wasn't already spoken in the Effects resort for other Export Modules, when it comes to Shader code functionality which would normally run in Windows EXE Runtime only.

Quote from Wodjanoi

I always had the assumption that from the programmer's perspective our treasured animation system is stubborn and inelastic like an old donkey - living in a doghouse.
I seem to remember many requests years ago asking for allegedly simple features, for example a 200 animation playback speed upgrade - or inbetween 0.5 speed steps etc.
A framerate independant option specifically for animations could be a solution. The possibility that even this is not realizable would be no surprise.
One can argue that improvements like this in Fusion 2.5 are not completely unresolvable - at least it seems hopeless to expect improvements anytime soon I guess.
Still - let's hope for the best.
Otherwise I think we can be grateful that suddenly other things began starting to move.
For example I personally hope the final word wasn't already spoken in the Effects resort for other Export Modules, when it comes to Shader code functionality which would normally run in Windows EXE Runtime only.

Display More

I just noticed this because I had forgotten that animations below speed 17 will slow down the higher the fps. At some point the animation speed will slow to 0. I had a 4-frame walk cycle animation I was trying to slow down. What I ended up doing was just clone frames. Now it's 8 frames set to speed 25. Looks good at 60, 144, 240fps. Still, it would be nice if Fusion can do this without having me to clone those frames. I understand that perhaps the animation code is old. Perhaps vanilla MMF days. Maybe there's nothing that can be done at this point.

Quote from Wodjanoi

I always had the assumption that from the programmer's perspective our treasured animation system is stubborn and inelastic like an old donkey - living in a doghouse.

My understanding is that it's more like a donkey on a glasshouse: No one's quite sure what it's doing up there, but everyone suspects that disturbing it would probably do more harm than good.

Probably requested a lot of times before, but just to bring it up again in case if possible, can we please have name based values, strings and flags?
I don't know how hard it is to implement into current Fusion, but it would be exteremly useful if possible.
As index based variables can be annoying to work with when implementing generalized systems, one simple example: upon pressing space -> subtract 1 from "health" value of "enemies" qualifier
If some objects under the "enemies" qualifier had there "health" value at a different index, the above event would be modifying a different value at this point...

It can be a different value system added alongside the one we currently have (like how instance value is) maybe even enabled optionally from app properties, and I honestly don't care if name based variables are slower, the added convienince would make it worth it when needed

Quote from Linky

Probably requested a lot of times before, but just to bring it up again in case if possible, can we please have name based values, strings and flags?
I don't know how hard it is to implement into current Fusion, but it would be exteremly useful if possible.
As index based variables can be annoying to work with when implementing generalized systems, one simple example: upon pressing space -> subtract 1 from "health" value of "enemies" qualifier
If some objects under the "enemies" qualifier had there "health" value at a different index, the above event would be modifying a different value at this point...

It can be a different value system added alongside the one we currently have (like how instance value is) maybe even enabled optionally from app properties, and I honestly don't care if name based variables are slower, the added convienince would make it worth it when needed

I'm pretty sure the answer has always been that no, it would be prohibitively difficult to implement.

Over the years, I've learned to try and make a habit of reserving certain altVal slots for situations like this. I keep a list of universal altVals referenced in a spreadsheet and try and stick to that when making a new object, to try and minimise the time I spend painstakingly rearranging objects' altVals (which still does happen more than I'd like :().

Though there's a relatively easy solution for your particular example. Select all of your "enemies" (frame editor>Right-click>Select Object with a given qualifier.....make sure all possible "enemies" exist on this frame), and press the "New" button to add another altVal. The next freely available altVal slot will come up, whether it's Alterable Value AJ or whatever. Whatever it is, if it doesn't say "Undetermined", then it's guaranteed to be free for all of your selected items, so just use that for your "health" altVal from now on. (temporarily name it something like "h_ealth" then use Find All to locate and replace all instances of "health" with the new one)

Another thing you can do is reserve certain very-far-down altVals for certain tasks. For example, I use Alterable Value ID for 'marrying' objects (eg. if I create a turret that belongs to a ship, I set Alterable Value ID of the turret to the Fixed Value of the ship so I can scope the pair later). I also use Alterable Value IN to store Instance Values in some situations. You could, for example, use Alterable Value HE for health, and there are some other potentially meaningful ones, like Alterable Value GO, Alterable Value FX, Alterable Value IS. The benefit of using these sorts of altVals is of course that they are so low down the list that they're very unlikely to conflict with any of your existing named variables. But because they're so low down, you don't want to actually name them (that would require clicking the "New" button hundreds of times), which is why you go for ones that have some inherent meaning in the existing name (ID, IN, GO, FX, IS etc.). When setting, Alterable Value HW onwards are the most convenient because they are instantly visible when you press End in the dropdown.

endloz

Not exactly what you're looking for but this may be of use to you.

There's this thread (Please login to see this link.) where users asked for the nostalgic look of Klik & Play and The Games Factory 1 for build 294. I did my best and made 2 skins; on the 1st page you will find some screenshots and on the 2nd page a ZIP file with the skins. You may want to try them out and see if they make your experience with the new interface a bit to your liking. This is as far as I managed to get as the current skin editor can't edit toolbar icons.

Hope this helps.

Quote from Volnaiskra

I'm pretty sure the answer has always been that no, it would be prohibitively difficult to implement.

Over the years, I've learned to try and make a habit of reserving certain altVal slots for situations like this. I keep a list of universal altVals referenced in a spreadsheet and try and stick to that when making a new object, to try and minimise the time I spend painstakingly rearranging objects' altVals (which still does happen more than I'd like :().

Though there's a relatively easy solution for your particular example. Select all of your "enemies" (frame editor>Right-click>Select Object with a given qualifier.....make sure all possible "enemies" exist on this frame), and press the "New" button to add another altVal. The next freely available altVal slot will come up, whether it's Alterable Value AJ or whatever. Whatever it is, if it doesn't say "Undetermined", then it's guaranteed to be free for all of your selected items, so just use that for your "health" altVal from now on. (temporarily name it something like "h_ealth" then use Find All to locate and replace all instances of "health" with the new one)

Another thing you can do is reserve certain very-far-down altVals for certain tasks. For example, I use Alterable Value ID for 'marrying' objects (eg. if I create a turret that belongs to a ship, I set Alterable Value ID of the turret to the Fixed Value of the ship so I can scope the pair later). I also use Alterable Value IN to store Instance Values in some situations. You could, for example, use Alterable Value HE for health, and there are some other potentially meaningful ones, like Alterable Value GO, Alterable Value FX, Alterable Value IS. The benefit of using these sorts of altVals is of course that they are so low down the list that they're very unlikely to conflict with any of your existing named variables. But because they're so low down, you don't want to actually name them (that would require clicking the "New" button hundreds of times), which is why you go for ones that have some inherent meaning in the existing name (ID, IN, GO, FX, IS etc.). When setting, Alterable Value HW onwards are the most convenient because they are instantly visible when you press End in the dropdown.

Thanks for the suggsitions, I already use some of them, but yea it's the not the most convenient way unfortunely
I started experimenting with a custom way of handeling data types using Arrays\INI, still not the best way, but it's easier and more feasable with the help of a new extension called DarkScript which can run functions with\without parameters even inside expressions, return data, keep object selection, run functions with delay..etc
Example:
Please login to see this picture.

Still not that readable, and I don't think that would work with auto object selection cases "magic scoping", but if name based values will never be implemented, I think this may be one of the best methods to try
Hopefully F3 is not that far away

Yeah, that doesn't look readable at all to me, though I'm terrible at reading syntax. I can tell that it's not complicated, but it still looks like gibberish to me X)

Ultimately, I think the best solution is to just bite the bullet and clean up your objects so that they have consistent altVals. Otherwise you're probably just creating workarounds to make up for disorganisation which may hurt you in other ways in the future. But there would probably be a number of different ways that you could do index-independent variables if you really wanted, though all would probably add some extra complication.

For example, if one enemy's "health" altVal is index 5 and another's is index 19, then at edit-time you could pick an alterable string for each enemy (any alterable string - it wouldn't matter) and set it to "healthV5" and "healthV19". Then, at start of frame, you could do a forEach loop for the enemies, running a fastloop 100 times for each one. In that fastloop, you'd check the first 100 alterable strings, and if the first 7 characters of any of them is "healthV", you would read the number after "V", which would give you the index of that enemies' "health" altVal. You could then then store that somewhere and subsequently use it to set the correct "health" altVal for each enemy.

By the way - just checking that you've seen the Named Variable Object? I think it's basically what you're after - but I think it's Windows-only, which is probably why you're not using it.

There's another extension-less method that I use in my game that I think is relatively neat and convenient. As my game evolved, I had a group of NPC objects that used one system, and a group of enemies that used a different system. Partway through development, I realised that both NPCs and Enemies should be able to use the same easing system to handle things like curved movements (eg. jumps). But the two object types were already full of their own mutually-incompatible altVals. In other words, I was stuck with the sort of problem that you described. My solution was to create a new proxy object that is shared by both NPCs and enemies, and which contains all the required easing altVals in a neat list. Whenever the engine creates an enemy or an NPC it also creates a new proxy object and 'marries' the two. Meanwhile, I now give both NPCs and enemies an additional new qualifier called "EZ easable":

Please login to see this picture.

Then in the Easing section, the code doesn't directly concern itself with enemies or NPCs at all, but deals directly with the proxy objects:

Please login to see this picture.

I find this solution relatively painless. You get to use a brand new object with neatly ordered altVals that are guaranteed to never get out of sync. It doesn't add much complication to your code - you just need to add a condition here or there when you scope an enemy/NPC to scope its proxy object too. And the performance impact is negligible unless you're going to have 10,000 enemies onscreen; it's just a bunch of motionless invisible objects. If your enemies already have 'married' helper objects (eg. collision detectors), you could potentially even just use those.

Quote from Volnaiskra

Yeah, that doesn't look readable at all to me, though I'm terrible at reading syntax. I can tell that it's not complicated, but it still looks like gibberish to me X)

Ultimately, I think the best solution is to just bite the bullet and clean up your objects so that they have consistent altVals. Otherwise you're probably just creating workarounds to make up for disorganisation which may hurt you in other ways in the future. But there would probably be a number of different ways that you could do index-independent variables if you really wanted, though all would probably add some extra complication.

For example, if one enemy's "health" altVal is index 5 and another's is index 19, then at edit-time you could pick an alterable string for each enemy (any alterable string - it wouldn't matter) and set it to "healthV5" and "healthV19". Then, at start of frame, you could do a forEach loop for the enemies, running a fastloop 100 times for each one. In that fastloop, you'd check the first 100 alterable strings, and if the first 7 characters of any of them is "healthV", you would read the number after "V", which would give you the index of that enemies' "health" altVal. You could then then store that somewhere and subsequently use it to set the correct "health" altVal for each enemy.

By the way - just checking that you've seen the Named Variable Object? I think it's basically what you're after - but I think it's Windows-only, which is probably why you're not using it.

---

There's another extension-less method that I use in my game that I think is relatively neat and convenient. As my game evolved, I had a group of NPC objects that used one system, and a group of enemies that used a different system. Partway through development, I realised that both NPCs and Enemies should be able to use the same easing system to handle things like curved movements (eg. jumps). But the two object types were already full of their own mutually-incompatible altVals. In other words, I was stuck with the sort of problem that you described. My solution was to create a new proxy object that is shared by both NPCs and enemies, and which contains all the required easing altVals in a neat list. Whenever the engine creates an enemy or an NPC it also creates a new proxy object and 'marries' the two. Meanwhile, I now give both NPCs and enemies an additional new qualifier called "EZ easable":

Please login to see this picture.

Then in the Easing section, the code doesn't directly concern itself with enemies or NPCs at all, but deals directly with the proxy objects:

Please login to see this picture.

I find this solution relatively painless. You get to use a brand new object with neatly ordered altVals that are guaranteed to never get out of sync. It doesn't add much complication to your code - you just need to add a condition here or there when you scope an enemy/NPC to scope its proxy object too. And the performance impact is negligible unless you're going to have 10,000 enemies onscreen; it's just a bunch of motionless invisible objects. If your enemies already have 'married' helper objects (eg. collision detectors), you could potentially even just use those.

Display More

Thanks for the suggsetions, in case of the named values object I already know about it, there are two main reasons of why I still don't use it yet, one being that it's still Windows only (I heard it will be ported to other runtimes at one point though), second being that it doesn't assign to specific objects it's basically like global data, so for each object to have it's own list of variables I would have to do some linking or having the fixed value of the object in the variable name it self and handle that in events kinda defeating the main purpose...

In case of the seperate object only for storing data linked to the main objects, yeah it's a nice idea and it's the one i'm using right now for some specific cases, it unfortuntely can slow down the app a bit in runtimes like Android with low end devices.
The solution I experiemnted with also works, and a bit faster as it doesn't require object linking or creating more objects, the only problem is it can be hard to read especially if you are not used to it yet, I think mixing methods and using the one best suited for the task would be the best thing for now

Not sure if this has been suggested before but I just had an idea pop into my head. 'Variable descriptions' when you click on them in the properties panel:
Please login to see this attachment.

Would be a nice way to help you remember what does what.

NaitorStudios, Volnaiskra, goldeng - thank for help!

NaitorStudios your "Default Fixed (Old)" skin help me partly. I will try to replace the remaining icons based on your skin.
Please login to see this attachment.

Quote from endloz

NaitorStudios, Volnaiskra, goldeng - thank for help!

NaitorStudios your "Default Fixed (Old)" skin help me partly. I will try to replace the remaining icons based on your skin.
Please login to see this attachment.

The toolbar looks a lot better, but the Properties icons are still very broken. Hopefully this can get fixed eventually

Quote from Volnaiskra

For that, you would have to uninstall 294 and install 293. With Steam, that could be tricky, since Steam automatically updates

Your idea is the best!
I downloaded older version from steam console (find need depot with steamdb). Its make me happy.
Please login to see this attachment.

But now i forced to use offline mode steam. It's so sad...
I hope that in new version will be switch UI between oldest and new views.