I can delete it and put a new one… just for try…
Ok, thanks a lot… I’ll try it now
Ok, to use this with all default parameters
And… LOL
Now it looks good in standalone and bad in the editor.
Playing in the editor looks fine
Too much light in both cases but it looks more or less the same…
Now the problem is the editing mode… it’s too dark LOL
Under the clouds it is completely black…
I just want to see it the same everywhere
it does work!! 
How did you manage to have sky under the clouds?
Maybe that’s why my editor looks dark now
Full view of the editor + outliner
It’s a basic default map with turned off lumen and virtual shadow maps switched to shadow maps. Added a spherical reflection node.
Nope… it must be some parameter in one of the added actors…
I’ll experiment with it…
I don’t understand why Epic does this…
I’m sure Epic has an evil programmer who enjoys watching users suffer.
I imagine him reading the forum posts while eating popcorn and laughing out loud. 
I touched all the parameters of the lighting actors and I couldn’t get it to work.
I found this on the forum… but, I have nto idea about this…
What do you think I need? Forward Rendering or Deferred Rendering?
I tried to do the sky sphere thing… but I don’t see any change… I assigned the directional light but the lower part of the sky is still black.
Forward rendering => Old tech.
Faster than deferred in some situations:
- If small amount of lights
- If no lighting overlaps
- Transparency can get more expensive (especially when transparent object overlap)
Deferred rendering
- Can handle more lights with better performance
- Introduces some slight offset with lighting update (it’s deferred so not a 100% in sync with the rendering)
*Transparency is calculated on a separate pass (it still uses forward rendering for this)
1 Like
Thanks for the info.
Got it… it seems that fog is not compatible with the sky sphere.
The other problem is also almost solved.
Now in playing mode, Editor and Standalone look the same.
The problem now is the editor in edit mode, It doesn’t look the same as in GamePlay.
And the difference is extreme… one has nothing to do with the other.
-In GamePlay it’s too bright
-In Edit mode it looks too dark
But in principle I would be happy if the two look identical. and are synchronized in the changes
Do you have any other ideas?
Does messing with the lit mode ev100 change anything? (though game settings should be ok)
Do you have any post processing materials enabled that could be modifying the incoming postprocess0 output?
Does a fresh level with no post processing look the same?
1 Like
Yes, it seems that a value of -0.5 is pretty close to what it looks like in GamePlay.
No, I’m not using materials for PostProcessing
Yes, a new level with no processing volume and a value of ev100 = 1 looks the same
Should I leave ev100 = -0.5?
I did another test…
It seems that this setting looks the same as GamePlay.
Did we get it?
Or should I not use “GameSettings”?
I’m a little confused right now…
Because I have not idea what is e100 and GameSettings are exactly…
But I’ve been using that for two years without knowing it.
I think it’s time to know what it is
Yes, it looks exactly the same!!
you rock @3dRaven
Well… I’ll look for information to learn what they are (e100 and GameSettings)…
game settings in the lit mode is on by default 
Looks like you tracked down your problem and squashed it.
Without your help I would never have done it.
We never really knew what the problem was… we just made a new map and added the lighting elements with the default parameters.
Sometimes very strange bugs appear.
Just yesterday the weapon mysteriously disappeared from my character’s hands.
I was looking for the busg everywhere.
Until I realized that when I used another character there was not bug…
But both characters inherited from the same C++ class… both executed the same code.
So the problem had to be the blueprint itself.
I deleted the blueprint and created a new one and the bug disappeared.
One of the weirdest bugs I’ve ever had.
Thank you very much for the help @3dRaven