SRMs reported with different eFP and rFP, in the weapons page.

[sestrand]

LSML version: 2.0.14
Screen resolution: 3440x1440
Java version: 8u333

Steps to reproduce issue:

1. Open LSML
2. Click on weapons page/tab
3. compare eFP with rFP on the SRMs (or any other single volley missile)

Actual result:
eFP and rFP have different values.

Expected result:
because they are a single volley they should have the same value.

[Li Song]

Summarising offline discussion here:

LSML is not correctly accounting for volley sizes of some weapons. For all weapons we need to determine the volley size. If it's not given in the XML files it should be assumed that all projectiles/missiles are fired in one volley. There's a delay between each volley, given in the XML. One odd observation from the game files is that IS-LRM20 has a volley delay of 0.5 seconds, I don't recall it firing in volleys does it? We need to confirm the actual firing period in game compare to LSML here.

For Historical context: volley size wasn't available as a parameter in the game files at the inception of LSML and some heuristics were used to determine if a weapon was "streaming" missiles.

So for all weapons the base computation of the raw firing period (rFP) should be updated to be:

double numVolleys = Math.Ceiling(numFiring / volleySize); // Use ceiling if volleySize doesn't evenly divide numFiring for some reason.
double firingDelay = (numVolleys - 1)* volleyDelay; // No delay after last volley
double coolDown = getCooldown(aModifiers);
return firingDelay + coolDown;

Obviously then depending on weapon type, burn duration of lasers and charge time for gauss etc needs to be added.

It has been noted that port size is now available in the game files and this would allow LSML to model the effect of the port size for missile launchers to better compute actual DPS of equipped launchers but this requires some careful UI design to make the user aware of this and to explain why the DPS might differ between the Weapons page and the Loadout page if equipped on a hardpoint that has a port size limit. We should file a follow-up FR to investigate the possibility of adding this but it's out of scope for this bug.

As for fixing the bug, I think a solid approach might be to let the Weapon class always have a volley size in addition to volley delay that's already present.
Then if volley size is not set for a weapon in the game files, we can just just set it to "num_firing" in the parsing code and then it will always be present in LSML and we can then push the function that L76 was supposed to perform down to Weapon.getRawFiringPeriod.

I'm a little bit worried about the possibility of other confusions also existing. In particular with num_firing compared to ammo_per_shot. It might be worthwhile auditing the implementations of the weapon classes and adding additional tests.

[Li Song]

I filed #776 for port size limits.

[sestrand]

regarding num_firing compared to ammo_per_shot: I concur this nomenclature in PGI files is confusing, but tests that may be missing can be built to check for changes from PGIs pattern (current PGI file extract below). numFiring is the value associated with determining damage and timing. ammoPerShot is associated with ammunition consumption and the total rounds carried (which is related to the total damage potential of the loadout etc). all lasers/PPCs, numFiring = 1 and ammoPerShot = 0. all IS AC/Gauss/IS UAC2/UAC5/Clan UAC2/ClanAC2/ClanAC5, numFiring = 1, and ammoPerShot = 1. IS UAC10/Clan UAC5/Clan AC10, numFiring = 2 and ammoPerShot = 1. IS UAC20/Clan UAC10/Clan AC20, numFiring = 3 and ammoPerShot = 1. Clan UAC20, numFiring = 4 and ammoPerShot = 1. lbxX, numFiring = X and ammoPerShot = 1. all IS lrmY/all (s)srmY/rlY, numFiring = Y and ammoPerShot = Y. all Clan lrmZ/Clan atmZ/IS mrmZ, numFiring = 1 and ammoPerShot = Z. for all of the above that consume ammo, volleydelay is > 0 (minus lbx, see below) and volleysize varies by type and is currently only set explicitly for missile weapons that stream ammunition. Also, the volley delay is only applied between volleys. I did some testing on the private server. to get a delay to occur for IS LRMs or SRMs, which normally fire all rounds in a single volley, you must install the launcher in a hardpoint that restricts the number of missiles below the max of the launcher. for example, atlas missile hardpoints are limited to 5 or 10 tubes (depending on which order you install the launchers) and you will get volleys of 5 or 10 for the lrm 20 you put in there... then delay listed in the PGI file is applied between those volleys. ballistic weapons do not have the explicit volleysize in the PGI files. so we may need to make some assumptions on ballistic weapon behavior... and do some private server testing to see if the (short) delay is actually being applied between the one round volleys in these weapons. In game the delay is applied, lbx fires all of their rounds together (lbx delay = 0) and the UACs and ACs with numFiring > 0 fire them with the short delays as listed. what does that mean for LSML? maybe nothing, but needs some testing. What I dont know for certain is if the delay extends the total firing time of the weapon or if cooldown starts at trigger pull. for a Clan UAC20 the accumulated delay is .33s with a cooldown of 4s. I will see if I can measure that and see if that is included or not. for all RACs/MGs/Flamers/AMSs, numFiring = 1, ammoPerShot = 1, but volleydelay = 0 and RoF > 0. [gets to the answer for a rate of fire, but does it more directly]

…

On Fri, Jul 1, 2022 at 7:23 AM Li Song ***@***.***> wrote: Summarising offline discussion here: LSML is not correctly accounting for volley sizes of some weapons. For all weapons we need to determine the volley size. If it's not given in the XML files it should be assumed that all projectiles/missiles are fired in one volley. There's a delay between each volley, given in the XML. One odd observation from the game files is that IS-LRM20 has a volley delay of 0.5 seconds, I don't recall it firing in volleys does it? We need to confirm the actual firing period in game compare to LSML here. For Historical context: volley size wasn't available as a parameter in the game files at the inception of LSML and some heuristics were used to determine if a weapon was "streaming" missiles. So for all weapons the base computation of the raw firing period (rFP) should be updated to be: double numVolleys = Math.Ceiling(numFiring / volleySize); // Use ceiling if volleySize doesn't evenly divide numFiring for some reason. double firingDelay = (numVolleys - 1)* volleyDelay; // No delay after last volley double coolDown = getCooldown(aModifiers); return firingDelay + coolDown; Obviously then depending on weapon type, burn duration of lasers and charge time for gauss etc needs to be added. It has been noted that port size is now available in the game files and this would allow LSML to model the effect of the port size for missile launchers to better compute actual DPS of equipped launchers but this requires some careful UI design to make the user aware of this and to explain why the DPS might differ between the Weapons page and the Loadout page if equipped on a hardpoint that has a port size limit. We should file a follow-up FR to investigate the possibility of adding this but it's out of scope for this bug. As for fixing the bug, I think a solid approach might be to let the Weapon <https://github.com/lisongmechlab/lsml/blob/develop/src/main/java/org/lisoft/lsml/model/item/Weapon.java> class always have a volley size in addition to volley delay that's already present. Then if volley size is not set for a weapon in the game files, we can just just set it to "num_firing" in the parsing code and then it will always be present in LSML and we can then push the function that L76 was supposed to perform down to Weapon.getRawFiringPeriod <https://github.com/lisongmechlab/lsml/blob/f2b6fae9ad894742b80079868d638ea0c32c0798/src/main/java/org/lisoft/lsml/model/item/Weapon.java#L196> . I'm a little bit worried about the possibility of other confusions also existing. In particular with num_firing compared to ammo_per_shot. It might be worthwhile auditing the implementations of the weapon classes and adding additional tests. — Reply to this email directly, view it on GitHub <#775 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AK7QXZFPRMDZIL5OTM4PBGTVR3PL3ANCNFSM52LDLD3A> . You are receiving this because you authored the thread.Message ID: ***@***.***>