Don't have an account yet? Then register once and completely free of charge and use our wide range of topics, features and great options. As a registered member on our site, you can use all functions to actively participate in community life. Write posts, open topics, upload your pictures, put your videos online, talk to other members and help us to constantly improve our project and grow together! So, what are you waiting for? Become a part of us today!
Login or registerTo get support for a technical issue such as installing the software, to query a purchase that you've made/would like to make, or anything other than using our software, please visit our Customer Service Desk:
Open a TicketWhat does the "MAX_SIMUL_SOUND" property do in Android runtime?
Unknown property is a common error. I assume you have already checked if any outdated extensions are possibly causing this?
Wait for Fernando's return in any case, but perhaps you could track down by yourself what's causing this exactly and eventually prepare an example file.
I know event 1698 is incorrect, i'm very aware of this, but i'm not imagining things and it used to work in 294.14
Thing is, one of the games I worked on that is now in production, and I made this silly mistake where I genuiniley forgot to add a slash there, sometimes i'm too used to do AppPath$ + "xxx" without slashes, that I did the same thing with DataStorage for android,
and because it awlays worked I never noticed such problem until it was late and the game was already in production.So if this can at least behave like how it was so I can at least be able to update the app to convert old saves from the incorrect path to the correct one would be very appreciated, or users will lose there progress...
I see. Sorry, I was editing my post one more time while you was posting your last answer here:
So, you are sure that you didn't wrote "/directorypath/" + "File.ext" before instead of "/directorypath" + "File.ext"?
Basically if I don't add a forward slash here to the path, it doesn't work anymore, but it used to work in earlier versions.
Please login to see this picture.
The forward slash was definitly required before. There should be everything ok here and nothing has probably changed.
Are you imagining things, Linky? 
Perhaps you wrote in the past "/directorypath/" + "File.ext" instead of "/directorypath" + "/File.ext"
- what you have in your image at the top ("/folder" + "File.ext") would be not correct.
On my system there is no difference between an empty example project and your test example.
If you mean another issue - I actually don't see it and I can only confirm that I don't notice a problem with Windows Shape object.
Wodjanoi, I'm not saying that this is precisely because of Windows 11, but just in case, I clarify.
Yes. Moreover, in the example that I attached to the post, there is nothing else that can cause a drop in frame rate.
I mentioned this for the same reason as you - I clarified that I was testing your example on Windows 11.
Actually I thought you mean that the FPS go down and fluctuate, when you hold left mouse button on the heading Window or you click on the top area of Debugger repeatedly:
This behaviour was never a problem for me personally, because I normally don't enable the Heading style for my applications and instead a custom solution to move the window could be can be implemented to avoid this type of FPS fluctuation.
Yves - I assume you know the exact reason why this behaviour happens in Windows? I thought this is more or less intended/necessary behaviour.
Are you sure there is a decrease of performance noticable that is directly related to Windows Shape object?
I didn't notice what you describe on Windows 11 so far and switching between Direct3D or Standard shows no difference for me.
Actually I thought constant fps fluctuation is always happening whenever you move any application window or Fusion 2.5 debugger around.
(issue found and reported by a user in the Steam forum - 25/07/2023)
Small bug - could you check if this is a problem in the current Beta Build?:
In the Frame Editor's CTRL + J window, the vertical movement of the list does not trigger, when you directly drag the larger handle.
If this wasn't fixed yet, could you possibly fix this directly in one of the next Beta releases of Build 295 version? Thanks in advance.
Yves, could you possibly provide some feedback - especially for [1] [2] [3]? Thanks.
The tweaks with appearance/positions & small fixes I suggested for the User Interface Elements of Fusion 2.5 - is this something you will tackle in the future?
I noticed everything is a bit untidy now in comparison to before Build 294 and a few minor UI related issues should be eventually repaired.
[1]
I suggested 2 ideas of an improved version - everything is explained with footage on page 3 in the Build 295 Beta discussion:
The improved Version A(my image with the violet text), could in theory allow to additionally bring back the vertical and horizontal separation lines which we know from previous Builds
as an option for a second Version B(my image with the blue text). We should be able to switch between both versions - perhaps a restart of Fusion 2.5 would be required.
Some people mentioned, they desperately want these special separation lines back for accessibility reasons and are not updating Fusion 2.5 further, because these design elements are no longer available now.
[2]
At the same place I asked, if there is something wrong with a specific behaviour of very first line/divider element directly under the Window title.
[3]
And one important feature request I had - better explained here again:
Could you realise an individual on/off property for Effects -at least for each Active object instance with an Effect- to maximally influence one more Layer below?
- as an option to avoid the situation to visually affect a lot more layers although it's not necessary
- or if you want an effect isolated explicitely only for the next Layer below
For each different Active in the Frame -this could be very useful to have at least for Effects applied on Active objects-,
I imagine there would be a Property available that we could turn ON/OFF and ON causes the Effect of an Active on current layer
to only maximally affect the next lower layer directly under it - skip all the other layers further below.
This special feature should support mobile Runtime as well.
These are other weird little issues I found (currently I tested those only with Build 294.14):
4)
A small fix suggestion for Object lists window that I didn't mention yet:
All the different Object symbols start at the first line 1 px to early (y position where the first row of object symbols begins).
I noticed this, because the Mouse Over selection box(I use yellow box borders) is cut at the top by 1 px.
5)
various issues in Storyboard Editor with Skin font adjustments:
- it seems specific fonts, for example these fonts: Sylfaen / System / Courier New
could trigger that the "Password:" option disappears completely (at the location where you also see: No. | Thumbnail | Comments)
Perhaps you can replicate it:
Open Fusion 2.5, CTRL + N, click on 1(No. 1), run Skin Editor toolbar, here under Storyboard editor change the Font name to Sylfaen or System for example, then CTRL + B
- and what's also strange behaviour in this context, when you are already in Storyboard editor, different things will unexpectedly happen when you press CTRL + B again:
For example set Font name "System"(enter) and then set it to "Sylfaen"(enter), press CTRL + B, then set to Tahoma(enter), press CTRL + B
- second problem, example: Font names Consolas / Courier / Courier New / Verdana / System / FixedSys:
The word "Password" often moves too far to the left side with many fonts.
Perhaps this area could be generally improved like this: Rename "Password :" to the shorter "Pw. :" and then align the 2 text lines
in a way that the center of both lines is always at the x position where the "fade out transition icon box" ends
6)
- also at the same place - Frame size width/height input boxes look a bit strange with higher numbers for most Font names.
Perhaps there is a way to correctly display at least "xxxxxx by xxxxxx" - and not only "xxxx by xxxx" with smaller fonts in most cases.
-the dimensions of these input boxes are also weird (somehow they are too large and any numbers you type into those are only partly visible)
Can you make audio frequency support on android?
The audio frequency event just doesn't work on android
It does work for me, tested on Windows, Android and iOS, so I presume it works on all runtimes
You sure that you selected the correct channel that the sample was actually playing in?
Well, if it wasn't a coding related mistake, I could perhaps imagine that AzazelGames tested set frequency with sample files, but you tested it via play sample/sample on channel, Linky.
There is a bit of a difference how this works technically behind the scenes with mediaplayer involved for Android.
Set frequency while playing sample files on the device - this was actually never supported and there were no changelogs released so far that told something else, I believe. I think, in this context the last information was:
There is no good solution ready yet, which could effectively perform on all devices.
If this specific set frequency support request for sample files can't be realized soon - for now I could only suggest to use any larger music tracks to play as sample files and always use the play sample option for all sounds or ambient audio effects, as long as you also need these for frequency changes at Runtime.
I can confirm the global improvement on my Android project with this beta! I don't know if it is only due to the sound engine improvement but the framerate is definitively better with this build!
It's great that performance has increased even further. 
Actually this information is available in the Changelog, I guess - here:
- All runtimes: optimizations (note: some of these optimizations are part of the Optimize Events)
Here is the sound file :
It is a 4kB wav file of 0,15s of duration.
What is surprising is that this is not the longest/biggest sound file in my game.
This is an easy fix! - Add a short fade to silence to the end in the WAV for flawless playing quick transitions.
It seems that the lags that were occuring very frequently when sounds were played are just gone.
Did you change the way sounds are played on Android ?
Yes! Fernando finally fixed it! I've made a lot of tests to help. Surprisingly, the issue of sounds being cut was fixed in the last beta I had to test before b295.x was released to public.
Dobermann - are your overall Android issue reports in the history of Android Export module also
over 20 meters long when you scroll downwards? XD
So you both noticed performance improvements with audio playback?
Yes! Fernando finally fixed it! - is this a confirmation actually?
Do you assume this, Dobermann or do you know this with certainty, because Mr. V did confirm it actually?
Or do you refer to something else completely with your enthusiastic exclamation above ?
Sorry for the confusion, I simply wonder why an adjustment like this wasn't already listed in the Changelog.
I have noticed that some sounds seem "cut" (they stop before the end) when the same sound is quickly played multiple times (in my case it is in a menu where you push a button to scroll through items : the sound played when you push the button is sometimes cut if you quickly push the button multiple times).
About the audio "cut" behaviour - it's most likely your sound files which could be optimized. That's what I mentioned as a possible problem cause in my direct message to you yesterday - or I could imagine something is conflicting with playback/channels or the way button interaction works could be optimized slightly eventually.
My own extensive Android test session is probably going to start today and I have a lot of test examples to go through, which I especially created to check if any old issues that were already fixed in the past(mostly layer issues, multi-touch behaviour, audio related issues, specific hard to discover floating point miscalculations and so on). I definitely need to try Build 295. with my untested Android 13 devices before final release too.
I'm happy to take a look at this potential issue as well during my tests (as I mentioned in my PM yesterday).
..... Would you be so kind to send me a test .mfa template that is showing the button tap sound "cut" behaviour you mentioned?
Please login to see this picture.
Please login to see this picture.
Please login to see this picture.
Display More
I would like to demonstrate some fix suggestions for certain Editor Ui elements.
Actually it was super fiddly to adjust this - some elements are obviously left which I didn't cover though in my above example footage,
but you would get the idea what I mean and what looks wrong there in theory.
I thought, if Clickteam would like wish to fix this, these image presets I prepared could save you a bit of time and are at least partly helpful.
Most Ui elements -including the interactive boxes and text inside these boxes and I also noticed a possibly strange behaviour with a specific line separator element -,
are not too tidy anymore in comparison to the older design - could it be that Clickteam was a bit rushy with the Ui elements for the new design because it's a super fiddly piece of work? ;D
Additionally I noticed complaints of people about a specific design idea that was removed and I thought, why not ask to bring this back eventually as an option, instead of complaining.
I mean these people refused to upgrade to Build 294 and missed all the great new features. I thought - really, because of this, ok!? (Footage is right above)
Please login to see this picture.
It's not clear to me why this very first line/divider element directly under the Window title - only pops up for the Main Toolbar if it's currently the very top row?
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 the general window options(of Windows) if you quickly plan to open |View - Toolbars →| per right click.
In this case it's a bit strange that this divider element disappears when a different Toolbar row maintains the top position, isn't it?
About feature request - New Layer related mechanic - On/off option for Effects applied to Active objects:
"For Active objects only - Allow Effect until next lower layer, hide the Effect on any layers further below"
My revamped explanation -my 1st post on this topic's page 2- could perhaps explain it well enough.
Do you mean a way to disable the effect in the editor only for each object?
Whenever page 3 opens - I would soon start to show some fix suggestions for certain Editor Ui elements.
Actually it was super fiddly to adjust this - some elements are obviously left which I didn't cover though in my example footage,
but you would get the idea what I mean and what looks wrong there in theory.
I thought, if Clickteam would like wish to fix this, these image presets I prepared could save you a bit of time and are at least partly helpful.
Most Ui elements -including the interactive boxes and text inside these boxes (and I also noticed a possibly strange behaviour with a specific line separator element)-,
are not too tidy anymore in comparison to the older design - could it be that Clickteam was a bit rushy with the Ui elements for the new design because it's a super fiddly piece of work? ;D
Additionally I noticed complaints of people about a specific design idea that was removed and I thought, why not ask to bring this back eventually as an option, instead of complaining.
I mean these people refused to upgrade to Build 294 and missed all the great new features. I thought - really, because of this, ok!? More about this soon.
(is this Feature idea realisable?)
An individual on/off property for each object instance with an Effect to maximally influence one more Layer below?
- as an option to avoid the situation to visually affect a lot more layers although it's not necessary
- or if you want an effect isolated explicitely only for the next Layer below
Do you mean a way to disable the effect in the editor only for each object?
I mean, there is generally no way to control this in the shader code itself, right?:
For each different Active in the Frame -this could be very useful to have at least for Effects applied on Active objects-,
I imagine there would be a property available that we could turn on/off and on will cause the Effect of an Active on current layer to
only maximally affect the next lower layer directly under it - skip all the other layers further below.¹
This special feature should support mobile Runtime as well.
Is this feature realisable at all? I really hope for it, because this is definitely something I would like to see, if there are no effective
alternate methods available to solve something like this. An example situation with some illumination effect:
You have your Background graphics on a Layer, then you could have a player character isolated alone on the next top layer
+ one layer higher the Effect that makes the character shine(after if he walked to the Effect location).
The layer with the Background graphics is not affected by the effect shine at all though.
Thanks for this small update asap.
Update: Compare Alterable String is broken in some cases in this version, I'll post an update asap.
Wow, this happened earlier than expected -
and I bet further improvements in this departement are already planned:
Background shaders now working, more shader support capabilities - there is even an example included for the people
that directly explains how the handle the OpenGL Y-axis flip behaviour - Nice support !
- also this specific sleep mode on and
multiple touch stop issue behaviour was something I personally discovered as a problem for quite some time now
- Mac Xcode project issue solved, caused by spaces in names of extensions
Issue noticed and steps for elimination directly suggested by Phi << thanks
- it was long awaited and finally it's there:
"Windows-like collisions on other platforms"
Two years ago I put my work for one Android game project on hold, because there was no good workaround to solve
a specific custom collision issue for an important mechanic in the game - now my ideas can work properly.
- all of this is definitely coming handy as well:
Support for Numeric Value calculation in expressions
+ new "Fixed Value of last created object" expression
+ "Don't include at build time" option for Objects
+ Preload is preserved for sound replacements in Data Elements editor
- for Windows Runtime: the better font for customized menus is a nice-to-have
- the Clickteam Fusion 2.5 Developer exclusive option for Android to
directly generate an Android Studio project is a very useful shortcut
+ Java 11 is now officially supported
+ the new Android display cutouts functionality could be amazing
Great stuff.
This was my personal reaction on only a few of the available highlights.
Hats off, Clickteam!
+ Feature Request
Could you technically realise an individual on/off property for each object instance with an Effect to maximally influence
one more Layer below - as an option to avoid the situation to visually affect a lot more layers although it's not necessary
or if you want an effect isolated explicitely only for the next Layer below ?
If you run into this problem very often when you work with Fusion 2.5, you should first test for a
while if you notice a difference after you defined a custom path for the temporary files in the first
Preferences tab - for example use a folder on an external drive that is always connected to your machine.
If the issue would be gone after this, it could be a sign that something is specifically messing with your temporary resources on the main system partition.
I watched the build 295 preview video. All of the fixes are interesting! I can't wait!
Yeah, this latest Preview Video for the upcoming Build 295 release was a nice surprise again.
As usual the Clickteam developers introduced many important and useful fixes and
at the same time they installed diverse cool and helpful new features.
Would it make sense to integrate a new default parameter row under 'Effects' in Display/layer options -always available for any effect instance- with the purpose to initially define by layer indices to exclude other layers completely
from being touched by changes of the effect instance + ways to control this per event in Active object and Layer object with "Effect - Exclude Layer(s)" and an additional command to undo effect immunity via expression?
If this idea causes too much hassle:
What do you think about the alternate wish to realise the existence of a toggle switch for any effect instance to maximally influence one more Layer below, as an option - to avoid the situation to affect a lot more layers, if
this isn't necessary - or if you want an effect isolated explicitely only for the next Layer below?
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.
(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.
Please login to see this picture.
UI - design questions / request
1)
Generally it's not clear to me why this very first line/divider element directly under the Window title(see above screenshot: fuchsia color) - only pops up for the Main Toolbar if it's currently the very top row?
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 the general window options if you quickly plan to open |View - Toolbars →| per right click.
In this case it's a bit strange that this divider element disappears when a different Toolbar row maintains the top position, isn't it?
2)
I think it's a regress that "Toolbar blocks" are now visually separated from each other only by the "move around/detach handle".
If it's no diffcult task - could you eventually bring back the horizontal(Toolbar block's lower edge) + vertical(Toolbar block's right end) divider elements from before?
I noticed 1-2 reports of other people who can't cope with this specific change in the UI design and for one person it was the only reason to completely stay away from Build 294.3+
Why do you have actually taken this design decision I wonder? One logical reason I see could be to better show that vertical position adjustments of movable Toolbar elements/rows are allowed.
It doesn't appear of such importance to suspend the previous divider behaviour in consequence though.
Almightyzentaco (Fusion 2.5 Tutorials)
Captain Quail (Firefly Tutorials)
