Unreal, when are you going to focus more on Paper2D improvements?
Did something change with the lighting in the 4.15 preview? Everything seems a little bit darker to me. I think my post processor is making the differences more apparent but it’s still noticeable with it turned off. Here are 2 comparison screenshots between 4.14 and 4.15, one with my post processor on and one with it off: http://imgur.com/a/xpni5
Nativizing Blueprints!!! This is the best news ever!!! THX!!! I love U guys!!! 
Did you try to compare lighting with standard assets from Epic Games, on sample projects for instance?
You should then open an AnswerHub question with these screenshots to get a proper analysis and feedbacks fomr Epic.
Very nice!
Please tell me there will be some more documentation / training streams / examples of GameplayTags.
I’m unable to even launch this, it doesn’t load past 0%. I added a bug report.
Yeah, I hope it will be back in 4.15P2
Hi, I have some problems with new fontface stuff.
In my ps4 and xbox packages I’ve got a lot of warning of failed fontcache loading, this i the log:
GetFontFace failed to load or process ‘…/…/…/…/UnrealProjects/XXXXXX/Content/Fonts/dnc47_0_Default.ufont’
I think the problems are 2:
- the path is relative and with PC path (the XXXXXX folder is the game project one)
- the file created has .uasset extension and not the .ufont one
–EDIT–
I have just discovered that the ufont file is created in StageBuild directory
Gameplay Tags = Awesome !!!
Really funny how “include what you use” process, really seems like going backward when you look at it at first glance.
“Sometimes you got to go back to actually move forward”
If i were to import a couple GameWorks feature i’ve put together in 4.14.3 how painful would it be? It can still works with the legacy system right?
The dependancy between PhysX and all nvidia Gameworks is a kind of work i don’t want any part of !
Does the change to a “include what you need” cose base model (as described in the post) mean that we shall not put our includes inside the .cpp file anymore, but rather into our header file? This would make forward declarations obsolete…
Lol, i guess it means you put the actual content that you were about to include inside the actual file instead of in a header. There’s some mystical read I/O stuff going on obviously if it’s -20% compile time!
I kind of doubt that…
But maybe I didnt make myself clear, so let me try it again: It says that all header files include only the header files they need. This is something that we would usually do in the .cpp file since we would use forward declaration in the header files.
Did anything change with instanced static meshes?
Because I got huge decrease in draw distances of instances, and can’t see any way to turn it back up.
Landscape foliage is also affected, it gets much higher LOD vs the same object as a regular static mesh.
EDIT: turning up foliage.LODDistanceScale fixed foliage, still trying to find fix for instanced mesh
EDIT2: foliage.LODDistanceScale also affects other instanced meshes. Not sure if that’s intended behavior or not, either way, turning it up fixes both.
This should be fixed for preview 2, but feel free to try out a source build from GitHub and let me know if you’re still seeing the issue.
It was previously writing out the .ufont path during cook, which wasn’t always the correct path to load at runtime. It now works out the .ufont path at runtime instead.
You should still use forward declarations in place of includes whenever possible. Basically all they’ve done is to clean up the engine includes, to remove a bunch of unnecessary code being included all over the place, hence the reduction in compilation times.
Generally, a header should include itself everything that it needs in order to compile, no matter where it might be included from. Previously this wasn’t the case, many engine headers relied on includes being made by the precompiled header, which meant you’d sometimes get errors if you included such an engine header from your own code module with a different precompiled header.
Ohh now I get it. I had assumed this was already the case. So I thought the change meant something different. My bad, my misunderstanding. I guess for us, nothing changes.
In the new UE 4-15 Preview1 version when i use the FOLIAGE tool and place some trees in the Landscape the Trees disappear dont draw anymore …when i move far away in the Editor also in Game!
In UE4.14.3 version that not happens!
What i must do when i wont the Trees dont disappear and stay.
Thanks!
4.15p1 BUG:Enum is broken after converting from 4.14.3