Ophiuchus wrote: ↑Sat Oct 20, 2018 11:41 pmGeoff the Medio wrote: ↑Fri Oct 19, 2018 5:12 pmNot for the first iteration. Probably later.
I honestly don't have the resources necessary for that kind of development style. The discussion was already past the first iteration some weeks ago. Is the intention to have something more complex or is it off the table? This really matters for the design and "later".
For this case (targetting), it's not necessary to implement a complicated multi-tier system immediately. Just adding conditions to select targeting for parts will be functional in of itself, should solve some / much of the problems motivating these changes, and should be relatively quick. It can also be implemented in a way that effectively changes nothing to start with... in that the targeting conditions added to parts can replicate the hard-coded part-type-based restrictions that currently exist. It will thus allow small incremental scripted content changes to be tried out and tested to see what works and doesn't. After that's implemented and understood with testing, whether how to extend the system further can be better determined than now. We / you shouldn't spend a lot of effort and time implementing a much more complicated system than is necessary to make that first step. By keeping the scope of the initial changes smaller, it can get accepted and put into master much quicker, at which point other can start experimenting with it.
The stockpile case was a bit different, in that there needed to be a lot of interacting complicated systems working together to get it right. But the stockpile is the same in that knowing how it will work as a system before it was implemented and tested wasn't possible.
Since in this case things can be done more incrementally, I strongly prefer to do so, and just start with the minimal functional change, which is, I think, adding a targeting condition to parts to extend and replace the part-type based restrictions that currently exist. Prioritizing targets with randomness might be interesting, but I don't think it's necessary or a good idea. If it is done, I don't think it should be done the way you propose, and should instead be done using the existing conditions mechanism, with some supporting extensions to that.
It's also not necessary to add any new conditions to start with, to support things like fighters that have a particular damage value, or better support for sorting / prioritizing targets instead of just filtering them. The current system just has fighter vs. not, and all that is needed to support that is to extend the types recognized by the ObjectType condition, which currently doesn't support matching Fighter objects. This is a relatively simple change, which I can just do in master if you prefer not to. And if without that change, a workaround could be scripted using something like "Not [Or [Planet Ship]]", which would be equivalent to "Fighter" in the context of objects involved in combat. Edit: "Fighter" should work now in master /Edit
Geoff the Medio wrote: ↑Thu Oct 18, 2018 9:12 pmAn implementation detail is whether to enforce number of targets in the condition or after the condition narrows down the options...
I really don't understand why you say that and the connection to what i wrote. If you have a possilbe_targets condition like armed ships, all the enemy troops, scouts, ... will be unharmed.
I was discussing how to go from a large set of possible targets (that match a targeting condition like "Fighter" or "Ship") to a single or small set of targets that will actually be fired upon by a weapon. This was in response to:
Ophiuchus wrote: ↑Fri Oct 19, 2018 4:49 pmAll the individual weapons in the ships in that system will shoot at that one target and ignore the other 99 because they have the same deterministic possible_targets condition.
Regarding what happens to objects that don't match a targeting condition, like unarmed ship or planets if the targeting condition excludes them, I don't think that needs to be addressed in the first pull request. I have suggested solutions though; the most flexible would be having a sorting based targeting condition, which will pick armed ship first, and then target unarmed if no armed ships are present. Doing this would probably require implementing some non-trivial condition support though, so I'd put that off for now. Alternatively, use conditions that limit the target of a weapon to armed ships sparingly. Most weapons in the initial iterations should target all ships. A few specialized one could target only armed ships. This would be a temporary solution, though.
Geoff the Medio wrote: ↑Thu Oct 18, 2018 9:12 pmFighter objects have a damage property.
Which is different depending on the hangar type, the owners empire tech, if the ship was resupplied since tech change and species weapon skill. Probably something else what i forgot. Does not look too simple to me.
Fighter objects are created during combat and assigned a damage value at that time based on the meters of the ship they launch from. After that, it doesn't matter what effects or factors lead to a fighter object having a particular damage value, and it isn't necessary to know what hangar type a fighter launched from to test its damage value. A fighter's damage value can be tested and matched by a condition (that needs to be implemented, but not necessarily in the first pull request, or by you).
Geoff the Medio wrote: ↑Thu Oct 18, 2018 9:12 pmI'd just add a Condition or ValueRef to test that value for fighters, which can be used in targeting conditions. One can also set up a ValueRef to get the the name of the design of the ship that launched a fighter, since fighters track ship they launched from. This would involve adding a suitable ValueRef to access the Fighter object's stored launching-ship-ID.
Yes, i called that condition "LaunchedBy". I am really not sure you read what i wrote...
*puzzled*
LaunchedBy would let one get access to the statistics of the ship that launched the fighter. But as above, this information is unnecessary to just check what the fighter's damage value is because the Fighter object itself contains the damage value which is set when the Fighter object is created when the fighter is launched. Edit: I've
added support for the .Attack property on fighter objects in FOCS, which returns their stored damage value. /Edit