Sorry just to be clear, which part isn’t fixed yet in 4.25 preview? The 2D Scene Capture component or mouse cursor leaving VR screen issue?
Tested 4.25.0p7: a brand new VR template project builds & launches nice now on Quest. Great this is fixed now.
One problem though: old/converted projects still crash like before. Have to investigate more whats causing this
Both…
it is the stereo layers in your pawn, go into your pawn and remove them. then open EVERY map in your game and build lighting then save then open your project in the NEW engine. DONT add a stereo layer or it will crash your project again.
so stereo layers even if added newly in 4.25 don’t work?
Thanks for the suggestion. But, there are no stereo layers in my pawn. Never have been. Also not in the MotionControllerPawn that i used for testing this issue.
This is fixed in preview 7. I didn’t know preview 7 was out. I was testing on P6
Yep. i tried to add them in my project, saved closed the engine, upon reopening
the project can no longer load giving errors saying something about expected stereo layer component but got stereolayer(type) instead I posted it in this forum somewhere the error it gives.
Object StereoLayerShapeCylinder StereoLayerShapeCylinder_0 created in Package instead of StereoLayerComponent <--------
Full error below
removing the stereo layers from the pawn still caused these errors until i loaded each map and built lighting and saved to
kinda force the map to recreate its build data.
even after that if i add a stereo layer and set it to ANY mode it crashes the project with these same errors.
Fatal error: [File:D:/Build/++UE4+Licensee/Sync/Engine/Source/Runtime/CoreUObject/Private/UObject/UObjectGlobals.cpp] [Line: 2232]
Object StereoLayerShapeCylinder StereoLayerShapeCylinder_0 created in Package instead of StereoLayerComponent
0x00007ffa5f4ca839 KERNELBASE.dll!UnknownFunction ]
0x00007ffa06140d36 UE4Editor-Core.dll!ReportAssert() [D:\Build++UE4+Licensee\Sync\Engine\Source\Runtime\Core\Private\Windows\WindowsPlatformCrashContext.cpp:1355]
0x00007ffa06144388 UE4Editor-Core.dll!FWindowsErrorOutputDevice::Serialize() [D:\Build++UE4+Licensee\Sync\Engine\Source\Runtime\Core\Private\Windows\WindowsErrorOutputDevice.cpp:78]
0x00007ffa05ecf25d UE4Editor-Core.dll!FOutputDevice::LogfImpl() [D:\Build++UE4+Licensee\Sync\Engine\Source\Runtime\Core\Private\Misc\OutputDevice.cpp:61]
0x00007ffa05901357 UE4Editor-CoreUObject.dll!StaticAllocateObjectErrorTests() [D:\Build++UE4+Licensee\Sync\Engine\Source\Runtime\CoreUObject\Private\UObject\UObjectGlobals.cpp:2232]
0x00007ffa058ff761 UE4Editor-CoreUObject.dll!StaticAllocateObject() [D:\Build++UE4+Licensee\Sync\Engine\Source\Runtime\CoreUObject\Private\UObject\UObjectGlobals.cpp:2273]
0x00007ffa059018ba UE4Editor-CoreUObject.dll!StaticConstructObject_Internal() [D:\Build++UE4+Licensee\Sync\Engine\Source\Runtime\CoreUObject\Private\UObject\UObjectGlobals.cpp:3165]
0x00007ffa0590282b UE4Editor-CoreUObject.dll!StaticDuplicateObjectEx() [D:\Build++UE4+Licensee\Sync\Engine\Source\Runtime\CoreUObject\Private\UObject\UObjectGlobals.cpp:1994]
0x00007ffa0590235f UE4Editor-CoreUObject.dll!StaticDuplicateObject() [D:\Build++UE4+Licensee\Sync\Engine\Source\Runtime\CoreUObject\Private\UObject\UObjectGlobals.cpp:1961]
0x00007ffa02c37d24 UE4Editor-Engine.dll!FComponentPropertyWriter::GetDuplicatedObject() [D:\Build++UE4+Licensee\Sync\Engine\Source\Runtime\Engine\Private\ComponentInstanceDataCache.cpp:84]
0x00007ffa02c0c9a2 UE4Editor-Engine.dll!FComponentPropertyWriter::operator<<() [D:\Build++UE4+Licensee\Sync\Engine\Source\Runtime\Engine\Private\ComponentInstanceDataCache.cpp:127]
0x00007ffa05f6a622 UE4Editor-Core.dll!FStructuredArchiveSlot::operator<<() [D:\Build++UE4+Licensee\Sync\Engine\Source\Runtime\Core\Private\Serialization\StructuredArchive.cpp:508]
0x00007ffa058a21ad UE4Editor-CoreUObject.dll!FObjectProperty::SerializeItem() [D:\Build++UE4+Licensee\Sync\Engine\Source\Runtime\CoreUObject\Private\UObject\PropertyObject.cpp:108]
0x00007ffa058a3e32 UE4Editor-CoreUObject.dll!FPropertyTag::SerializeTaggedProperty() [D:\Build++UE4+Licensee\Sync\Engine\Source\Runtime\CoreUObject\Private\UObject\PropertyTag.cpp:240]
0x00007ffa0574c965 UE4Editor-CoreUObject.dll!UStruct::SerializeVersionedTaggedProperties() [D:\Build++UE4+Licensee\Sync\Engine\Source\Runtime\CoreUObject\Private\UObject\Class.cpp:1521]
0x00007ffa0574a8ac UE4Editor-CoreUObject.dll!UStruct::SerializeTaggedProperties() [D:\Build++UE4+Licensee\Sync\Engine\Source\Runtime\CoreUObject\Private\UObject\Class.cpp:1219]
0x00007ffa05547a9c UE4Editor-CoreUObject.dll!UStruct::SerializeTaggedProperties() [D:\Build++UE4+Licensee\Sync\Engine\Source\Runtime\CoreUObject\Public\UObject\Class.h:402]
0x00007ffa02c01a6c UE4Editor-Engine.dll!FComponentPropertyWriter::FComponentPropertyWriter() [D:\Build++UE4+Licensee\Sync\Engine\Source\Runtime\Engine\Private\ComponentInstanceDataCache.cpp:47]
0x00007ffa02c00ac0 UE4Editor-Engine.dll!FActorComponentInstanceData::FActorComponentInstanceData() [D:\Build++UE4+Licensee\Sync\Engine\Source\Runtime\Engine\Private\ComponentInstanceDataCache.cpp:307]
0x00007ffa02d31378 UE4Editor-Engine.dll!FSceneComponentInstanceData::FSceneComponentInstanceData() [D:\Build++UE4+Licensee\Sync\Engine\Source\Runtime\Engine\Private\Components\SceneComponent.cpp:2252]
0x00007ffa02d4c3f7 UE4Editor-Engine.dll!USceneComponent::GetComponentInstanceData() [D:\Build++UE4+Licensee\Sync\Engine\Source\Runtime\Engine\Private\Components\SceneComponent.cpp:2329]
0x00007ffa02c0140c UE4Editor-Engine.dll!FComponentInstanceDataCache::FComponentInstanceDataCache() [D:\Build++UE4+Licensee\Sync\Engine\Source\Runtime\Engine\Private\ComponentInstanceDataCache.cpp:409]
0x00007ffa0290cc31 UE4Editor-Engine.dll!AActor::RerunConstructionScripts() [D:\Build++UE4+Licensee\Sync\Engine\Source\Runtime\Engine\Private\ActorConstruction.cpp:313]
0x00007ffa0317c3d4 UE4Editor-Engine.dll!ULevel::IncrementalUpdateComponents() [D:\Build++UE4+Licensee\Sync\Engine\Source\Runtime\Engine\Private\Level.cpp:992]
0x00007ffa03b91d48 UE4Editor-Engine.dll!UWorld::UpdateWorldComponents() [D:\Build++UE4+Licensee\Sync\Engine\Source\Runtime\Engine\Private\World.cpp:1862]
0x00007ffa0040365f UE4Editor-UnrealEd.dll!UEditorEngine::Map_Load() [D:\Build++UE4+Licensee\Sync\Engine\Source\Editor\UnrealEd\Private\EditorServer.cpp:2685]
0x00007ffa003f280f UE4Editor-UnrealEd.dll!UEditorEngine::HandleMapCommand() [D:\Build++UE4+Licensee\Sync\Engine\Source\Editor\UnrealEd\Private\EditorServer.cpp:6136]
0x00007ffa003da971 UE4Editor-UnrealEd.dll!UEditorEngine::Exec() [D:\Build++UE4+Licensee\Sync\Engine\Source\Editor\UnrealEd\Private\EditorServer.cpp:5616]
0x00007ffa00c10f47 UE4Editor-UnrealEd.dll!UUnrealEdEngine::Exec() [D:\Build++UE4+Licensee\Sync\Engine\Source\Editor\UnrealEd\Private\UnrealEdSrv.cpp:697]
0x00007ffa007528e2 UE4Editor-UnrealEd.dll!FEditorFileUtils::LoadMap() [D:\Build++UE4+Licensee\Sync\Engine\Source\Editor\UnrealEd\Private\FileHelpers.cpp:2561]
0x00007ffa007526e4 UE4Editor-UnrealEd.dll!FEditorFileUtils::LoadDefaultMapAtStartup() [D:\Build++UE4+Licensee\Sync\Engine\Source\Editor\UnrealEd\Private\FileHelpers.cpp:3950]
0x00007ffa00c527a9 UE4Editor-UnrealEd.dll!FUnrealEdMisc::OnInit() [D:\Build++UE4+Licensee\Sync\Engine\Source\Editor\UnrealEd\Private\UnrealEdMisc.cpp:361]
0x00007ffa00c0cfc8 UE4Editor-UnrealEd.dll!EditorInit() [D:\Build++UE4+Licensee\Sync\Engine\Source\Editor\UnrealEd\Private\UnrealEdGlobals.cpp:114]
0x00007ff6f9c2be8e UE4Editor.exe!GuardedMain() [D:\Build++UE4+Licensee\Sync\Engine\Source\Runtime\Launch\Private\Launch.cpp:149]
0x00007ff6f9c2c0ea UE4Editor.exe!GuardedMainWrapper() [D:\Build++UE4+Licensee\Sync\Engine\Source\Runtime\Launch\Private\Windows\LaunchWindows.cpp:137]
0x00007ff6f9c3e7f9 UE4Editor.exe!WinMain() [D:\Build++UE4+Licensee\Sync\Engine\Source\Runtime\Launch\Private\Windows\LaunchWindows.cpp:266]
0x00007ff6f9c418da UE4Editor.exe!__scrt_common_main_seh() [d:\agent_work\5\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl:288]
0x00007ffa60bf7bd4 .DLL!UnknownFunction ]
0x00007ffa6256ced1 ntdll.dll!UnknownFunction ]
i made a bug report but can’t even find it… I think they deleted my bug report as you can’t even search for it LOL…
So this only happens if the project was made in 4.24 then converted to 4.25…
making a clean 4.25 vr project does NOT cause this issue.
it seems converting from 4.25 is leaving some bad juju in maps made in 4.24… 
Lightmass is not usable. (Reported)
Lot’s of artifacts on organic meshes with high tri count.
Interactive comparison: Lightmass is not usable - Imgsli
Hi @](Lightmass is not usable - Imgsli)****This is likely to appear in the final release as I don’t see anything about it in issue tracker. It’ll hold us back from moving projects to 4.25. Please have a word with someone about it. Thanks.
https://i.imgur.com/7eS8iIo.jpg
https://i.imgur.com/u9F8WC1.jpg
Hi
I noticed that ServerTravel works without the Seamless check box ticked in the game mode!
I’m on P6 atm
AI issues
-
Environment Query System setting was reset to off after upgrading. Prevented me from opening EQS files and would get errors like [2020.04.18-14.51.09:773][131]LoadErrors: Warning: CreateExport: Failed to load Outer for resource ‘EdGraphPin_0’: EnvironmentQueryGraphNode_Option /Game/
-
AISystem.cpp is now firing off the following checks. It was working in 4.24. Have no idea why at this stage. - check(BlackboardDataToComponentsMap.FindPair(&BlackboardData, &BlackboardComp) == nullptr); Looks like it’s comparing nullpointers and return that value. Need to investigate more.
AI now behaves differently. Going to be fun working that out… 
Update: the check macros seems to be firing due to a change in how component and registered and unregistered. Still looking into it.
I noticed in 4.25 a new error started happening.
Can’t use hidden enum values as parameter defaults.
And game trace channels are marked as hidden.
What are we supposed to do in 4.25 and on for default params for game trace channels?
ECC_GameTraceChannel1 UMETA(Hidden),
ECC_GameTraceChannel2 UMETA(Hidden),
ECC_GameTraceChannel3 UMETA(Hidden),
ECC_GameTraceChannel4 UMETA(Hidden),
ECC_GameTraceChannel5 UMETA(Hidden),
Right now in 4.24, it actually works fine. My custom collision channels configured within the engine appear as enum values. And when I try to call a C++ function with this default param from Blueprint, the default param is correctly set to the custom collision profile.
UFUNCTION(BlueprintCallable, BlueprintNativeEvent, Category = "Damage", meta = (WorldContext = "WorldContextObject"))
bool ApplyRadialDamage(const UObject* WorldContextObject,
float DamageMultiplier,
float RadiusMultiplier,
const FVector& Origin,
AActor* DamageCauser,
AController* InstigatedByController,
ECollisionChannel DamagePreventionChannel = /*FCollisionConstants::Instance.DamageIgnoreNonSolidTraceChannel*/ ECC_GameTraceChannel2) const;
what is maximum jdk version that we can use with ue4 4.25 ?
first time i use jdk 14 and i cant export my android project with this version
now i am using 1.8.0_77 and 4.25 work correctly with this version
https://www.unrealengine.com/en-US/t…al-engine-4-25
this page does not have information about jdk in 4.25
Project link for lightmass problem Dropbox - File Deleted
More dark spots as you increase lightmap resolution. @DanielW
I reported the skylight slider being unusable as a bug but was told it was by design. Moving the slider one pixel increases the value from 0 to 47.(same thing on the directional light moves it from 0 to 0.71)
[video]https://i.imgur.com/8VOOKRL.mp4[/video]
Just curious if anyone has actually used the skylight intensity slider in recent versions instead of typing in numbers.
Using 4.25 preview 7. I have tried to compile for Android, armv7 builds fine. But arm64 I continually get the following errors and the build fails for both APK and AAB. I tried on a different PC with same issue.
UATHelper: Packaging (Android (ETC2)): [5/7] MyProject-arm64.so
UATHelper: Packaging (Android (ETC2)): ld.lld: error: undefined symbol: FMemory::Malloc(unsigned long long, unsigned int)
UATHelper: Packaging (Android (ETC2)): >>> referenced by MyProject.cpp:4 (C:/unreal/MyProject/Intermediate/Source\MyProject.cpp:4)
UATHelper: Packaging (Android (ETC2)): >>> C:/unreal/MyProject/Intermediate/Build/Android/UE4/Development/MyProject/MyProject.cppa8.o:(operator new(unsigned long))
UATHelper: Packaging (Android (ETC2)): ld.lld: error: undefined symbol: FMemory::Free(void*)
UATHelper: Packaging (Android (ETC2)): >>> referenced by MyProject.cpp:4 (C:/unreal/MyProject/Intermediate/Source\MyProject.cpp:4)
UATHelper: Packaging (Android (ETC2)): >>> C:/unreal/MyProject/Intermediate/Build/Android/UE4/Development/MyProject/MyProject.cppa8.o:(operator delete(void*))
this won’t be fixed until the release of 4.25. the engine is undergoing a HUGE change and everything is broken. but maybe in 3 years they will stop adding features and
fix the bugs. WE PRAY FOR THAT DAY.
But… preview releases are all about testing and bug fixing, so everyone would get a stabilized engine once the final release happens.
4.25 has 7 preview releases already, almost 2 months focused mostly on bug fixing and tweaking features. Tons of fixes every day. If GitHub mirrors changelists live some fixes committed during weekends, probably some people are crunching to make things done. And they are slowed down by working remotely.
It feels weird to read statements like “not enough bug fixes” in this topic which is all about bug fixes.
Or reading suggestions “stop adding features, fix bugs only”. The problem is, if they wouldn’t add features, that means engineers would go work elsewhere - why keep hundreds of programmers in the company if only a few needed to fix critical bugs? - and engine development would practically stop. There wouldn’t be even the next engine version to support new/updated platforms, no features you need to stay competitive. And bugs would be still there.
[edited upon mod request - fixed so it wouldn’t feel like offending anyone]
I think we all get a little negative. It’s just because we love Unreal and are so passionate about it that when things don’t work like they say they do, or do work one version only to be broken the next, it is really disappointing. The main problem is not that preview releases have bugs, but that these bugs introduced in previews often stay for several full release versions, if they get fixed at all (I’m looking at you Landscape Physical Materials).
And make no mistake, we are happy to have new features and want to use them. But often we can’t because systems we’ve spent 100+ hours working on sometimes break when we upgrade. I wrote an entire blueprint only save system, was about to put it on the marketplace, only to have it broken in the next release. So now I have to decide whether to rip that out and use a different system, or forgo new features that are really cool. And that’s not a fun decision.
Sure, but I can’t see how this is related to my comment or comments above?
I was complaining on complaining in this Preview topic, not on all threads and everything. And now you’re preaching me on that 
I can take that I’m “sounding preachy”, but sometimes people here expect miracles. They **demand **miracles, full stability of codebase with 2-3 million lines of code
My opinion is: there’s simple reason for the lack of roadmap is that… Epic simply is unable to guarantee a given system/feature/fix would be delivered in the promised timeframe. Or if it would fulfill expectations.
- Unity tried it hard, and couldn’t deliver “production-ready” systems on schedule. This backfired, devs often complain about “ready” features that aren’t ready.
- A lot of software houses don’t announce precise details of future product revisions before features are implemented, i.e. Houdini, Quixel.
- Epic actually tries to communicate things. They simply can’t give you exact date i.e. “when Chaos would be production-ready” because they simply don’t know. Creating new features/systems usually don’t meet “time exceptions”. This is true even if developing features for a small game…
- When they still had a clunky roadmap (it was very working well), people were just repeating questions “why X is still not implemented” and Epic couldn’t properly reply - they didn’t know the answer or couldn’t announce things like “hey, we started working on our own physics system, but we don’t know when this will be ready, maybe 2 years, maybe 3 years”.
- UDN doesn’t provide an exact roadmap. Sometimes you’d get “current estimations”, but nothing you can truly rely on.
So… yes… I’d love an awesome roadmap with precise release goals and dates. I do try to adjust my development to engine development.
- Just I don’t see how this would be possible? Without actually delaying most of the release goals.
- It’s extremely important for my projects to have all these new features and system refactorings. So I don’t share enthusiasm to say “stop adding features, fix all the bugs”. Especially if added in the Preview topic.
The thing is, you present this like “people demand a stable build”, but “Epic doesn’t care”. It creates notion that “they don’t care, don’t fix things”. Or more things would be fixed in an audio system if they wouldn’t work on raytracing. Or similar claims
Please, take into account the fact my perspective. I started a gamedev career by working with in-house engines. I was happy if editor didn’t crash 20 times a day or somebody actually had time to properly implement tools without running to another task.
Overall quality and stability of Unreal Engine 4 are amazing, brand new standards.
- Compared to most in-house engines designed to support only single game type, impossible to use tools if its programmer didn’t come to your desk and explain everything in detail, there was never time for engine documentation.
- It’s superb if compared to Unity where devs often mention a long list of things that stop working. Or they had to revert the project to the older system or engine version.
- If somebody demands 100% stability from such huge software, he never gonna get it. We’re quite close to this 100% however. There are hundreds of modules updated with every version, and it’s not like people complain about the big amount of them…
Let’s take one of the issues mentioned in your link:
“Audio on Xbox One broken if updated a project, required massive rework and research”
Yes, because they switched to the new audio engine by default. Nobody rushed it. They spend 2 years on maintaining the old engine (very time-consuming since old implementation wasn’t multiplatform, often they had fix things multiple times, for every single platform) and that slowed down introducing the new, properly designed audio mixer. Audio team spent a lot of time to make a new engine as compatible as possible with the old one. Obviously, it’s not 100% compatible, some things need to be reworked.
- Now if you take such comment above without proper context/explanation… It gives impression that things broke for no reason! Epic failed and ignored the serious issue! Which simply isn’t true.
But we don’t even know the context… does the author use the new audio engine? If not forced, it could switch back to the old engine? Does the author is aware that switching to a brand new system (entirely different code) cannot be painless?
Another post states “Turning UE4 into more or less useless and not reliable at this point.” That isn’t exactly true for the general engine community. Could it be better? Sure, but these posts are often over-dramatic. Like the entire engine got “less useless”.
Meanwhile, I do keep updating the project to every new version. Often waiting longer (weeks) before the upgrade. Yes, I can’t consider the first final release as stable enough. If not compiling the engine from source, it’s often better to wait until the first patch.
I’m always preparing to encounter major issues that would need to be immediately fixed. I don’t issue “demands for stability”. Yeah, I had to deal with some bugs with almost every engine release. Still, an incredibly small price for getting all these new features, improvements and work of hundreds of engineers. A dream for an indie developer.
Call me “taking the superior high-ground”, but I gonna defend the opinion that UE4 is an extremely stable engine compared to all other ones and given the speed of engine development.
What they could do and should do is to release patches more frequently. Why couldn’t they release a patch every week or two? It would improve a lot if given project uses launcher build of the engine 
Yeah, I understand your pain. There’s one of the reasons I follow all information, browse GitHub submits - to minimize such issues.
It happened often while we’re porting the game to early UE4 that rendering programmer implemented missing things. And actually Epic implemented it in their way such a version later
Another thing they could improve is to communicate core engine changes. It’s black box, shortly listed in release notes without explanation.