At a second glance i get some missing imports too …
like:
Compiling 90 source files to /home/sam/project/JME/jme/testbuild
/home/sam/project/JME/jme/src/jmetest/effects/TestDynamicSmoker.java:39: package jmetest.renderer.loader does not exist
import jmetest.renderer.loader.TestMilkJmeWrite;
buildtest.xml should be fixed now.
could u please post the jars on the java.net site it seems like no matter what i do ant can’t compile the cvs
I think i read a proposal somewhere around the boards to drop buildtest.xml and integrate it as a target into build.xml, just can’t find it right now.
I think this is a good idea - especally for me as i’m using NB and it’s build-system is ant, but this works not well with multiple build-xxx.xml files.
So i’d personally be most happy with buildtest.xml integrated into build.xml as a target (like the non-core .jars) and with an additional new run - target wich executes the selected class.
This would allow one to import jme as a project with existing ant - script into NB 4.0 and 4.1 and that was it - just build with the targets and run classes with the run-target…
But maybe i’m a little late here and the majority of useres ( Eclipsoids 
) doesn’t share this preferences
I’m not sure how to change that. Do you have any suggestions?
Sorry, thwas me
BTW: is there a particular reason jme-physics is not in jme cvs ?
Hello mojo, this is just a little thougt after donwloading the new cvs…
Perhaps i misunderstood something in the new packaging, but i’m surprised that you moved the all model package outside of the core.
I thought reading .jme format (in binary and in xml) was a standard feature of the api.
However, i understand why converting from other format to jme is out of the core.
bye,
Adenthar.
hopefully i will do the the same for the editor soon, but so far so good.
Marble Fun and the Format Converter GUI also ported fine.
I thought reading .jme format (in binary and in xml) was a standard feature of the api.
If it does move to the core, then how do we best load classes that aren’t part of the core but would still need to be saved and loaded. I had always thought of saving/loading as a basic functionality (any game needs to save and load file formats) , but specific format converting as extra.
There lies the rub. Already there is a dependancy from Model to Terrain because of the loading. So, keeping that dependancy (and more) from moving into the core is not going to be easy. It may require a slight redesign on the saving and loading so that the core binary reader and writer know nothing of the classes they are saving and loading. Cep, this is your baby, so I let you make the call.
If the core know nothing of the classes they are saving, then you would have to move saving/loading files from one big JmeBinaryReader/Write that uses 50 instanceof statements to the files themselves that are saved/loaded.
IE, add a "writeMe" and "loadMe" (for example) to each class that needs to be written or loaded. Something similar to serialization, but in an XML format. Does that make sense?
That seems like a better solution anyways, this would allow users to save custom mesh types without having to touch a core class.