Skip to content
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

Update world gen. configuration with Component clones #1893

Merged
merged 3 commits into from
Aug 18, 2015

Conversation

msteiger
Copy link
Member

This PR changes the current property binding scheme for world gen. configuration. Previously, fields were modified directly through PropertyProvider's reflection system. This has the drawback that world gens are not notified (or only afterwards) that a parameter has changed.

This PR uses copies of configuration components and calls worldConfig.setProperty() as usual. This allows the world gen. to update accordingly (reload a height map, clear caches) or even decline the new parameter set.

I had to change handleSwitchToPreviewEnvironment.handleSwitchToPreviewEnvironment so it would update the ComponentLibrary with the new module environment. It also uses the sub-context now. Unfortunately, this update cannot be undone atm. Since this is using the sub-context only, it should be ok though.

To test this try the HeightMap world gen. or PolyWorld. Both should work nicely now even when the height map / graph density is modified.

@GooeyHub
Copy link
Member

Refer to this link for build results (access rights to CI server needed):
http://jenkins.terasology.org/job/TerasologyPRs/228/
Hooray Jenkins reported success with all tests good!

@Cervator
Copy link
Member

Tested around some, making config changes with heightmap and previewing a bunch. Looks fine. Does that cover the changes?

Pinging @flo if interested in commenting on the fun with contexts

@flo
Copy link
Contributor

flo commented Aug 16, 2015

This will propably collide with the changes @immortius made about the engine life cycle.

See his last comment on #1770

@immortius
Copy link
Member

Probably not worth worrying about my branch though, who knows when it will be ready.

@Cervator Cervator merged commit e867b74 into MovingBlocks:develop Aug 18, 2015
Cervator added a commit that referenced this pull request Aug 18, 2015
@Cervator Cervator added this to the v0.54.1 milestone Aug 18, 2015
@Cervator
Copy link
Member

Went ahead and merged it then, at least it isn't a huge number of changes to deal with :-)

@msteiger msteiger deleted the property-updates branch October 21, 2015 08:24
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants