Jump to content
Sign in to follow this  
looter

ARMA 3 Alpha - Java Virtual Machine

Recommended Posts

I was wondering if the Alpha will contain any of the functionality of the planned JVM support mentioned here? Would love to get a head start on developing with it, but I seem to remember it kind of being up in the air a few months ago - any news?

Share this post


Link to post
Share on other sites

Hi, the Alpha will not sorry to say. We are not happy to include it until we can support it with updates and fixes.

Share this post


Link to post
Share on other sites
Hi, the Alpha will not sorry to say. We are not happy to include it until we can support it with updates and fixes.

Will the callExtension mechanism be supported?

Share this post


Link to post
Share on other sites
Hi, the Alpha will not sorry to say. We are not happy to include it until we can support it with updates and fixes.

This is an absolutely heartbreaking disappointment.

Does BIS at least acknowledge what an abomination SQF is, and do you plan to offer any sane alternatives in the future?

Share this post


Link to post
Share on other sites
Will the callExtension mechanism be supported?

It was not purposefully removed from Arma 3. On the other hand it's not functionality we use in vanilla content, so I do not believe it was tested. Therefore it should be in Alpha, but I cannot guarantee it.

We have not abandoned Java, and we want Object-Oriented scripting.

Share this post


Link to post
Share on other sites
It was not purposefully removed from Arma 3. On the other hand it's not functionality we use in vanilla content, so I do not believe it was tested. Therefore it should be in Alpha, but I cannot guarantee it.

Thanks for the info. I was thinking of trying to make it possible to script in e.g. lua with this, provided the interface is capable of that, and I was dreaming about an external debugger of sorts.

We have not abandoned Java, and we want Object-Oriented scripting.

Great to hear. My major gripe with SQF is that it seems to be very difficult to get an "off-line" semantic check going. More than once, running the program is the only way to find syntax errors. With a well-supported external scripting/programming language like LUA or Java, it would be easier to do, and in the long run, I think that this would benefit mission builders greatly because even those branches of execution that are usually neglected/rarely run would at least not cause syntax errors.

Share this post


Link to post
Share on other sites
Hi, the Alpha will not sorry to say. We are not happy to include it until we can support it with updates and fixes.

Thanks for clearing it up. Just glad to hear that it's not forgotten, makes sense for something like this to be worked on after more important things are sorted out, glad you guys are moving towards an OOP perspective and looking forward to more news on it as it becomes available.

Thanks for the info. I was thinking of trying to make it possible to script in e.g. lua with this, provided the interface is capable of that, and I was dreaming about an external debugger of sorts.

Great to hear. My major gripe with SQF is that it seems to be very difficult to get an "off-line" semantic check going. More than once, running the program is the only way to find syntax errors. With a well-supported external scripting/programming language like LUA or Java, it would be easier to do, and in the long run, I think that this would benefit mission builders greatly because even those branches of execution that are usually neglected/rarely run would at least not cause syntax errors.

Couldn't agree more, LuaJ has been my plan since the announcement of the JVM.

Edited by Looter

Share this post


Link to post
Share on other sites
We have not abandoned Java, and we want Object-Oriented scripting.

What are the chances of either the beta or the full game including Java or some other SQF alternative?

Share this post


Link to post
Share on other sites

so will it possible to use the scripting from ArmA 2 in ArmA 3 ALPHA? Example for testing mission setup, which you like in ArmA 2 and import it to ArmA 3?

Share this post


Link to post
Share on other sites
What are the chances of either the beta or the full game including Java or some other SQF alternative?

according to what has been said, I'd assume the chance is 100% that it will be in the relase version, but it is hard to say at what stage it will appear in the pre-release versions. According to the usual definition (Alpha being an executable, but untested and feature-incomplete version, and Beta being a partly tested and feature-complete, but not yet bugfree version of a software program), I assume it will appear in the Beta, or put differently, they will probably not call the game "beta" if it is still missing.

Share this post


Link to post
Share on other sites
so will it possible to use the scripting from ArmA 2 in ArmA 3 ALPHA? Example for testing mission setup, which you like in ArmA 2 and import it to ArmA 3?

Yes, as far as I can tell you should be able to script things in SQF the same way, object and unit classes will change for sure and maybe some syntax but I can't imagine much more changing on the SQF front, so far I don't think anything new on that front has been announced. It will be easy to tell next Tuesday.

Share this post


Link to post
Share on other sites
It was not purposefully removed from Arma 3. On the other hand it's not functionality we use in vanilla content, so I do not believe it was tested. Therefore it should be in Alpha, but I cannot guarantee it.

We have not abandoned Java, and we want Object-Oriented scripting.

What improvements are bring made to the Java implementation over the implementation seen in Take on Helicopters? I haven't worked with the implementation itself and my only source for how it works is the Java Scripting article on the wiki, but even with just a hello world example there are several glaring poor implementation decisions.

import com.bistudio.JNIScripting.RVEngine;

/**
* Sample Java class 
* @author Bohemia Interactive
*/
public class Sample {
/** 
 * Show a hint passed to jCall.
 * @param args Method parameters
 */	
public static Object showHint(Object[] args) {
	if (!(args[0] instanceof String)) return null;		
	RVEngine.hint((String)args[0]);
	return null;
}
}

So the first the thing that stands out to me is the complete lack of type safety. Sample doesn't extend any class or implement any particular interface, so there's no contract that Sample has to implement. In order to invoke showHint at runtime an expensive method probably iterates over classes in the class loader to find suitable methods(it would better to use Annotations here instead!) to put into a registry(I hope it's in a registry). Sample should probably extend instead be required to implement Callable. This would allow the enviroment to pass any class class implementing a callable function for use via jCall into a Future, making it possible for invocations to the JVM to asynchronous from SQF functions. Also Object shouldn't use as type parameter, define an interface for parameter types and use generics. ShowHint's prototype should look something more like

public static <T extends FunctionParameter> T showHint(T... elements)

Where T is a typed wrapper objects around SQF Primitives.

Two particular features I'm looking forward to is a annotation driven library for sub-classing defining functionality of a class with extensive use of dynamic proxies that will allow mission developers to implement functionality in runtime.

Share this post


Link to post
Share on other sites

Another question DnA, do you guys intend for Java as a full replacement option for SQF (make missions and mods without any need for SQF code), or will it be kind of an "add-on" (something like a callJVM SQF function, similar to callExtension)?

Share this post


Link to post
Share on other sites
In order to invoke showHint at runtime an expensive method probably iterates over classes in the class loader to find suitable methods(it would better to use Annotations here instead!) to put into a registry(I hope it's in a registry).

Non-sense.

Two particular features I'm looking forward to is a annotation driven library for sub-classing defining functionality of a class with extensive use of dynamic proxies that will allow mission developers to implement functionality in runtime.

Please no. Just provide static functions equivalent to SQF and let everyone to build their crazy OOP API.

Share this post


Link to post
Share on other sites

I was working on a C# implementation once, and wrote this test script:

public class TestScript : Script
{
   public TestScript()
   {
       this.Sleep(5000);

       string result = Main.ExecuteSqfStatement("getPos player");
       Vector3 playerPosition = Vector3.FromGameTableString(result);

       Vehicle plane = new Vehicle("A10_US_EP1", playerPosition, VehicleStartPosition.Flying);

       this.Sleep(1000);

       while (true)
       {
           string msg = "Fuel tank of plane: " + plane.Fuel.ToString();
           Game.ShowHint(msg, true);
           this.Sleep(250);
       }
   }
}

Would be nice with an official implementation though, as I had to use the extension command to communicate with the game, which is extremely slow, but it works.

Share this post


Link to post
Share on other sites
Non-sense.

Please no. Just provide static functions equivalent to SQF and let everyone to build their crazy OOP API.

None of the features I suggested conflict with simple static methods in anyway. For example, wouldn't it be awesome to use a @ServerSide or @ClientSide annotation to have the security manager enforce execution of methods in thier respective context? What if you wanted a method that took in any Vehicle cloned it? How would you have the method return the proper type without generics? Generics would be necessary to model functional closures which are a (poorly implemented) feature in SQF. Besides there are a lot of constructs which should be managed by the RV engine instead of clients like threads and file system resources, or a concurrency model for the synchronization of game objects.

Share this post


Link to post
Share on other sites
Maybe C# Scripting :D
C# support would be awesome :-)

Quicker... and in my opinion better.

I believe the problem with this would be cross-platform support for Linux dedicated servers. Yes, there is mono, but just my two cents as to why they chose Java over C#

Share this post


Link to post
Share on other sites

All this coding talk is very alien to me.

Could anyone explain or summarize what Java implementation will or could be used for in ArmA3?

Share this post


Link to post
Share on other sites
All this coding talk is very alien to me.

Could anyone explain or summarize what Java implementation will or could be used for in ArmA3?

I think that is what the guys are trying to find out :)

Share this post


Link to post
Share on other sites
All this coding talk is very alien to me.

Could anyone explain or summarize what Java implementation will or could be used for in ArmA3?

Many technical differences, but it brings the possibility to use existing java libraries outside of the game for added functionality, as well as the fact of being able to program using object-oriented techniques.

Share this post


Link to post
Share on other sites

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
Sign in to follow this  

×