Jump to content
Sign in to follow this  
looter

ARMA 3 Alpha - Java Virtual Machine

Recommended Posts

SQF is not really that slow. It is slower obviously than native code, but it is very very fast otherwise. ACRE executes thousands of commands per-frame in SQF with very little performance impact. Most people just do not understand how to leverage SQF correctly in the engine.

Second, I care, because it means something more stable and useful if its easier to work into the engine. There are already enough little quirks to make programming on the RV engine a pain in the rear sometimes, throwing a heavy VM on top of it and having to deal with all the crap that goes on between the engine and VM is even more of a burden, both for content developers and the developers at Bohemia.

I'm an experienced programmer, but am pretty unfamiliar with SQF. Personally, I'm a big booster for Java and the OO approach that it brings. Though, I'd like to hear from another developer some tips on leveraging SQF with Arma. Acre is probably my favorite mod of all time, so I'd love to hear how you go about executing those thousands of commands per frame.

Share this post


Link to post
Share on other sites
I'm an experienced programmer, but am pretty unfamiliar with SQF. Personally, I'm a big booster for Java and the OO approach that it brings. Though, I'd like to hear from another developer some tips on leveraging SQF with Arma. Acre is probably my favorite mod of all time, so I'd love to hear how you go about executing those thousands of commands per frame.

The single most important thing you can do is not do anything in the scheduled SQF environment, the scheduler is incredibly unfair and prone to lagging execution times. The rest is optimization that you would do in any other language, reducing the number/complexity of operations, using pre-computed data where possible, caching data at intervals, knowing which engine commands are the most intensive (doing extensive benchmarking to figure out what engine commands are slow, if there are alternatives, etc).

We can do multiple signal simulations, which include analyzing the terrain and objects between transmitter and receiver, calculating the antenna gain based on pre-computed gain tables, and doing positional audio all in a single frame, usually in the 25-100ms range in response time depending on load (and obviously computer capabilities).

Share this post


Link to post
Share on other sites

Last we heard is that it's not going to be in alpha.

I can guess it won't be in beta and it might not even make it to "final" until a patch.

Another thing to consider is: Can you actually program/Have you programmed before? If not, you're not going to enjoy Java at first. It's not anything like SQF. There are hard defined data types and a strong object-oriented structure.

Share this post


Link to post
Share on other sites

Well, I would say Java is pretty easy to learn. If you are used to SQF, Java won't be a problem either.

Share this post


Link to post
Share on other sites

Sorry for asking but what kind of benefits could Java have for an ARMA3 player?

I don't know so that's why Im asking :)

Share this post


Link to post
Share on other sites
Sorry for asking but what kind of benefits could Java have for an ARMA3 player?

I don't know so that's why Im asking :)

For a player? Nothing.

For modders, anything really. Technically you could potentially offload some heavy number crunching onto JVM and have it run in a separate thread. Possibilities are endless, assuming the ArmA 3 - Java api is decent.

Share this post


Link to post
Share on other sites

Having Java as a language for accessing the capabilities of the Arma engine would primarily mean that more people could get into scripting faster. For someone scooled in any kind of procedural language (Java, C++, Python etc.) SQF has some quite strange syntax

Share this post


Link to post
Share on other sites
Having Java as a language for accessing the capabilities of the Arma engine would primarily mean that more people could get into scripting faster. For someone scooled in any kind of procedural language (Java, C++, Python etc.) SQF has some quite strange syntax

I have never understood this complaint... Yea its a bit odd, but to get a hold of it only really takes an afternoon.

I have professionally coded in a number of OO and procedural languages and SQF is really not that hard to pick up. I find Java far more annoying. Library hell, really long class names, etc. I really dislike it to be totally honest. I think it is one of the worst constructed OO languages out there.

Share this post


Link to post
Share on other sites
I have never understood this complaint... Yea its a bit odd, but to get a hold of it only really takes an afternoon.

I have professionally coded in a number of OO and procedural languages and SQF is really not that hard to pick up. I find Java far more annoying. Library hell, really long class names, etc. I really dislike it to be totally honest. I think it is one of the worst constructed OO languages out there.

Long names? Doesn't matter when you're using a proper editor :P

Share this post


Link to post
Share on other sites

I do question the choice of Java as well.. especially now when the whole thing is under Oracle control and such. Personally, I would like them to use something fast for scripting (such as Google's v8 JavaScript or LuaJIT).

Share this post


Link to post
Share on other sites
For someone scooled in any kind of procedural language (Java, C++, Python etc.) SQF has some quite strange syntax

I would like to know what you mean by strange syntax as well. Sure, there are some annoying little features such as then after if, while has the condition in curly brackets instead of round ones plus there's a do after them and there is no colon after the default case in switch. But that is no different from the inconsistent declaration of multidimensional arrays in C/Java/C# for example: int array[][]/int[][] array/int[,] array.

I really don't think the difficulty of learning SQF comes from its syntax. In fact, I don't think SQF itself is difficult at all. I believe the problem is here.

Share this post


Link to post
Share on other sites
Having Java as a language for accessing the capabilities of the Arma engine would primarily mean that more people could get into scripting faster. For someone scooled in any kind of procedural language (Java, C++, Python etc.) SQF has some quite strange syntax

The problem is lack of proper documentation. Been there, done that. Wiki needs more explanations and examples. Some commands descriptions contain as little letters as the command itself.

Share this post


Link to post
Share on other sites
The problem is lack of proper documentation. Been there, done that. Wiki needs more explanations and examples. Some commands descriptions contain as little letters as the command itself.

Documentation could be better, but compared to a huge number of other games I feel entirely spoiled working with SQF and RV.

Share this post


Link to post
Share on other sites

Any news on this yet, BIS?

You said OO scripting is desired, yet there have been no announcements or hints in a while.

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.

OMG pls pls pls pls pls, one thing that drives my batty is the lack of OO scripting ability, yes you can make fake OO but tbh i want a solution not work arounds.

Share this post


Link to post
Share on other sites

Still now news yet? I've heard/read that there is no longer commitment to JVM?

Share this post


Link to post
Share on other sites
Still now news yet? I've heard/read that there is no longer commitment to JVM?

How did you hear that if there has been no news on the subject?

Share this post


Link to post
Share on other sites
I do question the choice of Java as well.. especially now when the whole thing is under Oracle control and such. Personally, I would like them to use something fast for scripting (such as Google's v8 JavaScript or LuaJIT).

I do like the idea of using JavaScript or something similar and i believe this can run on all platforms that can run the game. Plus that V8 will be part of the game and Java is external (or is it?).

Most articles on Java are dominated by the mention of security leaks and that makes me dislike Java. I know security leaks/bug are also possible in V8 or any other scripting engine, but when it is embedded into the game you only have 1 app that can be used to exploit that leak. With Java multiple browsers and other applications can use the same engine to exploit it.

[edit]Could be that i do not understand the way Java is going to be used in Arma 3 and that my issue with the Java RE is a non issue[/edit]

Edited by Comm512

Share this post


Link to post
Share on other sites
I do like the idea of using JavaScript or something similar and i believe this can run on all platforms that can run the game. Plus that V8 will be part of the game and Java is external (or is it?).

Most articles on Java are dominated by the mention of security leaks and that makes me dislike Java. I know security leaks/bug are also possible in V8 or any other scripting engine, but when it is embedded into the game you only have 1 app that can be used to exploit that leak. With Java multiple browsers and other applications can use the same engine to exploit it.

[edit]Could be that i do not understand the way Java is going to be used in Arma 3 and that my issue with the Java RE is a non issue[/edit]

There are always security issues with compiled code. In the end you have no idea what the java .class file holds inside it. It doesn't matter which language you're using really.

Browsers and other applications are a non-issue in the context of ArmA, ArmA invokes the execution of the files, not your browser or any other java enabled app.

Choise of java makes sense since it's a full-stack language and mature.

Share this post


Link to post
Share on other sites
There are always security issues with compiled code. In the end you have no idea what the java .class file holds inside it. It doesn't matter which language you're using really.

Browsers and other applications are a non-issue in the context of ArmA, ArmA invokes the execution of the files, not your browser or any other java enabled app.

Choise of java makes sense since it's a full-stack language and mature.

Browser in the context of ArmA are indeed non-issues, but i must install the JRE to be able to use ArmA's Java mission code, then i am introducing a larger security threat to my machine then when ArmA had some script/code engine embedded.

Just because of the external JRE requirement. Because that is on the system, not just ArmA can invoke the executions of java files, but other apps also could. I am aware that ArmA does not have anything to do with browsers, but ArmA requires JRE and browser/other app that is not ArmA can use that also to execute malicious java code that has nothing to the java files used in ArmA.

java does exist for a long time, and it may be mature, but it is troublesome that so many zero-day leaks are still being found in the java RE. More so than in other frameworks so it seams.

http://www.infoworld.com/t/java-programming/java-zero-day-holes-appearing-the-rate-of-one-day-213898

Do not get me wrong, the security issues aside, java itself is a solid language which can make the life of ArmA mission creators much easier. But unfortunately the security issues are there and the choice for java does not make so much sense IMHO.

I am all for decent scripting/programming on missions, but i would also like it to be safe

Share this post


Link to post
Share on other sites
Browser in the context of ArmA are indeed non-issues, but i must install the JRE to be able to use ArmA's Java mission code, then i am introducing a larger security threat to my machine then when ArmA had some script/code engine embedded.

Just because of the external JRE requirement. Because that is on the system, not just ArmA can invoke the executions of java files, but other apps also could. I am aware that ArmA does not have anything to do with browsers, but ArmA requires JRE and browser/other app that is not ArmA can use that also to execute malicious java code that has nothing to the java files used in ArmA.

java does exist for a long time, and it may be mature, but it is troublesome that so many zero-day leaks are still being found in the java RE. More so than in other frameworks so it seams.

http://www.infoworld.com/t/java-programming/java-zero-day-holes-appearing-the-rate-of-one-day-213898

Do not get me wrong, the security issues aside, java itself is a solid language which can make the life of ArmA mission creators much easier. But unfortunately the security issues are there and the choice for java does not make so much sense IMHO.

I am all for decent scripting/programming on missions, but i would also like it to be safe

Java programs don't just get executed by themselves.

If that happens you either ran the program yourself or there is a virus on your computer that executes the malicious file.

Browsers don't execute java by themselves either. You're required to stumble on a malicious/infected website that hosts a java web start executable (or an applet) that is malicious. And that isn't any different from stumbling on a website that infects you with non-java viruses.

In the end it boils down to knowing where you visit on the web and what files you download and execute.

Share this post


Link to post
Share on other sites
Java programs don't just get executed by themselves.

If that happens you either ran the program yourself or there is a virus on your computer that executes the malicious file.

Browsers don't execute java by themselves either. You're required to stumble on a malicious/infected website that hosts a java web start executable (or an applet) that is malicious. And that isn't any different from stumbling on a website that infects you with non-java viruses.

In the end it boils down to knowing where you visit on the web and what files you download and execute.

Yes, I do understand that it comes down to knowing what is safe to execute, but JRE does enforce a browserplugin that can execute malicious java code. And that piece of software is alarmingly insecure. see this page http://www.reuters.com/article/2013/01/14/us-java-oracle-security-idUSBRE90D10P20130114

And just because ArmA requires JRE, a whole lot more is installed that is not used by ArmA.

There are many sites that are legit and use ad networks to generate income. these networks do get hacked and malicious code is introduced and spread to the legit site's visitors. So the chance of being hit with a virus (java, or non java) from the net while not visiting the "dark side" of the net is greater then you may think.

Plus code executed by java are all executed by java.exe, so it is much harder for security programs to recognize malicious code IMHO.

Please dont get me wrong, I do understand your point and a lot comes down to knowing what you can execute.

Share this post


Link to post
Share on other sites

I have been working on my own object oriented language for Arma the last couple months. It compiles down to SQF and requires no additional addons to run. It has support for classes, references, basic typing (it contains number, string, bool, and void primitives, and objects obviously are a type), casting, and a few other goodies that are meant to help improve performance for those that want it (pointers mainly).

It is styled after C++ syntax wise, but it is still developing.

Performance should be exceptional, and the implementation in SQF is very simple, replicating memory operations using arrays. I also hope to write a decent threading system that will make code execution more tolerable performance wise in regards to the SQF scheduler.

I am trying to gather people together to help write the standard library (did I mention it will have a linker system and the ability to use static libs during compilation?) which will hopefully create a nice system for "objecting" most things in the RV engine.

The project will be entirely open source, very unrestrictive license, and be geared towards use on any RV platform, including VBS2 with out any restriction.

Hopefully a very rough version of the compiler will be out in a couple weeks, along with all the source (the grammar is built in GOLD Parser, and the compiler is written in C# using the BSN Gold Parser library).

The project is called Carma (do not confuse it with the link in my sig, that is an older idea that didn't pan out performance wise, though it might still be valid to some degree going forward) and I will be making a new dedicated thread for it closer to release.

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  

×