nyles

Fantastic, this will be interesting in regard to long range engagements. Are there any similar rules how dealt out damage is modified? We still have the issue with enemies often taking several hits before going down over distance. http://dev-heaven.net/issues/11479 This latest change might help a lot in the case when distant enemies are also prone, but perhaps there are other modifiers worth looking at, like the examples below? Hitting enemies in the arm often seems to absorb a lot of damage when aiming at the body. Can shots penetrate through different hit locations or is the first collision the one that defines the damage multiplier? I can understand that hitting only the arm reduces damage, but when the shot pierces the arm and strikes the chest, I would expect more damage to be applied in total. Hitting weapons often absorbs damage (perhaps even completely?). You can see sparks on the gun in this case. Without any other gameplay effect for this, like the gun breaking when hit, wouldn't it be cleaner to ignore it? Glancing hits (if they exist?), where you can clearly see the face go bloody in the case of a headshot, but the enemy doesn't die. For the sake of clear readability, headshots should always be lethal, regardless of distance and weapon used in my opinion. How does weapon damage drop over distance come into this all? Maybe most of the issues we perceive with shooting at enemies over distance where we expect them do drop but they magically don't, come down to too many multipliers and special cases being put on top of each other? I think hitting stuff is hard enough in ArmA2 already, and that's great, but if I actually score a hit, I expect a rewarding result. :)

Nice! Yeah, RCTRL with arrow keys works, but just using the arrow keys will change the piper's position, too, along with steering the plane. I am using WASD for movement so I don't mind, but there could be some people who will.

Hey Mando, Yes you are right, when I designate a target in the A-10's HUD AGM65 (ground) mode and then switch to the respective AGM65 camera, it is indeed focused on the same spot like the HUD marker. However, the camera position is not locked (red box) in the TV view automatically and it is simply impossible to move the cursor into the box to lock it manually without moving the camera off the target. Would it be possible to have the TV camera locked on the HUD target already when you enter the view? In addition, if you already locked the TV camera on a target in beforehand, this earlier lock currently will persist instead of updating to the target designated via the HUD. It would be great, if any current locks would be overwritten by newer locks performed either on the HUD or in the TV. I also tried this technique for other modes, but it seems what you describe is not working there (or I am doing something wrong): When I select the normal AGM65 HUD mode and lock a target following the regular procedure (TAB), the same target will not be locked when I enter the AGM65 camera view even after the HUD locking has been completed. This is also the case the other way around unfortunately, where a target that got locked via the TV camera, will not be locked on the HUD either. I think it would be a lot cleaner and more readable to the player, if you could establish the rule that there is always just a single lock per plane at any time - regardless of current HUD or camera mode and weapon type. Locking a new target would cancel any previous locks and reset TV cameras. Instead, locks should be carried over between compatible modes automatically. What do you think?

Kick ass! :) While we are on the topic of Lock-On vs. ArmA (haha, see what you started!), it would be super-sweet if locking a target in the HUD would slave the TV camera to the same target, too. So basically I am asking for having an option in the scripts to link a specific camera mode (i.e. LGB, AGM65, etc) with a specific HUD mode (i.e. AGM65 remote). If one is locked on to a target, the other is locked to the same target as well. That way you could use the camera/tv view to lock a target and when you exit the camera view that target would also already be locked as the current target on the HUD (only if the linked mode is the currently active one?). Vice versa, you could lock on a target in the main HUD, then switch to the camera (which would already be slaved on the locked-on target) to either do some fine adjustments or simply to visually confirm the target and check there are no friendlies nearby on the TV screen before you fire. In flightsims, there usually isn't a choice between either camera or HUD. Instead you usually find and engage targets by using a combination of both, moving between both stations for adjustments. For the limitations we have in ArmA, of course it is not possible to have exactly the same procedure, but this camera-slaving option would already be a great step forward in this direction. Again a bit of reference for inspiration: ;) Please note that I am not suggesting to use the little + to control the actual camera orientation, like you see in some of those videos! I think just being able to slave a linked camera mode to an existing HUD lock (and the other way around) would be sufficient already and immensely speed up the workflow. :)

Haha, absoultely not! :D Just merged the changes into my modified version and it works like a dream! This is simply amazing! Thanks! :) When you are happy with it, it might be worth putting some readabilty in the button menu so people understand how to move the + around.

Ok, I see. What do you think would be the best approach (and is this something that I could already do?) to make designating ground targets on the SU-25 a bit more usable? I am currently experimenting with only allowing ground lasing for the SU-25 when equipped with the laser variant of the Kh29. Therefore this HUD alignment issue becomes very apparent. Usually it is not a big deal, since people rarely target the ground, I suppose. Btw, I am using this Lock-on SU-25 tutorial video as a reference:

Sweet! Thanks a bunch! :) More a general question to a problem I am having (not really related to the latest release): Is it possible to offset the aiming point for ground targets to match the targeting reticule of specific aircraft? For example, when you are flying a SU-25 and you want to target the ground for the Kh29 laser missile, the HUD currently is a bit inconveniently arranged. The ground target will be generated at the small MMA Hud "+" crosshair at the center of the screen, which is usually covered by the text on the HUD when zoomed in on the SU-25. Also, due to the cockpit view, the small + is slightly offset above the aiming reticule for the SU-25 weapons, which adds to the confusion. It would be great, if "ground" targets could be designated using the regular weapon reticule rather than the small + at the center of the screen.

Ah, that overlapped. Very nice! Looking forward to the next build then. Cheers! :)

This one is really really important. With this broken, user-content like Mando Missiles that is part of most Warfare missions is not working. Would be super sweet to get this addressed before the patch goes final. :)

Just received a CIT update mail regarding issue #15969. Thanks for the fix and keep up the effort! :)

Did someone already escalate this bug to Suma? I think it's really criticial this gets addressed before 1.60 final, but I am not sure a ticket alone will do the trick here.

So true! If only "No Target (2-1)" would cancel any watch or look at orders, would be so much more useful. In general, I think helicopter pilots should be able to detect infantry on the ground a lot faster, if they are being attacked by them or clearly moving around in the open. Making AI gunners focus on assigned areas (i.e. watch command) should also increase chances to spot threats.

Hey Mando, I just tried the SCUD min-range out, really nice! Thanks a lot! There is one small problem with it however: If you select a target but not launch the missile and drive closer to the marker instead, you can circumvent the min-range restriction and fire the SCUD from much shorter distances. Would it be possible to always reset the target marker when you enter the target menu again, when you are closer than the minimum distance?

YAY! :D Thanks a lot! :D

Can we please get an official word on content bugs and whether they are still being fixed or not? If not, this saves us all a lot of trouble spending our free time to look for and report new content issues. If yes, it would be nice to understand the criteria for content bugs being reviewed and worked on. It is understandable that no content bugs are included in beta patches, but it would be great to know, if any further patches will include config and asset fixes or only code changes.

Would be nice to have this target acquisition system also for the Shilka. Even without missiles it would still help a lot to assign targets as commander. Not sure about the thermal vision though. Maybe night vision?

I was being provocative. As you know, I am simply not convinced that this should be the exclusive order in choosing what to fix (see SetMimic example). Not sure, but I actually like that this thread has turned into a much general constructive discussion with a lot of good feedback and interesting suggestions, including a repeated plea to continue fixing important content/config issues not just engine issues - especially also focusing on those issues that help gameplay. edit: thread, not threat....d'uh

What are you complaining about? Your top issue of SetMimic was fixed! Sorry. Couldn't resist.

One strange thing that I noticed tonight was that the gunner of the BTR-40 I was driving stopped engaging a guerilla pickup with SPG-9 after he killed the driver. About ten seconds later the jeep fired back, killing us. I am not sure, if this is related to the kind of problems you are looking for, Suma, but it surely felt wrong. I was expecting my gunner to continue firing at the jeep as usual until it goes up in flames. It's great he doesn't do that anymore, but he should at least continue until all relevant crew are dead.

Without BI there is no chance for any community effort to be able to reach the majority of the players and be in widespread use on online servers (where it's really needed). Just take a look at all the problems that persist to this day with many (new) players not managing to connect on Combined Ops servers. In my opinion, any discussion about possible content updates or additional community-provided content (fixes, reskins, etc) has to go hand in hand with the distribution method - be it a free DLC, patch or other official channel. Ideally this is process is combined with further code fixes and rolled out over the regular and proven patch process.

That would be fanstastic indeed. But the key here really is that this fixed content would be released via an official patch, otherwise there is no point for online gaming since no-one will download it. Simple but sad truth. We could even go further with this: (click!) :omg:

Exactly my point. If the policy is not to fix config/content bugs anymore (and I can fully understand this stance with complex issues), then we as a community should try to put this up on the agenda and communicate our misgivings to BIS rather than pick at each other.

My point is, that if only a limited amount of issues can be fixed, let's rather focus on those that make sense and help the GAME, than fixing those with the most votes. There is thin red line between what you describe as content or code issues. Many issues on your original list can in fact be fixed easily by doing config adjustments, but that doesn't necessarily make them content issues, like for example fixing geometry. The same is true for most items I presented (which at the risk of repeating myself, match many items on your list :) ) We are talking semantics here. I just want to steer this discussion more into a gameplay-focused direction, because ultimately this is where I believe the game needs more attention. Using the example of the top-voted item SetMimic again: just because it got voted high doesn't necessarily mean it should be one of small number of items that we could get fixed. I think I made my point. Enough from my side. :j:

Thing is, I am not even talking about changing anything on the model geometry. This would be a different topic, yes. I am talking merely about fixes/tweaks on the config layer, which should not have any impact on art or programming resources and could be dealt with by a dedicated designer.

Sorry, but that is arguable, seeing that there are plenty duplicates on this list that match items on the original list (i.e. damage drop over distance too aggressive, missiles not guidable beyond 1500m, etc). To be honest, I think what's really important here is that we do not forget about maintaining playability. I dare to say that game balance adjustments (many of which are in fact due to bugs) should be more important than let's say fixing the SetMimic, just because it has 78 votes. From a gameplay perspective I personally couldn't care less about that. Sorry. Another point is that ideally many of those gameplay related issues come down to faulty parameters rather than code bugs, and might hopefully be fixable without having to bother any coder, who could then focus on proper code issues instead.