Missile.cpp: yield based damage

[PtrMan]

Missiles use with this change only the yield. The received damage computation is now more physically correct/realistic.

This addresses some of the computation of #4923 .

It basically allows warheads with a wide range of choices for yield and type of explosion (conventional explosive, (thermo)nuclear)

[fluffyfreak]

Why such a large distance compared to the old one?

[PtrMan]

This is just the query distance, not the "real" explosion distance. There is no real explosion distance due to the nature of an explosion in empty space. The spatial data structure which is queried has to know a maximum query distance.
I've chosen a relatively large distance to allow for a bigger yield without modifying the queryDistance too.
Note here that this doesn't have any effect on the performance because the query is done once and because space is relatively empty anyways. Not an issue in my opinion here.

[laarmen]

May I suggest adding a comment to that effect?

Suggested change

	double queryRadius = 2000.0; // hardcoded to 2 km, this is sufficient for most explosions
	// The radius in which to search for possible recipients of the damages
	// Hardcoded to 2 km, this should be sufficient for most explosions
	const double queryRadius = 2000.0;

[PtrMan]

I am done here with this PR.

The computation is still not as realistic as it may get. I think the transfered energy depends on the solid angle of the exposed surface of the hit target. The computation to approximate it better isn't that much more complicated.
It converges to roughly the same result with a increased distance, that's all what matters to me with this PR.

[impaktor]

1. If this fixes the issue, please edit your first post to use keywords that close it if this is merged.

2. If this sets variables, like damage, radius, etc. of warhead, those aught to be set in data/libs/equipment.lua, rather than hardcoding in C++ side

[PtrMan]

1. it addresses this part "The radius can get computed with a simple formula by the yield, this is realistic in most environment (space and in atmosphere combat)" but not the others.

2. the damage was hardcoded in the original code too, can I do this in another PR after this one?

[impaktor]

2. the damage was hardcoded in the original code too, can I do this in another PR after this one?

Sure, I withdraw my objection.

[Web-eWorks]

I'm still (unfortunately) unable to chime in further, but I'll echo @impaktor's comment that we'd love to see this exposed to Lua and the equipment system. If you have any suggestions or ideas for how to improve that system that come up as you work on it, I'd love to hear them - not sure (and don't have time to check right now) if there's an open issue, but I'd definitely like to see equipment capabilities gain a bit more structure and flexibility than simply lumping them all into the Ship's properties.

[fluffyfreak]

Is this just waiting on clang formatting to be fixed?

[PtrMan]

Yes

[PtrMan]

closes #4923

[impaktor]

@PtrMan we're about to do a release soonish (in a few days? a week?), so if you could 1. rebase to master, 2. and fix the clang complaint, then we could merge this, assuming @fluffyfreak is OK, which he seemed to be.

[PtrMan]

Maybe I'll do it, I don't care if it is in this release or a future one.

[Web-eWorks]

This PR has been manually merged into master in commit 3b4b436. Thank you for proposing it!