Slapstick

That is the most promising I've seen yet. It is too bad I just signed a three year contract or I would send in my resume and try to convince BIS to let me telecommute from NYC (I still might). ---------- Post added at 01:58 PM ---------- Previous post was at 01:56 PM ---------- But at least it means BIS has a Java code base that requires continuous integration!

I would love to help out, but I am just about to leave town for 10 days. I'll send a note when I return. I am in NY, which should make testing a bit easier (at least time zone wise).

For me, it would give me some indication how much time and effort I should spend playing around with the the Java API in TOH. If further development is still planned, but just on hold, I will continue working with the API, looking for bugs and suggesting solutions. If the Java experiment is over then I won't waste my time.

+1 It would be nice to hear some sort of formal statement, or an informal statement from a knowledgable source (I.E. a BIS employee), about the future of the Java API. It seems a shame to invest so much effort, tout Java as the "next great thing", and then just let it languish with no further comment...

I looked through the tickets on DH and didn't see any statements saying Java would not be developed any further. In fact, Java was announced as a major scripting upgrade for A3. After all the hype about Java it seems like a huge waste of resources to put that much work into the Java API and then not develop it any further.

Well, there isn't anything specific I want to do other than play around with the Java API and provide some feedback for BIS. I am just here to play around, but there are definite areas that need improvement and I was hoping there would have been some progress over the last few months… Actually, event handlers are one thing that needs work in the current Java API. There is an RVEngine.addEventHandler method, but the event handler has to be written in SQF (as far as I can determine), so you can't stay in pure Java Land. So, at this point I would say that want you want to do is best done in SQF. However, the lack of progress or any new information has me concerned… If BIS wants to open a New York office I would be happy to apply for a job as a Java developer and help out! ;-)

I've been away for most of the summer and my Windows machine has died so I haven't been doing much with TOH. After being away for so long I was hoping to come back and find lots of new updates and more information on the Java API... but things don't seem to have progressed at all since I was last here... Is the Java API going to get any love? Are there any patches or updates in the pipeline that address some of the issues that have been raised? Now that the summer is (almost) over and I have some spare time I was hoping to get back into TOH Java programming. ---------- Post added at 06:20 PM ---------- Previous post was at 05:46 PM ---------- I have not experienced this. I have spawned several threads that call RVEngine methods but I use Thread.sleep() to pause my thread. RVEngine.sleep() is likely just a left over from porting the SQF API to Java and should likely be avoided. Having said that, I have only been attempting relatively simple tasks with relatively long sleep periods and I haven't been testing to see if I can find race conditions. All my Java code is on my dead Windows box, but basically I: jCall a Java method that starts a worker thread Call RVEngine methods from the thread. Use Thread.sleep() when I want to pause processing.

The Java crowd hasn't been getting much love recently, so I thought I would put together a simple "Java Tech Demo" to give people not familiar with Java an idea what will hopefully be in store for us down the road. I call this a tech demo because I cover too much ground and don't have time to fully explain everything. However, people should be able to follow along without too much difficulty. I was originally just going to write an article, but that quickly turned into a wall of text that most people would likely find hard to follow. So instead I've make a short (11 minutes) screencast. Acknowledgements I would like to thank the following people/organizations. BIS for giving me permission to put the jniscripting.jar on my Maven repository. [EVO] Dan for permission to use his Convoy Attack as the basis for this demo. OFPEC for allowing people to use the ofpec.com domain for Java packages (If you have a tag registered at OFPEC). Since I have registered the tag "SLAP" at OFPEC I am permitted to use com.ofpec.slap when naming Java packages, modules etc. The Video Download the video: Java Tech Demo (101MB) Notes Here is the information you see me enter into the dialog boxes, etc in the video. This won't make any sense until you watch the video, but instead of trying to write down everything I type I've included the information below. To download the settings.xml file Go to http://maven.suderman.com Right click on the settings.xml file and select Save Link as... (or whatever is appropriate for your browser). Close your browser. Open a command prompt. mkdir .m2 copy Downloads\settings.xml .m2 [*]Close the command prompt. Maven archetype information Archetype Group Id: com.ofpec.slap.maven Archetype Artifact Id: tkoh-archetype Archetype version: 1.0.0 Repository URL: http://maven.suderman.com/release The Reaper module: Group Id: com.ofpec.slap Artifact Id: reaper Version: 1.0.0 The Vehicle Respawner module: Group Id: com.ofpec.slap Artifact Id: respawner Version: 1.0.0 Modifying the mission Remove all SQF code from the init fields of the four helicopter. Give each helicopter a variable name (I used helo1, helo2, helo3, helo4). The init.sqf script Comment out the line that calls cly_removedead.sqs Add the following two lines: GameManager = jLoad "com.ofpec.slap.examples.convoy.GameManager"; GameManager jCall ["init", [helo1, helo2, helo3, helo4]]; Conclusion I have not tested this mission or the Java code. The mission may not work as advertised and may cause frequent CTDs. The intent is not to provide working code, but to give an overview of some the features available during Java development. In particular we use Maven to build our source code and handle dependency management. We don't have to edit a single line of XML, and we automagically have the source code and documentation avaiable for the "third party" modules (reaper and respawner) that we use. Enjoy!

I know others have had security/access questions as well, and yes there are restrictions on what you can do in Java. TKOH uses (seems to use) a Java SecurityManager and a custom ClassLoader which means the game should be able to exercise a fine degree of control over what user code can do. I say "seems to" because who know what the game engine really does under the hood. At the moment the security model is very restrictive, but I can definitely see the possibility for hosts to specify exactly what specific classes are allowed to do. Hopefully at some point in the future server admins will be able to say something like, "only classes in com.ofpec.salakka.servlet can open sockets". But I suspect that time is quite far off.

Well, I don't know how much TKOH would like it if the Java code started a server like Jetty; TKOH does use a security manager and opening a socket is likely not allowed (although I've never tried). Of course, you can always try tinkering with the java.policy file and see if you get anywhere. However, there are some class loading issues as well that might cause problems for now (see here and here). I have also tried using SLF4J/Logback to do some logging and didn't get very far, although to be honest I didn't try very hard. That is a good question. I suspect it works the same as it does in SQF, so if event handlers are asynchronous in SQF they are likely asynchronous in Java as well. However, I don't know SQF very well so I have no idea. I always assume if I want something to be async I have to do it myself. With RVEngine.addEventHandler. However, addEventHandler takes a GameCode object, and the only way I've found to create a GameCode objest is with RVEngine.compile, which compiles a bit of SQF code into a Java object. So you end up doing something like: GameObject player = ... GameCode code = RVEngine.compile("SLAP_GameManager jCall ['handleEvent', [1, _this]"); RVEngine.addEventHandler(player, Arrays.asList("killed", code)); ... public static Object handleEvent(Object[] args) { int type = ((Float) args[0]).intValue(); Object[] eventArgs = (Object[]) args[1]; switch(type) { case KILLED: ... } } This does work, but it seems a little silly to use Java to compile SQF that does nothing but call Java code. Hopefully, this is one of the things that will get streamlined in a future Java update.

I am trying to use the Hinds DLC from another user account on my computer. While Take On Helicopters works fine, the Hinds DLC is not available from the "Expansion" menu. Do I need to install the Hinds DLC from the second account, or did I do something wrong when I installed Hinds the first time?

Sadly, that did not work and I'm hesitant to do much more mucking around in the registry. Screwing up something that requires a Windows re-install to fix is NOT an option on this machine. The next time I need Hinds I'll try installing it from the second account and see if that fixes anything.

Anyone? I use this second account when shooting "tech demos" so I don't screw up my regular Eclipse install, but having TOH not be the same as in my regular user account is a bit of a problem. I suspect a registry issue as none of the expansions listed in my regular account show up in the second account. For example in my primary user account has the following in the expansion menu: Take on Hinds (listed twice) Jedra's Time Trials Jedra's Taxi A blank entry (can't select it so I have no idea what it is) JRE But when I start TOH from the second user account the expansion menu is empty.

No, I misunderstood you completely ;) Part of the reason I had to do so much typing is because my Maven repository isn't actually a real Maven Repository, it is just a directory structure on my web server that Apache serves file from. In particular it lacked a proper index so Eclipse/Maven didn't know what artifacts were stored on it. I've since generated the index so adding dependencies is much easier and more closely resembles the way it would work once a real repository is set up. Now to add a dependencies simply type a few letters from the name of the module (any part of the groupId or artifactId) in the Enter groupId, artifactId, or sha1 prefix or pattern (*) field. For example, if you enter com.ofp you will see all modules that contain com.ofp in the name, which is currently only the modules I've deployed. Then double click on the module you want to include and the latest version will be added to the pom.xml file. Unfortunately you still have to do all that typing to add an archetype. At least in general, for first time users I could include the archetype-catalog.xml that Maven generates/uses. Also, since I started from a brand new Eclipse install Eclipse didn't have any history to work with. But now if we want to add an updated tkoh-archetype all of the information we typed in the first time will be available in the drop down boxes so we don't have to do all that typing again. I may re-shoot the video, or at least parts of it, to reflect these changes. We might have to wait for some documentation and bug fixes from BIS before we can do anything really useful. I can see lots of really interesting things in the Java API but I have no idea how to use them...

You could create a template mission and then simply import that into Eclipse. So you wouldn't actually "extract" anything from the archetype. You could, but you would be making a lot of unnecessary busy work for yourself. For instance, I didn't talk about transitive dependencies. That is, the reaper and respawner modules make use of the com.ofpec.slap.core module, yet we never actually included that module in our project. Maven figured out that we needed it, downloaded it for us, and added the classes to the compiled output. Further, every time a module is updated you would have to download the new module, plus its transitive dependencies all over again. With Maven you simply update the version number in the pom.xml and let Maven worry about everything else. I'm glad I didn't use Gradle for the demo then as Gradle requires even more error prone typing. (I almost used Gradle, but Gradle support isn't built in to Eclipse like Maven support is and I didn't want to start with a tutorial on installing extra plugins). However, once Eclipse/Maven has an index for a repository you can select modules from a drop down list. I just forgot to show that in the demo. I'm not sure what you mean. I don't actually make any calls to RVEngine in the GameManager class, but the core, respawner, and reaper modules do. So the code will not work outside of TKOH. However, the intent of the demo was to showcase Eclipse and Maven and not TKOH/Java. I'll update the first post with a link to the video on YouTube.

Thanks Thromp. Hopefully there will be better resources than this by the time Arma and TOH come together. I was just bored waiting for the next Java update *cough* and wanted to stir up a bit more excitement in the Java community. However, after re-reading my "Conclusion" above, I think I ended on the wrong note. I have tested the mission and the Java code, I just haven't tested it extensively and I've not done any MP testing. But anyone should be able to follow along with the video and have a working TKOH mission that they can run. The bit I wanted to highlight was how easy it is (can be) to import and use external Java modules.

I suspect once the Java bandwagon gets rolling more people will jump on it. The advantage Java will have is that server side code can be written that runs on Linux and Windows servers. Alot of the functionality that coders are trying to achieve with callExtension can be done quite easily in Java (SQL databases anyone?) However, given the amount of SQF code out there it is not going to go away anytime soon. What has my interest piqued is the RVEngine.GameCode class. Hopefully, calling SQF scripts from Java will be just as easy as calling Java from SQF.

Nuke: When you are experiencing the problems open a command window (dos prompt) and run the command tracert forums.bistudio.com You should see something like: (of course, the servers and IPs will be different). That will show all the routers packets pass through on the way to the BI servers and if any are having problems. Note: some routers won't respond to pings and the request will time out, but that is ok as long as the tracert continues. As LockJaw said, since you can access the forum from work it is likely something specific to your home machine/network, or something about the route from your house to BI. A tracert might give you some indication where the problem is. Of course, if the problem is a mis-configured router between you and BI there is diddly-squat you can do about that except hope some admin catches on and fixes the problem.

Instead of doing a reformat boot from your Windows DVD to reinstall Windows. The Windows installer should detect the previous installation and give you the option to "Repair" Windows. That usually fixes most Windows problems and is a lot easier that doing a full reformat and reinstall.

I came here to report the same thing, I was getting "host not found" for the entire bistudio.com domain. Someone's DNS server is/was having problems. I would normally attribute this to a normal internet hiccup, but it seems to happen too frequently for that.

And indeed it did. The first time I tried the SQF mission I had a CTD with a popup dialog from nVidia saying the graphics card drivers had crashed and been restarted. However, subsequent attempts ran fine and both missions (SQF and Java version) worked as expected. The nVidia updater just notified me that new drivers are available so hopefully all will be good now.

I went ahead and ported (most of) the mission to Java and the Java mission works (and doesn't work) in exactly the same manner as the SQF mission. So either something has changed in the game engine or I'm still having settings/driver issues.

Thanks for the kind words! Continuing my proof of concept mission I've now thrown Scala into the mix, so I now have a single mission that combines Java, Groovy, and Scala code: // In Java.java public class Java { public static Object test(Object[] args) new Groovy().test(); } // In Groovy.groovy class Groovy { void test() { new Scala().test() } } // In Scala.scala class Scala { def test() = { import com.bistudio.jniscripting._; RVEngine.hint("Take on Scala") } } // In the player's initialization field SLAP_Java = jLoad "Java"; SLAP_Result = SLAP_Java jCall ["test", []]; The most difficult part was making Eclipse happy with a three language project, and I finally gave up on that and just compiled everything from the command line. NOTE: I am NOT recommending this as the way to mix and match classes written in different languages. This is just a proof of concept, but there is a difference between saying something can be done and actually doing that something. The process to use Scala was identical to getting Groovy working and simply involved unzipping the Scala runtime library (scala_library.jar) into the mission folder (its safe to ignore the META_INF folder and library.properties file). In fact using Scala didn't require a modified jniscripting.jar or any changes to the java.policy file (Groovy requires both). However, Scala doesn't have the same concept of static class methods that Java does. It has some syntax that looks similar, but the bytecode generated by the Scala compiler is considerably different. I only mention this because people trying other languages might experience something similar; just because a compiler generates bytecode doesn't mean it will generate the same kind of bytecode javac would generate.

This is the one comment that got me the most excited so I've decided to be one of the people to help test this claim. My language of choice is Groovy and so far I can report some success; I can use .class files generated from Groovy source code, but there are some problems. While Groovy does compile to plain .class files, the generated classes do require the Groovy runtime classes to be available on the class path. I tried putting the groovy.jar everywhere I could think of (the mission directory, beta/jre, beta/jre/lib, beta/jre/lib/ext, etc.) and nothing worked. I finally extracted all the classes from the groovy.jar file and copied them into the mission directory. Then the Groovy classes worked... sort of. While I can call and use the Groovy classes the Groovy classes seem to be unable to use the RVEngine object. I say "seem to be unable" because TOH also seems to silently swallow exceptions thrown by the code so I have no idea what is going wrong... No CTD, no error messages, no stack trace, the code just silently does nothing and the mission continues on. However, if the Groovy code doesn't try to use RVEngine I can call methods in Groovy classes from the Java code just fine. That is, the following does work: // In Sample.java public static class Sample { public static Object showHint(Object[] args) { Object obj = GSample.hint(); RVEngine.hint(obj.toString()); } } // In GSample.groovy static class GSample { static Object hint() { return "Take on Groovy" } } So the Groovy class is being recognized and loaded, but there are definitely other class loading issues going on. However, any meaningful debugging is impossible because TOH swallows any exceptions thrown. For example, while the above works, the following silently does nothing: // In Sample.java public static class Sample { public static Object showHint(Object[] args) { try { RVEngine.hint(GSample.hint()); } catch (Exception e) { RVEngine.hint(e.getMessage()); } } } // In GSample.groovy static class GSample { static Object hint() { throw new NullPointerException() } } While the game engine does have to continue when the Java code fails, we really do need to see the exceptions and stack traces during development. Are exceptions logged anywhere? The takeon.RPT file in the AppData folder doesn't contain anything and I can't find anything else logged anywhere. Having said all that, I am quite pleased with what I see so far and have high hopes for the future.

I just wanted to pop in with a word of encouragement and say that I am dying to see your finished product! Keep up the good work.