Bomber wrote in Fri Sep 15, 2017 11:21 am:If the core development group were interested in stopping this constant circle of fruitless combat functionality debates that occur they'd need to change their attitude towards it.
The key point here that most of the core devs have no interest or wish to provide any combative functionality and aren't going to work on it, regardless of how often they are asked. It is the constant asking that creates the fruitless circle - as it is well known that the answer will be a loud NO.
However there is functionality that can go into the core that is equally applicable to combat - I've not seen anything blocked or removed; it's just that most of the core devs aren't going to do this. I've recently been looking into how to publish AI models over MP, this is something that has wider applications. Extensions to the MP server (for private servers), supporting scenarios, running simulations of missiles etc, is somewhere that changes may be required.
Most of the work that I did to the MP protocol - extending the number of properties available and improving the efficiency of transfer came out of the need for the OPRF aircraft to transmit more properties - but is something that has much wider applications. Equally Emesary developments are coming along nicely - we should soon (next few months) see Emesary used on the OPRF fleet to allow models to communicate with each other in a more structured way to provide chaff, flares, radar, missiles, bombs, link16, damage etc.
The excellent work by Leto and Pinto to add and improve the OPRF models shows that large steps can be made without needing core changes. As an example damage is largely implemented using the core failure system[1].
It seems to me that the core code has a good part of the support that is needed - and that actually there are lots of building blocks already available.
---------------------
[1] this generally doesn't include aerodynamic damage, but that is something that is entirely needing to be implemented in the models anyway.