I’ve run into an issue. Comboboxes no longer open when they are within an in-world UWidgetComponent. They work in PIE, but not in standalone.
I’ve tracked it down to them calling:
[FONT=courier new]SMenuAnchor::SetIsOpen within that it calls:
[FONT=courier new]FSlateApplication::Get().GeneratePathToWidgetUnchecked(AsShared(), MyWidgetPath);
if (MyWidgetPath.IsValid())
and the widget path returned is invalid. I looked through [FONT=courier new]GeneratePathToWidgetUnchecked and it calls [FONT=courier new]FSlateWindowHelper::FindPathToWidget which seems to have had a lot of changes in 4.20 and in there it checks against [FONT=courier new]GSlateFastWidgetPath and does different logic depending on the value of it.
So I tried setting Slate.EnableFastWidgetPath 0 on the console and it fixes things in standalone. The bug seems to be in the fast path.
There is also a bug that [FONT=courier new]Slate.EnableFastWidgetPath will initially report zero when queried on the console in standalone, even though the underlying global is set to true. It reports the real value only after setting it at least once via console.
It seems there were some additional changes to the AI navigation. I needed to decrease recast navmesh cell size with 4.20, otherwise movement was completely broken. The “Move to” node still randomly fails for simple movement (regression, was fine in 4.19), even though a path is obviously available and the target is very near. Did anyone else encounter these problems?
I must say, yea I kind of agree with the OP on most everything. I have not updated to 4.19 because of the many reports that are flying around here with that stuttering behavior, although I desperately need the encryption feature of 4.19. I thought, Oh well wait for 4.20 hopefully it will be gone then, but OMG this forum thread here is basically mayhem. I mean in the past you had these kawaii “Thank you thank you Epic for some great new features” posts, but if those posts completely disappear in exchange for cries for help because literally nothing works anymore, I must say, I am glad I haven’t moved on from 4.18.3 and I won’t anymore unless there is one version that halfway work and should that ever happen I will stick with it because none of the features since 4.19 matter to me.
I am seriously beginning to worry about the state of this engine and I am beginning to think maybe I would have been better off with Unity, but after 100s of $$ of investments on the marketplace it’s too late for me.
Setting “tile size uu” to 560 (instead of 600 on UE 4.19) fixed this for me. I have increased navmesh cell size to 10 again, and things are back to normal. So basically, this means you have to readjust nav mesh params in 4.20.
I have no idea where to go next with this. All my levels work perfectly individually, and the persistent level functions fine in-editor, but once I try to play it I get this weird ol’ render resource crash. Nothing’s changed except the 4.19.2->4.20 update. Anyone else seeing it?
EDIT: This went away when I enabled “Use Background Level Streaming”, which I had disabled in 4.19 due to Blocking Loads not working while it was on (which I’m told has now been fixed in 4.20, so this is a happy ending)
Also having some issues on a blueprint-only project upgraded from 4.19 to 4.20 - I get a crash when trying to compile my Weapon_Part blueprint script component (which is a child of InstancedStaticMeshComponent, with the only changed variable being the StaticMesh).
That’s after receiving these warnings when loading the editor:
Warning: Unable to load PhysicsSerializer with outer SNF_Weapon_Part_C /Game/Blueprints/Weapons/SNF_Weapon_Part.Default__SNF_Weapon_Part_C because its class does not exist
Warning: Unable to load PhysicsSerializer with outer SNF_Weapon_Part_Barrel_C /Game/Blueprints/Weapons/SNF_Weapon_Part_Barrel.Default__SNF_Weapon_Part_Barrel_C because its class does not exist
[2018.07.22-01.33.31:364][815]LogLinker: Warning: Unable to load PhysicsSerializer with outer SNF_Weapon_Part_Body_C /Game/Blueprints/Weapons/SNF_Weapon_Part_Body.Default__SNF_Weapon_Part_Body_C because its class does not exist
[2018.07.22-01.33.31:367][815]LogLinker: Warning: Unable to load PhysicsSerializer with outer SNF_Weapon_Part_Clip_C /Game/Blueprints/Weapons/SNF_Weapon_Part_Clip.Default__SNF_Weapon_Part_Clip_C because its class does not exist
[2018.07.22-01.33.31:369][815]LogLinker: Warning: Unable to load PhysicsSerializer with outer SNF_Weapon_Part_Grip_C /Game/Blueprints/Weapons/SNF_Weapon_Part_Grip.Default__SNF_Weapon_Part_Grip_C because its class does not exist
Oddly, I can still play and the weapon parts show up. I submitted a crash report with the log/dump.
P.S. I’ve just fixed my case by redoing my (still prototype) weapons from scratch to not use ISM components. But some may not be so lucky.
Wow, way too ranty there (good way to get ignored). But for some reason I read it, and did get that little tidbit:
This is quite a big invasive change and should definitely be added to the release notes, since it breaks existing light setups. It should be noted that devs can no longer adjust light roughness, and need to use the new SpecularScale property instead.
Anyone else who was using Min Roughness - you can copy/paste all your lights from each level into notepad and search for roughness, to see which lights were using it. Then set Specular Scale values accordingly.
I’ve been playing around with the new Editor Scripting functionalities, and they look quite cool and useful to automate some workflows, but there’s something I couldn’t get my head around.
I’m following the documentation/tutorials, and it says that in order to access a wider range of tools, you need to derive your Blueprint from something like PlacedEditorUtilityBase. Does it mean you need to derive your Blutility from that? I tried but it doesn’t work like that. So I tried to create a normal Blueprint, and it does allow to derive from PlacedEditorUtilityBase, but what’s the point of it? Shouldn’t it be available for Blutility?
Also, deriving a new Blueprint from PlacedEditorUtilityBase, I don’t see all the categories shown in the picture from the tutorial/documentation (for example, I’m totally missing the StaticMesh category, which I’m mostly interested in); am I missing something simple here?
EDIT: Nevermind, I had Editor Scripting Utilities plugin disabled, now it’s working as expected
Not unless Apple changed that policy. Blueprint only projects will work (since those binaries are already signed), but custom binaries won’t (unless you just cough up the $100 bucks and become a developer).
There are some Camera Control Issues on iOS when Camera is on Mesh “Head” Socket ( and head will rotate according to camera rotation), This Issue was not visible on 4.20 preview 5 , nor any other ue4 version. It runs smoothly on Android and PC… the Bug is only on iOS
There is a comment on it in SlateCore/Private/SlateCoreClasses.cpp that says:
I think it could make sense to enable both fast and slow at once in development and have some ensures to make sure the results always agree. But maybe there are known edge cases that happen too frequently in editor.
word of WARNING for mixamo rigs… UE 4.20 now appears to import the ‘mixamorig’ prefix for mixamo skeleton, so existing rigs and animations will no longer match with pre-4.20 rigs… either reimport your rigs with the new rigs, or change any new anims to the old rigs (no prefix)… do it now or pay for it later
Blueprint-only is what I was hoping for (I don’t know how to code in C++). I ask because last year, I had to have my college professor convince the college to shell out for an Apple Dev account for my last semester’s Internship course project because that was just the way it was at the time (I think I was using either 4.15 or 4.16 at the time). If I may ask, how would I be able to launch a blueprint-only project on an iPhone without a paid dev account now? I’m not sure how to go about it, and info on the subject is scarce (and mostly unhelpful for my needs).
