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.

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.

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 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?