Barry Evans
Barry Evans
My view is the existing Mission framework is spaghetti coding and impossible to test. We need to look forward to the new approach that should be more stable and fully...
I think you should do this work on a branch as it has the potential for a large impact
Also any shared memory object needs to be thread safe and efficient. I think containers can still be individual objects but more lightweight without the Unit logic
Ok but are you going to have to specialise whenever a new container is used in all the various calling code places?
I do think we need to address how Containers are simulated because having them as Units is too heavy weight. For example they do not need to be centrally managed...
The key question is do these need to be actively simulated when not attached to a Vehicle? The answer will say weather they are Equipment or not. Equipment are expensive...
Ideally the FRU should be a Equipment. This is how I see the modelling: - Parts - stateless entities not individually modelled - Equipment - stateful entities modelled individually but...
Having a ContainerOwner is going to complicate the modelling more. I think we should retain EquipmentOwner but drop Unit from the Equipment class. This would also drop Equipment from UnitManager....
I still believe that if we implement loading the high resolution map on the fly for a region around the target we can also achieve this purpose. Also we need...
Interesting, I think the best way to do this is to create a new map later implementation that can convert a low res map into a high res map. So...