-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
refactor: merge universe setup into world pregen screen #5122
refactor: merge universe setup into world pregen screen #5122
Conversation
22fe085
to
06217b5
Compare
…w gen - world generator can no longer be null if target world is not null - preview is generated during screen initialization due to binding
@skaldarnar with bb7fab6 I run into the OOM issue again during preview generation:
Without it I don't, but I don't get how the changes in that commit would result in running into this kind of a loop there 🤔 any ideas? |
@@ -162,7 +159,7 @@ public WorldGeneratorInfo get() { | |||
@Override | |||
public void set(WorldGeneratorInfo value) { | |||
if (value != null) { | |||
if (universeWrapper.getTargetWorld() == null || !value.getUri().equals(universeWrapper.getTargetWorld().getWorldGenerator().getUri())) { | |||
if (universeWrapper.getWorldConfigurator() == null || !value.getUri().equals(universeWrapper.getWorldGenerator().getUri())) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why configurator here?
public void setUniverseWrapper(UniverseWrapper wrapper) { | ||
universeWrapper = wrapper; | ||
public void setEnvironment(UniverseWrapper wrapper) { | ||
CoreRegistry.put(UniverseWrapper.class, wrapper); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Theoretically, the idea was to do the following:
context.put(UniverseWrapper.class, wrapper);
CoreRegistry.setContext(context);
However, this does not work and leads to an NPE in UniverseSetupScreen.java:182
when attempting to access UniverseWrapper
from a context that it's not in. At this moment, it's unclear, why this does not work.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you want to persist this information in the code as comment instead of just here on this PR?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done
- especially relevant for coming back from WorldSetupScreen
…ld-pregen-screen' into refactor/merge-universe-into-world-pregen-screen
…ld-pregen-screen' into refactor/merge-universe-into-world-pregen-screen
@skaldarnar from my side this would be ready for review |
engine/src/main/java/org/terasology/engine/rendering/nui/layers/mainMenu/UniverseWrapper.java
Outdated
Show resolved
Hide resolved
public void setWorld(Context subContext, WorldSetupWrapper worldSelected) | ||
throws UnresolvedWorldGeneratorException { | ||
world = worldSelected; | ||
public void setWorld(Context subContext, UniverseWrapper universe) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm annoyed by these HiddenFieldChecks - I'd like to have an overview in how many places this would actually cause trouble right now, and if we find none, disable this check.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I had it run on a iota workspace and it came back with more than 2k findings for hidden fields.
I think most of them are constructors or setters, but it's hard to filter those out.
} else { | ||
worldGenerator = world.getWorldGenerator(); | ||
} | ||
worldGenerator = universe.getWorldGenerator(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The world generator in the universe can no longer be null
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
world generator is set at initialize time (see UniverseSetupScreen#168)
I'd say it not being set is sufficiently unlikely that we don't need the null check anymore.
if you disagree I can re-add it of course
super.onScreenOpened(); | ||
|
||
final UIText seed = find("seed", UIText.class); | ||
if (seed != null) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hm, if we need to check for null
here, should we at least log a warning or something in case the seed
text widget could not be found? I mean, it should be there when the screen is opened, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
tbh I'm not sure, why we need the null check(s) (there's one in AdvancedGameSetupScreen::initialise, too)... I would agree that the text widget should be there when the screen is opened and it should even already be there when it is initialized...
I don't see a valid reason why it should ever not be, so I'll remove the null checks.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the main reason is that we don't have automated tests that spot NPEs like this. For instance, they can appear if we rename the UI control in the some .ui
file but not here, or vice versa, move UI controls around but forget about the code, etc.
It will be pretty apparent while testing locally, but we don't have automated tests that "click through all the screens" that would catch that...
...gy/engine/rendering/nui/layers/mainMenu/advancedGameSetupScreen/AdvancedGameSetupScreen.java
Outdated
Show resolved
Hide resolved
...gy/engine/rendering/nui/layers/mainMenu/advancedGameSetupScreen/AdvancedGameSetupScreen.java
Outdated
Show resolved
Hide resolved
...gy/engine/rendering/nui/layers/mainMenu/advancedGameSetupScreen/AdvancedGameSetupScreen.java
Outdated
Show resolved
Hide resolved
public void setUniverseWrapper(UniverseWrapper wrapper) { | ||
universeWrapper = wrapper; | ||
public void setEnvironment(UniverseWrapper wrapper) { | ||
CoreRegistry.put(UniverseWrapper.class, wrapper); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you want to persist this information in the code as comment instead of just here on this PR?
|
||
DependencyResolver resolver = new DependencyResolver(moduleManager.getRegistry()); | ||
ResolutionResult result = resolver.resolve(config.getDefaultModSelection().listModules()); | ||
if (result.isSuccess()) { | ||
environment = moduleManager.loadEnvironment(result.getModules(), false); | ||
//BlockFamilyLibrary library = new BlockFamilyLibrary(environment, context); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why is this commented out?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This was originally part of initAssets
but library
was never used afterwards.
IIRC I commented it out to see if it breaks anything and wanted to check on possible side-effects it might've been needed for. During my manual tests I didn't see any indicators that commenting it out broke anything.
I can either remove it entirely or replace it with a comment stating that this used to be done in case we see weird behavior in the future that might be related... Which would you prefer?
Contains
Merging
UniverseSetupScreen
andWorldPreGenerationScreen
incl..ui
representations.java
classesUniverseWrapper
for persisting stateHow to test
Outstanding before merging
Based on #5118.
UniverseWrapper
instead of local copies of target world and seedFollow-Ups