Make Love Not War

Strange how we can be playing the same game and have completely opposite opinions regarding the AI. I've always felt that ARMA AI are far too aggressive and would greatly benefit from a mod that forces them to prioritize self-preservation over trying to kill the enemy at all costs. Also, when caught in an ambush, trying to push directly through the kill zone and into the enemy positions sounds like a desperation tactic that would almost never be used IRL. The correct response is to escape the kill zone ASAP rather than go directly through it. It'd be a major tactical blunder to set-up an ambush where the easiest route out of the kill zone would be to assault the your positions, no?

The glitchy movement at slow speeds and the new problem of the helis bouncing around the deck on the latest dev branches notwithstanding, my immediate thought upon watching the LCS video is why not create a proxy vehicle, attachTo or place a man class unit into its cargo space, hide the vehicle, and then play the corresponding anims on the man as you move the vehicle around the deck?

These kinds of tutorials are always an invaluable addition to the community. Thanks, guys!

Edit: I'm blathering on about A3 and I just realized I'm in the A2 forum. NVM, post deleted

Really nice work! Is there anything that can be done regarding the midrange texture being overlayed onto the concrete aprons and runways? I notice the road texures seem to overwrite whatever is beneath them, so I'm wondering if its possible to cheat the engine by defining areas we don't want to apply the midrange texture as roads? I suspect that would have to be done within the binarized island file, wouldn't it?

That's an excellent and undeniable point that a number of people have brought up. Consider myself sold. Actually, there's not all that many building models in the game: probably a dozen civilian structures and half a dozen military ones. It wouldn't take too long to create a template - or even multiple templates - that populates each model with furniture objects. Although there would be a performance hit, you could try and mitigate it by spawning your furniture in dynamically around the players. If one was particularly adventurous, physics simulation calculations (for moving the furniture objects about) could also be done locally to the players (a la dayz). Still, any way you cut it, spawning objects would create a performance hit compared to having static, immovable furniture "baked" into the building models themselves (a solution I would very much NOT like to see used). All this was talked about early in the thread, BTW.

Agreed, altough the impression I get is that people aren't trying to silence others, but rather trying to explain why adding furniture is not something that interests them, or, alternatively, wouldn't be a reasonable use of development resources that, in their opinion, should be spent on other features. Indeed!

@GilgaMesh: Sure, in a perfect world, I would like to see furniture, but with the proviso that ONLY if it has proper physics simulation included and isn't bolted into place as it was in A2. Oh, but that would be a hit to performance, wouldn't it? Also, it certainly is within our rights as players to say what features and fixes we would like to see priotrized over others.

Bad Benson et al, I think what this discussion ultimately comes down to is that a significant portion of people here simply disagree with prioritizing furniture in houses over other features. In fact, as far as I'm concerned, furniture is about the last thing on my A3 wishlist. Even talking specifically about the issue of houses, I can think of a lot of features and fixes that I feel are far more important to the game than furniture: Openable and/or destructible shutters: may seem like a very minor point, but, ATM, having 1/2 or more of the windows tactically unuseable because of closed shutters is unnaceptable. Breachable doors: would also be nice if we got fluid door opening as per Rainbow Six without having to mod it in. Breachable walls: kind of, sort of there with the partial destruction models, but, as Kapito66 suggested, a better ability to mouse-hole would be very cool. Fortification and loopholes: again, echoing Kapito66's comments, the ability to fortify houses and, in particular, create firing loopholes would be awesome, although this is getting into micro-destruction effects, so we're talking about pie-in-the-sky fantasy now, I suspect. AI navigation and CQB abilities: not a modelling issue as such, but the terrible, single path waypoint navigation system has to go. In fact, if BIS could amend only one thing regarding interiors, then this should be it. I respect the opinion of those in this thread who consider furniture a priority, but, to me, the things I just listed - the first and last bullet points, in particular - are more important than seeing a few furnishings scattered about various interiors. And, I haven't even talked about the myriad of other, non-building related features that, IMO, should take priority over any of this stuff.

Cool. Seeing as the only word of Farsi I know is "dushman", which apparently means "enemy" in just about every freakin' language from the Caucasus all the way to India, I was musing a few days back whether the Farsi in A3 is actually authentic and sensical or whether it's the "movie bad guy" version of the language. I should have known better; this is BIS we're talking about, after all. Thanks, OP.

Quantity, quality, cheaply; pick any two. But, I'll agree that all this talk of 'authenticity' does make me a nervous panda. Of course, for purposes of gameplay and the overall sanity of users and developers alike, some - or even many - things have always needed a certain level of abstraction within Arma, but that doesn't mean we should just forego the idea (and the ethos that comes with it) of Arma as a simulator.

A warning: we can't use onEachFrame (for anything) because - like vanilla eventhandlers - only a single iteration of this command can exist at one time, with the last instance over-writing all previous ones before it. So, because you never know when another script or addon might invoke another onEachFrame, you can never guarantee something isn't going to overwrite your code, which in turn effectively makes this a useless command (in anything slated for public release). Also, I expect the attachTo regressions probably have a lot to do with the shiny, new physics simulation.

Thanks for the explanation; I will definitely give that a shot. Interesting find in regards to the performance boost. Edit: @Das Attorney: Yeah, both disabling SP for your missions along with tutorials on running through a DS are excellent ideas. Although, if people are already able to improve performance in this manner, it really makes me scratch my head as to Marek's overall position regarding the concurrency issue (ie., any potential improvements to performance are not worth the investment in programming time and effort).

You brought this up again, so I gotta admit I don't understand what you're doing here. As far as I always understood it, dedicated server means that the PC running the server can't be used concurrently as a client. That's the whole point of "dedication", right? Can you please explain your process here in greater detail?

The problem I have with the sway is the randomness which leads to massive frustration as the player is constantly "fighting" it without being able to predict how he'll have to adjust his mouse movements from one split second to the next. BIS, please, the sway needs to be properly simulated as a figure-8 pattern.

Bigpickle, so very glad to see this mod is still in the works. Your explosion and heavy ordinance sounds are the best, and that nighttime video sent chills down my spine. Really awesome work that truly needs to make it into A3. I was thinking, have you tried to PM or otherwise contact some of the devs directly in regards to the remaining engine issues you're still dealing with? I understand using the feedback tracker and all, but considering the work you have already displayed, people at BI might very well be willing to help you out on a more individual basis.

I was just going to ask if somebody could repost this list. Thank you!

Yes, I do believe the helicopter damage is bugged ATM. I've done a little bit of testing and the only way I've found to take down even a dinky, unarmored Littlebird is to kill both pilots. The helicopters themselves never seem to take any actual damage. EDIT: Just confirmed it with the Littlebird: despite multiple hits from a Zafir, as confirmed via eventhandler combined with a counter, "damage heli" command is always returning 0. Heli only goes down after I kill both crew members. Doesn't appear to be anything on the bug tracker either. Will test with other weapons and choppers and open a new tracker report later. EDIT2: Ok, found the problem. Adding EH "handleDamage" seems to make all vehicle invulnerable to damage. Using a different EH, helicopters are quite easy to shoot down with small arms even (assuming you can hit them).

Good points, Maffa. These problems you describe from the end user's perspective could indeed become real game killers. Allow me to address some fatal flaws of the pay-for-mods plan from the modding community perspective. Granted, it would certainly be nice to see modders financially compensated at least in part for their hard work, monetizatoin could potentially kill off a large portion of the community. Namely, getting money involved in the mod making equation will create a hyper-competitive environment in which few people will want to share their work or help others for no immediate financial benefit (ie., unless they are being paid for their services). Even now, we already have certain modders - albeit, a minority - who have expressed extreme displeasure at the idea that ARMA .pbos allow for the easy extraction of source code. Now, magine the situation if guys are allowed to make money off their modifications. There would almost certainly be an immediate push on BIS to allow for the binarization and encryption of .pbos. If this was to pass, then the vast majority of modders would have to switch to closed source releases as it would be impossible for anybody releasing open source code to verify that unscrupulous individuals didn't steal their work and included it within monetized addons. Ultimately, the lack of a significant and up-to-date body of source code available for study, combined with an unwillingness of veteran, paid modders to educate others in their proprietary techniques, would raise the barrier of entry into ARMA modding exponentially. Without educational resources available to up-and-coming modders, the old guard would probably thrive for a while, but, in the end, the community would stagnate and die.

My current area of greatest concern regarding AI skill settings is that there are many different places where the various AI skills are set - within player UI, within the editor, within mission scripting, within addon scripting - and the relationships and interactions between these various settings is largely unclear. If that could be documented and explained it would go a long way to clearing up much of the current confusion.

Needs "I enjoy A3, but I don't think I should have to use mods to finish the game" option. Actually, the biggest worry for me is that the game has issues and missing features which have to be addressed within the RV engine itself and cannot be fixed with mods. Still, having fun with this game and a major improvement - in the long run - over A2.

Why place unnecessary restrictions on players and mission makers that everyone with ARMA know-how is going to be able to circumvent anyway (just play SP on recruit with custom difficulty settings)? The only ones who'll have to suffer under this - and suffer they will, because one save that cannot be over-written (!!) is plain silly - are the newcomers who won't know any better.

I know this is a little OT, but an updated SQUINT for A3 would be awesome. Even in it's currently outdated form, it remains an absolutely invaluable tool. Many, many thanks for creating it, sbsmac!

570. But, doing some modding, so it's running in the background lots.