Build 293.10 - Release version

There's an annoying issue on SteamWorks extension that I hope can get fixed on the next update...

It pairs the overlay to the EditWindow, this means extensions that manipulate the EditWindow (like Ultimate Fullscreen object) will result in a stretched, cropped off-screen overlay.
I was hoping the overlay could be changed to pair with the MainWindow if possible (as long it can display above the EditWindow) or maybe it would be necessary to create a new Window above the EditWindow were the overlay would show, the same size and position as the MainWindow.

It's one of the reasons people have stopped using Ultimate Fullscreen, which is really important to get pixel perfect resolutions in fullscreen.
I'm making a unofficial update for Ultimate Fullscreen, I was looking for a way to fix the Steam Overlay myself but I can't figure out how to do it, maybe it can only be done from the SteamWorks extension.

Quote

Please login to see this picture.

Quote from Dobermann

I think it's because the groups is put into comments, like in real code, so it's like there is no group here. Only way to deactivate a group once for all is to set it to "deactivate" in code or at start.

Then perhaps the best solution would be to disallow reactivating any event that's inside a deactivated group, by greying out "activate/deactivate line" in the right-click menu. Because as far as I can tell, reactivating such an event is completely useless. If you want the event to run, you still have to reactivate its parent group, which will automatically reactivate all events in that group anyway. So manually reactivating a single event inside a deactivated group achieves nothing, other than being potentially misleading.

Ugh. I bamboozled myself, and what I said above was completely wrong. I wish they gave us back the ability to edit posts D:<

Another potential complication from this issue (reactivating an event that is inside an already deactivated group) is that if you reactivate a child event, but its parent event is still inactive, it 'orphans' the child event. In the below example, the "immune" flag condition from event #655 is no longer checked (ie. event #656 runs even if the immune flag is on):

Please login to see this picture.

Yves: To recreate this problem, you need to select the event first. If you try and reactivate such an event when it's unselected, you won't be able to because the option is greyed out:

Please login to see this picture.

I guess that's probably because you already foresaw this issue and disabled the option to reactivate these events. But if you click to select the event first, you get a different context menu that still lets you reactivate:

Please login to see this picture.

If anyone from CT reads this, please consider adding value Index in front of Values names. (PROPERTIES of the active object).

Global value already shows the number of Indexes before the name of value. However Active objects (frame editor - properties) are missing this. This would be a helpful feature.

Adding to the post above, different from how Global Values/Strings currently is, would be better if it was something like:
0 - Named variable
1 - Alterable Value B
Instead of:
0 (Named Variable)
1 (Global Value B)

Would look a lot cleaner... And I hope to see Global Flags one day, if this is not possible on 2.5, well, at least I'm sure it will be on F3.

Actually, that ( - ) pun can be confusing, I'd avoid that. @Naitor

I particularly don't agree because you can't use - on the names anyway...
But it doesn't look good wrapped by ()...
Alternatively, a separated column with just the index might look better.

Window Control's Attach to Desktop action don't work (at least on Windows 10 / 11 and maybe 8 as well)
It just makes the application window disappear completely, I tested it on Windows 7 and it worked fine

I don't know if it's related to a Windows API that doesn't work anymore but it would be really useful if it can be fixed
This can allow making desktop widgets and such, which is something I have wanted to do for a long time

In Layer Object when you select Sort by Y decrease, would be possible to add the possibility to specify which group (or object ) you want to sort?
For example
Sort > By Y (Decreasing) > Group.1

it is possible to copy paste an animation from one asset to another which is very convenient. unless I am mistaken, it is not possible to select several animations to paste them all into another asset, and yet it would be very convenient! maybe it is easily implantable?

il est possible de copier coller une animation d'un actif vers l'autre ce qui est tres pratique. sauf erreur de ma part il n'est pas possible de selectionner plusieurs animations pour toute les coller dans un autre actif, et pourtant ce serait tres pratique! peut être est ce facilement implantable?

There's a glitch that happens when the Layers Toolbar is docked and folded on the side of the screen while using a non-maximised Frame Editor window. When you're dragging an active object on the Frame Editor, the Layers toolbar seems to mistake the edge of the Frame Editor for the edge of the main Fusion window, and automatically unfolds whenever the active object happens to touch the edge of the Frame Editor. This can be a bit laggy and distracting, but the main problem is that it prevents the Frame Editor from scrolling when this happens (and since you dragged an active object to the edge, scrolling the Frame Editor is probably what you were trying to do).

This glitch happens on both left and right sides (ie. if you dock the Layers Toolbar on the left, then it'll also unfold if you drag an active object to the left side of the Frame Editor window)

Please login to see this picture.

Maybe I am not understanding exactly what you meant here. Way I see it working is the layers toolbar opens so you can drag the active object out of the frame editor and onto the layer you want it on. That makes sense to me how I work with Fusion. Not sure how or why you want to scroll the frame editor if you are already dragging an object.

Quote from c4t

Maybe I am not understanding exactly what you meant here. Way I see it working is the layers toolbar opens so you can drag the active object out of the frame editor and onto the layer you want it on.

That should only happen if you drag onto (or near) the Layers Toolbar. It makes little sense for it to happen when you drag onto a spot 1000 pixels away from it (as in the example pictured)

Quote

Not sure how or why you want to scroll the frame editor if you are already dragging an object.

Really? This is a really common behaviour, not just in Fusion, but in most programs. Once you drag an object to the edge of a window, the program recognises that you want to drag it somewhere beyond the current bounds of the frame, so it scrolls the view to let reach previously obscured locations. Basically all programs do this, whether it's dragging an active object in Fusion, a file in Explorer, selected text in Notepad++, or a highlighted row in Excel. You probably use this technique yourself without thinking about it; it's hard to move things long distances without it.

The scrolling thing i thought you meant scroll it by using the scroll bar as you highlighted that in your pic.
Dragging an active near the edge of frame window does scroll the frame area on my system. When I drag it past the frame window scroll bar the layers toolbar opens.

There's a certain spot at the edge of the frame window where it triggers. If you go past it (into an empty area of the main Fusion window) and wait a few seconds, the layers toolbar will fold again. Then if you move the cursor (still dragging the active object) back into the frame editor, the layers toolbar will unfold again as you hit the edge of the frame editor window on your way back in. At least that's how it works on my pc.

I have a high DPI laptop screeen and I see this but perhaps not as severe in my case. Dragging to a point very close to the edge the layers panel looks like it shimmers in and out very so slightly, drag a bit closer (a couple of pixels) and I get the frame scrolling while the layers panel continues to shimmer, a bit closer still and it pops open properly. At this point I can drop the active on to a new layer but can't push scroll the screen while the layers panel is open.

I guess you'd be looking for a change to prevent the layers panel opening unless you drag the mouse out of the frame and into the layers toolbar tab?

Guys, you do realize that the next update will completely replace the API used for the graphical interface and be DPI aware, meaning these issues will probably not be present there, right?

It works ok for me how it is. I guess if you wait around outside the frame window with your assets until the layers toolbar closes again that's different. Personally I never really do that, I just drag stuff over to the layers toolbar and when your over there it stays open. Maybe a bit of extra time could be added to the layer toolbar before it auto closes. Don't think having to drag the assets to the layers toolbar tab to open it is a good idea. Its good being able to just drag the assets to the required layer how it is now.
Seems like its different for others Im running fusion at 3440X1440 and it works ok for me.

Looking forward to the update too. Be interesting to see how it changes things on high dpi monitors.

Quote from c4t

It works ok for me how it is. I guess if you wait around outside the frame window with your assets until the layers toolbar closes again that's different. Personally I never really do that, I just drag stuff over to the layers toolbar and when your over there it stays open. Maybe a bit of extra time could be added to the layer toolbar before it auto closes...

It's not about that. It's about two unrelated functions (A: scrolling the work area | B: opening the Layers toolbar) interfering with each other. To do A, you need to move very close to the edge of the window. But if you go too close by just a few pixels, it suddenly triggers B and aborts A, which is annoying.

If your Layer Toolbar is right next to the Frame Editor window anyway, then it may not be a problem. But look at my setup below. I have two Frame Editor windows on two monitors. My Layers Toolbar is docked on the far edge of the right screen (green bar). Yet I keep accidentally triggering it when I'm dragging an Active Object to the pink area. Not only does this annoyingly abort the scrolling, but it's pretty illogical, because the pink and green areas are almost half a metre apart X). I appreciate the benefit of the toolbar opening early so that it's ready to drag an item onto it by the time you get there. But it shouldn't open that early. Especially not if, as I said above, the trigger for it is going to be so close to - and will interfere with - the trigger for an entirely unrelated function.

Hopefully NaitorStudios is right, and this problem will go away with the new version, though I guess that mainly depends on whether Clickteam choose to use the same logic or not when programming this new API.

Please login to see this picture.