jaemn

30 FPS was unacceptable when playing Quake 3 on a CRT monitor in 1999. It's still awful now (asshole). Yes, because your vision is atrocious. It's almost as bad as being in a room full of mag-ballast fluorescent lights (thankfully they don't seem to make those anymore).

I agree. Whereas some lazier developers would have settled for last-gen stationary houses, BI have went the extra mile, providing us with the cutting edge in burrowing domicile technology.

You will likely want to model drag. For bombs dropped from a sizable height, I suspect that drag will considerably alter the impact point (assuming you aren't dive-bombing).

Unless things have changed since ArmA2, ArmA 3 doesn't model the drag coefficient as a function of velocity. It models drag as a function of velocity, but the coefficient remains constant. In reality, the coefficient should be be a function of velocity, air density, the shape of the projectile, and other variables I'm sure I'm not aware of. The effect of velocity is is quite large. Here's an example I grabbed from a report at dtic.mil: The angle of attack of the projectile should also come into play (although I believe this is already the case, at least for bombs), as well as gyroscopic drift. Also, as you said, wind should play an effect, although this would be more difficult to implement; wind would have to visibly affect foliage, dust, and other game objects in order to be believable. This is low priority stuff compared to many current issues with the game, but I definitely wouldn't say that ArmA ballistics are realistic.

There are a couple of ways to balance that out, without having to make aircraft unrealistic. One way is to ensure both sides have access to aircraft and air defenses. The second is to add civilians, and make killing them eventually lead to a mission failure.If only one side has aircraft, and the other side lacks any sort of deterrent, then the side with aircraft should probably win. A fixed-wing flight-model overhaul has been needed for ages. A BMS 4 level of avionics simulation isn't necessary, but at the very least the flight model should be adjusted. Also the behavior of ground radar should probably be adjusted. Something along the lines of switchable CCIP/CCRP modes, and GM/GMT tracking for CCRP. The current setup makes it trivial to locate, lock, and shoot an enemy vehicle. CAS should usually require assistance from people on the ground.

I would like a key to throw grenades, but with a brief animation required before actually throwing it. In an ideal world, releasing the grenade key before the animation is finished would cancel the animation, and re-shoulder your rifle. Throwing a grenade shouldn't be instant, but it also shouldn't be an uncancellable commitment to a long animation. e: The stock first aid module in ArmA 2 was a pretty good example of what not to do. I was playing a mission with ACE, but with stock first-aid. I started healing somebody too close to a burning car. All of Ventrilo burst into laughter as my character burned to death, trapped in the first aid animation, screaming the entire time.

The ArmA series has always had some serious UI flaws (such as the action menu), but that has little to do with how exciting the UI is. A UI isn't supposed to be exciting, it's supposed to be functional - not that what we have is functional, by any means. The ArmA UI is atrocious, but a better UI would benefit realistic gameplay too. Nothing in your post has anything to do with realism.As far as arcadey gameplay goes, I would say that the majority of ArmA pubs are already about as arcade as it gets. Finding a public server without third person, crosshairs, player icons on the map, and death messages is nearly impossible. Hopefully this will change once ACE gets released.

The issue isn't the lack of Java support. Java support was never going to be possible to implement properly, without an enormous stretch of time during which the developers would be able to focus on little else. I have no idea why they promised Java, when something such as Lua would have been vastly easier to embed.The issue was promising it, and then not saying anything after failing to release it. This is exactly what BI should be doing. They shouldn't state that a feature is going to be in, unless it's so close to being finished that its implementation is a certainty. A bunch of vague, noncommittal answers is absolutely preferable to saying a feature is going to be in, failing to put that feature in, and then saying nothing about it afterwards.

No, actually, it's not. If you had actually read the last two paragraphs, you would understand that.So either you didn't read the post, or you didn't understand it, and are now trying to cover by trolling.

Good lord. You write off modders as 'spoonfed babies', and then fail to actually read a post that provides a clear use-case example describing why people want better tools. Read the entire thing, you lazy git.For some reason I suspect you have never written any substantial amount of code with the current BI offerings. With them, once you get to 10k+ lines, writing maintainable code that isn't a mess of hacks becomes very tedious. Even before that point, SQF still leads to verbose solutions that are awful to read. The ACE guys effectively implemented their own namespace system with macros, and still needed to use horrific (brilliant, but horrific) hacks to accomplish what should be basic functionality.

Answering a question regarding a feature that was (originally) promised to be in the release is not 'giving in to demands of the vocal and having to spend endless hours in the forums'. It is basic diligence with regards to the failure of the developers to actually release their product in the state that they said they were going to release it. As I said above, doing anything less is completely scummy - it is lying, and it should be reacted to by not purchasing future products, and by encouraging other to do the same.I also enjoy that you failed to respond to my above post that addressed your gross misrepresentation of modders' dissatisfaction with the current mod tools as a demand for spoon feeding. edit: I would love to point out that my previous job had me working as a developer for a fairly small company, supporting a significant number of clients (other companies in the industrial sector). If, for whatever reason, we couldn't deliver a feature or update that we had previously promised, then we (the developers) were required to articulate the reasons to our HR people, who would then forward these reasons to the customers.

Or people are just tired of being forced to write atrocious hacks based on ill-documented features, in a language that gracefully combines the expressiveness of C with the readability of Perl.Want an example? Look at the CCIP implementation done by the ACE guys for ArmA 2. It's a brilliant hack, but the fact that they had to jump through the hoops they did is a very sorry state of affairs. For that matter, I would love to see somebody attempt a readable, short RK4 implementation in SQF. What should be about 20 lines of readable code instead turns into a mess, largely due to the fact that the SQF syntax for manipulating arrays is awful. Every project I have seen (including the ACE CCIP pipper) simply resorts to using Euler integration, despite the fact that an RK4 implementation would be significantly more performant. The other option is to just keep the vector components all stored in separate locals, but that's hardly better (a1_x a2_x a3_x a4_x v1_x v2_x v3_x... etc etc etc). For comparison, the following is an F# RK4 implementation, adapted from a Python implementation here (untested, as this is just an example): That's about 20 lines of actual code, and 20 lines to define reusable types that would have applications well beyond just RK4 integration. Consider the fact that I'm a complete amateur at writing F# (I only started last week), and that an experienced F# developer could probably implement the entire thing more readably, generalized to types beyond just 3D vectors, and in fewer lines of code. Given that, it becomes obvious just how cumbersome SQF is. There would, of course, be an equivalent Scala (JVM-based) implementation, but I don't have Scala installed at the moment. I should point out that not only is the above code shorter and easier to read than an equivalent SQF implementation, but it is also statically typed. e: why RK4 you might ask? Well, ages back I had written a . ArmA 2 came out, and I was getting around to adding some features (sheaf selection, radio dialogue based on FM 6-40, realistic charge selection for 155mm guns), and removing some old hacks, namely the fact that I was coercing the shell path into to a purely parabolic curve (IE no drag, which grossly exaggerates the effective range of guns, and makes it impossible to differentiate between base-bleed and non-base-bleed shells).Well, fixing the latter requires doing numerical integration in order to calculate the impact position. I needed this to be fast, since multiple paths would have to be calculated to converge on a solution, and I would need further calculations to get realistic range-probable-error and deflection-probable-error dispersion (likely with some lookup tables to speed things along). This meant that I would be best served by RK4. I prototyped the function in Python, and then started to implement the actual solution in SQF. I got about a third of the way through before I could just no longer tolerate what an awful language SQF is. The entire project had been contorted to try to render SQF into something readable, and I was just sick of looking at it. But lo and behold, I hear that ArmA 3 is going to support Java (and through that, less verbose languages such as Scala). I could finally get back to writing a decently realistic artillery implementation, without hating every single second I spent working on the thing. I could probably even bear to get it into an acceptable state for releasing to the community. That is why the lack of Java irks me. I can even understand the numerous reasons why JVM support would be difficult to implement. In order to get a decent implementation, BI would have to write wrapper classes for the arguments and return types of just about every single function available in SQF. SQF scripting is likely tightly integrated with the game logic, and modifying that to support the JVM would be an enormous undertaking. I'm not even sure how they would add an equivalent to spawn{}, without introducing horrible concurrency issues. Add to the above the fact that JNI is a terribly clunky interface requiring an ungodly amount of boilerplate, and I'm perfectly understanding that they would either abandon or indefinitely postpone the project. What I am unhappy about is the complete lack of feedback on the status of JVM support.

If the developers ship a game without a promised feature, and then fail to provide any status on that feature, then I am absolutely going to do my best to dissuade people from purchasing it.BI could have either a) Not promised features b) Provided the features they promised or c) Given solid feedback as to why those features aren't in Doing anything else is a flagrantly dishonest tactic to boost sales. It is scummy, and should be called out.

Ages back (prior to the alpha), Java support was stated by the devs as one of the features of ArmA 3; it is still not in. Seeing as there has been no recent information released on the subject, I'd say he's damn well entitled to ask what's up.I've simply resorted to cautioning everybody I know against purchasing the game, despite the fact that many of us have well over 1000 hours logged on the previous titles.

The advantage is that it isn't SQF. Java, Python, Ruby, JavaScript, Lua, C# - any of those would be an improvement over what we have now.For me, the inclusion of a better programming language was the main selling point of ArmA 3. Without that, I don't really have any interest in the game. Scala provides that, and would be supported via the JVM.