- User Since
- Jan 29 2014, 11:08 AM (399 w, 2 d)
May 10 2016
Is this making the attachment pristine, or the M4? Wasn't certain from the report, but guessing it's just the attachment.
Glitch needs to be fixed...but another good reason to not camp ;-) You gotta relocate son! :-)
I've experienced this several times...especially when the latest stable release patch came out... I was at NWAF survivor camp when I logged out. The next morning I came in and I was on the coast as a fresh spawn... I've only joined Regular servers and all say Public as the type. I did note that if I hopped around to some servers hosted by certain hosts that my gear would be back...but eventually that died as well.
I'll be honest, if this is intentional to prevent server hopping, I'm fine with it - but we need to know what conditions trigger it so that we can be aware of it.
This behavior is much like the Charcoal Tabs...they basically induce higher stages of the illness so that it gets burned out of the character - much akin to real life. This probably just needs better documentation on the FAQ.
+1 to anyone calling this BS. The DayZ Dev group intentionally pushed spawns out to the East coast of the map to spread things out a bit and not make Balota such a hot spot...but then to take away *all* the loot ... that's ridiculous. Just for grins and giggles I have hung out around Balota for 5 days now to see if *anything* spawns in/around the tents... nothing. Not even a rotten kiwi. I've found plenty of Zeds...so fun target practice...but no loot for such a large militarized area is awkward at best.
Dean has clearly stated that this is a known issue and is something that is being actively looked into...but that doesn't mean that the Balota tents will stay. There is a chance that the entire section will be replaced/etc...depending on what the Devs think will benefit the community the most.
@fr3nchy: there are still loot tables for those areas, and there are spawn points, but they aren't spawning *anything* in the Balota tent area. The Balota airfield seems fine though. Dean has recognized this issue, and the Devs are looking into what course of action to take. This is based off of the release notes for the latest version in the Experimental branch, and off of Dean's post in Reddit.
Confirmed as well. Pristine kit, m4, mp buttstock, mp handguard, BUIS, bipod, coupled mag. Shot once, everything is still pristine. Cleaned, and now the weapon shows as Worn. Attachments are still pristine though...
@iInsanityx09: As I stated, the problem is trying to switch and already-attached handguard with another already-attached handguard. If the handguard is attached to a weapon, it cannot be removed. It can, however, be replaced if you find another handguard that is *not* attached to something. i.e.:
Situation #1: You have an M4 in your inventory with a damaged handguard, and you find another M4 on the ground with a worn/pristine handguard on it that you want to swap it out with. Dragging the handguard from one weapon to the other does not allow for swapping, and you cannot drag either handguard off of either of the weapons.
Situation #2: You have an M4 in your inventory with a damaged handguard, and you find another handguard just laying on the ground that is in worn/pristine condition. In such a case you can drag the lone handguard over to your M4's handguard and choose to swap - this works fine.
So, again, the problem that is a *known* issue is that handguards that are currently attached to weapons cannot be removed like any other component. They can be swapped if there is an unattached handguard laying around, but they cannot be swapped with another already-attached handguard.
I have the exact reverse as this - cannot remove attached handguards. Everything else is fine. However, I think this is a known issue.
@iInsanityx09: Gotcha, sorry for any confusion. Luckily I found a damaged handguard sitting around and a pristine m4 sitting around as well...so I just swapped my MP handguard with the damaged one, picked up the mp handguard and ditched the m4, then went over to the pristine m4 and swapped out the plastic handguard for my pristine mp one and voila! Got lucky that time...but next time I need to, I'll try your steps. Thanks again for the info. The only other times I've tried is with the pristine m4 on the ground, and tried swapping with my m4 that was in my inventory (not in my hands).
- If you find just the handguard on the ground, you should be able to swap it out without any problems.
- Unable to remove a handguard attached to an m4 already on the ground or on your character.
The problem this creates is that you have to find a pristine m4 with the pristine handguard you want, or try finding just the pristine handguard you want, in order to come up with a pristine gun.
This is further compounded by the fact that using a cleaning kit on your gun after firing it causes the core weapon to be set to the condition "Worn", which is already a reported bug.
If the condition of the core weapon plays no role in determining it's accuracy, then it's no big deal...but based on personal experience and several reviews from other players, accuracy is already affected reasonably by condition of the core weapon and it's attachments.
Please look into this as soon as possible Devs, thanks for all of your work!
Replicated the issue this morning. You can crank it pretty high, but fully dark areas that are in shadow are pretty blacked out. Odd thing... periodically I can push my gamma/brightness up high enough that it reminds me of the mod - basically full daylight during night time.
Pristine m4, OE buttstock, worn MP handguard, bipod, prone, pristine ammo. I can drill Zeds at 250m easy. Right-click to steady....and boom... 1 less Zed. I do see less dispersion fully pristine attachments and using MP stock/handguard...but this is known.
I've had this happen a few times. It seems to happen more consistently when you do a bit of server hopping. If you stay on the same server for a while, sit for a second to make sure it saves, and then switch to just one other server, all seems to be ok. If this seems to happen with specific servers, we should probably compile a list of those servers so that they can be investigated.