dnk
-
Content Count
578 -
Joined
-
Last visited
-
Medals
Posts posted by dnk
-
-
Well, the AI suppress YOU, yes, but can you suppress them? That's the issue, though it's good that the other side of it is solved already.
-
There you go, citing your sources finally. Sorry I don't keep regular tabs on the votecounts for issues I've already voted on. I do have a life outside the alpha, after all.so you are unaware of the very popular (most voted) voting on the bug report, mentioned a few times on this topic, i really didnt expect that since you are so very knowledgeable about the issue on this topic.I think I've already responded to this (and upvoted that issue despite not having serious issues myself (imo for my rig)): just because X number of people complain about a problem, doesn't mean that 50x people don't experience it - especially for such a vote, for which people with no experience of it are either going to A) ignore the vote, or (as I did) B) vote anyway to support others with the issue.
Really, even if you didn't have this issue, why would you downvote it? Apparently 13 people just have issues with other people having issues... There's always those types.
I can remember using launchers for other games. GR1 was one. I used ASE for that. DF1/2/LW all used an external browser (IE2 or whatever it was then). I know these are dated examples, but this is hardly the first game I've needed an external launcher for. And they're nice here because they give more options than the devs would put in an internal one anyway. Plus they allow for auto-updating mods, etc. DayZCommander and Six are quite effective, community-developed solutions, so why bother when there are other, more serious issues (like this performance one)?you logic makes no sense, given how popular launcher are, thats exactly why it is important. if it werent popular then would be uninportant. how many games out there require a launcher for basic server browser functions. "its an alpha". arma 2 isnt, and as stated who knows if they will do anything about it or not. only "whiners" draw attention to the problem so it becomes a priority or not, not the useless fanboys.
Yeah, just one of those suckers who support businesses they like. You have a charming attitude towards life, don't you! I even donate money to organizations that I like, expecting nothing of personal gain in return. Same for individuals. Crazy guy I am!its called doing someone elses job for free, and thus making them money while at it.. -
Yes, I think "no more than 3-5 seconds" for the effect is reasonable.
Only mild visual effects.
Increased "heart rate/breathing" audio effect.
Mild increase in weapon sway.
Enough to make someone less accurate, so that sniper-aim is not possible, but no enough to make them overpowered by the mechanism or unable to score kills (just to make it harder to score them, and to make suppression worthwhile in PvP and as something to be avoided in PvAI).
-
These pictures look good. Some constructive feeback (which may already be in place, it's hard to tell from 1 smallish photo) for the various "logics":
- The dark green/thick low vegetation needs more contrast. It should be very high. This is because generally in these biomes there is a mixture of lower, grassy vegetation and many larger, "plump" growing trees as the system builds up into a forested canopy. As such, from a distance, there would be lots of shadows and high contrast from that. These are, in effect, low forests.
Example:- Shrubland (intermediate between thick non-forest vet, the above, and strict grassland) should have patchiness with a both fairly low-contrast background that has regular inclusions of more high-contrast elements. A great example picture that has both grassy patches and shrubby patches: LINK, LINK (this would be more of a mix of grass and shrub)
- Grassland should be fairly monotonous, with a silky texture. From a distance, grass patches contrast with other patches by NOT contrasting internally. From a distance, they blend well, so a gently, blending texture would be nice. Examples: LINK, LINK, LINK
- Low grass (brown usually) and some dirt should be relatively untextured. You NEED to have parts with NO added texture, because some things just look smooth from a distance, plus it adds more diversity to the overall image. Plus, it's hard to hide in low grass so the need for camo is not important. Example: LINK
- Dirt (washouts, gorges, tracks) should have a wispy look. This is due to erosion usually creating "winding" ditches through exposed mud.
Additionally, if it's possible to add color and not just contrast, that could add more visual information to these areas, though the tiling would become more apparent. Balancing with only very subtle coloring might have a good effect.
- The dark green/thick low vegetation needs more contrast. It should be very high. This is because generally in these biomes there is a mixture of lower, grassy vegetation and many larger, "plump" growing trees as the system builds up into a forested canopy. As such, from a distance, there would be lots of shadows and high contrast from that. These are, in effect, low forests.
-
Well, it "isn't" a Greek island anymore, so it could be anywhere...
-
They have flashlights in A2:OA working properly for other players, so it's an assumed bug that also should be assumed to be fixed by release.
-
This is your idea of constructive contribution to the thread - numbers without links or context or explanation? What about 23434 to 435454545.4? Stop trolling and try to participate, if you can.what about 1191 vs 13, is that a good stats sample?RE Gamespy: k, it sucks. They should fix it. They're kicking that decision down the road to focus on other things, obviously. Given how popular external launchers are, it's not really that important, is it.
It's called "being proactive". What you're doing is called "pointless whining". See a distinction? One is useful. One benefits others potentially. The other wastes everyone's time and attention.im sorry didnt know that reporting the bug wasnt enough, so we have to find (without access to the code) and maybe i guess solve the bug aswell. thats a new approach. all while theres people peing paid that should be doing that. (maybe they are? who knows) -
Yeah, the developer is under no obligation to give firm dates on anything when in alpha. It's an alpha. Why do people expect it to be anything close to a final release with full features, AC, and optimizations. Seems like 3/4ths of the whining in this forum comes down to "I don't understand what an alpha release is"/"I'm impatient, mememememe". I'd prefer the devs be flexible and focus on what's most important as they see it and not get locked into pointless deadlines for certain features just to satisfy a few raging forum members.
Christ, NO. It IS and WAS an issue in A2 well before DayZ came out. It's not like DayZ was the first PvP mode for A2. Cheating was an issue with Warfare/etc as well, just less so than now with DayZ.It isn't actually a problem in ArmA2 or ArmA3 when some players uses a cheat and create a "better weapon" or "endless ammo" and such. This is a problem related to DayZ. Since we know that DayZ is going to be released standalone, all of your nifty "Sherlock Holmes-investigations" are a plain waste of time.
Dean Hall came up with the idea and developed the mod without BIS having any say until it got popular and they jumped on board for the standalone. It wasn't "official" (whatever an official mod means) until after it had been developed and gained popularity in the community. But go on and hate more based on your fantasy: ArmA was a perfect world of cooperative play and teamwork before the evil BIS decided to have Dean Hall create DayZ so they could CODify ArmA just to spite you.BIS came out with the idea, to create a mod where one player can kill another player for his equipment. One could say, teamkilling was cultivated with the official DayZ-Mod from BIS. -
If you can't hear ambient sounds with gunfire at the top of your volume range with headphones on, see an ear doctor.
-
1) Who forces 3000+ VD? I've played on fairly client-determined VD servers, but even on my PvP servers it's usually set pretty low (sub 2000).One suggestion I've put forward, was to have AI more commander oriented, and subordinates being more generic. In other words, less individual thinking pr AI unit. Equals less CPU time reserved for AI, leaving more for other stuff.And again, dedi servers will fix alot. So will server admins who doesn't force long draw distances fix a lot. anything above 3000 draw distance will kill any now living computer do to the insane amount of objects drawn.
2) From my own research (posted a few posts above), it seems like pathfinding is the biggest issue. Having all the AI "think less" doesn't fix the problem that all the AI have to figure out where their asses are moving to specifically with every command.
My own suggestion on that is to have them be less responsive to formation commands in complex terrain (like cities - this could be determined simply by the engine keeping track of mean pathfinding times for a unit per virtual meter, and when this gets too high, this optimization kicks in), which would cause them to adjust their position (and hence require pathfinding) less. If there is a way to get them to "follow" the path of another squad member also, all the best. So, for example, when the distance to move is more than like 4:1 the distance between them and the squadmate (in complex terrain), they let the squadmate do the pathfinding, then they just pathfind to the squadmate's current location and then follow his original pathfinding from there, then at the end of the trip doing a quick pathfind to a different piece of cover, etc. In many casts, the distance between squadmates is probably a lot easier to pathfind than the longer one, requiring far less resources overall.
Stats?most people.
Alphas are the part in the process where they decide what they're going to do with the game? This isn't that complicated.a few days ago i saw a discussion on steam regarding gamespy serverbrowser, and dwarden said something like "its still an alpha, we might use gamespy or not, we might use both gamespy and steam, who knows". my reaction was "dafuq, you developers should know by now what the hell you are going to do with the game". the lack of prior design choices regarding this and those other mentioned issues paint a bad picture overall imho.
Dunno, seems like I've been making some progress in finding a culprit, but quitting and whining works too I suppose.theres nothing else to report about the performance issues, its been covered over and over -
There aren't distinct shadows as such, but rather a lot of ambient occlusion happening in the area beneath the object. This could be added by removing the normal sun shadow as overcast increases, and replacing it with a second shadow based on a "12-noon" shadow for the ambient lighting.
-
What he said.
-
This +1I would suggest you think about leaving some of the shadows in -even if its raining.You could tone them down or have them faded out more but in the end - shadows are what make the game look good. And since they went missing in the previous rainy weather - bad weather really looked bad.
Also - reflecting ground and ground fog is what makes rain look good + shaking trees and appropriate sound effects - like dripping water when standing under a tree.
-
What did InstaGoat say?
The biggest fixes the AI have needed since A2 are:
1. not lying on the floor of a house looking at a wall for hours on end when an enemy is known in its direction
2. being able to actually, you know, look around themselves regularly
3. getting suppressed
The rest is nice extras, but just having a solid base of that would help a lot with missions, especially the more sandbox-style ones like Insurgency or Domi. How hard are these 3 things? The pathfinding's been well improved (though at what cost?), I think, and other nice changes have been made, but these 3 basic "stupids" are still there and still ruining an otherwise stellar (by most gaming standards, I think) dynamic infantry AI system. Fixing them would erase a LARGE part of the immersion-killing (and challenge-killing) idiocy that you see too often, which mission makers can't really fix either.
-
Not definitively, but this is looking very likely.
My rig:
i5 3350P 3.3GHz x4 6M L2
GTS 250 1GB (POS GPU)
OCZ 2x2GB 1066 CL7 DC
WD 1TB 7200RPM (new)
Win7
1600x900
Note that this should be highly GPU-bound, as the CPU is fairly decent for A3's needs, but the GPU sucks even on A2. The rest of the system is up to spec, with moderate RAM latency, and as much RAM as the game can handle, plus a moderate speed HDD with plenty of space and a newer 64-bit OS.
Test scenario 1:
40v40 AI, ungrouped, unarmedeach start and are given a waypoint in open countryall begin moving to waypoints without seeing opposing forcesResults:
GPU usage quickly raises to 99%, FPS steady in upper 30s, CPU usage between 40-50%http://i482.photobucket.com/albums/rr181/davidk594/openground_zps6a7a7ade.jpg (107 kB)
Test Scenario 2:
40v40 AI, ungrouped, unarmedeach start and are given a waypoint in Agia Marinaall begin moving to waypoints without seeing opposing forces until late in test runResults:
A very stable version of the poor performance seen in combat. AI seen bunching up on edge of a bridge and doing other stupid things.GPU usage around 70%, as in prior combat scenarios I've done (see earlier in thread)CPU usage more erratic, yet higher overallFPS around 24 throughout (very similar to that seen in combat)
Test Scenario 3:
From last week - using it for comparisonSimilar amount AI in combat situation in Agia Marina, typical squads used with basic "Seek and Destroy" WPsLonger than above 2Results:
Obviously, was a bit more complicated, and I've already discussed it in full before - note that these are moving averages and not raw data in the pictureFPS around 24 throughout, GPU around 70%, CPU usage higher than Scenario 1 but similar to Scenario 2.
Conclusions:
Pretty much looks like AI pathfinding is a culprit. When in open ground, it isn't such an issue, especially for a single WP, but when the terrain gets more complex, it is clearly both causing seriously reduced performance and GPU underutilization.The big question remains: why is this causing such a reduction in simulation speed without fully utilizing the CPU. Why is pathfinding forcing the CPU to regularly sit around and "wait" for information/threads to complete? Is it a simple matter of all AI routines being on one thread? But then why isn't at least that one core getting heavily used? All cores are roughly equal at ~50% use in my tests.FEEDBACK TICKET
-
AI Pathfinding Causing Huge Performance Problems?
Cross posted from this thread:
Not definitively, but this is looking very likely.
My rig:
i5 3350P 3.3GHz x4 6M L2
GTS 250 1GB (POS GPU)
OCZ 2x2GB 1066 CL7 DC
WD 1TB 7200RPM (new)
Win7 64-bit
1600x900
Note that this should be highly GPU-bound, as the CPU is fairly decent for A3's needs, but the GPU sucks even on A2. The rest of the system is up to spec, with moderate RAM latency, and as much RAM as the game can handle, plus a moderate speed HDD with plenty of space and a newer 64-bit OS.
Test scenario 1:
40v40 AI, ungrouped, unarmedeach start and are given a waypoint in open countryall begin moving to waypoints without seeing opposing forcesResults:
GPU usage quickly raises to 99%, FPS steady in upper 30s, CPU usage between 40-50%http://i482.photobucket.com/albums/rr181/davidk594/openground_zps6a7a7ade.jpg (107 kB)
Test Scenario 2:
40v40 AI, ungrouped, unarmedeach start and are given a waypoint in Agia Marinaall begin moving to waypoints without seeing opposing forces until late in test runResults:
A very stable version of the poor performance seen in combat. AI seen bunching up on edge of a bridge and doing other stupid things.GPU usage around 70%, as in prior combat scenarios I've done (see earlier in thread)CPU usage more erratic, yet higher overallFPS around 24 throughout (very similar to that seen in combat)Test Scenario 3:
From last week - using it for comparisonSimilar amount AI in combat situation in Agia Marina, typical squads used with basic "Seek and Destroy" WPsLonger than above 2Results:
Obviously, was a bit more complicated, and I've already discussed it in full before - note that these are moving averages and not raw data in the pictureFPS around 24 throughout, GPU around 70%, CPU usage higher than Scenario 1 but similar to Scenario 2.Conclusions:
Pretty much looks like AI pathfinding is a culprit. When in open ground, it isn't such an issue, especially for a single WP, but when the terrain gets more complex, it is clearly both causing seriously reduced performance and GPU underutilization.The big question remains: why is this causing such a reduction in simulation speed without fully utilizing the CPU. Why is pathfinding forcing the CPU to regularly sit around and "wait" for information/threads to complete? Is it a simple matter of all AI routines being on one thread? But then why isn't at least that one core getting heavily used? All cores are roughly equal at ~50% use in my tests.FEEDBACK TICKET -
Let's also note that the current AI scripting likely (but hardly confirmedly) is behind a large part of the performance issues players are having relating to "underutilization" (though there are other reasons as well, this seems to be the prime culprit). This really should be the #1 focus of the devs overall, not just fixing the glaring issues with realism ("bugs" here, lack of suppression, poor SA) but the performance as well (whatever's holding up the CPU's advancing of the simulation).
---------- Post added at 09:24 PM ---------- Previous post was at 09:06 PM ----------
UPDATE
Fixed: AI no longer fires on targets it does not see (but which are reported by other group members)
Someone want to check that? I'm off to bed soon.
-
means you are going to suffer from impairement most of the time in an engagement. Hardly fun if you ask me.
What I would expect is probably how it already is:What exactly is suppression effect?Every time a bullet travels (or hits) within a certain close distance, it increases gun sway a bit, with modifiers for closeness and caliber (or, better, bullet energy x caliber).
Each of these increases is added to a variable, like "suppression sway", which is constantly emptying itself, such that a single shot would only have a minimal effect for a few seconds. There also would be a max limit, such that you can never be suppressed after the firing stops for more than like 10 sec or something.
But, these sway increases are cumulative, so if you start getting a lot of incoming rounds, it will build up quicker than the natural rate of decrease, such that you'll be significantly affected (by how much is up for debate), and take 5-10 sec to return to "normal".
So, some guy taking the odd pot shot at you is going to have an effect, but unless it's a 50 cal, the effect would be minimal and would dissipate fairly quickly after he finished.
But, if a guy with an M249 unloads on you, your aim is going to be quite reduced up to 5-10 sec after he stops.
I think further PP effects are unnecessary, though a light one that has no real detrimental impact might be a nice touch. Increased breathing/pulse are also good and have no impact but to increase immersion.
-
And their hitboxes not being where their bodies are being rendered is.... not a problem for hit detection?
-
I guess only people with good aim get kills in real-world combat then. Certainly, someone with mediocre aim spamming shots won't:reward bad aim. You just have to shoot in the vincinity of someone (note : you were initially NOT shooting for suppressing, but for killing, but you have bad aim and simply miss), and magically, you are immune to return fire because your target cannot aim correctly at you... because you missed. This will happen A LOT more than tactical suppressing.1. (semi?)unintentionally suppress their target
2. sometimes kill their target by chance
Yes, this is certainly something a sim-game should avoid, simulating such obviously unlikely events. /sarcasm
Hey, if anyone with bad aim is suppressing you on accident, then you know you can start shooting back as their aim isn't that good, and voila! they're suppressed too now, and they suck to begin with, so the field is even and the better man, on the whole, will win. That seems both fair, realistic, and more immersing/"fun" than "good aim guy one-shots under heavy fire, bad aim guy has 0 effect on battles".
Note:
A. A good player-marskman can correct for gun sway
B. Most players ime are sucky marskmen, so they're going to want to have some effect even when they aren't getting quick kills, and this gives it to them.
-
No offense to ACE2, which I love, but the medical system was basically "anything but a headshot is survivable with some bandages and epinephrine/morphine." 5-story fall? Just patch yourself up with a medkit and you're good to go. Get shot 5 times with a 50cal (with intevening medical attention), 6th shot... just a few bandages from being 100% again. It's pretty ludicrous, as is constantly passing out from pain for like 3 minutes. ACE2 does some things well, but a realistic damage/health/medical system is not remotely one of them.I'd say that would be everyone, who is in favour of this topic, seeing as we don't even have a proper medical system, nor any of the tangible stuff that ACE 2 had, which reminded the player of his own mortality at every single step.I like the A2 suppression effects for the player, though adding in little twitches for "close bullet snaps" and impacts would add to it.
-
I'm not sure if this would show up in Process Monitor's files, but I don't think FSMs were even on the list of files being read (from HDD, I believe) during play. I assume they get placed on RAM, if not a CPU cache, during initial loadup. That would certainly make sense anyways.It rarely goes to the page file though, unless there is no ram left.The likely cause, as has been mentioned before in here, is that some thread is getting held up regularly when the AI are in combat, likely waiting on other threads. It may very well be that any given AI's routines need to wait on the other AIs' routines before stepping the scenario up to the next "frame". Clearly this is happening just with pathfinding (likely due to subordinates needing to check not only on the squad leader's commands but also the relative positioning of all other subordinates, though I haven't checked this with solo squads yet, which would make for a quick confirmation test - I'll do that as soon as I can). There's probably some other inter-AI referencing going on when in combat. This isn't an I/O issue or RAM latency issue or whatever, but rather just coding a lot of interconnectedness in that hard-caps the simulation speed by the AI amount, effectively CPU-binding the system.
It would be nice to go through the FSMs and remove parts to see if anything specific is the cause, but then what are devs for if not these things?
-
Is this basically impossible to mod, or does the community have a chance to implement this if the devs can't get it done?
-
Huge oversight to not have it. Quite doable. Both returning the effect for the player AND adding it to the AI.
normal house mods in sight ?
in ARMA 3 - GENERAL
Posted
Believe someone's importing all the A1/2/OA content over, which includes a robust selection of buildings and objects. If you include all the additional mod work done (MBG, I think, as in Duala) in A2, you'll have just about anything you could want (with a lot of Middle Eastern/African flavor). The one thing we don't really have is Asian housing (India/China/SEA/Oceania/Japan), which is a considerable oversight. I guess OFP2 might have put people off of it or something... Here's hoping for a SEA/Chinese expansion. It just makes sense, they've done every other hotspot now (not sure how Greece is a hotspot, but ok).