Harrumph

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.