Build 295.10 - Release Version

LET Yves finsh and stop the "feature creep" requests. I hope he's ignoring all this for now!

Quote from danjo

LET Yves finsh and stop the "feature creep" requests. I hope he's ignoring all this for now!

Is there an official channel to submit feature requests? I can submit there but am unaware of a preferred place for that.

Feature Suggestion: Child events -> break parent

Hello everybody. Hopefully build 296 will be out soon. I can't wait for it. What do you think? Will the update come out this year?

My thought, as well. What is the hold up?

Let Yves work! It's obvious 296 will be AWESOME!!
Some really cool stuff in there that I like already!

That is good to know. Thank you.

Bug.

Fusion says that altVal names must begin with a letter:

Please login to see this picture.

But sometimes it still lets you begin names with a number:

Please login to see this picture.

Sometimes it does, and sometimes it doesn't, and I'm not entirely sure why. If I try to name an altVal "123" then it will never work. If I try "123dfgdf" then sometimes it does, sometimes it doesn't. It seems more likely to block you if you've already been blocked trying to rename that same altVal, but the same name may work when used on a different altVal. And it seems less likely to block you if you just append numbers to the start of an existing name rather than typing a whole new name with numbers at the front.

I guess this isn't a massive deal, though I did find myself with some altVals starting with numbers that I was under the impression were fine (though which I assume would have broken my code). It's only because I had a nagging feeling that something wasn't right that I tried a few other names and discovered that starting numbers indeed weren't supposed to be allowed.

bug fix, just edit the notice box. names are only affected if you use a reserved name, so it doesnt really matter

Quote from danjo

bug fix, just edit the notice box. names are only affected if you use a reserved name, so it doesnt really matter

Yes, I guess limiting variables now to not use numbers in the first character could cause problems with many MFAs.
I guess internally Fusion doesn't use numbers in the first character of variables and will give them another name, maybe starting with _.

______________________________________________________________________________________________________________

Quote from TonyThunder

When you add a new condition, you have three ways to view the objects.

What is the use of the third view compared to the second?
The icon and text are the same size.

In the third view, there is a lot of space on the right.
So I thought: could the icon and text be made larger in that view?

Please login to see this attachment.

I would like to see better use of the third view in the next build 296 with larger icons and object names.

or that the size of objects in those views could be changed.

its not broken.

For me, the size of the icons and text is ever so slightly larger in the second view. If nothing else, it seems to me that the 3rd view is useful for being able to fully display the name of objects that are incredibly long without needing to manually resize the window. Long object names get cut off in the 2nd view.

Please login to see this attachment.

Quote from Tek

For me, the size of the icons and text is ever so slightly larger in the second view. If nothing else, it seems to me that the 3rd view is useful for being able to fully display the name of objects that are incredibly long without needing to manually resize the window. Long object names get cut off in the 2nd view.

Please login to see this attachment.

Then... An option to be able to modify the size according to the user's preference would be good for everyone.

Feature request:

We should be able to choose all the objects only in a layer we chose.That would be a good flexibility addition for the layer spesific stuffs we wanna make.

Issue report and Feature request:

I was experimenting an active object's width,height and angle with sin and cos calculations,and i found the width and height is changing when the object is turning.it causes problems while using these calculations to move the object.So,something like REAL width and height both the normal and scaled versions of the objects should be added into the CTF itself so we may not struggle while making calculations with the essential object values.

Quote from OyunKaosu

Issue report and Feature request:

I was experimenting an active object's width,height and angle with sin and cos calculations,and i found the width and height is changing when the object is turning.it causes problems while using these calculations to move the object.So,something like REAL width and height both the normal and scaled versions of the objects should be added into the CTF itself so we may not struggle while making calculations with the essential object values.

And what i mean by REAL width and height is width and height values that the're not being affected by the angle change of the objects.

Regarding a possible bug in the Counter object's bar display on Android:
It appears that when the value of (current value − minimum value) * the bar’s pixel size exceeds 2^31,
the bar becomes invisible, and if the value increases further, it begins rendering in the opposite direction.