A long time ago I was under the impression libgdx used jBullet (Bullet 2.72) for the 3d physics. However, to my warm surprise this is not the case at all. It is actually using (Bullet 2.81rev2613) which means its light-years more evolved than jBullet. There are a few other factors that make it better overall, but it uses unmanaged memory with a garbage collector as a fallback. I find it oddly funny how hard it is to find out what version of Bullet libgdx was using. I ended up having to look through the revision history for information on it.
So maybe this little post will help anyone else who is curious about it.
July 17, 2013
July 8, 2013
Modding KSP with Scala
TL:DR Just use C# for making addons with KSP, it really isn't worth spending all the extra effort to use a JVM language.
Getting Java 1.7 to work as a mod with Kerbal Space Program is 'easy'. However, the same trick appears to not be able to work with Scala 2.10. It looks like the bridge between Scala and C# is just a bit too far. However, it isn't the end of the world because it still works.
IKVM.NET is pretty good, it does the job well and actually makes the whole thing possible. However, there is one big catch that really hurts when working with KSP. I'll quote the author:
First limitation: Currently only custom attributes that have a default constructor or a single one-argument constructor (taking a supported type) are supported.
The second limitation is that not all parameter types are supported, only the Java primitive types (where Java's byte maps to System.Byte), type literals, strings and enumerations are supported (and single dimensional arrays of these types). Custom attribute parameters typed as Object are not supported.
Java
The issue is most things in KSP work by using attributes and thus IKVM.NET will choke on a number of these attributes. However, there is a way around it: inheritance. If you take an attribute and subclass it (to meet the above limitations) IKVM.NET will happily work with the attributes. This does mean you have to write a C# adapter to provide attributes you can use as interfaces in the JVM world. Below is an example of what I mean:
public class EditorAnyAttribute : KSPAddon {
public EditorAnyAttribute() : base (KSPAddon.Startup.EditorAny, false) {}
}
Doing all that you can compile your java jar into a dll and slap it into the Plugins folder for your mod, just like you would normally put in your C# dll. However, you also need to put in the IKVM.Runtime.dll and the IKVM.OpenJDK.Core.dll (totaling just over 5MB). If you use some of the other classes, you will also have to provide dll for them as well.
This means your plugins folder will look like this:
[mod].dll
[ksp_attribute_layer].dll
IKVM.Runtime.dll
IKVM.OpenJDK.Core.dll
Pretty gross.
Scala
Now if you simply try to apply the same process to Scala, it won't work. There is an issue between the annotations generated for attributes by IKVM.NET and how Scala expects an annotation to work. The end result is scalac will complain the annotation is not defined. It will insist it is not defined and cowardly refuse to believe in it. This means you need another adapter in Java to actually use the annotation and then from the Java code you can call your Scala code. Another nice catch is you will also need to use IKVM.NET on the scala-library.jar to use any of the Scala objects, but out of box this doesn't work.
I'm going to assume I will need to apply proguard onto the scala-library.jar first with my jar file to strip it down only to the tiny bits I'm actually using (sounds very much like the Scala workflow for Android).
This means if you want to use Scala your plugins folder will look like this:
[mod w/ java wrapper].dll
[ksp_attribute_layer].dll
scala-library.dll
IKVM.Runtime.dll
IKVM.OpenJDK.Core.dll
IKVM... (other IKVM libraries depended on by Scala)
At the end of the day, yes you can use Scala to make a mod for KSP, but you are going to have to use 3 languages and 2 tools to make it happen. Your mod is going to be a massive binary blob to even make the simple things run. This means KSP loading time will also be increased by the fact you are now loading a number of extra dlls.
In conclusion, you can do it and in order to keep yourself sane you are going to need to automate the whole process because its going to be painful (Gradle for example). Additionally, you will need to write code to fill in the gaps between C#, Java and Scala. Using Java isn't quite as bad and reduces the number of steps required to build a mod, but you still are going to need to use some C# to hook it up for working with some of the attributes. This basically means you might as well just do the whole thing in C# and not spend the time making things compatible.
Getting Java 1.7 to work as a mod with Kerbal Space Program is 'easy'. However, the same trick appears to not be able to work with Scala 2.10. It looks like the bridge between Scala and C# is just a bit too far. However, it isn't the end of the world because it still works.
IKVM.NET is pretty good, it does the job well and actually makes the whole thing possible. However, there is one big catch that really hurts when working with KSP. I'll quote the author:
First limitation: Currently only custom attributes that have a default constructor or a single one-argument constructor (taking a supported type) are supported.
The second limitation is that not all parameter types are supported, only the Java primitive types (where Java's byte maps to System.Byte), type literals, strings and enumerations are supported (and single dimensional arrays of these types). Custom attribute parameters typed as Object are not supported.
Java
The issue is most things in KSP work by using attributes and thus IKVM.NET will choke on a number of these attributes. However, there is a way around it: inheritance. If you take an attribute and subclass it (to meet the above limitations) IKVM.NET will happily work with the attributes. This does mean you have to write a C# adapter to provide attributes you can use as interfaces in the JVM world. Below is an example of what I mean:
public class EditorAnyAttribute : KSPAddon {
public EditorAnyAttribute() : base (KSPAddon.Startup.EditorAny, false) {}
}
Doing all that you can compile your java jar into a dll and slap it into the Plugins folder for your mod, just like you would normally put in your C# dll. However, you also need to put in the IKVM.Runtime.dll and the IKVM.OpenJDK.Core.dll (totaling just over 5MB). If you use some of the other classes, you will also have to provide dll for them as well.
This means your plugins folder will look like this:
[mod].dll
[ksp_attribute_layer].dll
IKVM.Runtime.dll
IKVM.OpenJDK.Core.dll
Pretty gross.
Scala
Now if you simply try to apply the same process to Scala, it won't work. There is an issue between the annotations generated for attributes by IKVM.NET and how Scala expects an annotation to work. The end result is scalac will complain the annotation is not defined. It will insist it is not defined and cowardly refuse to believe in it. This means you need another adapter in Java to actually use the annotation and then from the Java code you can call your Scala code. Another nice catch is you will also need to use IKVM.NET on the scala-library.jar to use any of the Scala objects, but out of box this doesn't work.
I'm going to assume I will need to apply proguard onto the scala-library.jar first with my jar file to strip it down only to the tiny bits I'm actually using (sounds very much like the Scala workflow for Android).
This means if you want to use Scala your plugins folder will look like this:
[mod w/ java wrapper].dll
[ksp_attribute_layer].dll
scala-library.dll
IKVM.Runtime.dll
IKVM.OpenJDK.Core.dll
IKVM... (other IKVM libraries depended on by Scala)
At the end of the day, yes you can use Scala to make a mod for KSP, but you are going to have to use 3 languages and 2 tools to make it happen. Your mod is going to be a massive binary blob to even make the simple things run. This means KSP loading time will also be increased by the fact you are now loading a number of extra dlls.
In conclusion, you can do it and in order to keep yourself sane you are going to need to automate the whole process because its going to be painful (Gradle for example). Additionally, you will need to write code to fill in the gaps between C#, Java and Scala. Using Java isn't quite as bad and reduces the number of steps required to build a mod, but you still are going to need to use some C# to hook it up for working with some of the attributes. This basically means you might as well just do the whole thing in C# and not spend the time making things compatible.
Kerbal Space Program Modding
At the time of writing (KSP 0.20.2) modding Kerbal Space Program is actually rather trivial.
When I say trivial, there is a very nasty catch to the whole modding process. You need to be relatively familiar with some of the Unity Engine code AND you need to be ready to figure out how to use undocumented code. Fortunately, there is a nice guy in the modding community who has come along and helped ease this process by creating some XML documentation on github.
It isn't really enough, because the documentation is very skimpy and the biggest issue is figuring out how everything hooks together. Of course, if you plan to simply add a few parts to KSP that is a very dead simple and well documented process. On the other hand, if you plan to add a complex new set of features to KSP, you are going to have to learn by example from the source code of other mods.
If the guys at Squad (people who created KSP) really want to make plugin developers not cry, and do a better job of modding the game, they need to publicly expose some of there API so that modders have a much smaller learning curve.
I looked at a few mods and re-created the sub-assembly mod to work with the 0.20 plugin system as a test. My next task is to port it over to Scala to test my Scala -> IKVM -> KSP workflow.
I'm at a disadvantage already because of a lack of experience with C#, but I've used the language before and can easily learn it because of my experience working in a number of languages. Right now I'm really curious to see if I can easily integrate JVM languages as a viable modding option for KSP. I mentioned IKVM in my previous post, but I also came across jni4net.
My current issue with IKVM is the huge amount of bloat required to simply add a minor feature to KSP (I have to add in 5MB of dll just to log "hello, world" from Java. On the other hand, jni4net acts as a bridge between the languages using proxy classes and is significantly smaller, but its Windows only, requires 64-bit java, etc.
The end result, my only real option is to use IKVM if I want to develop mods for KSP using a JVM language.
When I say trivial, there is a very nasty catch to the whole modding process. You need to be relatively familiar with some of the Unity Engine code AND you need to be ready to figure out how to use undocumented code. Fortunately, there is a nice guy in the modding community who has come along and helped ease this process by creating some XML documentation on github.
It isn't really enough, because the documentation is very skimpy and the biggest issue is figuring out how everything hooks together. Of course, if you plan to simply add a few parts to KSP that is a very dead simple and well documented process. On the other hand, if you plan to add a complex new set of features to KSP, you are going to have to learn by example from the source code of other mods.
If the guys at Squad (people who created KSP) really want to make plugin developers not cry, and do a better job of modding the game, they need to publicly expose some of there API so that modders have a much smaller learning curve.
I looked at a few mods and re-created the sub-assembly mod to work with the 0.20 plugin system as a test. My next task is to port it over to Scala to test my Scala -> IKVM -> KSP workflow.
I'm at a disadvantage already because of a lack of experience with C#, but I've used the language before and can easily learn it because of my experience working in a number of languages. Right now I'm really curious to see if I can easily integrate JVM languages as a viable modding option for KSP. I mentioned IKVM in my previous post, but I also came across jni4net.
My current issue with IKVM is the huge amount of bloat required to simply add a minor feature to KSP (I have to add in 5MB of dll just to log "hello, world" from Java. On the other hand, jni4net acts as a bridge between the languages using proxy classes and is significantly smaller, but its Windows only, requires 64-bit java, etc.
The end result, my only real option is to use IKVM if I want to develop mods for KSP using a JVM language.
July 3, 2013
Kerbal Space Program + IKVM + Scala
Lately, most of my time has gone towards Kerbal Space Program. At first the game is very frustrating and has a very high learning curve, but you should expect that when the point of the game is rocket science. Minecraft is making significant progress towards its modding with the recent release of 1.6.1; however, it still has a long ways to go before I will consider actually attacking it with my ideas. KSP on the other hand already has full support for modding, but the game has Unity limitations (32-bit/single threaded), which is unfortunate but also offers large benefits of rapid development because of all the tools and assets provided by the engine.
The kicker is I would need to develop in C# to make a mod. There is nothing wrong with C# and infact it has some huge improvements over Java in many of the language related points. However, Scala makes C# look pretty bad (okay LINQ is still kick ass) and why spend the time monkeying around with C# when I could simply use Scala?
The bridge between Java and C# is called IKVM, there might be others but that is the one I know is used by projects such as LibGDX for compling to non-Java platforms (iOS). It does work pretty well and I know IKVM can be used with Scala without any real hiccups.
The big question is how well can I minify all this into a plugin for KSP?
Even bigger question is will it even work and will it work relatively well?
I expect issues, hiccups and probably making myself want to give up. I will end up reporting progress and information here as I work on it, although I admit I seem pretty bad at that.
The kicker is I would need to develop in C# to make a mod. There is nothing wrong with C# and infact it has some huge improvements over Java in many of the language related points. However, Scala makes C# look pretty bad (okay LINQ is still kick ass) and why spend the time monkeying around with C# when I could simply use Scala?
The bridge between Java and C# is called IKVM, there might be others but that is the one I know is used by projects such as LibGDX for compling to non-Java platforms (iOS). It does work pretty well and I know IKVM can be used with Scala without any real hiccups.
The big question is how well can I minify all this into a plugin for KSP?
Even bigger question is will it even work and will it work relatively well?
I expect issues, hiccups and probably making myself want to give up. I will end up reporting progress and information here as I work on it, although I admit I seem pretty bad at that.
Subscribe to:
Posts
(
Atom
)