Over two years ago I started a thread on BIForums related to one of the oldest issues of Real Virtuality engine which existed since OFP (Arma: Cold War Assault) - //the fallen tree bug//.
[[ https://forums.bohemia.net/forums/topic/216507-17-years-old-bug-in-a3-a-fallen-static-objects-geometries-bug/ | 17 years old bug in A3 - 'A fallen static objects' geometries bug' ]]
A summary of the issue:
> Static objects such as Trees, Fences, Walls etc. which feature:
>- value: //DestructTree/////DestructFence/////DestructWall//
>-- destrType token in config class,
>- value: //Tree/////Fence/////Wall//
>-- damage token in model properties,
>are vulnerable to the bug. If such an object gets destroyed it falls over and losses/ignores all of its geometries (Geometry, FireGeometry and ViewGeometry). A player (or an AI unit) can move and shoot through such a fallen object, no matter what material it is. Moreover, an AI unit, as opposed to a player, can also see through the fallen object. As a result, AI is unfairly aided what has a significant influence on the gameplay. Concealment & cover - none of fallen trees, fences or walls can provide it because of the bug.
Eventually, the issue was resolved in [[ https://dev.arma3.com/post/spotrep-00081 | 1.84 Encore Update ]]. As a result, **fallen static objects keep FireGeometry and ViewGeometry**. However, **Normal Geometry is not kept by fallen static objects**. Such an approach is something I myself suggested at that time due to keeping backward-compatibility with all the original missions and campaigns in mind. Under specific circumstances there is a probability that Normal Geometry of fallen static objects would cause AI-related issues (path-finding problems, getting stuck). However, it does not mean that community-made content should not be allowed to have fallen static objects which keep all of their geometries!
My suggestion of this feature request is: **Provide a switch (a module / a scripting command / a function / a global variable / or any other mean) which would allow for enabling/disabling Normal Geometry of fallen static objects.**
- Aspects of such a feature:
-- Improved immersion & fidelity of Arma environment
--- No more walking or driving through fallen static objects which currently behave like non-interactive props.
--- A vehicle driving over a fallen object (e.g. a tree) in respect to the fallen object's geometry provides better aesthetic experiences. Moreover, it also highlights physics engine by putting it to use with already-existing content.
-- New gameplay elements
--- Imagine an ambush of a convoy in a forest. You blow up some trees at the front and at the end of the convoy. Tracked vehicles might get over fallen trees but wheeled vehicles mostly get stuck. It is a new tactical situation which emerges new possibilities, challenges & gameplay elements.
- Problems of such a feature:
-- AI-related issues
--- path-finding / getting stuck
Scope of such an issue would be **limited** due to the fact that the main factor which determines if a vehicle would driver over a fallen static object (or not) is [[ https://community.bistudio.com/wiki/Arma_3_Named_Properties#mass | Mass ]] model property. If mass of a vehicle is greater than mass of a fallen static object then the vehicle will drive through the fallen static object (with or without Normal Geometry). Mass of tracked vehicles is usually greater than mass of Trees, however, mass of wheeled vehicles might be lower or close to mass of Trees. Mass of Fences and Walls is close or lower than mass of Trees. As a result, the issue may apply to some of wheeled vehicles controlled by AI. It is also highly probable that AI infantry units would not by affected by the issue as it is easier for AI infantry entity to navigate than for AI vehicle entity.
How does it work in practice?
Recently I released [[ https://forums.bohemia.net/forums/topic/231138-treefix/ | TreeFix ]], a OFP/ACWA modification which provides a solution for //the fallen tree bug//.
> By default, TreeFix provides limited geometry for fallen trees (View Geometry & Fire Geometry). You can enable all three geometries (Geo, ViewGeo & FireGeo) for fallen trees by placing TreeFix gamelogic in a mission or by a statement TREEFIX_FULLGEO=true.
My modification provides not only the solution that was applied in Arma 3 with 1.84 Encore Update, but goes a step forward and introduces a solution for having all the geometries of fallen static objects working. Taking into consideration that the modification is based on a workaround - turns out to work really well. Also, it is multiplayer-compatible!
[[ https://youtu.be/FU__vlXMYH0 | OFP: "Geometry of fallen tree - FIXED"]]
Due to the nature of the workaround TreeFix uses, and amount of modifications of models that is required for the workaround to work, TreeFix is limited to trees only. However, engine-side solution, which I believe would be much more simpler in implementation, would apply to all objects which feature Tree/Fence/Wall destruction type.
> An alternative solution (if it is not possible to provide a switch).
> Introduce alternative destruction types (//destrtype//) which would keep all of geometries of fallen static objects. The destrtypes would be a follows:
> - for config class
> -- //DestructTreeX/////DestructFenceX/////DestructWallX//
> - for model properties
> -- //TreeX/////FenceX/////WallX//
Such an alternative solution would not be user-friendly and would require additional work for anyone who would like to make a use of the new destrtypes. The alternative solution would require to change destrtype of each class/model for the new one. It is feasible as long as such an object has a config class (Fences or Walls do have their config classes). However, Trees do not have their config classes. As a result, Tree models would have to have their //damage/dammage// property changed manually in their [[ https://community.bistudio.com/wiki/Arma_3_Named_Properties#damage.2Fdammage | Named Properties ]]. Due to the fact that Tree models are binarized and that Arma 3 Licensed Data Packages have not been released, modification of Tree models properties is not possible. This is why the alternative solution should only be considered as the last resort if all the efforts of providing a switch fail.