Suggestion: Changing default properties
So, idk know if this was suggested before, but if not, it would be very useful if we had an option to change the default properties for Application, Frames and Objects
- Applications: I mostly uncheck the menu bars, set the border color to true back, uncheck heading when maximized and enable both "Resize display to fill window size" and "Fit inside(backbars)" options
- Frames: I frequently set the Object count to: 30000 (maximum)
- Objects: mostly change "Inactivate if too far from window" option to No, uncheck "Destroy object if too far from window" and check "Do not reset current frame duration when the animation is modified" options
I don't know if it will be easy to implement for objects however, as different types of objects have different properties from each other, but at least the ability to change them for Active objects would be great
Sub-App "linking" problem and other Suggestions.
I noticed something with Sub-app that kind of breaks this workflow I have. Explaining this will go everywhere, so I'll try to word it right, srry
So I have two MFAs, One is the Main Game and the other is Sub-app. Whatever I do in the Sub-app, the main game needs to have it preloaded. So let's say there's a sound to play in the Sub-app. The Sub-app will work on its own but if it's in the main game, it won't play unless I have the same sound already in the main game. I tried loading the sound by path, it works in the Sub-app MFA but not in the main games... ONLY IF I have something in the selected sound channel in the main MFA. It works fine if you run it in the editor. but if I built it... it won't work. I have to have a dummy item loaded into the mainframe to have it work.
Same for a lot of other stuff. Sounds/Sounds channels, Fonts, (extensions If the main game is in Unpacked mode),etc.
More things I ran into and Suggestions:
- Having the Machine independent ticked in Sub-app and the main game has a double effect which drops fps. with V-Sync on, both makes the fps worse.
- Actives with the Global Object ticked that's in the main game frame do not work with Sub-app that also have the same object/settings ticked. From what I have tested.
- Sub-app display as sprite should be renamed to "DX9 Fullscreen Mode" ex; previous conversation I had with Yves, You mentioned it was for the DX9 Fullscreen. I feel like if it was renamed it would lower confusion newbies.
- An option to have the Sub-app size scale with the root app size/ size the sub-app object is in. ex; Resize to root app display
- Have Sub-Apps act as a sprite. ex; previous conversation I had with Yves x2, as stated that something like this is on the wishlist, Hope that entry is high on there lol. so many useful workflows can be done if it was possible.
Besides Sub-app stuff there is a bit of DX11 stuff I like to see be updated, if possible.
- Depth buffer
- Texture Lods
- Vertex Shaders
- Font Anti-Aliasing toggle
- Font external importing
- Ability to use the bounding box on strings for Shaders/effects instead of text itself. ex; found some fonts has noticeable clipping with some effects.
- more Shader uniforms for xml. ex; vector2,vector3,better RGBA color input. maybe ability to get output of some values back?
- !if Possible! The ability to take layers into some sampler for Shaders to use. be nice to have layers as passes for some Shaders
Anyway that is my suggestions and problems I noticed on Sub-App. My thought is: Was Sub-apps designed to only work with frames on the same MFA instead of a different MFA?
I feel like if they where updated or some new option to have frames as file/ new frame object. It could open so many new paths to do in CTF.
New properties option suggestion
Could it please be added on the next update a option to accept loading a incompatible .mfs (save frame position), removing the warning if checked.
I know this was probably added to avoid loading a incompatible file and getting a crash, but seems like incompatible mfs may work without a problem sometimes but the warning appears and it quickly restore the previous state.
Just add on the description of the toggle that it may cause a crash on the app if the app was heavily modified.
Honestly I think that warning shouldn't be there, since we already can set a version number, so the version number could be used alternatively to prevent loading a file that the dev is sure that will cause a problem.
For example, the game relies on mfs to save states, the dev makes a update and test loading the previous mfs, it works without any problem, so it's safe.
If for some reason a update makes these incompatible on the testing, the dev just increment the version number to avoid loading mfs from the previous update.
Seems like a pretty simple change, you just have to add a toggle that bypass the warning and give the usual routine of loading a mfs file.