assessment: modularity - standalone addon feasibility + function subfolder organisation

[MBarkerUK]

Modularity assessment (from the #196 three-system split)

Goal

Determine what can publish as standalone mods, and organise the functions folders by category.

Dependency map (verified from config.cpp + EFUNC/EGVAR grep)

Three tiers:

• Tier 1 (already standalone: main+core only, pure leaves): atmos, ballistics, fx, maritime, material, mobility, physiology, radio
• Tier 2 (standalone after one extraction): nightvision, thermal - both need getEyeState + getSmoothedWeather + calculateIlluminance + 4 grain-max settings currently stranded in optics
• Tier 3 (cannot split): core (the updateEnvironment star hub - 104 EFUNC calls, the shared state bus) and optics (the vision dispatcher)

Tier-2 extraction (this issue)

Move from optics -> core:

• fnc_getEyeState (consumed by optics/thermal/nightvision)
• fnc_getSmoothedWeather (consumed by optics/thermal/nightvision)
• fnc_calculateIlluminance (produces illuminanceLux, consumed by nightvision)
• the 4 grain-max settings (nightGrainMax, rainGrainMax, fogGrainMax)

Result: nightvision and thermal become main+core+itself = standalone-distributable.

Function subfolder organisation (open question)

The functions folders have natural clusters (thermal: solver/environment/surface/display; optics: shared/fx/sensor). Subfolders are purely organisational (PBOs flatten) BUT must not break the PREP include mechanism - needs verification.

Related

#73 (defence-grade CM documentation)