Jump to content

gwheeler

Member
  • Content Count

    2
  • Joined

  • Last visited

  • Medals

Community Reputation

0 Neutral

About gwheeler

  • Rank
    Newbie
  1. gwheeler

    KA50 AT Weapon Fix for ArmA 1.14

    From an article about the KA-50: "The 'Vikhr-M' missile can penetrate of up to 900 mm of explosive reactive armor from the maximum launch distance of 10 km, which makes it the most deadly anti-tank missile in service around the world. This remarkable missile can also engage aircraft flying at speeds of up to 800 km/h. Even though the Ka-50 is capable of firing dedicated air-to-air missiles, the air-to-air capability of the 'Vikhr-M' allows to maximize the efficiency of the available maximum 2,000-kg weapons load." Even taking a conservative view of these performance figures, I would hardly scoff at the missile's capabilities. Seems BIS is just upping the realism factor, which is a big part of why most folks get into ArmA to begin with. Given the technological asymmetry between the US and Russian hardware featured in the game, it's kind of nice to have a weapon that's actually pretty capable on that side... Just a thought, anyway.
  2. As a longtime BIS fan and a programmer, I am coming out the shadows to post a few thoughts: The whole concept of ArmA is huge. There's so much that has to be accounted for, reproduced, implemented... I think it is asking too much that the BIS dev team be responsible for providing a completely accurate warfighting game out of the box, especially when so many end users are looking for so many different things out of the experience. There are a far greater number of people outside of BIS who know what a 4-bladed AH-1 should sound like, or who know what standard radio calls and language or map symbols are used by the US Marines, or FDF, or SAS. If you give them a solid foundation on which to build, they can take care of all that stuff. My main concern with the game is that it has a flexible, open, and (this is crucial) WELL-DOCUMENTED architecture for allowing user interaction and modification. The fact that so many people have slogged through poor documentation, in order to use crude tools, to create new content and game experiences for ArmA, is a testament to the passion and dedication of this community. The "Evolution" mission is one of the best examples (just that I've seen, I'm sure there are lots more) illustrating this passion. That level of dedication is not an inexhaustible resource, however, and it will eventually die off if it is not nurtured. I'll be the first to admit, scripting in OFP was what got me interested in programming again. Now that I've been a professional web developer for a few years, I've been exposed to a wide variety of languages, platforms, architectures, and design patterns. I've been guilty of re-inventing the wheel plenty of times in my own right. It's a part of the programmer's journey. Quite often you don't start out intending to do so and it just happens. The AFP/ArmA scripting language had its origins in a simple one-off expression interpreter for the mission editor. It wasn't designed to be a full-fledged programming language. but it's being pressed into service as such. I don't mean to be harsh, but let's face it: This thing they have created is like the bastard love child of LOGO and Visual Basic for Applications, with a little Reverse Polish Notation thrown in for good measure. There are lots of excellent, powerful, and flexible interpreted languages out there that are perfect for embedding into a game engine in order to define and manipulate the game logic layer. Python and Lua have proven very popular and capable in this arena, and I daresay even ECMAScript/JavaScript would be better suited to the distributed, object-oriented simulation that is ArmA. In fact, JavaScript's prototype-based OO and on-the-fly object manipulation combined with anonymous functions would allow for some very flexible scripting and game behavior. The fact that people are able to build things like GUI-based fire support systems and missions like Evolution using the current technology is pretty amazing. If these people had access to a real OO language, with a more straightforward syntax and solidly-documented API, imagine the kinds of stuff we'd be seeing and doing with this game. That's pretty much the crux of my personal rant. I realize my suggestion to scrap the current scripting system is probably not very feasible, for both short and long term financial reasons. In the short term, they are invested heavily in the current architecture. In the long term, giving players a better set of tools and documentation could potentially result in BIS losing money because the community isn't just going to rush out and buy the newest game if its content and gameplay can be better implemented by the community itself. That scenario might not hold true in a lot of genres, but I think the ArmA crowd tends to be more mature, more hardcore and more passionate about crafting a certain game experience. If you've gotten this far, you're a trooper! Thanks for listing to me ramble, and by all means weigh in with your thoughts on how we can best enhance the modding experience while keeping BIS out of the poorhouse.
×