Jump to content
Bohemia Interactive Forums

jaemn

Member
 View Profile  See their activity

  • Content Count

    15

  • Joined

  • Last visited

  • Medals

Posts posted by jaemn

  1. Posted · Edited by jaemn

    That's not what I was saying. You probably just started playing video games a couple of years ago on your fancy flatscreen and are so spoilt by recent technical developements that your eyes hurt if you don't have everything in super HD and 120fps.
    30 FPS was unacceptable when playing Quake 3 on a CRT monitor in 1999. It's still awful now (asshole).
    Should I or many other people go see a doctor then because we don't get a headache from playing at ~30 fps?
    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).

  3. Posted · Edited by jaemn

    <snip>

    So attach this code to your dropped bombs:

    _goodGrav = 
{
   private ["_b","_velb","_vx","_vy","_vz"];

   _b = _this select 0;
   _velb = velocity _b;

   _vx = _velb select 0;
   _vy = _velb select 1;
   _vz = _velb select 2;

   _vz = 0;

   GoodGrav_prevTime = diag_tickTime;
   waitUntil //runs on each frame
   {
       _vz = _vz - 9.81 * (diag_tickTime - PrevTime);
       _b setVelocity [_vx,_vy,_vz];

       GoodGrav_prevTime = diag_tickTime;
       isNull _b // for non-exploding object add:|| ((getPosATL _b) select 2) < 1  //no ; at the end!
   };
};

[_myBomb] spawn _goodGrav;

    Or make a re-configged addon. :)

    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).

  4. Posted · Edited by jaemn

    Honestly the ballistic model of Arma makes me fall in love with it; actual drag, mass, and momentum is calculated (though wind simulation on ballistics is still missing).
    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:

    556_cdrag.png

    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.

  5. Posted

    Most players probably don't even have their view distance past 1.6km and with a realistically modelled plane, most people wouldn't even be able to see the plane before they get blown up. Realistic values for things like top speed would just lead to bad gameplay experiences.
    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.

    It's getting to the point were BI can't put off overhauling fixed wing aircraft anymore...
    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.

  6. Posted · Edited by jaemn

    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.

  7. Posted

    For example the lobby is about as boring and uneventful as it gets. You join...pick a faction from a column, pick a slot from a column and go. In terms of game interface sexiness its a zero out of ten. Functional yes but it's the microsoft excel of game lobbies.
    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.
    To those who would oppose any prospect of more "arcadiness" I would suggest that fearing difference in your Arma experiences makes no sense to me and whats the worst that can happen?
    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.

  8. Posted · Edited by jaemn

    Is it just this 1 issue - Java support?
    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.

    A marketing professional, who is never going to commit to anything
    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.

  10. Posted · Edited by jaemn

    All I see is some offtopic ramblings about RK4.
    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.

  11. Posted · Edited by jaemn

    Now, if BI were to actually hire a community manager, who's job it would be to police the forums answering said questions, then I'd have nothing against that. But the devs should continue to do what they do now - answering threads when they peak their interest, rather than giving in to demands of the vocal and having to spend endless hours in the forums.
    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.

  12. Posted · Edited by jaemn

    And modding survived because back then when it started the modders wanted to learn, to experiment, to push the boundaries. Now it seems like the vast majority just want to be spoon fed so that they can soak up the glory for releasing M4/AK pack #235232134
    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):

    type Vector3(x:float, y:float, z:float) = 
   member this.x = x
   member this.y = y
   member this.z = z
   member this.mag = sqrt(x*x + y*y + z*z)
   static member (+) (a:Vector3, b: Vector3) = Vector3(a.x + b.x, a.y + b.y, a.z + b.z)
   static member (*) (a:Vector3, b: float) = Vector3(a.x * b, a.y * b, a.z * b)
   static member (*) (a:float, b:Vector3) = Vector3(b.x * a, b.y * a, b.z * a)
   override this.ToString() = sprintf "(%.2f %.2f %.2f)" x y z

type Position = Vector3
type Velocity = Vector3
type Acceleration = Vector3
type Time = float
type AccelFn = Position -> Velocity -> Time -> Acceleration

let private step (pos: Position) (vel: Velocity) (accel: Acceleration) (accelFn: AccelFn) (delta: Time) (stepFrac: float)=
   let pos' = pos + stepFrac * vel * delta
   let vel' = vel + stepFrac * accel * delta
   let accel' = accelFn pos' vel' (delta * stepFrac)
   (pos', vel', accel')

let rk4 (pos: Position) (vel: Velocity) (accelFn: AccelFn) (delta: Time) =
   let p1 = pos
   let v1 = vel
   let a1 = accelFn p1 v1 0.0

   let (p2, v2, a2) = step p1 v1 a1 accelFn delta 0.5
   let (p3, v3, a3) = step p2 v2 a2 accelFn delta 0.5
   let (p4, v4, a4) = step p3 v3 a3 accelFn delta 1.0

   let pos' = pos + (delta / 6.0) * (v1 + 2.0*v2 + 2.0*v3 + v4)
   let vel' = vel + (delta / 6.0) * (a1 + 2.0*a2 + 2.0*a3 + a4)

   (pos', vel')

    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.

  13. Posted

    Why? SP is fairly rock-solid, and most people play SP. The campaign is also getting released finally, and there's a decent stock of missions already available, but no, the community thanks you for your "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.

  14. Posted

    This entitlement attitude with many members has to stop. You are 1 customer out of perhaps hundreds of thousands. Why do you think you're entitled to anything more than the game + updates?
    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.

  15. Posted

    I can't even use editor... imagine JAVA <<that is a greek word? =D

    But what is the advantages of it?

    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.

    Though first class functions would be nice :|
    Scala provides that, and would be supported via the JVM.
×