seannybgoode

This is the first I've seen of it. It seems pretty cool. How fast is it compared to using the arma JVM? I'm kinda curious as to how it's all implemented, and how everything works. Also, do you know of any arma developers guides? The guides that I have found seem to be directed toward modders, and not anyone with any serious coding skill. Is there a guide out there that will skip all the trivial stuff and get into the meat of how exactly everything works together and what we need to do to get stuff working in-game? I've seen a lot of guides around "This is how you place an item in the editor, this is how you attach some sqf code to it". Ideally I'd like to be able to work with the editor as little as possible and work in code as much as possible.

They said that Java wouldn't be in the Alpha, but that was the last I heard of anything. Got a link for any more recent news?

You guys know that ACE mod does this in Arma 2 right? Hopefully it will hit Arma 3 soon (if it hasn't already, I'm a little out of date at the moment). You have wind and bullet drop that you have to compensate for, as well as bipod vs prone, as well as the ability to drop a backpack and rest your rifle on it. Ace is awesome.

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.

As both a huge Arma fan, and a Java developer, I was absolutely elated to hear that Java would become the supported language for Arma 3. However after reading here that the Alpha would not support Java, I'm extremely disappointed and confused as to the state of Java in Arma 3. So if Java is not going to be included in the Alpha, can we get confirmation that it will be included in the release version of Arma 3? SQF is an awful language to work with. It's barely supported as it is, and compared to java, there is about 0.1% as much info about sqf as there is about Java. Worse still, there is virtually no documentation on the SQF language. Here's a great example of why SQF is just bad. Trying to learn how to script in SQF? Click on any of the links, they're all dead. I'm not trying to be harsh here, but I really want to get it across to Bohemia that the Java replacement of SQF is not only good for this community, it's crucial for the growth of the genre. Prioritize Java support for Arma 3.

They could probably build some furniture items right into the building models without adversely effecting performance. Having separate chairs and tables and shit in all the buildings though might cause some issues. Keep it minimal, because, yeah man, it's war. Everyone bugged out and took their shit.

wait for java if you want to save data across server restarts.. writing binary files is easssssssssyyyyyyyy

Here's hoping that's why BI pulled it from the Alpha release.

Regarding the whole ToH thing, to me it's no surprise that the API is a little raw. It's a first time implementation of Java in this engine for BI, and they probably kept things simple on purpose. Furthermore, I saw that BI was hiring a Java developer a while back, shortly after ToH was released, so maybe they turfed their Java dev?

Amen.

Apology accepted. I'm a fairly young coder. I'm ok with trying fantastic things and failing spectacularly (like a Takistan fast-rope). I'm definitely going to take a stab at it. I read an interesting PHD disertation on ray-tracing with stream processors (there's also a potential approach to AI vision using shadow volume), so I'm confident that I can relegate more than just the pathfinding to the GPU when it's all said and done. Whether any of what I'm talking about will work out? No idea. Gonna try though.

Did I say anywhere that I haven't learned SQF? I've actually done a little work on it. It's an awful and difficult to read language. That's my experience. I'm sorry you don't like that. I'm sorry, I don't spend my spare time honing my coding skills for a soon to be obsolete language that nobody on earth uses except the Arma community. Yes. It's bad because there are very few resources out there for it. Dead links are a part of that problem. Yes it has a wiki. Yes there are a handful of people that know it. Other than that, there are almost zero resources for it. These forums are rough. If you don't have anything constructive to say, how about you don't say anything at all? Now I can see why people say the folks on these forums are jerks. I make some pointed criticisms and all the SQF fanboys feel the need to make smart-ass comments without bothering to read the whole thread.

Actually I do have some experience writing AI, and no, I have absolutely no experience with CUDA. Why does it matter? Why the bad attitude? This is something I'm looking at implementing a) as an experiment and b) for fun. You have absolutely no business being so condescending towards me. Just because something is going to be difficult is absolutely no reason to not try. The benefits of *trying* to implement some AI in CUDA or some other framework like OpenCL would be that many instances of AI could be processed in parallel. Using the GPU for pathfinding, an especially taxing operation on CPU, would be a benefit for performance in and of itself. Aren't you the least bit curious to see if it's feasible? Or would you rather spend your time tearing people down in internet forums? Believe it or not I've actually considered these problems, and it really depends on how Java is implemented in Arma how we approach a solution. I haven't had the benefit of getting my hands on it yet so I don't really know what it can or cannot do. I understand that Arma 3 Java is going to be "sandboxed" to a degree, but I don't necessarily think that stops us completely from doing some of this more interesting stuff. This whole idea is only a few days old and I haven't done much of the background yet, but I have gotten so far as to consider some kind of standalone application that runs alongside Arma and talks to the GPU, does calculations and feeds them back into the game. Like I said, it's an idea for an experiment. Anyone using it would require specialized server hardware anyway. But if it works it could be really interesting. ---------- Post added at 07:52 ---------- Previous post was at 07:13 ---------- So, enlighten us, what approach would you recommend? Do you think a procedural approach makes more sense? I'm sorry but when you're dealing with abstract concepts like "Player" and "Spawn Area" and "Weapon" it makes perfect sense to encapsulate your code into an object that describes an entity's properties and the things that can happen to that entity. Presumably BI didn't choose a language like C or Fortran for a damn good reason. I get it, you don't like Java, but just because you don't like it doesn't mean it doesn't have its uses. It's a great language if you want to solve your problems within the OO paradigm, and presumably, that's why BI chose it. It's also very easy to read, which will promote more people getting into the mod scene, and hopefully some awesome content.

Heh, not a bad idea actually, but you can start making requests once I actually have a working prototype.

Personally speaking, I'm interested in writing an AI that will be smarter and deadlier, and faster (performance wise) than anything done thus far. I'm looking at processing AIs in parallel on GPUs using JCUDA, among other things. Imagine a server with a couple of GPUs able to handle hundreds or even thousands of instances of AI units without so much as a hiccup. I think Arma players would be up for the challenge too. Honestly though, all of the major Arma mod projects would benefit from an OO approach. Java will make code more reusable and more readable. That, and I think java is probably a whole hell of a lot more optimized than SQF. Complex java programs will probably be a lot less taxing on servers than complex SQF scripts. Plus having access to stacks, queues, trees and other advanced data structures will allow for more nimble programming. Java being a strong typed language will prevent errors, and java being a safe language will force people to write better code. Hell even network sockets are crazy easy in Java. You probably won't see much of a difference with simple mission scripts, but complex projects like A.C.E. and A.C.R.E. will fare much much better. The stuff people will be able to do will be very impressive if the platform is open enough.

The last time I tried the notepad++ sqf extension, the extension hadn't been updated to support newer versions of notepad++. ---------- Post added at 23:54 ---------- Previous post was at 23:46 ---------- And like I said, this thread isn't about SQF, it's a request for an update on Java support. Whether or not SQF is awful (it is, but that's just IMHO), is of no consequence. There's a million reasons why Java is a better option than a homebrew scripting language, but it's not about that either. Presumably, the folks at BI agree that an Object Oriented approach is the way to go, or else we would not be having this conversation. I just want a status update on Java. Although if I decide to do any SQF work I'll definitely try the Sublime text SQF Bundle. Thanks for the link. And thanks to the other folks who've posted SQF resources. I sincerely hope I will not need them.

Id personally love to play insurgency on the new engine. So, yes. +1