Just a quick update. Tried all of the fixes suggested in Jawsh's post and a few other. Reinstalled Steam & ArmA and used a new Profile. Updated all the C(++) runtimes, Java, and all the other listed runtimes. Reinstalled GPU drivers (nVidia) and tried rolling back, etc.

While it is true that we already have tools to allow this via different methods:

• Sync all editor placed objects to an Add Editable Objects (ModuleCuratorAddEditableObjects) synced to Game Master (ModuleCurator_F)
• Scripted solutions using curatorObj addCuratorEditableObjects [objects,addCrew] commands

Not sure I understand the whole context here, but if you are talking about a BattlEye ban then you would have to take it up with them: http://battleye.com/support.html

If your ban is from VAC/Steam you'd likewise need to take it up with them: https://support.steampowered.com/

Unfortunately, the mods here won't be able to help you with these.

No. 1 bug right here! This is really killing the whole 'Realism' of DayZ for me. THIS HAS TO BE FIXED NOW!!!

Lots and lots of spam appearing everywhere. Looks like someone has a bot running on the feedback tracker. Really need to be stepping up and squashing this.

Logged out, and came back as guest to clean up a few issues in the tracker. That's not the way to do it. Half an hour and only two issues cleaned up!

It's becoming impossible to follow and discussion on the feedback due to excessive spam.

@deewd22
Were you playing on the SAME server. We've had this issue and are able to all play at the same time on DIFFERENT servers. If we try to play on the same server (i.e. together) only the last person connecting is able to play as the others are automatically kicked.

Was playing as medic yesterday and came across two players kneeling on ground bleeding out. Bandaged both and got a message like 'Successfully bandaged unknown agent' (Might not be exact wording).

I'm assuming that these were bodies of players who had respawned or logged out. A PITA as I spent a good deal of time trying to revive these players.

Not actually sure I've encountered this problem, but ATM there is no check in-game to prevent it. Definitely needs a fix ASAP.

Game doesn't run that much worse than DayZmod and will get better as we go along. As long as you have read and understand the Alpha/Beta process, drop your cash and play the game.

Honestly, you're not going to want a refund for this baby!

Sounds like a personal problem!

Go into config -> video. Sometimes just going there fixes a lot of graphics glitches.

Else, if you're using the -world=empty startup param, don't.

Other than that, idk. Except of course to say 'it's alpha'!

Duplicates other feedback

Closing due to multiple duplicates in tracker.

&& 0003347

Looks like same bug as in 0001677

This is what happens in the RV engine. The only known alternative I've seen working is one where everything outside the scope is blurred out.

The fact that this hasn't been changed in the ArmA2/3 engines would point to the fact that the fix would need a considerable amount of work in the engine and the amount of time that it hasn't been fixed would indicate that this change isn't coming anytime soon.

You need to be right up on a zombie to hit it with melee weapons. I've not been seeing a problem when using an axe. The clipping, tho, is a known issue.

Check your cooling fan and radiator. DayZ isn't doing anything any other 3d intensive game isn't, so doubt it's DayZ specific.

In fact, the ArmA engines don't tend to push my graphics as hard as some other 3d apps.

Working as intended. HDR only takes into account range of brightness in the current fov, and then scales accordingly.

That's a lot of upstream. I doubt it's DayZ, tho, as there is no way it could have triggered 30 gigs of upstream data.

Just looking at the figures, the period Dec 20-22, someone was downloading something large. DayZ might account for 7 gig if you count patches (current size on disk is around 5.5 gb).

I'm currently monitoring my connection and even at it's worst (~25kB/s Upstream) you'd only be looking at around 2.5 gB Up for the ~30 hours I've been playing. (The average is closer to 3.5 kB/s Up and therefore total is a little shy of 400 MB Up).

Sorry, not very helpful.

Don't know what happened with the hours number above... should be thirty.

Ohhh... but I really love that stats screen... want that!

You're dead. Vision and hearing are both senses you are not going to need anymore. All immersion ended with you... not actually being in the world anymore. Why would you want to hang around as a corpse....

Oh, wait! This is a zombie game.

Hey, Rocket! IDEA! Killed players come back as Player-Character Zombies!!

Most likely graphics card related from error number. Not enough info given to be able to say definitively or to suggest a fix.

No.

Lighten up DuoBlackrose, this was only meant as a lighthearted attempt to distract people from the real work being done and maybe put a little bit of humour into their day.

Be assured that this small aside will not distract Rocket and the Rocketts (i.e. the Dev team from their v. important work.)

The only way forward, as I see it:

1. Cancel christmas
2. Double... TRIPLE the dev team
3. Fix ALL the bugs in DayZ

then we can just get on with playing the game.

It's a pity only 1) and 2) are realistic.

I should clarify a little. I don't think this is a DayZ issue per se, as I believe this was also an issue for me during the ArmA3 alpha/beta as well.

+1 M4A1 not showing any info text. Working for axes and bats, tho.

*Sigh* The can opener is the mechanic being employed in the game by the devs as to optimal method. Please feel free to use whatever method you want in real life.
Half the fun of the game is having a backpack full of food that you can't get at while you slowly (quickly!) starve to death!!

Some of the decisions on item interaction are simply there to make the game interesting. Where's the challenge if you find a can of food and can simply use it as is. At that point you might as well get rid of the whole hunger mechanic altogether.

Can openers open cans. Opening cans with anything else has a penalty. I don't see any problem here. Move along now.

The mag acted on when you press reload will be the mag that is top left of any other mags in your inventory. Simply move the mag you want to reload so that is is in an inventory slot up and to the left of any others.

Swap the mags in your inventory. The active one will be up and/or left of the others. Known 'feature' of the arma engine.

This could be as easy as putting 'voteThreshold=2;' in the server.cfg file. (i.e. a vote needs 200% of the players to vote for an action.) People can still vote 'early and often' but with no effect. see http://community.bistudio.com/wiki/server.cfg for description of this parameter.

Haven't seen this used as an exploit yet, but better to patch the hole now before the deluge, right?

Good point, flexAUT. I've spent so much time in ArmA that I don't even think about things like that anymore, you just go crouched or prone and hold your breath to take the shot.

(Now if they'd just let me live long enough when I do get some ammo for my M4, maybe I could test this! Just saying KoS-play guy...)

Were you standing, crouched or prone. As stated, these directly affect the accuracy of weapons in the engine. If you make any shot at 300+ standing, you're going to miss with this engine. Crouched gets better results. Prone, and you have to go out of you're way to miss.

Not sure if I'm remembering correctly, but I seem to recall a similar issue in ArmA with the calibration of sights and scopes being screwed if you changed the fov. Try resetting it to default and test.

+1 Probably network/dbase related. Sometimes it's instantaneous, sometimes it takes a while. also pointing to network load is the observation that it is worse on fuller servers.

ok. Have thought about that myself, but I'd hazard a guess that Rocket wants to keep a lot of that stuff hidden away. It would be nice to know food/hunger/blood levels and how they are effected in-game by different things. But those are probably the same things they want to NOT be 'gamed'.

Not likely to happen. Too easy to exploit and would compound problems with reporting issues more than it would help.

But, it would be fun to have access to some of the inner workings....

From experience with ArmA servers (and DayZ is using much the same techniques) the factors relating to local fps are multiple and varied, and for the most part bear no relation to your own hardware set up. A better indicator is to look at the player with the worst connection to the server. That seems to be the overiding factor.

This is why we sometimes limit connections based on ping.

Just what we need... Someone in Side/Global swamping comms with chatter about nothing.

Aside: The other channels are only 'disabled' in the mission configs, atm. This may change if/when radios are introduced (or not).

@KnightOps
See: http://forums.dayzgame.com/index.php?/topic/156129-confirmed-upcoming-features-for-dayz/

Specifically::
"Server Management Options

Target Delivery: Ongoing

Additional options for those hosting servers will be rolled out as soon as we can. We want to encourage a "hardcore" mode that will operate on a separate database, featuring things like first person only, no hide body, etc... In addition, we also want to provide passworded servers that will operate on their own shard of the database. This shard could be grouped, so that a group of passworded servers could operate on their own database. Eventually, we would like to see these different communities on their own db running their own variations of DayZ to meet specific communities needs."

For all intents and purposes this IS a private server on a separate hive.

Current hive and global character or one character per server. Second option requires much more storage whether or not it is distributed of centralised.

Private hives will have this functionality.

As to the original problem (Combat Logging, Ghosting and Server Jumping), that's the lowest common denominator of player behaviour and has plagued similar games since forever. That's what we get for the freedom to do almost anything in-game.

Definately not FairFight or PunkBuster. BattleEye for the win!

^^ Of course, your user name will be different ;-)

try in: C:\Users\DJPorterNZ\Documents\DayZ\DayZ.cfg

should be something like:
Resolution_Bpp=32;
Resolution_W=1440;
Resolution_H=900;

Eat lots. Drink lots. Wait a long long time. Eventually got a message about my wounds looking better. Then a little later got a message about wounds being all healed up.

+1 Needs fixing.

Managed to drop a backpack into a position between two trees where it wasn't accessible because of the trees clipping over it. We don't have tents so was trying to make a temp cache. Removed all trees, and was able to retrieve backpack.
(Trees are all back, btw.) [Didn't matter. Was hit by a server restart and character wiped on reconnect (unrelated)].

Definately not router/modem. Have three copies of ArmA2:OA and three copies of ArmA3 running on three separate computers. Each has their own PID (Profile IDs) assigned and we can all play together on the same servers with no problems.

DayZ, afaik does not have a traditional PID as these other games, and seems to restrict based solely on IP address alone.

This will also mean that any system of banning players will necessarily be based on IP. If either of my two sons go rogue and get banned for any reason, it would mean that all of us would get a ban. Not good.

Just did a quick check by 'hijacking' the neighbours wifi on one of the other computers and were able to connect to the same server. So would likely confirm the IP based connection checking.

Big problem! Bough three copies so we could play together, but because we play through the same router/internet only one per server can connect.

Assuming that servers are restricted based on IP address and not the ArmA2/3 system of assigned PID.

When you spawn in, you're already on the verge of hunger/thirst. Get to a water pump and juice up till you get the stomach full message and you'll be good for a few hours in-game time.

Same with hunger. Eat another couple of cans after the hunger icon goes away and you'll be good for a bit.

As to the items. They'll tweak those to try and get the mix right as we go along. ATM I'm getting more food than I need and water pumps are dotted around the place, so water is also plentiful.

Bleeding is a pain. But, you know that t-shirt you're wearing at the start. Take it off and rip it up into rags. <<- best early survivability tip I was ever given!

As to the indicators. I'm finding it enjoyable enough not knowing how close to death I really am. It would be to easy to do something stupid to get yourself killed whenever you thought you were too close to death to bother doing something that might actually save your life for a while longer.

Yep. Just keep using the drink option, and after 20~50 times you get a message about your stomach being full (shows up in white amongst all those yellow 'You quench your thirst...' messages.

Could be related to the 'Dropped items disappear' bug.

+1, having this happen on entering a server on starting game from scratch. Entering video config and exiting without changing anything fixes it atm.

Not a cheat; not an exploit. Down voted.

Inventory search order: Top left -> bottom right. Stops at first item of type looked for. This is not a bug but a 'feature'.

@RuwnDecay
How would you even begin to code for that?

1st/3rd is a player choice. I use both depending on circumstance. 1st person inside buildings and 3rd out in the big wild. By all means, restrict away on your own server as you want. But then, I don't PvP.

Seems to be any ladder/door you can interact with. Proximity check seems to be 2-dimensional. Can be fun to be on the 2nd+ floor and opening doors on ground floor.

+1

Forces you to use the Gamma/Brightness 'work-around' just to be able to play.

I'd assume this is similar to other containers. Have noticed that backpacks dropped on the ground in a location some times take a while to be populated with items when you return from a loot run. Delay in response from dbase/server/hive?

Definately not! The 'Condition of Presence' can only be true or false. Either there is a chance the unit is present at mission start or it is not. If it is true, then the 'Probability of Presence' gives the percentage chance that the unit will spawn. This allows for a lot of variability in the mission start conditions and adds a huge amount to the replayability of any well constructed mission.

Reinforcements are better properly handled by use of the Trigger mechanics and the various 'Spawn AI*' modules. Adding something else that requires '...check the condition constantly through out the mission...' can have no positive effects on performance and the implementation can only have detrimental effects.

At worst, the constant checks can kill a mission by themselves, but the bigger issue is having units spawn in at their initial spawn points at random times throughout a mission with no reference to the ongoing flow.

Having units suddenly spawn in behind you in areas that you have expended a good deal of effort to ensure are clear is a tactic of far lesser engines.

Just finished testing this again in 1.57.134593 and the issue appears now to be fixed. TY.

(NOTE: Just to confuse the issue I've had to replace my MB and HDDs in the last week so can't be 100% sure that it wasn't at my end. I'm using the note posted in the change log for build 134414 on the 9th of Feb to indicate that the devs may have actually found something to fix.)

Good news and bad news:

Good news: Lost all my report files due to negligent key pressing, but just running the versions again replaced those with no hassles.

Bad news: 1.56 RC appears to be displaying the audio behaviour the same as 1.57 Dev. There seems to be a few quirks in there as well complicating things a little, but sound still disappears on Alt+Tab.

Uploaded .rpt files for 1.54, 1.56 RC and 1.57 Dev. Also included DXDiag.txt.

Game files updated to DEV 1.57.134216

Uninstalled and disabled nVidia hardware. This simply disables the HD audio passthru to the GPUs HDMI output. It shouldn't be interferring with the normal audio operation.

Logitech has been default input/output throughout testing.

Have tested with every config of hardware and drivers that seems to make any sense and the audio behaves the same. Looped audio doesn't seem to be getting re-initialised when coming back from Alt+Tab.

Tried altering between Fullscreen/Window/Fullscreen Window with no difference.

Tested in 1.54.133741 Stable and the problem does not appear there no matter how I try to force it to ;-)

More telling, IMO, Commandeered my sons PC (he's running AMD/AMD vs my Intel/nVidia) and installed dev branch there with the same results, i.e. was able to duplicate the sound loss there on coming back from Al+Tabbing out.

Currently downloading the 1.56 RC to test there.

Doesn't seem to be a way to upload my .rpt file from the last server run on dev branch or my dxdiag.txt file but I have these if they are required.

Thanks

Thanks for the feedback. To your questions:

OS: Win 10 Pro (x64)
SND: Logitech G430 Gaming Headset (Default)

Effect appears whether I'm using mods or not, and whether I'm using streaming/recording software or not.

Uploaded a shorter video showing my steps to reproduce: https://www.youtube.com/watch?v=zlUNh693T5I&html5=1

Quick update: I thought that it might have something to do with the Logitech G430 setup, so changed the audio output to my monitors standard stereo output. Unfortunately the problem persists there as well.

Currently reinstalling all my audio drivers, etc. just in case and will retest when that's complete.

UPDATE: No change. Reinstalled board level chipset drivers, Logitech drivers for the G430 + Dolby 7.1 Surround. Same result after Alt+tabbing out and back.

One new quirk I noticed here and is in the video, this time when going 3PP and back to 1PP to try and fix, the audio fades on the first two attempts. Tested this with Bandicam running (hence the video) and without, and the results were the same.

Heading into speculation here:

Happens with all of the vehicles that I've tried. With land vehicles it happens with the idle engine sounds. With helos, the sound played when they are fully spooled up, etc. Perspective doesn't seem to matter. If you're in 3pp and Alt+Tab sound is gone when coming back.

Sound resumes again dependent on whether there is a change in filtering or a different sound is required by the engine. I.e. accelerating in a land vehicle, changing perspective (3PP/1PP) or turning off the engine. Firing weapons other actions play their sounds as usual but don't restart the missing sounds.

Ofc, this doesn't get me any closer to finding a cause and TBH I'm not really sure where to look for one.

CTD happens if you sellect a unit in the 3D view and try to edit the attributes there, too.

As an alternative to exposing the API, even getting the performance related items output to the log would be extremely helpful. Hiding it behind an expressly opt-in option in association with the -nologs would ensure that it doesn't get in the way for people not interested in the output.

Sorry for the delay, but was tied up with wrok related BS the last few days. There was indeed a space in the profile path: 'D:\System\Users\DJPorterNZ\Documents\Arma 3\Profiles\1.55'.

Tested with the current build (1.55.134018) and it appears to have fixed the issue. Thanks for the quick response and fix.

I may be wrong, but AFAIK Drag and Carry are only possible in A3 via script, i.e. they aren't default actions but are available via the scripting interface. I would suggest that you pull apart the mission .pbo and look to see which reveive script is is using and see if it has been updated to match the changes needed.

The problem is not the security of the protocol per se, but with the security of connecting to random servers themselves. At least with Steam we can be confident that the servers are well maintained and the people looking at the traffic are somewhat vetted for legitimacy.

Would probably only be an option if the alternate to the local server supplying the mission file was the Steam Workshop. Too open for abuse if the server was completely open. A definite NO to it being implemented as a torrent for the same reasons.

Duplicate of http://feedback.arma3.com/view.php?id=27190, but this one is much easier to understand and duplicate.

Did some testing in current Dev (1.55.133793) and all directions are giving the same results (i.e. around ~0.1 Stamina/s loss).

Results shown with the aid of ceeeb's 'movementTestStaminaRPT.Stratis' mission posted in http://feedback.arma3.com/view.php?id=19701.

EDITED: Corrected attribution for the mission file.

Duplicate of http://feedback.arma3.com/view.php?id=6156: "This suggestion was processed by our team and will be looked into. We thank you for your feedback."

Not able to replicate. From the image supplied the image within the reticle seems to be the same as the rest of the image at the same distance. Could this possibly be hardware/GPU related at your end? Unless you are refering to the LoD of the reticle being the same as the LoD for that distance, which I don't see being changed anytime soon due to technical reasons.

EDITED: Added a comparison image from my own game: https://c2.staticflickr.com/2/1446/24070029942_ea0cc68d2a_o.jpg

Ability to do so is already present in the Eden 3D editor. Just select all the units and select the Attributes entry from the right-click menu and place a check mark in the Multiplayer Control check box. This is equivalent of the Playable status of a unit.

STATUS_INVALID_IMAGE_NOT_MZ error means that the executable file that is trying to be run is corrupted and is not being recognised as a valid program. Probably the easiest way to repair this is to delete the *.exe files in your ArmA 3 root directory and then have Steam re-verify the game and force the re-download of these files.

Currently running ArmA 3 under Windows 10 with no issues. Have tried v1.50/1.52/1.53 of the client and apart from existing known issues have not seen anything directly Windows 10 related that could be causing your crashes or freezing.

I don't think this is a bug but a consequence of how Steam manages downloading and installing Workshop content as this is also the case with every other game that I have that uses the Steam Workshop. As such, I don't think this behaviour is within the realm that the ArmA devs are able to influence.

@Fighting Power: I'm going to assume that your comment is directed to me and in particular to step 4 sub-step 3 of the ArmA 3 Tools: Game Updater section of my guide. Leaving the Steam Guard Code blank does not in any way turn off Steam Guard. The challenge code that Steam sends to verify the connection is properly entered into the SteamCMD CONSOLE window that verifies the Steam information and is only needed the first time you run SteamCMD on the PC. The code is retrieved from the e-mail that Steam will send to your accounts primary e-mail address.

Steam Guard remains in effect and protects all versions you choose to install. You should not disable Steam Guard for any reason or need to.

@wizard: TY again. Will test ASAP.

@Fighting Power: Check my Steam Guide for details: http://steamcommunity.com/sharedfiles/filedetails/?id=524329966.

@wizard: Thanks for the quick response.

EDITED: Corrected link to point to the proper guide page and not my editing link.