Hi monkeys,
I finally found some time to participate in this fine community again and eagerly tried out the beta. Now, although it’s smoothly working 
I found that the built-in support of groovy has been removed within JMP. I really liked the option and used it in my project. Cannot we just agree on groovy being the scripting language of choice for JME and include it again as an optional library? Sure I know that I can just add the needed jar myself but the old way was very convenient. Guess that it’s the domain of @normen.
Cheers
1 Like
Thank you! You’ve just solved my scripting language problem - I wanted a language that I could embed but allow users to modify the scripts if they wanted to, without needing a platform specific binary like I would for LuaJava. This works great! At first I thought I could only use it compiled into Bytecode, but it turns out, that can be done on the fly.
@Dodikles said:
I found that the built-in support of groovy has been removed within JMP.
When did it exist? I didn't knew they came with jMP.
btw, I just added, I just added groovy embaded jar and it was good to go.
still waiting for @pspeed 's 3 page essay on why groovy rocks ^_^, when in reality its only cus he likes the name of it 
Actually, I’ve always kind of disliked the name. There used to be this networking/collaboration thing called Groove. And they always called Groove apps “groovy code” or something. We had an object sync library we wrote based on JavaGroups and were constantly trying to explain to the non-technical why that wasn’t the same as Groove. (We even named the tech a recursive acronym like PINE [pine is not elm] just because it was so prevalant [xing is not groove]).
So I already had a lot of bad reactions ready the first time I heard the name “groovy”.
Since groovy is so similar to Java it is a natural fit. Both it and Javascript seemed to have much thinner integration layers than the other scripting languages… which makes a lot of sense. Much less to adapt. But unlike JavaScript, there are a lot of really nice language features for doing things you find yourself doing a lot. I still kind of a noob and sometimes I really feel that (when do I use “def” again?)… but it’s still fun figuring stuff out and the Groovy Mythruna integration is very far along now. Last night I added an IP-ban script in about 20 minutes including the admin commands to manage the IP list.
I like the fact I can write an interface in Java, use that interface in a Groovy class, and then instantiate an instance of that groovy class at runtime, and cast it to the Java interface. Quite impressive.
Plus I have a feeling that when I load a class at runtime, it is compiled to bytecode anyway, so its probably pretty fast. Anyone know details?
Now I need to find a convenient way to save/load objects. I looked at XML and XMLEncoder/XMLDecoder, which works with JavaBeans. However, its not quite working properly. I think it might have something to do with the fact that Vector3f, a data type used in one of the classes I want to store in XML, does not implement java.io.Serializable. I definitely cant subclass every class I use to make sure they inherit that interface, so if that is a condition then I’ll have to look elsewhere. I can do it in Groovy but I want a language more suited to storing lots of data. Last resort will be CSV files.
JME has a system for saving/loading objects. I’ve never used it but it would handle Vector3f and the other primitives, that’s for sure.
I want the format to be user editable though - ie not binary.
Turns out decoder.readObject() was throwing an IndexOutOfBounds exception - kinda surprising it doesnt handle it internally and just return null.
I’ll just use XMLDecoder - it suits my needs quite well. Doesnt really matter that it cant read/write Vector3fs - I’ll get around that if I really have to but its unlikely to be a problem.
My only remaining concern is that I need to make sure the library is supported under Android.
your mums so fat, she causes buffer overflow
@ancalagon said:
I want the format to be user editable though - ie not binary.
JME can store to XML, too as I understand it. Again, I've never tried it.
Personally, I tend to find "automatic XML" and "user editable" to not be so compatible... but it _is_ better than binary. :)
@wezrule
My mom died 4 years and 12 days ago so its probably not her.
@pspeed
Oh… well too late now! Its already working fine. In fact if anyone is curious, this is my code:
[java]/*
- To change this template, choose Tools | Templates
- and open the template in the editor.
*/
package RPGEngine.Game;
import java.util.Enumeration;
import java.util.LinkedList;
import java.util.Queue;
/**
*
-
@author Jonathan
/
public class LinkedListEnumeration<T> extends LinkedList<T> implements Enumeration<T>
{
public boolean hasMoreElements()
{
return !this.isEmpty();
}
public T nextElement()
{
return this.pop();
}
}
[/java]
[java]/
- To change this template, choose Tools | Templates
- and open the template in the editor.
/
package RPGEngine.Repositories;
import RPGEngine.Game.LinkedListEnumeration;
import java.beans.ExceptionListener;
import java.beans.XMLDecoder;
import java.beans.XMLEncoder;
import java.io.;
import java.util.ArrayList;
import java.util.logging.Logger;
/**
*
-
@author me
*/
public class XMLRepository<T extends Serializable> extends LinkedListEnumeration<T>
{
protected XMLDecoder decoder;
protected XMLEncoder encoder;
protected String fileName;
public XMLRepository()
{
}
public XMLRepository(String file)
{
readFromFile(file);
}
private void readFromFile(String file)
{
fileName = file;
try
{
FileInputStream fis = new FileInputStream(fileName);
BufferedInputStream bis = new BufferedInputStream(fis);
decoder = new XMLDecoder(bis);
}
catch(Exception e){}
if(decoder != null)
{
try{
T object = (T)decoder.readObject();
while(object != null)
{
this.add(object);
object = (T)decoder.readObject();
}
}
catch(Exception e)
{
Logger.getLogger(XMLRepository.class.getName()).log(java.util.logging.Level.INFO, null, “failed”);
}
}
finalizeCollection();
decoder = null;
}
public void writeObjectToFile(T object, String file)
{
FileOutputStream fos = null;
BufferedOutputStream bos = null;
try
{
fos = new FileOutputStream(file);
bos = new BufferedOutputStream(fos);
encoder = new XMLEncoder(bos);
}
catch(Exception e){}
if(encoder != null)
{
encoder.writeObject(object);
encoder.flush();
encoder.close();
}
try
{
fos.close();
bos.close();
}
catch(Exception e){}
encoder = null;
}
public void finalizeCollection()
{
}
}
[/java]
Yes I should probably do something with the exception that is caught instead of swallowing it. This was test code, that turned out to work rather well. finalizeCollection is a method I overwrite in subclasses - it allows me to do any processing after loading the list. Sometimes necessary. I would make it abstract, but I’m thinking it might be quite handy to instantiate this class directly.
1 Like
@ancalagon said:
My mom died 4 years and 12 days ago so its probably not her.
ahh sh*tttt, now i look like a dick, sorry man
it wasn't directed at you, i just thought of it and had to post it somewhere
Dont worry about it.
2 Likes
@wezrule said:
ahh sh*tttt, now i look like a dick, sorry man
This is not the first time. What's the point of saying sorry over and over again when you are not actually learning from it?
@ancalagon sorry to hear about your loss!
1 Like
Thanks.
1 Like
i don’t think before i say anything :s, i don’t intentionally want to offend anyone :(, its always by accident. Sorry again 
@Dodikles said:
Cannot we just agree on groovy being the scripting language of choice for JME and include it again as an optional library?
Yeah, groovy very much looks like the language of choice for something like that though its very very high-level, probably very game-specific and implementation wise probably easy to replace with any scripting language when done, through javas excellent scripting support.
When the scripting becomes a topic for the core engine we probably already have a base entity system for things like MMO's etc, that don't work via the graphics update loop.
@Dodikles said:
Thanks a lot @normen aka lifesaver
No problem, as long as you don't install Eclipse before asking if it could be done in the SDK... ;)
1 Like
