Wouldn’t it be cool to have a visual editor for @t0neg0d 's GUI? Well, I think so. So I’m going to learn, and try to create a module suite/downloadable plug-in which creates an editable .java class file from a visual jME interactive awt panel.
@atomix good Idea, yes. I’ll draft up an official design document and share it. read: something hopefully legible and sensible, lol. plus a video.
@t0neg0d would love to have you aboard, mostly because I would have to learn how you would like your project used in code and the conventions you would like to follow. I will be designing a " version independent model" using class generics and your get/set Methods similar to um… oh, say, testchooser.java from the jmetests has code with a similar base functionality. So when you update, the properties pane will allow them to directly set the public variables and use the get/set for the methods you provide to test functionality. I will also be adding @annotation readers if you want to provide your take on what a certain value should be in range of for the end user. (kinda like java doc that actually passes through into the .class file, if you will)
On another note, I believe I will base the project repository on GitHub, as that the core crew has set theirs there. AKA meh, why not?.
Ok, and done with first face palms and everything.
and an addendum:
On other news, I think I am going to head back to learning now, I’ll be setting up the initial outlay.
then, I will be attemping to get the awt & thread safe jme Canvas up n running in the design view.
Okay, so I’ve had mild success… :chimpanzee_facepalm:
I now have a jMonkeyEngine surface area ready inside of a netbeans environment. It is extremely buggy in that it fights with the netbeans input environment. … proba…definitely because I’m using a SimpleApplication to just test it getting fired up in there.
I notice that my code creates a new lwjgl thread in the Jme environment, which probably isn’t necessary. I don’t know how to work with the one that jme fires up for it’s own environment, yet. I will keep working at it though. and hopefully I’ll find out which important details I’m missing before I can properly instantiate and maintain a view of data when flipping between the multiview components.
If you create your own jME application then the plugin will not work in the JME SDK, just sayin’ Theres documentation in the wiki on how to write a SDK plugin, using its application etc. Wiki->SDK->Development
If you create your own jME application then the plugin will not work in the JME SDK, just sayin' Theres documentation in the wiki on how to write a SDK plugin, using its application etc. Wiki->SDK->Development
Oh, hey Normen! Okay, duly noted. Yes, the SDK Development Page over in the wiki got me started… And then… I panicked when I couldn’t read the byte codes of the .class files or be able to see any comments in the codes to help keep me on track with my design logic. (when I was coding away and needed to review the libraries I was working with) Then, I discovered that I could just go over to github and just read it as .java files. :facepalm:
So, yes, I am reading and learning about SceneApplication and implementing a SceneListener. It is of note, however, that my module will not be making/editing a .j3o file, but rather a .java/.tgve file similar to the .java/.form file. I will be making use of JME3 rendering for the absolute/relative tabs and having the generated code on the source tab.
The problem isn’t so much about the file format but about the multiple applications / render outputs, lwjgl doesn’t like that. But in the SDK you can grab the scene as you said with the SceneRequest/SceneListener and use it for anything really, this way you avoid any overlaps/issues.
The problem isn't so much about the file format but about the multiple applications / render outputs, lwjgl doesn't like that. But in the SDK you can grab the scene as you said with the SceneRequest/SceneListener and use it for anything really, this way you avoid any overlaps/issues.
I’m one step closer to getting my project to “play nice” with all the other objects in the kiddie pool.
It might be just as simple as queuing up a resize/reshape command into the SceneApplication’s thread from a parent container… though that is a pretty heavy handed way of doing things. There seems to be a problem with event consumption somewhere in the internal workings of the GDE resize/move listeners. The alternating “playing nice”/“not hearing it” behavior leads me to think this. ah well…
I’m listing these here because I will be reading until my eyes bleed while I try to get my module to work as I want. LOL
oh, and while I’m chunking down thoughts here… What is Scalability? I am using TGVE as the workhorse. the .java file as the “end product”, and the “j3o” file as like… I guess an optional way of tossing it into a game… the unreadable (for me) (JME friendly though) way of chunking it into a project. (It would be possible, I’m initially using it to store the scene for editing)… so the primary, and two secondaries one of which is definitely the “product” of this editor.
So yeah, I hope I’m on the right course for this project. It feels so slow, mainly because I’m working with other people’s ideas and cool stuff, and I’ve got to learn the correct way of working with it. (Egads, Lookups eeeek!) :explode:
Hey, thanks for the compliment. That reminds me, if any monkeys out there need voicework for a video game feel free to give me a holler. I’ll help out (mainly 'cause I know that most programmers have a hard time finding good voice actors in their social circles). I love video games, and I want to see us make some awesome ones with this engine.
Oh, and I looked up what Scalability is on the wikipedia. For software architecture, it’s the ability to handle an increasing load of complexity without slowing down the system badly. I could see how a bunch of modules with multiple file formats registered for a MultiDataObject could slow down a system. I looked at that, and went… well, duh, I’ve seen that happen when people have a ton of those widgets and taskbar programs on their windows computers. It’s like molasses… during winter… through some cheesecloth. I hope they don’t deprecate the MultiFileLoader feature though, I am targeting it so that 1: an intuitive visual interface speeds up prototyping, 2: Generated Code will help people learning java/JME, 3: The end product will (hopefully) be the “tweakable template” that knowledgeable programmers can take even further. … Much like the amazing .form/.java duo that I adore in Netbeans. I want to help us make cool tools like that.
Just doing an update for this project. It’s been about a month of reading and inching forward on code. I’m still stuck on figuring out how to register my loader properly with netbeans, at the time of this writing.