I finally came around to adding Custom AppStates in the SDK (similar to Custom Controls). I call it the mother of all SDK features cause it will open up some serious possibilities for the SDK and its general use cases.
Its the first implementation and I am sure theres bugs and issues with it but if you dare you can try around with it in nightly now. Its also at the moment probably a good way to break something in the SDK’s SceneComposer severely if you try hard :D
- Separate Explorer allows adding AppStates from the projects code or libraries to an opened scene
- Gives AppStates access to a fake, safe SimpleApplication, all with assetManager and other features like GUI Node
- Fake application has not all features of full application (partially this will change, partially its inherent with the method)
- Shows any compatible beans properties of the AppState (getter/setter pairs with corresponding field) in the Properties window, editable live
- Open a j3o scene
- Go to the AppStateExplorer
- Press the “attach..” button
- Select an AppState from your code or enter a full class name in the browser that opens
- Select the AppState to see any compatible beans properties
Example use cases:
- Complete coding of games in the SDK with all tools like SceneExplorer etc. to see and influence whats happening.
- Create an AppState that spawns your NPCs (with their custom Controls ^^) or other code to test a level.
- Write some simple AppStates initialize() code to set up a scene (all with your projects assets and classes), then save it as j3o, right in the SceneComposer.
- Sometimes when first adding a new class, the class has to be compiled and the SDK restarted for the file to be recognized
- The AppStateExplorer has to be open when the scene opens to work.
- You can halt the SDK with an infinite loop
- You have to press the “update” button in the SceneExplorer to see changes in the scene.
- The save button might not light up right away when you change the scene via an AppState and you might have to change a detail in the scene via the “normal” tools to be able to actually save it.
- The getter methods of the AppStates should be thread safe in the sense that they should not trigger thread sensitive things, the calling thread isn’t guaranteed yet. The setters are always called from the update loop thread.
- Esp. accessing views, renderer etc. will atm. behave strangely, partially this cannot be fixed or only at a later point
I’m sleepy and tired and will update this with some more info later, hope you manage to have some more *fun* with it than I managed to today ;)
Created a little quixote test project to show possibilities of this new game-editor interaction for the SDK, especially for examples and newbies :D (see updated pic above for screenshot, also note some of the updated “known issues”)
- Open project
- Open AppStateExplorer
- Open Scenes/ShootOut.j3o
- Open ConfigAppState in AppState Explorer
- Enjoy reading the code and thinking how this can be used further ;)
@normen Hmm, are you sure you uploaded the correct demo project?
1. There is no scene named Scenes/ShowOff.j3o (although there is on called ShootOut.j3o) which cannot be opened.
2. There is no ControlAppState class available in that zip-file.
So, I played around with this in a normal RC2 install with nightly updates enabled and at first my local project worked, the zip export not… When looking for why I found it out: Somehow new classes are only registered when the project is first opened, you have to restart the SDK to make it scan the classes again. So the solution to use the project would be first compiling, then restarting the SDK. After that new compiles *should* be registered so if you reopen the j3o or AppState the new classes will be in effect.
So, something to work on for me, the base systems for scanning classes etc. are relatively fresh and came with the Custom Controls feature. Guess it can be improved ;)
I think I found the issue. Because the “build/classes” folder doesn’t exist when the project is first created its not part of the list of source folders I get for that project. So theres also no listener registered on it to check if there was changes in that folder Hence a rescan is never triggered if the build/classes folder wasn’t there in the first place.. Fixed that in svn and also added a generally more robust change check.
I did a major overhaul of the node system and how it reads/writes its data and issues change events. This should avoid some strange issues with freezes and maybe also some random scene errors as the threading is much more straight now. This also makes the getter calls for Controls and AppStates be called from the right thread at all times.
Finally, this allows the SDK to sense changes in the scene even if they were not initiated by the SDK
Theres some issues with reading enum values still though.
Again a great job from normen, you must work as professional developer and not music !
Thanks for your work and this brilliant idea !
Hehe, thanks, I’m flattered Though its quite easy to improve a mess you created yourself ;) Some parts of the SDK have really been done quick’n'dirty as I wanted to get the whole package / point of the SDK across. Kirill put my obsessive self in a bad situation of “you gotta get this working, people will use it” by deciding we’d bundle the SDK and the engine ^^
But I have to say I am quite pleased with the results by now. The deployment to different platforms, model import, editing of particles etc.. I knew I (and everybody else) would implement that anyway when I’d go at actually doing a game, just like I did for jME2. I think the SDK is for many people replacing all those little tools and its by now even growing up to be comparable to the commercial packages like UDK and Unity, given how much more powerful the engine also grew beneath it
But yeah, theres still a few things to clean up.. Its kind of hard getting together the logic of a 3d engine, a swing editor framework and the general idea of “creating games” but we’ll crack that nut, I swear ;)
So.. @all, I am running into a logic/usability issue that I think I have the answer to, still I want to put it out here.
Currently, the rootNode of the fake application you work with is the same node as the loaded model. This means that from the perspective of the AppState there is no rootNode that the model is attached to but only the model node. While this is intuitive when looking at the scene and coding the AppState, I guess its less so when actually working with the scene and AppState later. When you have an application you could of course replace the rootNode with a loaded j3o but I guess that really makes no sense at all.
So in the end I guess the AppStates should get the “real” rootNode of the application, this way it makes most sense structurally. This would of course bring some usability/intuitiveness issues. For example you can attach stuff to the rootNode but you cannot save it in the editor or j3o. Of course this could be deemed a feature, in the current example Quixote will be saved in the j3o when you hit save while he’s running. Further you have to know the name of the scene you load to get the model. On the other hand that model is at the same time the only attached spatial to the root node when you open a model, so not exactly a problem either.
So, I say “real rootNode instead of model node”, k?
Btw, just because its so much fun I added TextureAtlas batching to the SDK (fixed 4096 texture size for now) and made the geometry batching undo work ;) So you can now batch geometry even if it has different textures and also undo if you falsely batched/optimized a part of the scene.
I added starting via the java file and editor menus ;) I also fixed most bugs that were left, see the updated first post. It now nicely updates every 1s when the scene changes. For now only the selected node is scanned “live” and scene change don’t trigger the save button (because of that).
You must be logged in to reply to this topic.