Weapon.GetAttachedOptics() is declared as proto native ItemOptics GetAttachedOptics(); (scripts/4_World/entities/core/inherited/weapon.c). Because it is a native method with no script body, mods have no supported way to change which optic a weapon reports. Please make it overridable, or provide an equivalent script hook.
== Use case ==
Mods that add optics which are not attached directly to the weapon's own optics slot, for example: - an optic sitting on a rail/mount attachment (weapon -> mount -> optic), - a secondary optic (canted sight, magnifier + red dot), - an optic integrated into another attachment (handguard, carry handle). In all these cases the weapon holds a perfectly valid ItemOptics in its attachment hierarchy, but GetAttachedOptics() returns null (or the wrong item), so ADS, the optics camera and zeroing do not use it.
== Current workaround and why it is bad ==
The method is called from 19 places in vanilla scripts: - DayZPlayerImplement (5 calls: ADS entry, optics selection, camera handling) - DayZPlayerCameraIronsights (1 call) - Weapon_Base (3 calls) - individual weapons: AKM, AK74, AK101, SKS, SVD, Mosin9130, VSS, PP19, Saiga To redirect the result a mod has to override every one of these call sites, often copying whole vanilla methods without calling super. This breaks on every game update that touches those methods, conflicts with other mods overriding the same methods, and still does not affect engine-side code that queries the optic natively.

0

1. Turn GetAttachedOptics() into a regular script method on Weapon whose default implementation calls the native lookup, and have the engine call the script version, so that override ItemOptics GetAttachedOptics() in a modded/derived class is respected everywhere.
2. Keep the native method, but add a script event the engine consults first, e.g. ItemOptics GetAttachedOpticsOverride() { return null; } where a non-null result replaces the native one.
3. Add a native setter, e.g. proto native void SetAttachedOpticsOverride(ItemOptics optics); The same applies to the neighbouring methods GetAttachedSuppressor() and GetAttachedLauncher(); handling all three consistently would be ideal.