Build 294.9 - Release candidate

Quote from Fernando

Did you read this document?

Please login to see this link.

I have only read the bottom of Page 7 as you have mentioned before. Ultimately, I have since found a workaround by just grabbing the app's Width vs Height and determining Orientation that way instead.

At the end of the day I just worry the that Object's Help File is somewhat misleading which led to my mild frustration until I found a workaround.

If the Accelerometer object's Help File claims that "It returns values from 0 to 6 :", and it states that it will return a "1" when in Portrait Orientation, the fact that it returns "1" even in Landscape Orientation is a bit strange...

Quote from ASD

Please see this example.

"Would Active at 100,100 overlap Active 2" would increase the counter if Active 2 closing in Active (even if the objects do not overlap each other).
On other hand, "Would Active 2 at 100,100 overlap Active" increases the counter even if Active 2 and Active are far apart.
What's the difference between these?

Please login to see this attachment.

Please see the green and yellow comments in the screenshot below. I've 'translated' the Fusion events into real sentences, to explain what each event is doing. Does this make more sense?

Please login to see this picture.

A typical use-case of this new condition is to make testing multiple collision boxes simpler. For example, here is some code I made last year, without the new feature. The details are unimportant. Basically, it checks whether an enemy is stuck in geometry, and if so, tries to figure out the best way to get it out. In #5153, I first test 1 preliminary collision box, to see if the enemy is stuck. If it is, then I set up 4 more boxes in #5155 to find out which side of the enemy is stuck, and test those 4 new boxes in events #5157 onwards. It's a complicated process, because I have to move lots of boxes around before I can test them. The logic is something like this:

-Move my first box here
-Does the first box overlap?
-It does? OK, then move these other boxes here, there, there, and over there
-Do one of the other boxes overlap?

With the new would <object> overlap at... condition, it could be done a bit more simply, using just one object, because I can test things immediately, without having to move anything first. Most of #5153 & #5155 would no longer be necessary. The logic would be more like this:

-Would my box overlap here?
-What about here, there, there, or over there?

Please login to see this picture.

There has been a problem with Sub Apps, not specific to this build nor even 293.10, basically if a subapp has "Display as sprite" option checked and you resized it on runtime, the rendering breaks (though it doesn't break if you resized it in the frame editor)

Please login to see this attachment.

Quote from Volnaiskra

The Frame Editor has an annoying bug/behaviour recently. I'm not sure if it's since 294.0 or one of the later updates.

If you click on an object to select it, and then quickly move your mouse away (eg. ~0.2 seconds after clicking), then the object is briefly selected for a split-second, but becomes deselected again. To successfully select an object, you have to ensure that your mouse is completely stationary for ~0.5 seconds after clicking. This is especially annoying when you are shift-clicking to select multiple objects. Because you shift-click 19 objects, and then on the 20th object you accidentally move the mouse a little too early, and all 20 objects become unselected, so you need to start over.

To be clear, I'm not talking about accidentally still holding the mouse button down while moving the cursor. I'm talking about a quick, sharp click (LMB down, then LMB up), and afterwards moving the mouse.

I've noticed this too:
Please login to see this picture.

At first I thought it was something to do with tooltips, but the same issue happens with tooltips set to 0, 1, 100 (what I had on originally) and 500
Resetting the context menus (suggested upthread) didn't seem to fix the issue, but I did notice that changing my "Menu Animations" option from 'fade' seemed to have done... something to make the issue less likely to happen? (I changed it to 'none' but even changing it back to 'fade' seems to have had the same effect) but maybe I'm just imagining things

not sure if the gif captures it but there's a slight flicker when it happens too - which made me wonder if it's the same root cause for the issue with F2/Right click rename not working on qualifiers

Quote from bybyblue

I have only read the bottom of Page 7 as you have mentioned before. Ultimately, I have since found a workaround by just grabbing the app's Width vs Height and determining Orientation that way instead.

At the end of the day I just worry the that Object's Help File is somewhat misleading which led to my mild frustration until I found a workaround.

If the Accelerometer object's Help File claims that "It returns values from 0 to 6 :", and it states that it will return a "1" when in Portrait Orientation, the fact that it returns "1" even in Landscape Orientation is a bit strange...

It will return 1 if the device is set in flat surface and was previously in portrait mode or the device is natural portrait (phones).

Also which device is this one you have done the test? What is the orientation set in manifest?

Quote from Fernando

It will return 1 if the device is set in flat surface and was previously in portrait mode or the device is natural portrait (phones).

Also which device is this one you have done the test? What is the orientation set in manifest?

I've been testing this on my OnePlus Nord N200. I've attached an Example file which better illustrates my point.
Example File: Please login to see this attachment.

Current Help File Text: (Confusing and doesn't accurately describe the behavior.)
Please login to see this attachment.

My Proposed Rewrite: (Far more accurate as to what is actually happening when using the Extension.)

[INDENT]Device Orientation
This expression returns the current orientation relative to the device's current Portrait/Landscape State.
A new Orientation can be detected by triggering the "Device Orientation Changed" condition.

It Returns values 0 to 6:

0 Unknown (Should not happen unless you shake the device)
1 Tilted Up
2 Tilted Down
3 Tilted Left
4 Tilted Right
5 Face Up
6 Face Down[/INDENT]

Bug Report Build 294.9
- Some particles cause a crash on Android exported version.
- Particles spread in a weird way after exporting on the iOS version.
- Game Center leaderboards receive a score once every couple of scores.

Quote from marbenx

I've noticed this too:
Please login to see this picture.

At first I thought it was something to do with tooltips, but the same issue happens with tooltips set to 0, 1, 100 (what I had on originally) and 500
Resetting the context menus (suggested upthread) didn't seem to fix the issue, but I did notice that changing my "Menu Animations" option from 'fade' seemed to have done... something to make the issue less likely to happen? (I changed it to 'none' but even changing it back to 'fade' seems to have had the same effect) but maybe I'm just imagining things

not sure if the gif captures it but there's a slight flicker when it happens too - which made me wonder if it's the same root cause for the issue with F2/Right click rename not working on qualifiers

I think it might have something to do with tooltips. I've always had mine at 10ms or so. I just increased it to 555, and it didn't make the problem go away, but did seem to make an improvement (but only after restarting Fusion after changing the setting). I've always used "Menu Animations>None", and I get the problem pretty reliably. Just tried it with "Menu Animations> Default", and it was the same. So I'm not sure if that makes much difference.

Another annoyance with this bug is that you also have to keep very still after double-clicking an active in the Frame Editor. Because if you move the cursor afterwards, it will do a little bait-and-switch where it unselects the object, and then interprets your double-click as being on an empty area. As a result, instead of opening up the Animation Editor, it opens up the "Create new Object" dialog.

Quote

not sure if the gif captures it but there's a slight flicker when it happens too - which made me wonder if it's the same root cause for the issue with F2/Right click rename not working on qualifiers

One thing I noticed about the qualifier editor is that when you right-click, the blue outline disappears from the editor window, as if the focus was stolen by the context menu. Maybe that's why clicking "rename" doesn't work, because at the moment you click it, Fusion doesn't think that the Qualifier editor is active? IIRC something similar was happening with the regular Animation Editor in an earlier beta, when you right-clicked on animation sequence names: the outline of the window would disappear, and stuff wouldn't work correctly.

On a related note, Yves, I just noticed that the Qualifier Editor still has some of the visual redraw glitches that the regular Animation Editor had in earlier betas (eg. resize the window and/or divider and elements disappear and/or are drawn in the wrong spot).

Is there any chance we could get an "ignore spaces" checkbox in Find All (it would make sense to put it with "Match case" and "Match whole text")? In most areas of Fusion, the program mercifully ignores spaces. But in the case of Find All, it doesn't. This can make it tricky to search correctly, especially as Find All is quite particular about spaces in certain results. For example, to find an action relating to a particular object's flag, you must place a space on either side of a colon:

Balloon : Set Flag 1 off

...but to find a condition relating to the same flag, you must place a space only on the right side of the colon:

Balloon: Flag 1 is off

An "ignore spaces" option would save us having to micromanage those spaces to get the search results working. After all, not having to worry about this kind of precision syntax nonsense is exactly why many of us love Fusion so much. ;D

Quote from Volnaiskra

Is there any chance we could get an "ignore spaces" checkbox in Find All (it would make sense to put it with "Match case" and "Match whole text")? In most areas of Fusion, the program mercifully ignores spaces. But in the case of Find All, it doesn't. This can make it tricky to search correctly, especially as Find All is quite particular about spaces in certain results. For example, to find an action relating to a particular object's flag, you must place a space on either side of a colon:

Balloon : Set Flag 1 off

...but to find a condition relating to the same flag, you must place a space only on the right side of the colon:

Balloon: Flag 1 is off

An "ignore spaces" option would save us having to micromanage those spaces to get the search results working. After all, not having to worry about this kind of precision syntax nonsense is exactly why many of us love Fusion so much. ;D

About this, hopes that we can get regular expression support in the future. Shouldn't be hard to implement so.
Another handy feature is auto update, when you edit events after search, and click another item, fusion will still use old one's line & position, instead of update it like other editors. Mainly because fusion does this in main thread instead of something async? IDK, but it's annoying to re-search again and again when re-construct something.

i had an issue that i tried to reproduce but couldnt, so im not sure of the circumstance it triggered; but the basics of it was; (any event) do something with (any object); when i deleted the event - it also deleted the object from the whole frame/project. i undo, and the object came back. i tried something else with the same object.. it left when i deleted the event. so i UNDO again. save my progress. exit and restart, the object is workable normally.
i cant say what triggered this, but it could be very bad if it happens, deletes everything out of their game/program, and they save it like that not knowing it left.

ps; i was able to reload the game back up and work on that object without issue after reload, so its not a corrupted object.. only corrupted under some strange circumstance.

Maybe this is a known issue, but many (most?) extension objects cannot be created with Create Object at... (eg. Ini, Ini++, Internal List, Advanced Menu Object, Joystick 2, File Object). They just don't appear in the list of available objects. It seems that they can be created with Create by name at... (at least the File Object can - I didn't test other ones).

Yves is it possible to make it so you can test for "overlap at" with both the objects,

so instead of just..

would ACTIVE1 at X=400, Y=0 overlap ACTIVE2?

is it possible to have...

would ACTIVE1 at X=400, Y=0 overlap ACTIVE2 at X=200, Y=50?

because currently the "overlap at" still does not fix the overlap issue & i am still unable to do what i need to in my program as shown in this example

...unless i am not using it right and there is a way to do it lol

Quote from Yves

Too late for build 294, maybe we can add a new condition in build 295.

I understand.

but it would be very VERY VERY much appreciated for build 295

(would be an added bonus if it was possible to do X=alterable value A, so each active can be checked at its own position ;))

is it possible to add also being able to retrieve the actual hotspot and actionpoint values that were set in the picture editor?
because when you get the values it currently gives you the actual position of it on the screen.

Quote from SHINBAXTER

is it possible to add also being able to retrieve the actual hotspot and actionpoint values that were set in the picture editor?
because when you get the values it currently gives you the actual position of it on the screen.

You can get object's rect position, minus top left then you can get the relative hotshot position.
However, for extensions, if author forgets to update object rect size then you may get incorrect result.