@piscesdreams sure, having it would reduce some clicking, but you can create and set position on the same event, and this should work as long you're not creating multiple of the same object on the same event (multiple actions)
If you are creating multiples, you can either separate this on a loop, so each time it runs it creates a instance and set position (separated action) or you can reset scoping after each creation by calling a Fast Loop (this will also clear the selection on the event's conditions so be aware), you can call this loop like "Clear Scoping" and "On loop" you can do something lightweight and that wouldn't do anything in practice, just to clear the scoping, like setting global value A to itself.
E.g., When we need to use values of two instance of one object, we cannot retrieve one's and give it to another directly in one event, temp values are needed: scope the first one, save all needed values, then scope the second one and do calculations. The more values needed, the more complex the code is. If we can retrieve alterable values via fixed value, a lot of works can be saved. (Expression can be like Alterable Value A("Object", >Fixed Value<), as an overload of normal expression. And this not only for alterable values, but also available for other properties like scale and angel)
Another expression that maybe useful is "number of selected objects" in object's count expression popup, and it seems not difficult to add as there is already "oilNumOfSelected" in objInfoList class. Currently we need to run a for-each loop and use a temp value to count the selected objects.
Great suggestion, @defisym !
Getting stuff by the fixed would be pretty cool, along with that, a way to get the fixed value of each instance scoped might also be cool.
So you specify the index of the selected objects and it returns the fixed value of it, this way you could easily compare two instances in a single event!
To not crowd the menus, perhaps these could be two expressions:
New Objects ---> SelectByFixed( > Selection Index <) : When on collide/overlap or conditions that has an order, index would be based on it, when not, would be by order of creation or perhaps Z-Order.
New Objects ---> GetData( > "Value/flag/X/Y/Z-Order/Layer/Scale/string/etc" < , >Fixed Value < ) : GetData$() Could be used to retrieve as a string.
Thank you guys, nice and interesting suggestion. I'll check how this can be done and if there is any possible F3 compatibility issue (important for such a feature).
I don't remember the reasons why expressions were never added to Create Object, but I can take a look
Just a correction:
PickByIndex( > Selection Index <) NOT SelectByFixed( > Selection Index <)
So it would return the fixed value of the instance.
I think it would be a simple but marvelous addition!
There was many times I had to loop through the selection, store the fixed and some other value I wanted to compare and then after the loop compare the both stored, and with the stored fixed I then could pick the instance...
Would eliminate de need of a temp object or variables for this sort of comparison.
And I guess about my GetData() expression, that would probably either require a third parameter, so one can specify the type and the other the index (along with the fixed)
Either this or having it separated: GetValue(), GetString$(), GetFlag()...
In Frame Editor, would it be possible to add a 10% scale or the possibility to choose the scale itself?
I work in high resolution and 25% is a bit restrictive.
margins glitch I've reported before is fixed also. This glitch gets worse the more you zoom out. At 25% it's quite bad; at 10% it would probably be unbearable.
Yes, it's done, the Frame editor will contain more zoom coefficients in a next update (in theory next update but it depends on other changes, so... And this future update will also be HDPI aware, i.e. at zoom 100% the editors won't be scaled by Windows on HDPI monitors).
I'll check the margin glitch, probably it's somewhere in our huge wish list...
About the margin glitch, I think the only glitch is that the window size was not taken into account when you zoom out, which means if you zoom out on a high res monitor you get a smaller margin on the top and left, and larger at the right and bottom, causing frame centering issues when you zoom out to the maximum and then zoom in. This will be fixed. Otherwise the margin is not in "visible" pixels, it's in frame coordinates, I wonder if you confused this from what I read in your other post.
Is new CTF build coming anytime soon?
Getting a change animation issue I posted here. (Since tagging you is too lame for the forums.)
Can we get an condition or expression to get which graphics mode is being used?
Cause there are some shaders that can't be made on DX9, so an alternative shader might be necessary, but I can't identify if it's using DX9 or DX11 during runtime...
Might also be useful for debugging purposes.
is it possible to make it so when you create a new object it has the cursor selected in the "X:" box, or even better if possible to highlight the contents of the "X:" box
as currently wen you make a create new object event you cant press return without having to first click on the create object panel box
& also you would be able to input the coordinates straight away without having to click on the "X:" box
this small change would greatly speed up the workflow of object creation :)
sorry image wasn't cropped X)
Sorry, I might have missed that, thanks for the answer tho!
"Animation is over" condition is not triggered if use the movement type of "Movement extensions(e.g. Vector, Sinple elipse)"
is there a way to get the number value of how many frames an objects current animation sequence has? i can't find it anywhere.
i recall many users asking for this years ago, was it ever added somewhere?
otherwise is it possible to be added, maybe like this :)
Another improvement that could be realy interesting but probably complex to make is a real viewport management in runtime.
This could help a lot to make split screen multiplayer games and even make non-destructive real zoom with simplicity.
Currently making a working split screen for a complex game is a nightmare. I personaly cancelled my multiplayer project because of the complexity to make decent split screen (and also to make network playable game, but this is another subject).
Zoom are also not easy to do. Some effect can be done with shader but with this way, zoom will pixelate content and will won't be usable under 100% level of zoom. Another workarround is to zoom all objects and move them programatically but it's still not alway easy to manage it.
Real viewport can be helpfull for theses kind of usage.
Maybe the more quicker way to allow easy splitgames could be this :
I seen an interesting extention for that named "Viewport" made by Anders Riggelsen (Andos)
But naturaly the object can't display content out of the main windows. I don't know if an option in the frame to "allow rendering of the entire frame" and not just the current windows size could be added and could work with this extention but maybe this kind of option combined with the Viewport extention could open the way to make split screen game if it's work.
Thank you for all !
Allowing the rendering of the entire frame would definitely slow things down...
Cause all this processing would go into the GPU, you seeing it or not.
But perhaps Clickteam could add a margin, something that will still render, but not the entire frame, would make zoom out a whole lot easier.
I honestly would prefer a better control of app resolution through Window Control object.
Currently you cannot toggle "Resize display to fill window size", I even made a small extension for this, but it gets reset on frame switches, like it changes per frame although it's a app property.
So I did a few tests of toggling it and trying to switch the fullscreen app resolution on the go. (all of this to simulate the "Fit inside and adjust window size" from mobile, adding support to different aspect ratios)
"Resize display to fill window size" is important for window mode, so you can resize the window and such without showing more of the frame.
But for Fullscreen you have to do something odd... You have to go windowed, change the window resolution and instantly go back to fullscreen, allowing it to show more or less of the frame depending on your aspect ratio.
Problem is that once you switch frames this is lost, so you have to go windowed again and repeat the process.
If it was just this, it wouldn't be too bad, but there's also another problem...
Within the logic of Window Control object (or some other part of Fusion) something prevents it to set it certain resolutions depending on the default resolution, it just doesn't make sense to me...
You can go lower, you can go higher, but certain resolutions will refuse to work, it reports the resolution you set, but it shows the default resolution or the last one you set before.
So I think this part could be improved, of course I'm talking about a workaround, but the ability to just allow the fullscreen app to automatically resize the window to fill up the black bars would be awesome.
Meaning a game running on a 4:3 monitor could crop the sides or perhaps show more above and bellow (although cropping the sides would be easier to work with)
A game running on 21:9 would resize the window to fill up the sides, showing more of the frame.
The expressions for getting screen edges should also reflect this change so people can anchor UI elements accordingly.
Anyway, I was trying to make a extension that does this, but of course I would need to figure out how to bypass certain limitations, which I'm not sure if it's on Window Control or Fusion itself.
And since my PC burned with the lightning strick I can't do much right now...
Either way, I think the following GIF should illustrate the problem I'm having:
-The margins in the above example are set at x=5000px, y=5000px (the frame dimensions are x=10000px, y=7000px). The tall purple mushrooms are placed at about -5000px, so that they should be about half cut off by the westmost margin.
-At 100%, 200%, 300%, and 400%, the Frame Editor correctly cuts off the frame at -5000px (in the middle of the purple mushrooms).
-At 75% it cuts off at -6667px (I checked it, though didn't show it explicitly in the gif)
-At 50% it cuts off at -10000px (I checked it, though didn't show it explicitly in the gif)
-At 25% it cuts off at -20000px (you can see this in the gif, where I demonstrate that I can scroll much further westwards than the purple mushrooms).
-The same pattern as above happens on the eastern margin too (at 100% the east margin stops correctly at 15000px, at 25% it stops at 30000px)
If my math is correct, that means that with a new zoom level of 10%, the frame editor will now cut off at -50000px, which will make it even harder to find my actual content, as it'll produce 45000px of 'dead space' between the westmost margin and my content (most/all of which will be eastwards of -5000px, since that is the intended margin of my frame, and that is the only area accessible at 100%-400%)
Sure. If you pm or email it I'll check.
Another cases, "Animation is over" condition is not triggered if change animation speed by event."
Animation is Playing Bug.
"Animation is over" condition are triggered with a Vector movement. But, the Bouncing ball and Path movement (and more other movements) aren't triggerd condition (they are triggerd after change animation sequence).
a cool trick is "select all the instances with a same qualifier" but it only selects the assets present in the scene editor, it would take 2 lines: "select the assets of the same qualifier present in the editor" and "select all the assets of the same qualifier" (even those created during the program) as that we could easily add a variable or other to absolutely all the assets of the same qualifier
Even tho it usually works, it causes MFA corruption and BAD objects... It's a unintended behavior, something that people exploit, not a real feature...
Honestly a warning should be added, or people will keep doing this although there are threads talking about how this causes corruption...
Same for setting global mode to "Identical", it's more of a legacy feature and it's known to cause corruption as well.
Load on Call for objects can also cause memory corruption sometimes (graphical artifacts), specially when having many objects with it.
"S’il vous plaît ne me dites pas que vous créez des objets par le biais d’événements puis que vous les supprimez du cadre..."
yes, i didn't know it could be a problem,
i have 30 differents actives with qualifier "good"
15 are displayed on the frame editor and ,15 are not because i create it in the program then i remove it in the frame editor
i want to rename the alterable value A of all the "good" qualifier
i click on "select all actives with the same qualifier" and i rename alterable value A, but only the actives on the frame editor are concerned.
i must put one instance of every actives on the screen. Now i kno than it's preferable to let every actives on the frame editor and unchek "creat at begining"