I’ve written a small plugin to visualize the heightmap from a TerrainGrid in runtime. It’s a sort of mini-map but it lives in the SDK.
The purpose was mostly to learn about writing plugins and also to try out using JMX to connect to a running jME application and instrument it.
https://bitbucket.org/zoom/zoom-jme/wiki/TerrainInspectorSS.png
Documentation and Source lives at BitBucket.
I don’t rightly know how useful terrain inspection is in itself. I do however believe that instrumenting running jME applications have many uses. For example drawing a graph of the FPS in the SDK, inspecting the scene graph, enabling/disabling appstates in a running application, and what have you.
Using JMX is one way to do so. My conclusion is that it certainly works. It has some drawbacks but it also offers some interesting possibilities. I’ve written about some of this here.
Very nice 
Cool but we could use Java7 to compile on the build server as well, if the plugins that as supposed to be “baseline compatible” just specify their source level it should still work. The engine for example does that. Was the build issue what I mentioned in the commit comment?
normen said:
Cool but we could use Java7 to compile on the build server as well, if the plugins that as supposed to be "baseline compatible" just specify their source level it should still work. The engine for example does that. Was the build issue what I mentioned in the commit comment?
As for Java7: Yeah sure, I can backport - I was just lazy with diamond operator and such, nothing major, should work on Java6 runtime (I think).
As for build stuff: I'm hoping to get these into the contrib-repo when they matured a little. It was just easier to hack it on my own side to get them to work. I also wanted to learn how to set up CI builds of NB modules anyway (for other projects) and it was just quicker to get it set up on my own.
The build issue was what you mentioned but then some other things too. I spent almost a day getting my layer.xml to work only to find out it was a caching issue in the platform and it actually did work after the first fix, found it by installing from my update center instead of from local nbm :cry:
Yeah, best test in the SDK with a testuserdir. You can clean&build it then to clean out cruft. Still you can quickly run single plugins. The thing is if you e.g. change something in a plugin, then go to a plugin that depends on it and just run the latter, the first one will not be built, only if you either run the whole suite or manually compile the first plugin.
Let me tell you that I cleaned and built the module, the suite, my whole outlook on life, my feelings for netbeans and a lot of things Some gawdamn cache held on to the layer.xml and just did not understand the changes. What I should’ve done is as you say, used a testuserdir. Which accidentally I found out when installing from my CI build (no cache there) and it worked, oh well, you live and learn :roll: