So, seeing that the jME SDK’s is pretty unstable, I decided to code my game in the vanilla NetBeans. But one thing that I would like to still have is the ability to browse the game’s assets through the Projects tab. Like this:
How can I “create” this layout in vanilla NetBenas? It would be much easier to program this way.
If you open an issue for anything where its unstable then i’ll make it stable within days.
You cant have that unless you create your own sdk and copy the Code. It’s called netbeans special files folder.
Or use the files tab and go with the assets folder
1 Like
Hmmm I also wonder about this unstable statement?! For me it feels pretty stable. But aybe I use only 1% of the features? Don’t think but possible 
Then it’s me who probably got an unstable SDK. I got the jME 3.1 alpha 1 SDK, although I’m using jME 3.1 beta 1.
This SDK I’m using is unstable for a couple of reasons:
- Sometimes when I write code and run the game, it’s not running the new code. Unticking “Compile on save” fixes this but it takes longeer to test the game.
- For some reason, everytime I open the SDK after using it once, I have to delete AppData, or else the SDK is totally weird and doesn’t detect projects.
- SceneExplorer tends to crash for unknown reasons
- If I open the SceneExplorer on another window (since I have two screens), it return some sort of OpenGL error and crashes the whole SDK.
I could go on, but I don’t think it’s worth it. I probably have an outdated SDK.
So, where can I get an updated one? In jME’s github?
Forgot to mention, but if I’m not careful, the SDK edits my whole NiftyGUI file and changes IDs for everything. And that’s a real pain in the ass.
Nevermind, I found the releases page on github for the SDK. I feel so “outdated”. Thanks guys!
Yes that bugs me as well. Does it happen when you accidentally open nifty graphical editor?
So even when you have the new version I want to comment on those:
Actually the first two were unknown to me, We never really had those reports.
I’ve heard that the Compile on Save is a bit bad but for me it worked well, you should always save the file and it should compile, mhh.
Those bugs are inherent from Netbeans though and not really related to our code.
The SceneExplorer, no clue why it crashes. Is the second monitor attached to the internal GPU (Intel Graphics)? If yes, it might not support the openGL version or something.
I always make sure to hit ctrl-s to be sure, I had never an issue when I hit F6 to run the game it was always from the most recent source. But I dont have a huge code base, maybe related to the amount of code or the amount of changes ?
I do the same way as you and have 1.5 mb of code (dunno is it considered as small or big code base), and never had this issue too.
One issue I had was with download the OSX tar.gz which is need if I select OSX Desktop in the project properties… It is able to download 3% or so.
That’s exactly what happens to me. And sometimes it really pisses me off.[quote=“Darkchaos, post:8, topic:37448”]
The SceneExplorer, no clue why it crashes. Is the second monitor attached to the internal GPU (Intel Graphics)? If yes, it might not support the openGL version or something.
[/quote]
No, it’s connected to my graphics card. This only happens if I separate the SceneExplorer from the main NetBeans. However, if I open a Java file on another window and then open SceneExplorer on that window, it doesn’t crash. I will give you more detalied info when I open the issue on Github. [quote=“ia97lies, post:9, topic:37448”]
I always make sure to hit ctrl-s to be sure, I had never an issue when I hit F6 to run the game it was always from the most recent source. But I dont have a huge code base, maybe related to the amount of code or the amount of changes ?
[/quote]
I actually started to gain that habit, but there’s still times where it doesn’t work. But again, I have an outdated SDK, and after I download the new one right after this post, I’ll say if these issues are still present.
Okay, so this is probably the place to say it then. @Darkchaos why do we still have the graphical nifty editor? All it does is harm. It can completely ruin your xml file, but for actual GUI design it is useless. Any thoughts from other people?
I think I gave that answer to you already but effectively you’re using beta software. The graphical editor was added when 3.1 was still pre-alpha, in the hope the creator (Nifty GUI Editor Project – Nifty GUI) would improve it further in time for 3.1. Of course it could be replaced again with the text-based editor with preview thats in 3.0 but that’d move the prospect of an actual graphical editor far off into the future. instead somebody could improve and/or fix it.
1 Like
We should leave it in 3.2 based SDKs and remove it from the 3.1 SDKs then. It’s harmful to leave it at this point since it ruins peoples’ files.
3 Likes
At the moment I have plenty of free time, and if it’s not very hard, I would like to fix the bugs in the graphical editor, and maybe improve it a little bit.
I just need to know where to start. Should I fork the jME’s SDK, or the Nifty Editor?
I didn’t look at the code myself but the Nifty Editor is the base code that is used, the core of it is designed so that it can be used in both contexts. Then there is some additional code in the SDK plugin project which “connects” the Nifty Editor code to work with the NetBeans framework (opening/saving files, windows, palette, drag&drop etc). So I guess you’d have to work with both ultimately but maybe you can start with the SDK plugin until you find bugs/issues in the core Nifty Editor code.
The fact that it rewrites the XML files is probably due to the core Nifty Editor though - thats my guess at least.
The SDK uses Swing as its UI framework, no? Your description of this bug triggered a memory of a bug report that was received by another project I contribute to, so I did some comparison and searching.
I’m wondering if this is being caused by issues with hardware acceleration (Perhaps at the Java2d/Swing level) when switching between monitors with different resolutions. If it is, it may not be easy to fix in SDK code.