- User Since
- Mar 8 2013, 2:58 PM (551 w, 2 d)
Nov 11 2016
Thanks Geez, apologies for doubling up the issues, I was running on empty when i posted this! won't happen again :)
May 11 2016
This has happened to me exiting a garage in Vyshnoye.
I definitely wasn't shot as I was the only one on the server at the time.
May 10 2016
Also product version was 0.59.105679, but there was no option to select in report form and no way to deselect the incorrect version
Good point about the hiding inside. but if there's a useable weapon then it seems only fair to be able to actively extend and defend your life.
oh and before the 'SEARCH THE BOARD' fest begins, This is a suggestion of a solution that I didn't find. But apologies if this is too far out of etiquette
They have this in the vbs2 versions
Yeah in the Mediterranean you'd need it like that in summer. Have tried changing the date to winter in the editor and checking again lol
If I'm just being really dumb, then I'll put my hands up but I tried a few different things and it seems the same
Ok just did another test. along a flat terrain 1000m zeroing works, but not on elevation. Tried 1200m and the rounds disappear, even aiming as low as you can to the floor they just fly off your ammo count and do nothing
I understand elevated targets may need further adjustment and on revisiting 800 I think it's not too bad at elevation. The higher zeroing is a problem though. One example was the car spawn on the stratis runway aiming at the house on the hill north of the radio tower. it was 800m away and the shells fell short when zeroing set to 800m. I put this down to elevation so upped the zeroing to 1000m shot a few shells at the same aimpoint and nothing. no impacts anywhere as if they'd flown straight over so I fired continuously while lowering the aim and I had to aim severely low to hit the same hill that 800m had shells falling short for. (I also tried 600m and it behaved as you'd expect, the shells fell some distance shorter)
The 1500m setting almost drops the shells at your feet lol, but that's obviously a bug and not fine tuning
I can't believe this was posted
Excellent work on this, good insight and demonstration that allows the less savvy players understand what is, why it is and what can be!
report 0004977 has a more verbose take on this, I think TTc30 already saw it.
Sheesh good job you guys weren't all in the same squad/outfit/team or whatever. Using the radio would be like some hellish monty python sketch where they all said the same thing for an hour only to agree to disagree then explode, not from enemy fire but the confusion of the situation where no one actually disagreed on the main point.
I'll shut up and upvote now
Thanks for the quick reassign, I have my alerts on so let me know if you need more info.
This happens on any scoped weapon that can be held at rest whilst kneeling. Red dot sights are not affected. Just been through and tested bluefor and opfor default weapons configs.
I just rechecked this issue and it's in the latest dev build.
Just to reiterate:
Go to Editor
Place marksman as player
double tap L-ctrl to rest gun
right click for scope view(L-ctrl right click if in zoom mode)
Still aims at the ground
Apologies... must be kneeling with gun at rest not at shoulder
May 9 2016
Hi Astaroth. Just went to recreate this and after the update that steam applied I can no longer recreate the crash with the mission I had saved. I even increased to 160 civs at one point, all in a tight space, but to no avail. I also noticed that the previewed mission was now smoother on startup. Previously the game ran at 1 or 2 fps once loaded, (I assume while assets were buffered) and then after about 15 seconds things were normal again. but it's a lot smoother now
Apologies milhaus, this was happening on several game types not just one in particular. No multiplayer games have done this today will update with all info should it happen again
when the game freezes, If you have a mouse pointer on the screen and you hover over where the "...has stopped working" dialog usually pops up(about dead center)then the pointer changes to a windows system pointer. I use this when possible to see if the game is just slow in loading or has crashed. saves waiting 5 minutes before giving up lol
Doesnt pg up and pg dn adjust the zeroing? I havent tried all guns and scopes, but I know in arma 2 you could set the zero to as little as 100m on some scopes
Glad this was picked up!
Also flows through the floor. Especially noticeable in high winds, in hilly areas. Renders smoke virtually tactically ineffective in some situations
I get flashes on my Intel q9450 w/hd7850. But its just the screen flashing white for about 1/4second with a thunder noise. Not very well implemented yet I assume because of alpha. Out of interest what cpu/gpu are you guys running?
I flagged this as well. Really messed with my head the first time it happen in a medium range firefight. Lol upvote
Im cool with that mad dog
Even tho it may sound a bit spoilt, with current graphical standards a rain box so obvious feels a little lazy. Sorry devs.
Hmmm surely rendering the rain like that would be more intensive than having one dynamic overlay affected by motion and viewpoint (e.g. scope/3rd person etc). DCS world has a fairly good rain effect that doesn't seem to impact too much on performance and although the differnce between clear and cloudy is pronounced, The performance difference between cloudy and raining in their engine is negligible
Completely agree Nod - very eloquently described. I wish I had half that patience for my reports. up vote
Ok numpad zero now works and frame rate is seemingly ok. Would be nice for normal internal view to match but this is better than earlier. Not sure what I changed but after a play with settings this is far more usable.
If it's set in 2025 I'd hope the weapons companys weren't using infrared imagers from the late 80's lol
To elaborate on skyfyre's point, the attention to detail in the weapons of the arma games is part of it's main appeal and to have an element like this half useful would be a shame. Maybe it could be more like the tank commander view in arma 2 with various vision modes(nv/thermal/thermal inverse etc) but with the screen surround in view? ??
@EmperorJon is your gunner screen frame rate usable?
Yeah I wasn't talking about firing from the boat. I think what is needed is more of a fine tune of how the vessel reacts to waves. This was one of the new elements the devs were selling us in their pre alpha videos which is why I thought I'd test in extreme swell conditions. The simple fix would be to reduce maximum wave height and then fine tune the physics to lesser conditions. Otherwise it looks silly without some animation for the men to act like they're trying to stay upright on the boat and when parts of the boat are submerged they then cut back through the water like two solid objects intersecting
I noticed that but the movement itself is unrealistic for the supposed scales and weights involved
Also, this movement in real life, would catapult men(even with the tightest of grips)into the briney deep! But the men just sit stuck fast
Ranked game MODE goes against what I think ArmA is about and to suggest they add it in because you want to be rewarded and told you're doing good is probably a sign that ArmA is not right for you. It's like asking for a drift mode in an F1 sim.
This is the same as 0003704. That was my report. Feel free to close mine down as duplicate
Just to bump this a bit. Using TM Hotas Cougar this limitation stops all throttle buttons and 2 of the joystick buttons being map-able so as above DInput buttons 1 - 16 are working but none above that.
In a game as complex as ArmA can be, this seems like a real glaring oversight.
I mean someone must've decided 16 DInput buttons was enough right?
@Demongornot - just out of interest have you tried with HT on? Noticed any difference?
I know this isn't a traditional forum, but would be interested to know.
@rogerx - hi, I did read some of your other posts and know that you're not new to computing as a whole. And I apologise as my post read as very direct patronisation. However it wasn't meant to be as direct as it read, my bad.
My point was that you won't see higher memory usage as is and can only assume you meant to highlight the limit of 32bit memory addressing which I echoed.
The hyperthreading issue is a big sticking point for dcs users. I have friends and colleagues who have better systems than mine but were having worse perfomance on both apps. I have a q9450 with no Ht and they had modest i7s and had Ht enabled. It made a big difference in dcs with only two threads, one for sound and one for all else. And with arma 3 they said they noticed an improvement
I know that Arma has had some level of multicore support for a while, and people have been using the -exthreads and -cpucount and reporting some benefit, but there has never been a killer solution using those. I suspect a level of placebo effect for some.
For example, if you have a 3770k and this game runs four threads threads, turning ht off will ensure 1 core to 1 thread rather than loading the first 2 cores with 2 threads each, reducing efficiency. And that is all assuming that this is how the threads are thrown at the cores.
Again apologies for not coming across right before
@rogerx - you ain't gonna be seeing more than 3.5 gb usage of ram maximum. T H I R T Y T W O B I T !
maybe also try turning hyperthreading off. Because that'll only benefit you if the game uses more than 4 threads. With less than four threads it may well try and run two threads per core, which means lower performance per thread when compared to one whole core per thread.
works for other similar war based simulations that maybe don't take full advantage of more than two cores properly.
@Roger - their last engine had a 64bit exe for the VBS2.0 version, so it would be safe to assume that future VBS releases on RV4 would have the same.
@Kid18120 - 32bit programs on a 64bit os suffer slight slowdown because of having to use the wow64 layer but this should only be noticeable in the most detailed benchmarks and as I said above is only a 2-5% drop I think that variance is due to the layer being "thicker" in some areas than others. My point was that there would be a significant performance increase if a dedicated 64bit, multicore optimized version was released.
Unless there is a massive fundamental problem with the way the RV engine handles data, and has mainly been visually tarted up with each revision then this really should be an academic fix. right?
Just incase I'm missing something obvious, i'll rip off Donald Rumsfeld: "There are things I know I know, there are things I know I don't know, and there are things that I don't know that I do not know!"
@darkmere - I'm up for chat. My steam id is mewle spose we can take it from there? My availability might be patchy due to manflu. What's your timezone? Gmt here.
@white - I mention the 64bit exe often as they have a 64bit production pipeline for vbs. It's higly possible different teams are responsible for arma and vbs, but they're all under the bohemia umbrella so a bit of crosstalk to advance this can't be impossible and cost vs payoff, from my layman's view, is already better than having to start from scratch if they already have it in place for vbs
ok just dug up the exThreads parameters from arma 2. And yeah it's basically a core loading setting so exThreads=7 should load the last 3 cores of a quad cpu with Geometry, Texture loading and file operations. But I've never noticed much of a bump.
@darkmere - With -cpuCount=n and -exThreads=n isn't that like opening more checkouts in the store... Still the same amount of customers(threads)? (forgive that analogy)
I was under the impression cpuCount would unpark cores and exthreads was usually set to the amount of extra logical cores, so I7 with HT would be cpucount=4 and exthreads=7. I feel Donald looking over my shoulder again LOL.
(Are these even implemented yet? and do they work from steam like others do or shortcut only?)
With the memory side of things, I have tried to use several mallocs, including winhoard for a laugh, but I only tried to set these through steam and not a windows shortcut. I found no large differences, but general consensus seems to be that -malloc=system is best for ArmA 3 although I no evidence to back this up
or disprove it. I might do a more detailed check to see if there are definite differences between them. Unless you're doing that right now of course. :)
Also going back to my earlier rant on 64bit. A 32bit process suffers around 2-5% performance loss in a 64bit os although if largeaddressaware gets access to 4gb (apparently 3.5gb in real terms) rather than 2gb in 32bit (3gb with LAA flagged)
However a process compiled in 64bit yeilds an avg of 5-15% better performance over it's 32bit twin. I guess a simple recompile of the exe is not all that would be needed, but surely a dedicated 64bit version with improved multi core usage could bring massive performance increases for the higher spec rigs.
Thanks darkmere and stk. I literally just got schooled on arma 3 ramdisk use probably as you were posting.
I was monitoring my system after this schooling last night and you could clearly see in resource manager all the pbo files streaming from the hard disk, but disk usage never really bust over 10MB/s during gameplay, with all settings maxed (inc view distance/shadows/objects). Also ram usage never went over 1.3gB.
At these setting in the vehicles showcase. im getting and fps of min-9 max-27 avg-14 and similar lower than expected usage of gpu and cpu at low fps.
4gb ddr2 1066
Sapphire hd7850 oc 2gb
Win 7 64
Samsung spinpoint 103uj 7200
Could this also not be a HDD bottleneck. I read that there was either no or inadequate caching of the game world so a lot of disk reads happening constantly. It would seem to make sense that the cpu and gpu drops at high vis distance/AI/MP is due to the fact they are just not getting the data fast enough.
I've seen a good few reports of people with this or ArmA II installed on a modern high speed SSD getting a real reduction in stutter and a more constant FPS.
Do any of you guys with high spec rigs, that are suffering this issue, have an SSD capable of ~500MB/s read and write on sata III? (eg OCZ Vector/Vertex(other ssds are available LOL))
Also do any have a PCIe SSD on a 1x or 4x slot?
Would be interesting to add this info to the general picture we have as disk performance is massively under considered for performance issues.
( I know this was '09 but this is testimony to the affect of an SSD on games made with real virtuality http://www.tacticalgamer.com/armed-assault/148235-performance-ssd-arma-2-a.html )
Hi guys, the chatter about an x64 exe piqued my interest, so I did some digging(pretty shallow digging TBH)
Scroll down the page linked below, just below the videos, and you'll see they already have an 64 bit exe for VBS2 v2.0 which runs on the RV3 engine. It also states there is NO support for multiple video cards and any performance gain is just down to the drivers only. Can we assume NO official sli/xfire support is the same for civilian products?(I'd guess yes, but only guess)
Surely RV4 has evolved from RV3 and both x86 and x64 are being developed(?), at least for VBS implementation(?).
So why is there no x64 option?(Is x86/x64 compatibility in MP an issue?)
For the mods, I'm not trying to insight a riot, but the community wants answers and more importantly action regarding this. I wish I could upvote repeatedly on this matter as it is starting to feel like the gaming community are getting a rough deal for their £$£$. I think this thread shows that we're all starting to feel the same.
Surely the work BIS do for the military of many nations at high prices (vbs1 and 2) surely this optimization is not outof their financial or technological rreach . Unless the real virtuality engines are all designed to run on unrealistic monster systems or maybe even proprietary military tech, I don't get why gpus are only at full stretch when cpus are not and vice versa. Are current cpus not able to feed info across to the gpu quick enough for high draw distance?
the reverse and stop effect are frame rate issues are they not?
I ask because I wasn't sure if above a certain RPM the rotor is modified to blur?