enableCamShake false;

Run this command in debug console (global exec), or place in init.sqf to prevent issues. Will do for now as a temporary fix.

Ok CAPTNCAPS, but you're still playing at a different resolution (1680x1050) and super-sampling (114%). For those that play at a standard resolution (1080p), and without super-sampling (100%), the problem exists (as seen by my screenshots).

Note: PP effects (such as Depth of Field) should NOT affect scope reticles.

Running at: 1920x1080
Sampling: 100%
All other settings: High (with Objects on Very High)

I appreciate your input CAPTINCAPS, but you're running 2x FSAA. The title is:

"0020161: Scope reticles are unusable without FSAA"

With 2D scopes (such as the PCML reticle) this is not an issue. 3D scopes are susceptible to aliasing.

Can we get a sitrep on this?

Note: I wasn't sure whether this should be posted as a feature request or not - apologies if this is not the correct category.

Huh, odd. I restarted my game and the command appears to be working correctly. Please ignore this report, sorry for wasting your time.

This would be very useful.

+1

This would be an incredibly useful and powerful feature that is sorely missing from the current Zeus editor. I can understand they implemented snapping (since Zeus is meant to be used as a fast-paced mission designer, where quick/easy object placement is required), but for finer control the ability to turn off snapping would be brilliant.

Thanks Killzone_Kid.

Note to those who may find this: We've found that it is possible to continue using init fields on units (that are also compatible with JIP) by using "if (local this) then { // code };

E.g:

if (local this) then {this addItemToVest "HandGrenade"};

This will only run the init line if the unit is local to the connecting client (i.e. only the player himself). In the case of AI, only the server will run AI init lines (unless the AI are grouped with the player, in which they will be local to the player and NOT the server).

However, all commands within this init line will have to be global or else the effects will not be seen by other clients.

As Killzone_Kid pointed out, this is quite a 'hacky' approach and it would be better to run this code via scripts/init.sqf rather than in init fields. However, for those that like to keep everything editor-centric, the above method is a possible option.

Hmmm, are you sure this is the case? We just ran a test on our dedi server for applying loadouts (using unit's init lines - copy & pasting loadouts from the Arsenal). These are the results:

if (isServer) will only apply the loadout for all clients that are present at the start of the mission. JIP clients do not have their kit applied.

if (alive this) applies loadouts correctly for all units, but JIP clients cause all player's kit to be reapplied due to their init lines being processed again by the JIP client (this could be avoided by using local commands in init fields, but this does not correctly solve the issue).

if (local this) applies loadouts to all clients. JIP clients also have their kit correctly applied without reapplying everyone else's loadouts. This appears to be the best solution.

Perhaps you/someone else could also run tests to confirm this?

Edit: "Init runs very early" - I know this may be the case for objects that already exist on the server, but what about playable units? Surely they do not exist on the server until a player joins that slot (assuming AI is disabled). Therefore, as soon as the player joins that slot, the playable unit is created and the init lines are /then/ run (and not very early on). This may be why "if (local this)" works for JIP clients.

Was just using "if (local unit) then {addItemToBackpack... //etc };" on init lines of units.

AFAIK, we were just using local commands in the init lines (copy & pasted loadouts from the Arsenal) and so the double-init was probably still occurring - it's just that we (clients) can't see this. However, this does seem to prevent the mass "no main subgroup" log spam as our logs were clean from such errors.

Please can we get a response to the questions asked above?

@Killzone_Kid: Thank-you for your detailed reply. I shall refrain from using the init line box in the mission editor. A box that writes to the init.sqf would be brilliant, especially for amateur mission designers who feel more comfortable doing everything in the editor rather than creating scripts (plus this would also streamline the mission making process).

@SaMatra: If I want to apply a loadout to a unit when they spawn, I can call a function that gives them their kit (e.g. "[this] call f_fnc_assignGear"). Once this unit dies, won't it become an object that re-executes its init line everytime another player connects - reapplying the gear to the dead body? There are many scripts that rely on unit init lines (e.g. the f_fnc_assignGear example is taken from the very popular F3 Mission Development Framework). It seems many are unaware of this behavior you have described.

So from now on we must put "if (alive this) then {...your code...};" for every init field of every unit? Does this include game logics? What about triggers?

Is there going to be an announcement made about this somewhere? This is quite a MASSIVE issue that I expect every mission maker is experiencing worldwide (it's just that those that run -noLogs don't notice it as much). If removing init lines/using "if (alive this)" prevents crash to desktops (even when running -noLogs) and major (major) RPT spam, I expect people should made aware of this, at least on the BI Wiki.

Update: We removed all init lines from playable units and these errors have completely vanished from our logs. Frame rates are massively increased.

So far no crash to desktops when JIP players join. Will keep this post updated with any new information.

Not sure if the double execution is related, but we are getting similar messages in our log files that are causing mass client to crash to desktops whenever a player joins the server. Log spams this constantly (on client):

Group B Alpha 1-1 (0x1a0d9300) - network ID 2:26

• no main subgroup

This is a massive issue for us right now.

Just to add (now 8 months later) - AI units also appear to ignore editor-placed objects (e.g. walls or H-Barriers) and walk straight through them.

Three of our guys were killed today by a target 2 metres behind us. Eventually someone else in our team took the target out. None of us heard his shots.

We've had this before in other missions where AI are dynamically created (Invade & Annex, War Storm, Occupation etc), AI shots are sometimes silent.

We're all on stable build at the moment. Hopefully the dev build that fixes this will be put onto the stable pretty soon!

I agree 100% with this - the new inventory UI is awful and nowhere near as practical/functional as Arma 2. The video you made sums it up perfectly, it's so frustrating.

An error on my part.

Just had the same issue - nopop = true forces targets to remain up/still even when shot. Please fix this.

You can get a player's actual name simply by using:

name vehicle (playableUnits select _unitIndex);

With _unitIndex being the unit's position number (index number) in playableUnits.

For example, if I were the only playable unit currently on the server then,

name vehicle (playableUnits select 0);

Would return "Jamie" (me).

Works every time.

EDIT: Just tested and simply "name vehicle player" also seems to do the trick!

Same issue here:

(6238 [magazine]): Network sync error - NMTFireWeapon
(6238 [magazine]): Network sync error - NMTFireWeapon
(6238 [magazine]): Network sync error - NMTFireWeapon
(6238 [magazine]): Network sync error - NMTFireWeapon
(6238 [magazine]): Network sync error - NMTFireWeapon
(6238 [magazine]): Network sync error - NMTFireWeapon

This still an issue in Arma 1.50.

Triggers set to "CIVILIAN" or "ANYBODY" activation are triggered by animals. I'm told this is caused by animals inheriting from the "Man" class.

As a test, putting "hint str(thislist)" on activation results in: "[Agent 0x6be5a700]".

This is a major mission-breaking bug.

After re-reading this a few times I think I understand what he's trying to say, it's just poorly worded - surround sound.

At the moment ArmA 3 doesn't support 5.1 surround sound, only stereo. This is also something that was missing from ArmA 2. For those with surround sound systems or 5.1 headsets (even virtual) the whole immersion and gameplay experience would be much greater. Communication with teammates using directional comms or ACRE would also be much more accurate and more immersive.

Not sure how easy this would be to achieve though.

I have attached a very simple mission to demonstrate the issue. Simply run the mission and it will hint you the player's loadout on spawn, on death, and on respawn.

Ammo crates have been provided for easy experimenting.

I've noticed this as well. Unless the grenade lands on their toes it has no effect. Fragmentation or a larger splash damage would be great. This may just be due to the Alpha though but still worth mentioning.

@T-Bone - What is that going to achieve? We already have a system in place to highlight the importance of issues - this feedback tracker (with which this report already has 2000+ upvotes).