Missile Spread is Incorrect

[LiSongMWO]

LSML version: (develop) Java version: 8u301

Steps to reproduce issue:

1. Open LSML
2. Add SRM/MRM/LRM/ATM/RL to mechs
3. Look in WeaponLab

Actual result: The damage fallof is based on a cone shaped, shotgun like spread pattern. This is correct for LB-X style Auto Cannons but not for missiles. Missiles have a limited spread, they seem to fan out into a tubular flight path. This results in incorrect fallof calculations.

Expected result: The falloff from missile spread better models real life behaviour

[sestrand]

ok, I'll start collecting data on this. Wont lie, I think this will take a while [month(s)?] and will be pretty tedious. And, unfortunately, the results might suddenly be incorrect if PGI changes anything related to the missiles, mid experiment. (although if all PGI is doing is mucking with the quirks, that will not be an issue if we have a good experiment design). But I think lots of shots from lots of distances with all of the pods (with and without artemis) will be the only way to really sort how these behave. I'll try to also include unguided LRMs and ATMs in the dataset.

With enough shots I think we can determine what the PGI attributes actually mean for missiles. is there a preferred way you would like to store the data? I am thinking in a shared google spreadsheet. But if you have a better way to keep this in github or something, let me know. I believe for each shot we will need weapon, range, damage, range quirks, velocity quirks, spread quirks, volley size (just in case we want to explore what a size limited hardpoint does to this), size of target (or probably even more specifically, chassis of target)... and I guess that is all I can think of for now. If you think of any more attributes that might impact missiles, please let me know. I would prefer to have the full list of columns we might need prior to starting this system of systems, multidimensional, experiment. Once I have a good list of the columns and variables, I'll design the experiment a bit so that we can get a good look from multiple angles at the volume of results.

for executing the tests, I'll run in game in private server against my own alt (although really I think the alt will be shooting at me because I have all of the chassii and my alt has very few... since it is normally just my target). any suggestions for small assault maps with close drop points? I think that is the fastest map/mode configuration I can use to get the best data.

I am assuming that these results will be built into LMSL when you change ranges and for the optimal range calculations. certainly could be built into a cool sandchart graph for the mech for damage over range.

[LiSongMWO]

That's a lot of questions I'll try to answer best I can:

Where store?

In the end, we need to be able to reliably go back and reference the data and conclusions. This means that the data should live somewhere under the control of the project. Typically this would be the wiki, so that in case some one doubts the research they can easily find/be pointed that way. During the process, a shared goodle spreadsheet sounds fine.

Test setup

I believe that the projectileclass defines the general behaviour of the projectiles.

I'd like to break this up into smaller test suites that each provide incremental understanding rather than doing one massive test matrix like I get the impression you're suggesting. Let's try to keep every step small and manageable. So here's my suggestion for an overall plan:

Step 1: Figure out if the projectileclass attribute acts as a general "code path selector" in that it decides the general behaviour of the weapon. I'd suggest starting by creating a spread sheet with all missile weapons and the attributes from Weapons.xml in the game files, grouped by projectile class. Already here we might be able to see that some properties are specific to some weapon classes.

At that point the first suite of tests would be to confirm if indeed the projectileclass attribute behaves as speculated above.

Step 2: Assuming the assumptions above were correct. We can design test suites for each individual projectile class, focusing on attributes specific to that class. These tests would be without skills, without quirks and without port size limits. We want to have as few variables as possible to tease out at a time. The testing effort is combinatorial in the number of variables :)

Step 3: At this point we likely have a decend idea of the basic behaviour of the spread for all the projectile classes and we can implement this as a first step in LSML without quirks being taken into account. We can verify that what's implemended seems to match empirical observations as a first validation.

Step 4: For individual quirks and skills we can devise tests to tease out how exactly they apply. In general this is fairly straigiht forward from the internal naming scheme of the quirk so presumably we'd have a hypothesis real quick just by looking at the quirk.

Test methodology

In general, for each test we want to vary as few parameters as possible. This could be hard due to the limited set of missile weapons available. But at the very least we should make sure that pilot skills and quirks do not affect the results until we want them to in the final step.

Also worth noting is that observing the spread from the first person view will be difficult because of the perspective projection of the camera and not being able to easily tell how far away the missiles are. For this reason it would be desirable to use an observer account that can view the flight path parallell to the view plane (i.e. perpendicular to the camera direction) both from the top and side to see if they differ.

Code reference

The Weapon class has a method called getRangeEffectiveness that for a given range gives a value for how much the range attenuates the weapon damage. This delegates the work to the WeaponRangeProfile class that handles all weapon fall-off, spread etc.

See here: https://github.com/lisongmechlab/lsml/blob/2db92da3250e47e8a69dc0d1d4950870e2fda7ae/src/main/java/org/lisoft/lsml/model/item/WeaponRangeProfile.java

This class would need some TLC to handle the different projectile types or potentially have that broken out into the various Weapon subclasses.

[sestrand]

I can design the experiment based on the variables we want considered. my question is... are there any other variables missing from my previous list?

I'll send you a link to the shared spreadsheet once I collect some data.

I do not believe the flyout matters in terms of what can be display on LSML. It is really just what happens on the (locked or unlocked) target end. The results will turn into an equation of some sort that will show the spread effects based on distance in the weapon and the other variables that can be evaluated in the experiment. Those resulting equations can be displayed in the sand tables of the weapon lab or in the single values when the user selects the range on the main mech editor page.