Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Redmunchkin opened this issue Apr 16, 2018 · 3 comments


Copy link

commented Apr 16, 2018

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"


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


I was told the ship was fully operational.


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(}%.
powerplant at {Humanise(}%.
thrusters at {Humanise(}%.
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 ..


This comment has been minimized.

Copy link

commented Apr 17, 2018

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.

  • 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 (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)

This comment has been minimized.

Copy link

commented Apr 17, 2018

hoksilato2 added a commit to hoksilato2/VAHoksiPack that referenced this issue Aug 27, 2018
Aunque parece no funcionar correctamente por unas modificaciones que ha realizado Fdev. mas info en:
@Tkael Tkael added this to To do in UI Updates Nov 7, 2018

This comment has been minimized.

Copy link

commented Apr 23, 2019

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
UI Updates
To do
2 participants
You can’t perform that action at this time.