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

Re-introduce the "Advanced" menu (for monitoring) with multiplayer compatibility #692

Open
Cervator opened this issue Sep 23, 2013 · 8 comments
Labels
Category: Build/CI Requests, Issues and Changes targeting gradle, groovy, Jenkins, etc. Category: Performance Requests, Issues and Changes targeting performance Multiplayer Affects aspects not visible in Singleplayer mode only Topic: Architecture Requests, Issues and Changes related to software architecture, programming patterns, etc.

Comments

@Cervator
Copy link
Member

Cervator commented Sep 23, 2013

During the multiplayer overhaul the advanced monitoring stuff has been sidelined a bit with all the changes (I forgot if we already discussed this @immortius - let me know / add some details if you like). Need to refactor it with multiplayer compatibility and maybe extend it to also do some server-side monitoring.

Unsure if this should be entirely inside the engine or involve a monitoring-style Facade. Ideal candidate for this would be @mbrotz - come baaaaaaack! :D

@immortius
Copy link
Member

Advanced monitoring is all still in multiplayer - the advanced config was removed but it was mostly unnecessary (and dangerous) data representation settings.

I would like to see the monitoring combined with TeraEd as a facade.

@mbrotz
Copy link
Contributor

mbrotz commented Sep 23, 2013

Hi Cervator...

I would like to help with the monitoring stuff... Just so little time... :( I'm very glad, tough, to see how much progress terasology makes! :)

@immortius, what do you mean with facade? How would i have to change the existing code?

Greetings, mbrotz

@immortius
Copy link
Member

Facade is an element of our upcoming restructure - a facade is... basically
a wrapper around the core terasology library that makes it runnable for a
system. So the applet would be one facade, the application another, an
android wrapper would be a third. TeraEd would be another, similar to the
application but adding a frame with various tools. Currently TeraEd allows
some runtime messing around with select shader params, but it could do so
much more.

On 23 September 2013 18:10, mbrotz notifications@github.com wrote:

Hi Cervator...

I would like to help with the monitoring stuff... Just so little time...
:( I'm very glad, tough, to see how much progress terasology makes! :)

@immortius https://github.com/Immortius, what do you mean with facade?
How would i have to change the existing code?

Greetings, mbrotz


Reply to this email directly or view it on GitHubhttps://github.com//issues/692#issuecomment-24904327
.

@Cervator
Copy link
Member Author

Cervator commented Sep 23, 2013

Hey @mbrotz - good to see you! :-)

There is some theory / brainstorming about the restructure here: https://forum.terasology.org/threads/codebase-restructuring.815/ and updates as part of The Great Convergence here: https://forum.terasology.org/threads/the-great-convergence.826/

@immortius - thanks for the details, good to know that the monitoring stuff is hiding in there somewhere (was almost certain it had come up somewhere, but couldn't find/remember). How do you then actually enable it right now? May not matter if we aim for a facade for it sometime, makes sense :-)

@immortius
Copy link
Member

It can be enabled through the config file, which I think is adequate for a debugging feature. I'm not sure it is completely hooked up correctly - specifically, it complains about chunks being recreated, but the other system that detects these problems doesn't complain so I think it isn't receiving chunk disposal events.

@mbrotz
Copy link
Contributor

mbrotz commented Sep 24, 2013

@Cervator, thanks for the links!
@immortius, thats correct, the chunk monitor is not recieving chunk disposal events. I am using weak references because i was suspecting that some of the chunks might be memory leaked somehow because i noticed that already existing chunks are sometimes recreated. But that was because of other bugs which i fixed. I think it would be best to change the chunk monitor to use the proper events for creation, loading and disposal.

@Cervator
Copy link
Member Author

Cervator commented Nov 5, 2013

Bump - wanted to link this to Nanoware#26 for when we get a chance to look at it :-)

@mbrotz - hope you're still out there and doing alright!

@Cervator
Copy link
Member Author

Zombie bump! @flo ran into this while hunting for disposal issues and I am just amazed it still works! Especially with stackable chunks. But yep, the chunk map still populates and updates live and the thread monitor looks great.

Adding this note in particular to point out when this is resurrected we need to make sure it disposes correctly as if it currently is enabled (via hack or config) it will keep the game from closing all the way. Adding bug flag for that piece.

(/me waves to @mbrotz)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Category: Build/CI Requests, Issues and Changes targeting gradle, groovy, Jenkins, etc. Category: Performance Requests, Issues and Changes targeting performance Multiplayer Affects aspects not visible in Singleplayer mode only Topic: Architecture Requests, Issues and Changes related to software architecture, programming patterns, etc.
Projects
None yet
Development

No branches or pull requests

3 participants