Use JME to save config data or not?

General Discussion
1

Hello,

after a few weeks of no activity I am back to do a few lines on my small project.

I would like to save specific user data to file. Currently I dont know exactly what kind of data I may need to store but it could be things like:

  • username
  • font size
  • preferred colors etc.

I am not sure if I should use the JME exporter/importer to do so or if I should just implement a Java standard save/write to file.

As I understood from the article JME can save only nodes to file?
So I do need to create a class

class myconfig {
Int Param1;
String Param2;
...
}

that I set as userdata of a node in order to save everything?

And in general:
What are the suggested approaches if saving configurations (to file) is needed?

I am open for all input.

2

IMO, you should use the JME importer/exporter, but not in the way you described.
It actually is capable of saving anything that implements Savable, so you can save the shenigans with the node.
It’s even in the wiki bit you linked, under “custom savable class”.

1 Like
3

I have read that part about “custom savable class” too, but it seems I have misunderstood it.
And I am still not sure if I need to add the custom class to a node or not.
The example code is just showing the export of the class. So I guess I wont need to add it to a node before exporting.

Is there more reading about the JMEexporter? The example code gives me no idea how to specify the location where the exporter stores the file.

4

I think you need something like BinaryExporter.export() and can specify a file stream there definitely.
The Background is: JME has two export formats: binary and XML (iirc)

5

And in the end it’s just another option that’s entirely based on requirements. For example I generally store options files in Json/text so its editable. For things like game objects, though, I’m looking at size, not readability. In that case I would probably use irregular formats with Data packed in various ways, including not wanting to ruin a drive with thousands of little files (e.g. terrain chunks/cells). There is always sql/SQLite/nosql too.

TLDR; it depends entirely on what you’re saving.

1 Like
6

Thanks for the replies to all.

It took me a while to make it run as I tried to use the class like

JmeExporter Jex = new JmeExporter
...
myconfig.write(jex)

which of course did not work. Also with the help of the example in TestSaveGame.java I could only save something, but not load.

Finally I found a solution with the BinaryExporter and BinaryImporter

       myconfig mc = new myconfig();

       BinaryExporter exporter = BinaryExporter.getInstance();
        File file = new File(URL+"testsave");
        try {
            exporter.save(mc, file);
        } catch (IOException ex) {
            Logger.getLogger(Main.class.getName()).log(Level.SEVERE, "Error: Failed to save game!", ex);
        }


        BinaryImporter importer = new BinaryImporter();        
        try {
            myconfig  import = (myconfig) importer.load(new File(URL+"testsave"));
            import.getSomeIntValue();
        } catch (IOException e) {
            e.printStackTrace();
        }

myconfig is the class defined in the example.

In the end I just missed the importing part in the example but could find (as usual) help by searching the forum.

I dont have experience in using the Jme exporter or importer but on a first look I dont see a huge difference between Jme and some pure Java examples.

@jayfella
You are right with requirements. I may have some editabe files and some that will just store a few variables.
I will read a bit about Json/text.

1 Like
7

You might also want to try the SaveGame class.
It’s really rather easy to use. You pass in a name for the save file, and the savable object you want to save. Done.

1 Like
8

JME’s export/import is convenient for JME objects… but I’m of the opinion that it’s pretty much garbage for anything else. Frankly, you’d probably be better served by Java’s standard serialization in the case you just want binary junk in a file.

There are many options, of course.

3 Likes