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

Ship targeted not working when 'Drive' subsystem targeted #2624

Closed
Darkcyde13 opened this issue Jun 21, 2024 · 4 comments
Closed

Ship targeted not working when 'Drive' subsystem targeted #2624

Darkcyde13 opened this issue Jun 21, 2024 · 4 comments
Assignees
Labels
6. not up to spec The expected behaviour per the spec doesn’t match the observed behaviour.

Comments

@Darkcyde13
Copy link

What's Wrong (please be as specific as possible)

Expected

Ship targeted script to run each time a subsystem is targeted.

Observed

Ship targeted runs for each susbsystem, except for 'Drive'. An error appears in the EDDI log when a drive is selected.

Steps to reproduce

  1. Add a test line to Ship targeted, to state the subsystem
  2. Target a ship
  3. Cycle the subsystems
  4. Observe Ship targeted voices every subsystem, but does not when a 'drive' is targeted.

Configuration

  • Version [Please give full version numbers here, not just "latest" or "current"]
    • EDDI Version: v4.0.4-b2
    • VoiceAttack Version: [if applicable]
  • Localization [if applicable]
    • EDDI's language: [or the operating system language if EDDI's language setting is "Automatic"]
    • Voice: [Name and language]

My Investigation

Investigation Notes

I was just targeting a couple of ships while outside a station, and I realised that my targeting script was always stopping when I selected the target's drive.

On investigation, I could see the entries in the game Journal appearing fine, showing that each subsystem was being targeted correctly, including the drive. However, when I looked at the EDDI log there were errors regarding "Object reference not set to an instance of an object." for each time I targeted the drive.

I made a copy of the EDDI default personality to test this out, and it still failed.

EDDI Logs

Log errors:

2024-06-21T22:43:28 [Info] ResourceBasedLocalizedEDName:FromEDName Unknown ED name ext_drive_class5_b in resource EddiDataDefinitions.Properties.Modules
2024-06-21T22:43:28 [Warning] ModuleDefinitions:FromEDName Unknown module edname: $ext_drive_class5_b_name;
2024-06-21T22:43:28 [Warning] JournalMonitor:ParseJournalEntry Object reference not set to an instance of an object./r/nRaw event:/r/n{ "timestamp":"2024-06-21T22:43:31Z", "event":"ShipTargeted", "TargetLocked":true, "Ship":"orca", "ScanStage":3, "PilotName":"$npc_name_decorate:#name=Seb Geddes Cloned;", "PilotName_Localised":"Seb Geddes Cloned", "PilotRank":"Master", "ShieldHealth":100.000000, "HullHealth":100.000000, "Faction":"Freedom Party of LP 462-19", "LegalStatus":"Clean", "Subsystem":"$ext_drive_class5_b_name;", "Subsystem_Localised":"Drive", "SubsystemHealth":100.000000 }: {"ClassName":"System.NullReferenceException","Message":"Object reference not set to an instance of an object.","Data":null,"InnerException":null,"HelpURL":null,"StackTraceString":"   at EddiJournalMonitor.JournalMonitor.ParseJournalEntry(String line, Boolean fromLogLoad) in EddiJournalMonitor\\JournalMonitor.cs:line 2259","RemoteStackTraceString":null,"RemoteStackIndex":0,"ExceptionMethod":"8\nParseJournalEntry\nEddiJournalMonitor, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null\nEddiJournalMonitor.JournalMonitor\nSystem.Collections.Generic.List`1[EddiEvents.Event] ParseJournalEntry(System.String, Boolean)","HResult":-2147467261,"Source":"EddiJournalMonitor","WatsonBuckets":null}

eddi.log

Player journals

Journal.2024-06-21T233423.01.log

@Tkael
Copy link
Member

Tkael commented Jun 22, 2024

Interesting. Most modules we can target have the exact same names as modules available to players. Drives appear to depart from that standard.

@Tkael
Copy link
Member

Tkael commented Jun 22, 2024

I'm sure this isn't a complete list but

$ext_drive_class1_c_name;
$ext_drive_class2_a_name;
$ext_drive_class3_cob_name;
$ext_drive_class4_a_name;
$ext_drive_class5_a_name;
$ext_drive_class5_b_name;
$ext_drive_class5_d_name;
$ext_drive_class5_e_name;
$ext_drive_class6_b_name;
$ext_drive_class7_a_name;
$ext_drive_class7_b_name;
$ext_drive_class7_c_name;
$ext_drive_class7_d_name;
$ext_drive_krait_name;
$ext_drive_krait_light_name;

@Tkael Tkael closed this as completed in c0f8041 Jun 22, 2024
@Tkael
Copy link
Member

Tkael commented Jun 22, 2024

Should be fixed in the next release.

@Tkael Tkael self-assigned this Jun 22, 2024
@Tkael Tkael added the 6. not up to spec The expected behaviour per the spec doesn’t match the observed behaviour. label Jun 22, 2024
@Darkcyde13
Copy link
Author

Thank you! :)

bcthund pushed a commit to bcthund/EDDI that referenced this issue Jun 26, 2024
…ystems with unrecognized module definitions are targeted.

Resolves EDCD#2624
bcthund pushed a commit to bcthund/EDDI that referenced this issue Jun 26, 2024
…ystems with unrecognized module definitions are targeted.

Resolves EDCD#2624
bcthund pushed a commit to bcthund/EDDI that referenced this issue Jun 26, 2024
…ystems with unrecognized module definitions are targeted.

Resolves EDCD#2624
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
6. not up to spec The expected behaviour per the spec doesn’t match the observed behaviour.
Projects
None yet
Development

No branches or pull requests

2 participants