First of all thanks for making this excellent product and for providing such comprehensive documentation too. One of the best assets on the marketplace IMO.
Unfortunately I have a major issue in 4.11: Play-In-Editor takes 10-15 seconds longer to load because Unreal auto-recompiles all your blueprints every single time PIE launches (log attached). What’s more, all these blueprints are auto-tagged as “modified” so a huge list of unsaved files builds up (screenshot attached). To reproduce, create a new 4.11 project with QualitySettings 1.5.2 (or 1.5.1) and hit Play.
While 4.12 doesn’t exhibit this issue, I’d prefer to stay on 4.11 if possible because my game is near release and as we all know (or will eventually learn!), migrating from a stable build without good reason is ill-advised; what with new versions often containing very subtle bugs that don’t become apparent until much much later, etc.
In any case, thanks a lot for your feature-rich product, I look forward to using it
Hi, i keep getting this warnings even on fresh new project created. at first i thought it was from the Macros (on the makeArray0-11) but i tested adding a new pin and the warning stayed at -1/11] (when it should have raised to /12) so i guess thats not it. do you have any clue what is it? it doesnt make any impact on the game (i think) but it shows up every time i play on editor. settings are saved properly.
forgot to say, im on 4.12.4 and have been experiencing this since 4.12.1 (even 4.11 i think)
First off, this menu is amazing. I’ve been using it since day one and just recently updated to 1.5.1 for the key rebinds. The only problem I’m having is when I click on of the keys to rebind I get “Err: QualityMenu is missing Action Manager. Cannor Remap Keys”. I’ve tried to troubleshoot this on my own but kind find where in the blueprints this error is being printed from. I followed the setup documentation and set an action manager with the update keybinds in my player pawn. I didn’t see anywhere that I shoud somehow add an action manager to the UMG although that’s what the error implies. Thanks for the help and once again, this menu is awesome.
Thank you, this issue was an oddity that appeared with 4.11. I finally found out that the 4.11 engine simply dont like any references to my game settings interface.
For example, this node with a yellow interface. It triggers the compile/re-save in any blueprint it is added to, even when nothing is connected to it. The empty node alone is enough to require a resave on play.
And when it’s in a macro library, it corrupts everything in that macro library, even other macros not related to it. So if a blueprint is using an unrelated macro in that macro library, it too needs to resave on play.
Unfortunately, this node is also an essential part of the “Get Game Settings” macro, so we have to do some work to improve this problem per project.
**Step 1: **
If you just opened your project, press play once to remind editor that GameInstanceWithSettings blueprint exists, it sometimes forgets.
Step 2:
Open up Macro library QualityMenu => Blueprints => Util => GameSettingsMacros
Find macro function Get Game Settings, and cast directly to your projects GameInstance blueprint, instead of using the interface.
In this picture, I use my default “GameInstanceWithSettings” blueprint and get the GameSettings variable as output.
Step 3:
Open up you GameInstance blueprint and find “Init Game Settings”.
Make a literal string and literal int for “Settings Save Name” and “Save User Index”
Right click and expand the macro node.
Step 4:
Upen up GameSettingsMacros library again and delete the “Init Game Settings” function.
The macro library is now clean of any references to a game instance.
If you press and play now, you dont need to re-save most files.
GameInstanceWithSettings and GameSettings still reference the interface class, and needs to be resaved.
Step 5:
Create a new variable of your Game Instance class in GameSettings
Then replace all references of game settings interface in GameSettings with your own game instance.
Replace Input/Output variable types as needed.
Finally delete the “Game Settings Interface” variable when all references to it has been replaced.
(Global Post Process Interface dont cause any problems)
Step 6:
Since you changed input type on “Init Save Game Settings”, you need to reconnect it in you Game Instance blueprint.
Done:
This will make pressing play on PIE responsive again. Sorry about this, this has been one odd bug. I feel like there is a simpler solution somewhere, so if I find one, I will put out an update for 4.11.
Thank you for telling me this, I needed a bit of rubber duck help from you. I had been bothered by this one, but I understand if you have a bigger project, this can get frustrating fast.
(Edit, it triggers on 4.12 too, but not always, I need to look into it)
Tell me if you need more help. Good luck on finalizing your project.
Hi, I checked it, it’s harmless. Your first hunch was correct, its in the replace key mapping macro. the /11 refers to the second array, not the first one.
I have a select statement that chooses output depending on if it finds something in the array or not. Even if its not used when element is not found, and output is false, the GET node still throws a warning message.
It works as it is supposed to do, but thanks for telling me, I had not noticed it. I will change it so it does not throw the error message later.
Wow thank you! Your commitment and support is simply outstanding, I really appreciate it.
So I’ll scrub out GameInstanceInterface like you described, sounds good. Must have taken a while to test a fix and write those detailed instructions, so thanks again.
Also eager to see more marketplace items from you in the future
Appreciate your kind words. Summer time does give me more time on my hand ^^
I have some small projects, might be something for the marketplace later, but not anytime soon.
About the Windowed mode problem, I think I will by the way set FullscreenMode=0 and wait Epic fixes the problem. If I am correct, I must write FullscreenMode=0 in the GameUserSettings.ini (which is blank) located in …/Intermediate/Config/CoalescedSourceConfigs ? Since UE4 detects the resolution of the screen, why not set a project in FullscreenMode=0 ?
If you only write “FullscreenMode=2” (Window mode) and nothing else in the ini file, it will ignore it. I think you need some of the tags. “[/Script/Engine.GameUserSettings]”, but I have not checked that out myself. You can start the game, press ok in menu, and GameUserSettings will be generated with settings.
I just got an idea to make a workaround. If ini file its set up so game always starts up in windowmode (Where it works with titlebar), I can then apply the saved screenmode after game starts up from my save file.
Then every time settings are saved, it is set to window mode in the ini file, but the correct screen mode in stored my settings save file. You lose access to change fullscreen in ini file. But I think that is an acceptable loss for now. I will try it out later.
I will try to be clearer. What I would like now is :
Player opens the project => set Fullscreen + Screen resolution detection and adjustment.
Your option menu detects the “Fullscreen” and the “Resolution” : if I am correct, this is not yet possible. You wrote about merging your system with the new Epic system about that. Is it possible to merge it ?
Player can set the project in Windowed mode with your menu without being fixed at the corner of the screen (which seems to be an UE4 bug).
I don’t entirety understand what you are asking me, but I can explain in detail how my system now works with Epic own system.
When a packaged game is started the engine reads the GameUserSettings.ini file, applies its settings and starts the game with its resolution and screen mode.
If no GameUserSettings.ini is found. It uses a default one with windowed fullscreen with your systems max resolution. (As far as I have observed)
If the game is started in a fullscreen mode from GameUserSettings.ini file or default settings, it is now in the bugged state where the game will be stuck in corner and missing a titlebar if screen mode is changed to windowed.
When the game has started, my system takes over. First it loads its own file “SettingsSaveFile.sav” or creates a new one if none is found.
Then it reads the data from ini file that epic has made available through blueprints. It replaces the relevant variables in my settings system, such as quality settings, resolution and screen mode.
Some settings, like motion blur, brightness and keybinding are stored in SettingsSaveFile.sav and is not affected by the GameUserSettings.ini
When my settings system later applies settings, it mostly ignores the settings system Epic included with 4.11, and uses the “execute console command” node instead, since it is more flexible and can have more features.
The exception is when it applies resolutions. Here I now use Epics own system to apply resolution settings. I thought this fixed the windowed issue, but it didn’t, and that’s when I bug reported it to epic. Using the old console command “r.SetRes {XRes}x{YRes}{Mode}” does not improve this problem. (It worked in previous engine releases)
When the player press OK to save the settings file, it then does the reverse, and copies settings from my system, to epics system, to properly store settings in the GameUserSettings.ini file. The ini file is then saved before “SettingsSaveFile.sav” is saved.
So Epics system is partially merged, but not fully used due to lack of flexibility. I mostly only have it now for the ini file since a user requested it. I’ll improve it whenever I can.
The idea I will try out later is to set GameUserSettings.ini to always start the game in window mode, (to avoid bugged state), then instantly on gamestart change screenmode according to my SettingsSaveFile.sav and not GameUserSettings.ini
Hopefully this can “fix” the the windowed problem.
What I would like : the player can open (at the first time) the project (with your option menu) and the project is directly in fullscreen mode (FullscreenMode=0).
I use the 4.12.0. I didn’t update your last patch (I wait the fix about Windowed bug. I customised your option menu and don’t want to have to change it after every patch. I don’t have time for that.)
Problem seems to be here :
It seems that you use default values (windowed mode + 1280x720) which overwrites other values.
If I try on my own to make the project start in fullscreen mode :
I clear my “.sav” files
In MyProject\Intermediate\Config\CoalescedSourceConfigs\GameUserSettings.ini :
I write those 2 lines in this blank .ini :
[/Script/Engine.GameUserSettings]
FullscreenMode=0
(But it seems this .ini is reset to blank when packaging is finished.)
I package the project for development.
I open the packaged project (I click the .exe) : I see a black screen (fullscreen) and shortly the project is set in Windowed Mode (fixed at the corner) in 1280x720 (I didn’t add in my BP nodes like “Set Fullscreen”, setRes…).
In PackagedProject\WindowsNoEditor\Sigur\Saved\Config\WindowsNoEditor : GameUserSettings.ini is blank. If I delete it, project still opens in Windowed Mode (fixed at the corner) in 1280x720. So “It uses a default one with windowed fullscreen with your systems max resolution” doesn’t happen.
Ok, I think I got it fixed. (It works at my end, shipped and development build)
Only the latest 1.5.2 release started using the GameUserSettings.ini file. Since you are using an older release, it ignores it and uses its own default values as defined in GameSettings blueprint.
These following steps are for your version 1.5/1.5.1 and not the latest 1.5.2 release.
Close your editor, open up your project directory and create a new “DefaultGameUserSettings.ini” in your Config folder.
Add this text inside DefaultGameUserSettings.ini. All these settings are ignored by my menu in 1.5/1.5.1, but it forces the game to start up in windowed mode, avoiding the bug.
Then, open the project again, open the GameSettings blueprint, Press class Default and set new default resolution and screen mode. Compile GameSettings.
Now you should be able to package the project and it works.
The game will start up in windowed mode according to DefaultGameUserSettings.ini, avoiding the bugged state.
Then my settings menu starts up and changes to the correct screenmode, either the default in GameSettings blueprint, or according to SettingsSaveFile.sav file.
(If it does not work, restart editor and package it one more time to make sure it found DefaultGameUserSettings.ini)
I need to do some adjustments to take into concideration the UserGameSettings.ini included in 1.5.2, but I think I got it solved.
hi guys, i bought this pack and would like to use it in my project; but there is a problem, after migration i need to set the gamesettings game instance blueprint, but i already have one where there are all game logics.
Then how should i do? i need to implement gamesettings gameinstance staff in my game instance blueprint…how can i do it?
