EDCD / EDDI

Companion application for Elite Dangerous
Other
440 stars 81 forks source link

Script "Damage Check" not correctly reporting damage to ship #495

Closed Redmunchkin closed 4 years ago

Redmunchkin commented 6 years ago

EDDI version :- 3.0.0 (updated on 2018/04/16 at approx 22:15 BST))

Steps to reproduce

  1. damage ship - hull at 95% various modules between 90 and 30 %
  2. say the command "damage report"

Expected

I expected to be told that the ship was damaged and that the modules where in various states of damage

Observed

I was told the ship was fully operational.

Investigation

I created my own command to be called via a VA command This script/command read out the item and the variable e.g

Hull at {Humanise(ship.health)}%. powerplant at {Humanise(ship.powerplant.health)}%. thrusters at {Humanise(ship.thrusters.health)}%. < This script worked but the values read out where all 100%!!! Image of the actual damage attached ....

Other EDDI Commands work like Pad XX Open Elite Redit Check Aberrant Shield Pattern Analysis (gives the correct value) Is there any news? Which materials can i discard ..

eddi.zip screenshot_0056

Tkael commented 6 years ago

I'm afraid that FDev have given us rather limited visibility into hull and module health. There is no generic event written for module damage. The event for hull damage is only written when hull damage changes by at least 20%.

The data EDDI references for hull and module health is derived from two sources:

  1. The Loadout event, which is generated when you first enter the game or switch ships. (sample below)
{ "Slot":"MediumHardpoint1", "Item":"Hpt_PulseLaserBurst_Gimbal_Medium", "On":true, "Priority":0, "Health":1.000000, "Value":41225, "Engineering":{ "Engineer":"Broo Tarquin", "EngineerID":300030, "BlueprintID":128673384, "BlueprintName":"Weapon_RapidFire", "Level":5, "Quality":0.000000, "Modifiers":[ { "Label":"DamagePerSecond", "Value":12.996548, "OriginalValue":10.296336, "LessIsGood":0 }, { "Label":"Damage", "Value":2.132533, "OriginalValue":2.450000, "LessIsGood":0 }, { "Label":"DistributorDraw", "Value":0.322116, "OriginalValue":0.490000, "LessIsGood":1 }, { "Label":"RateOfFire", "Value":6.094418, "OriginalValue":4.202586, "LessIsGood":0 }, { "Label":"Jitter", "Value":0.487069, "OriginalValue":0.000000, "LessIsGood":1 } ] } }, 
  1. The Frontier API, which FDev have asked us to use sparingly (sample below)
{"LargeHardpoint1":{"module":{"id":128049387,"name":"Hpt_PulseLaser_Gimbal_Large","locName":"Pulse Laser","locDescription":"Single-pulse laser weapon on gimballed mount, with signature tracking assist.","value":140600,"free":false,"health":726563,"on":true,"priority":2},"engineer":{"engineerName":"The Dweller","engineerId":300180,"recipeName":"Weapon_Efficient","recipeLocName":"Efficient Weapon","recipeLocDescription":"Installing this weapon blueprint reduces thermal load and power draw.","recipeLevel":4},"WorkInProgress_modifications":{"OutfittingFieldType_ThermalLoad":{"value":0.475,"LessIsGood":true,"locName":"Thermal load","displayValue":"52.50%","dir":"\u02c4"},"OutfittingFieldType_DamagePerSecond":{"value":1.2,"LessIsGood":false,"locName":"Damage per second","displayValue":"20.00%","dir":"\u02c4"},"OutfittingFieldType_Damage":{"value":1.2,"LessIsGood":false,"locName":"Damage","displayValue":"20.00%","dir":"\u02c4"},"OutfittingFieldType_PowerDraw":{"value":0.6416,"LessIsGood":true,"locName":"Power draw","displayValue":"35.84%","dir":"\u02c4"},"OutfittingFieldType_DistributorDraw":{"value":0.65,"LessIsGood":true,"locName":"Distributor draw","displayValue":"35.00%","dir":"\u02c4"}},"specialModifications":{"special_scramble_spectrum":null}}

Note that the data is not reported equally in these two events. The Loadout event reports health as a fraction of 1, while the Frontier API reports health as the total integrity of the module, including all modifications. We cannot use the Frontier API data effectively at present because we cannot currently calculate the maximum module integrity.

There are several options for moving forward:

  1. Somehow flag the Damage report script so that it's only available immediately after a loadout event, before you leave dock (which I believe was the original intent when coupled with the start pre-flight checks VoiceAttack script)
  2. Remove the Damage report script
  3. Update our module definitions to include base values for module integrity and upgrade our Frontier API code to convert modified modules and output fractional health values (this is the most resource intensive option and the most likely to break, unfortunately)
  4. Petition FDev for a module damage event (it's likely that if we were to get this, it'd either be written at increments of 20% damage, written when you look at your right hand modules panel, or written upon docking)
Redmunchkin commented 6 years ago

Thanks for the quick and informative reply! Its unfortunate that it's not possible to get that data from the game. I was quite excited to see that script and had thoughts of warnings being read out as critical modules get damaged.

It would be handy for FDev to let the API have access to that kinda data, as it's there for us to see as a percentage on the panels already.

On 17 April 2018 at 04:45, Tkael notifications@github.com wrote:

I'm afraid that FDev have given us rather limited visibility into hull and module health. There is no generic event written for module damage. The event for hull damage is only written when hull damage changes by at least 20%.

The data EDDI references for hull and module health is derived from two sources:

  1. The Loadout event, which is generated when you first enter the game or switch ships. (sample below)

{ "Slot":"MediumHardpoint1", "Item":"Hpt_PulseLaserBurst_Gimbal_Medium", "On":true, "Priority":0, "Health":1.000000, "Value":41225, "Engineering":{ "Engineer":"Broo Tarquin", "EngineerID":300030, "BlueprintID":128673384, "BlueprintName":"Weapon_RapidFire", "Level":5, "Quality":0.000000, "Modifiers":[ { "Label":"DamagePerSecond", "Value":12.996548, "OriginalValue":10.296336, "LessIsGood":0 }, { "Label":"Damage", "Value":2.132533, "OriginalValue":2.450000, "LessIsGood":0 }, { "Label":"DistributorDraw", "Value":0.322116, "OriginalValue":0.490000, "LessIsGood":1 }, { "Label":"RateOfFire", "Value":6.094418, "OriginalValue":4.202586, "LessIsGood":0 }, { "Label":"Jitter", "Value":0.487069, "OriginalValue":0.000000, "LessIsGood":1 } ] } },

  1. The Frontier API, which FDev have asked us to use sparingly (sample below)

{"LargeHardpoint1":{"module":{"id":128049387,"name":"Hpt_ PulseLaser_Gimbal_Large","locName":"Pulse Laser","locDescription":"Single-pulse laser weapon on gimballed mount, with signature tracking assist.","value":140600,"free":false,"health":726563,"on": true,"priority":2},"engineer":{"engineerName":"The Dweller","engineerId":300180,"recipeName":"Weapon_Efficient","recipeLocName":"Efficient Weapon","recipeLocDescription":"Installing this weapon blueprint reduces thermal load and power draw.","recipeLevel":4}," WorkInProgressmodifications":{"OutfittingFieldType ThermalLoad":{"value":0.475,"LessIsGood":true,"locName":"Thermal load","displayValue":"52.50%","dir":"\u02c4"},"OutfittingFieldType_ DamagePerSecond":{"value":1.2,"LessIsGood":false,"locName":"Damage per second","displayValue":"20.00%","dir":"\u02c4"}," OutfittingFieldType_Damage":{"value":1.2,"LessIsGood":false, "locName":"Damage","displayValue":"20.00%","dir":" \u02c4"},"OutfittingFieldType_PowerDraw":{"value":0.6416," LessIsGood":true,"locName":"Power draw","displayValue":"35.84%", "dir":"\u02c4"},"OutfittingFieldType_DistributorDraw":{"value":0. 65,"LessIsGood":true,"locName":"Distributor draw","displayValue":"35.00%", "dir":"\u02c4"}},"specialModifications":{"special_scramble_spectrum": null}}

Note that the data is not reported equally in these two events. The Loadout event reports health as a fraction of 1, while the Frontier API reports health as the total integrity of the module, including all modifications. We cannot use the Frontier API data effectively at present because we cannot currently calculate the maximum module integrity.

  • We do not track the base integrity for each module and
  • we do not calculate the effects of modifications on module integrity. (calculating module special effects and maintaining tables of base module values are areas that we've generally deferred to Coriolis and EDShipyard and tried to avoid doing internally)

There are several options for moving forward:

  1. Somehow flag the Damage report script so that it's only available immediately after a loadout event, before you leave dock
  2. Remove the Damage report script
  3. Update our module definitions to include base values for module integrity and upgrade our Frontier API code to convert modified modules and output fractional health values (this is the most resource intensive option and the most likely to break, unfortunately)
  4. Petition FDev for a module damage event (it's likely that if we were to get this, it'd either be written at increments of 20% damage or would be written upon docking)

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/EDCD/EDDI/issues/495#issuecomment-381827618, or mute the thread https://github.com/notifications/unsubscribe-auth/AbL4GTgNKniNiNz7aD_rqHfQiGpdOBy-ks5tpWVSgaJpZM4TXVr4 .

Tkael commented 5 years ago

The Frontier API provides information on both the hull and module health, but using it for this purpose would require much more polling than we use now.

richardbuckle commented 4 years ago

Closing as cannot easily fix.