Harrumph

Myself and several others would like to ask for a 'formal' statement from BIS on the status of Java integration within ArmA 3. If it has been abandoned, or is 'no longer the focus' as some posts (without citations) seem to indicate, then why is this the case? It is my opinion that a well integrated scripting solution would be, by far, the most significant enhancement that could be made to ArmA 3. - The reasoning is quite straight forward: it's vastly acknowledged that one of the largest features of ArmA II is the community and addons, so imagine what could be produced with a feature complete general purpose programming language such as Java. I've done my best to list and describe a few of them on the CIT, but there's been little feedback on that: https://dev-heaven.net/projects/jvm/issues Object orientation, debugging and compile-time checking are sorely needed tools, please could you tell us if we can expect them. If not, why not?

Any news on this yet, BIS? You said OO scripting is desired, yet there have been no announcements or hints in a while.

Integrating the JVM means that mission scripting could also be done in many languages other than SQF. This is an important feature that I highly doubt C++ can do in any practical way. Even if it was possible to script a mission in C++, there are three significant reasons as to why this is a terrible idea: 1. C++ executes natively without a sandboxed environment. I'd be very hesitant to run randomly compiled native C++ code locally, while the JVM provides a more secure approach through SecurityManagers, etc. 2. C++ is a very complex language. For hobbyist programmers and mission makers simply looking to get something to work in a basic format, C++ is a horrible, horrible solution. Using the JVM allows access to much more suitable languages, such as Lua, Python, Ruby and Groovy, all of which have guaranteed interoperability with existing Java libraries and code. 3. C++ is platform dependent. I realise that C++ itself is a portable language, but this would mean recompiling the code for both windows clients and a Linux server - an awkward solution at best. I still hope that one day we might get a Linux based server that isn't neglected. Using C++ as a scripting language would be a step backwards here.

I agree that BIS should make every effort to get the language into as usable state as possible, but this will have a lot more to do with having pure java calls from the engine, such as triggers, init.sqf, waypoint conditions, etc. At present, BIS has provided a library of static, non-typesafe functions directly converted from their SQF equivalents. This is precisely the approach I'd advocate, as it greatly reduces the maintenance requirements on their side. By having a community-managed wrapper around BIS' primitive interface, we could construct it better to our own needs, rather than being obliged to use a potentially badly designed one from BIS. Even if BIS could fully anticipate every use case, I'd be much more trusting of the community's collective expertise to maintain it and keep it up to date. Look at the Linux server for several reasons as to why community maintenance is the way to go.

This is irrelevant - The first thing the community is going to do is construct a sane wrapper API around this with concurrency protection, type safety and OO support. I have been nagging about the status of Java for ages due to wanting to get started on this as early as possible. The only thing that matters is that the functions are available in some form or another. For actually relevant issues, you might want to check out the take on java tracker: https://dev-heaven.net/projects/jvm/issues

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?

It's going to need to be done in some or other form before the Java implementation can be used for any larger projects. I'm not expanding any effort on this until I have some confirmation of the status.

Actually we can - TKOH already implements a very crude version of the Java scripting interface. If this is confirmed to be present, work on general features for ArmA 3 could be started in TKOH. An example of this would be a proper OO layer around the RVEngine static methods, and possibly a java-side solution to the race conditions that are experienced.

What they actually do and should do are entirely different things. I'm precisely arguing that their customer service is unsatisfactory. It is a 'confirmed' (cough 3D editor) feature. Are people only treated as customers after a purchase is complete? That's absurd. The equivalent would be a salesperson refusing to help you before you had purchased anything (on this visit to the store) because "You're not a customer yet".

Given this, why is this topic still unanswered?

This is a reasonable customer service response time. This thread hopefully highlights how lackluster their communication with the ArmA 3 community has been. DayZ dev blog Arma 3 - online services Survey This really annoyed me. Here's a post from Forbes detailing precisely why it's an absurd term to use. Its subject is Mass Effect 3, but the general principle still stands. (Bold is my emphasis)

The lack of communication from BIS on this severely important issue is immensely disappointing. How can you neglect to take a few minutes to respond to a well supported and phrased question from a large number of community members? After well over a month of waiting, this is outrageous.

Hence my request for new information - the supposed 'developer comment' is not a valid response to the original question. You are correct - for basic tasks, ANY language with a bare minimum of features is good enough. However, it's precisely for those larger projects that I'm passionately arguing in favour of this. As 'computing ability' increases (through more expressive languages, faster clock rates, or even more processors) people have always tackled bigger tasks instead of saving time or budget. A good example of this is the progression in animated films from Toy Story to Avatar. I have no doubt that with the proper tools we'd see a larger number of valuable additions to the ArmA being made.

As for the motivation behind this thread, as well as my general frustration: A large amount of extremely inventive and novel enhancements to the game are possible currently with scripting in SQF. I'm shocked and amazed that the developers seem completely unable to realize what a significant difference adding a proper scripting language would make to their own (and modding community's) development cycles. Is all programming on their side done in imperative C using only a text editor with basic highlighting? Why is this need not recognized at all? SQF is nothing short of a nightmare to work in due to awful syntax, slow execution speed and a complete lack of critical programming features as I have outlined in the original post. It is highly frustrating to work with it as it lacks all of the features of many freely available tools, which are used worldwide on a daily basis.

They have over 140 employees. I'm sure they can manage a few minutes to inform the community on the status of this critical and promised feature for ArmA 3. Besides this, at least Ivan was involved in DayZ rather than ArmA 3: Source: Cherno Plus: Hall On Day Z’s Standalone Future

This well supported thread has been in existence for almost a month without any response from the developers. This reflects very badly on Bohemia's community involvement with regards to ArmA 3. I would like to think, as a future customer, that I am entitled to an answer about the features of the product I am interested in purchasing. If this forum is an unsuitable location for information to be requested, please could you direct me to an appropriate contact address to find out this information about your product.

This is a woefully inadequate response. It's been over a week since the creation of this thread with no answer from BIS. This is both worrying and frustrating. If the original question could be answered instead of this pointless evasiveness, I for one, would certainly be happier.

I appreciate the constructive comments, AstutAvian. However, it would be preferable if we can keep language wars out of this as it's a surefire way to derail the thread. The fact that there's almost certainly going to be argument about which language to use is a strong indicator of how similar they are. The core idea which is being motivated here is the importance of any general purpose programming language instead of SQF. Java is only mentioned for two reasons: The developers have already promised it There has already been work done on integrating it to the engine. If BIS would rather use an alternative that has a similar feature set to java, I'm sure most of us would be happy to just escape SQF.

Yes... That's precisely why the thread is being made? If just a handful of issues (as that thread outlines) are fixed, it'll be in a workable state. I don't see that as an official statement from BIS, and even if they do 'confirm' it, I'd like to know the reason behind it. "Malicious code can break your computer!" Java isn't really different to harmful code in any language in this regard. What the article seems to outline is web based Java attacks, what's to say this would apply to ArmA? Edit: I'm not trying to motivate that "WE MUST HAVE JAVA!", only that a proper general purpose programming language is vastly preferable to what we currently have with SQF. Using the JVM allows a huge amount of languages, based on the author's preference, to be used.

Edit: The Title is a complete misnomer - if a mod could edit it, that would be appreciated. This is a discussion of the addition of Python or Lua as a scripting language As Several other companies have done, adding a more modern and commonly used scripting language (Python or Lua) would do wonders for customization and modding. See this link for a brief discussion of how Autodesk have implemented this in Maya. A switch to the incredibly rapidly developed and executed Python (or Lua) would provide a significantly stronger platform from which to code addons, mods and scripts. It is a vastly more modern, efficient and commonly used language than the current, internally developed one, with generalization applications extending far beyond the scope of the current internally developed one. To paraphrase a member of the Arma.co.za community who works with python regularly - "... with a complete enough API, persistent worlds would even be possible." For those looking at the languages themselves, the strength of Python is not in the syntax (which is extremely similar to Lua), but instead in it's ability to be adapted to any situation using the thousands of libraries and modules available. A small syntax Comparison using If statements: ArmA's Scripting Language: if (alive player) then { if (someAmmo player) then { hint "The player is alive and has ammo!"; } else { hint "The player is out of ammo!"; }; } else { hint "The player is dead!"; }; Python: if alive(player): if someammo(player): hint("The player is alive and has ammo!") hint("The player is out of ammo!") else: hint("The player is dead") While I realize this may cause trouble with importing over some mods, I do not believe it would be impossible to convert them. Switching to one of these languages would certainly be in the best, long-term interests of the ArmA series, not only allowing the faster development, execution and maintenance of both the game itself and mods, but also will strongly encourage new developers to participate due to the greater amount of people familiar with Python and Lua. On the comparison of Python and Lua: "Lua is far more basic than Python, but it's an excellent embedded language - the interpreter is much faster than Python. That said, most of the real work will be done by ARMA itself, so I'd rather use Python which is a much easier language to use and has lots of modules/support."

Please note that the thread text clearly states the following: If you'd read the post beforehand you'd have noticed the bold text. Could mod please change the title of the thread to avoid further confusion, despite the endless clarifications of this.