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

Dump() of cargo.haulageData crashes EDDI #2593

Closed
Darkcyde13 opened this issue Jan 30, 2024 · 5 comments
Closed

Dump() of cargo.haulageData crashes EDDI #2593

Darkcyde13 opened this issue Jan 30, 2024 · 5 comments
Assignees
Labels
3. crash / lockup The app crashes or stops responding to input and the user must kill it, but no data is lost needs more data A developer needs more data collected for a suggested feature or needs help replicating a bug

Comments

@Darkcyde13
Copy link

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

Expected

Using dump() with cargo.haulageData to either resolve normally, or fail gracefully.

Observed

EDDI crashes to desktop.

Steps to reproduce

  1. Take surface rescue missions (two or more) that all need the same type of commodity. Like landmines or bootleg liquor.
  2. Collect all needed cargo for all missions.
  3. Run CargoDetails() for the specific mission commodity.
  4. Check dump(cargo.haulageData) for the mission commodity.
  5. Observe that EDDI crashes to desktop.

Configuration

  • Version [Please give full version numbers here, not just "latest" or "current"]
    • EDDI Version: v4.0.3
    • VoiceAttack Version: v1.12
  • Localization [if applicable]
    • EDDI's language: British English
    • Voice: Ivona Amy

My Investigation

Investigation Notes

I've been trying out some new things with missions and cargo, and in the process, I started getting crashes to desktop.

To try to find what was causing it, I first tried the EDDI default, but all went as normal. I then made a copy of the EDDI default, and created a new test script, the same as I am using in my own personality:

{set cargo to CargoDetails("Bootleg Liquor")}

  Cargo:{char(10)}
   Name: {cargo.name},{char(10)}
  Owned: {cargo.owned},{char(10)}
Haulage: {cargo.haulage},{char(10)}
  Total: {cargo.total},{char(10)}
   Need: {cargo.need},{char(10)}
 Amount: {amount}.

{if cargo.haulageData:
    {char(10)}
    Haulage:{char(10)}
    Miss ID: {cargo.haulageData.missionid},{char(10)}
       Name: {cargo.haulageData.name},{char(10)}
       Need: {cargo.haulageData.need},{char(10)}
     Amount: {cargo.haulageData.amount}.{char(10)}
       Dump: {dump(cargo.haulageData)}
}

I use the first line to set the commodity to the same one as for the missions I have, when I've manually tested it, otherwise I comment that line out.

In the above case, I had taken two missions that both required one unit of Bootleg Liquor for each. When I'm running my personality, I have the above script trigger from within the Commodity collected event script, and when I collected the first unit, EDDI crashed. I then reloaded VA, and proceeded to the second mission location. After landing, I set EDDI to the default personality and collected the next unit, which worked normally.

I then copied the EDDI default and created the above test script. Running this with 'Bootleg Liquor' set as the cargo, crashes EDDI every time. I have tried both from VA as a plugin and EDDI standalone, and they both just crash to desktop.

Further trying to narrow it down, I created a script with just the {set...} line, and that works OK. Next I tried with just the first block of code, and that also worked OK. So I was sure it was something in the second part, and testing that alone (with the set line) also made EDDI crash.

Finally, testing line by line, I have determined it is the dump() line that is crashing EDDI. I guess EDDI is failing somewhere to get haulage data for the mission commodity. If I try the same thing with any normal cargo, and set the IF statement to !cargo.haulageData, then it all works OK, including the dump() line.

For these types of missions, the cargo is considered as haulage, but seems to have no haulageData. All the properties in the script for the haulageData section are empty. Shouldn't they be populated with the correct mission specific data? Maybe this is why EDDI is crashing?

I tried running these tests with verbose logging, but nothing is reported in the log. It shows that the script resolver has the script, shows the script, but then just ends, there is nothing after the script is listed.

I also note that for these types of missions, the game doesn't produce a 'mission redirected' event when the last mission commodity is collected, leaving the mission permanently active with the system target as the original destination. Would it be possible, in the process of fixing the above, to make the mission automatically redirect to mission origin when the last commodity container is collected? I would think it not too difficult, just check the number of mission specific commodities collected against the requirements for the mission? Just a thought, in case it can be done. :)

Oh, and one last thing, I also noticed that for mission commodities like the above, all missions are counted together rather than individually. So in the above example, both Bootleg Liquor commodities, while each having individual mission IDs in the Journal, are counted and listed as two haulage and two needed in the cargo monitor (which I guess is correct), but they also appear to be two when checking haulage cargo details. I had been hoping to check if I had collected all units for a single mission, using the mission ID assigned to the specific cargo (as they are listed separately in the righthand ship inventory panel), even if I had more missions for the same commodity, but this doesn't appear to be possible. Maybe this can be addressed as part of the fixes too please? :)

EDDI Logs

N/A Nothing useful in them (see above).

Player journals

N/A

@Tkael Tkael added the 3. crash / lockup The app crashes or stops responding to input and the user must kill it, but no data is lost label Jan 31, 2024
@Tkael Tkael self-assigned this Jan 31, 2024
@Tkael
Copy link
Member

Tkael commented Mar 9, 2024

Hi there. Sorry it's taken a while for me to respond on this one.

In summary:

  1. EDDI is crashing when using {dump(cargo.haulageData)} when you have the same type of cargo from two or more surface rescue missions.
    • Did you try this with a single active mission? If so, what was the result?
    • Did you try this with cargo associated with other mission types? Is surface rescue cargo specifically needed to trigger the crash?
    • Did you happen to look at the Windows Event Viewer or VoiceAttackFault.txt (in the VoiceAttack install directory) after these crashes? These might catch traces of crashes that EDDI failed to log.
  2. Surface rescue mission cargo is classified by EDDI as a haulage quantity but seems to have no haulageData. Could null data cause a crash when a dump is attempted?
  3. The game doesn't produce a Mission redirected event when the last mission commodity is collected, leaving the mission permanently active with the system target as the original destination. Would it be possible to generate a synthetic Mission redirected event once all mission cargo has been collected?
    • Perhaps. If the mission commodity is subsequently lost or sold prior to delivery then what should happen to the mission?
  4. Haulage data is not allocated to specific mission ids. "... both Bootleg Liquor commodities, while each having individual mission IDs in the Journal, are counted and listed as two haulage and two needed in the cargo monitor (which I guess is correct), but they also appear to be two when checking haulage cargo details."

Some journal logs would be helpful both for simulating what you were seeing and for investigating your other suggestions. :-D

@Tkael Tkael added the needs more data A developer needs more data collected for a suggested feature or needs help replicating a bug label Mar 9, 2024
@Darkcyde13
Copy link
Author

Hiya,

No worries, it's been a while since I was doing the above. I kinda stopped when I realised that it wasn't really possible with the current data that's available to the user, and to EDDI. Since then I've been playing around with the Titans, so not done much in the way of missions. ;-)

I'll try to run through some over the next few days, and see if I can provide any of the requested feedback.

@Darkcyde13
Copy link
Author

OK, so this is what I have so far...

EDDI is crashing when using {dump(cargo.haulageData)} when you have the same type of cargo from two or more surface rescue missions.
I've tried it (as noted below) with only one item from one mission, and it still crashes.

- Did you try this with a single active mission? If so, what was the result?
I have now. It crashed with only one unit of the mission cargo.
Here's the Journal entries for picking up both needed for the mission:

{ "timestamp":"2024-03-10T20:16:23Z", "event":"Cargo", "Vessel":"SRV", "Count":0 }
{ "timestamp":"2024-03-10T20:16:56Z", "event":"CollectCargo", "Type":"structuralregulators", "Type_Localised":"Structural Regulators", "Stolen":false, "MissionID":957334340 }
{ "timestamp":"2024-03-10T20:16:59Z", "event":"Cargo", "Vessel":"SRV", "Count":1 }
{ "timestamp":"2024-03-10T20:17:10Z", "event":"MaterialCollected", "Category":"Manufactured", "Name":"shieldemitters", "Name_Localised":"Shield Emitters", "Count":3 }
{ "timestamp":"2024-03-10T20:17:10Z", "event":"ShipLocker" }
{ "timestamp":"2024-03-10T20:17:33Z", "event":"CollectCargo", "Type":"structuralregulators", "Type_Localised":"Structural Regulators", "Stolen":false, "MissionID":957334340 }
{ "timestamp":"2024-03-10T20:17:36Z", "event":"Cargo", "Vessel":"SRV", "Count":2 }

- Did you try this with cargo associated with other mission types? Is surface rescue cargo specifically needed to trigger the crash?
Black Box missions (space based) do the same. Here's journal entries for collecting this one:

{ "timestamp":"2024-03-10T21:38:38Z", "event":"CollectCargo", "Type":"USSCargoBlackBox", "Type_Localised":"Black Box", "Stolen":false, "MissionID":957348719 }
{ "timestamp":"2024-03-10T21:38:38Z", "event":"MissionRedirected", "MissionID":957348719, "Name":"MISSION_Salvage_CivilWar", "LocalisedName":"Civil War Black Box Salvage Operation", "NewDestinationStation":"Aristotle Gateway", "NewDestinationSystem":"Ross 780", "OldDestinationStation":"", "OldDestinationSystem":"Fomalhaut" }

Testing dump() with this, also made EDDI/VA crash.

The last thing in the EDDI log is:

2024-03-10T22:19:34 [Info] SpeechResponder:Start Initialized Speech Responder

This is when I clicked the Test button of my script. There is nothing in the VA fault text file. Windows Event Viewer has a application crash error reported (see next section below).

I tried it with a non-mission commodity, and the dump() was... nothing... nothing was voiced, but the speechresponder.out had two square brakets, [ ].

- Did you happen to look at the Windows Event Viewer or VoiceAttackFault.txt (in the VoiceAttack install directory) after these crashes? These might catch traces of crashes that EDDI failed to log.

VoiceAttackFault.txt
Nothing noted regarding the crash, but I do have lots of timeouts like this:
09/03/2024 20:36:58 - Unload of plugin, 'EDDI 4.0.3' timed out (5000ms).
I have noticed that quitting VA, it does take a long time after pressing 'close window' button at top right, I guess this is why, EDDI is not unloading properly (or at all?).

Windows Event Viewer
There is an error in the Windows Logs -> Application. See screenshots.

Screenshot 2024-03-10 203626

I noticed there is another entry just after it (this is a second instance,not the one above):

Screenshot 2024-03-10 223011

I don't know what the clr.dll does, but it seems to be that that causes the crash. Is this something that EDDI interacts with?

Surface rescue mission cargo is classified by EDDI as a haulage quantity but seems to have no haulageData.
Could null data cause a crash when a dump is attempted?

While that could be a possibility, dump() will usually say 'void' if a variable is null. I guess maybe it can't handle haulageData because that's not a single variable, but an 'array' of properties?

The game doesn't produce a Mission redirected event when the last mission commodity is collected, leaving the mission permanently active with the system target as the original destination. Would it be possible to generate a synthetic Mission redirected event once all mission cargo has been collected?
Perhaps. If the mission commodity is subsequently lost or sold prior to delivery then what should happen to the mission?

Hmm, you may have a point. It would probably just be moving the problem to another level. Ejecting the cargo produces this event (which you probably already know):

{ "timestamp":"2024-03-10T21:02:01Z", "event":"EjectCargo", "Type":"structuralregulators", "Type_Localised":"Structural Regulators", "Count":1, "Abandoned":false, "MissionID":957334340 } 

So that would mean creating another synthetic event to reset the mission, but that wouldn't be fesable, because you have no idea if the cargo can be picked up again or not.
Although, maybe, after collecting all that's needed (effectively completing the collect part of the mission), but then losing one or more for whatever reason, you could auto-fail the mission if the user jumps to supercruise or hyperspace? I mean, there is no way to get more, as the mission destination will no longer exist, and after jumping away, there will be no way to regain any lost cargo.
So, a synthetic event to complete the collection and redirect back to origin, but if any are subsequently lost, consider the mission a failure when they jump away with fewer than the required amount? Are missions something you can query from the FDev game servers with the API? (I'm guessing no).

Haulage data is not allocated to specific mission ids. "... both Bootleg Liquor commodities, while each having individual mission IDs in the Journal, are counted and listed as two haulage and two needed in the cargo monitor (which I guess is correct), but they also appear to be two when checking haulage cargo details."
As each cargo container picked up has it's own mission ID, could these not be listed separately in the cargo monitor, one row for each mission? Maybe with the mission ID beside them?

Some journal logs would be helpful both for simulating what you were seeing and for investigating your other suggestions. :-D
If there are any specific files (or parts of) that you'd like to see, other than those attached, please let me know, and I'll do my best to provide them. :-)

As a side note, I have noticed that when VA is closed (or crashes) then EDDI will no longer load as a plugin. Sometimes I have to reboot a couple of times before it will start again with VA. If I try to restart VA, it gets stuck, as in it doesn't load, and doesn't appear on screen. It does show in the list of active background processes in Task Manager. I then need to force quit (end task) VA. Still, it won't load EDDI as a plugin until after a reboot. I can run EDDI standalone fine (after 'end task'), just not with VA. But as there's nothing in the VA fault text, I'm not sure how to troubleshoot this.

@Tkael Tkael closed this as completed in 6f49c31 May 7, 2024
Tkael added a commit that referenced this issue May 7, 2024
This DateTime? property seems to have been the source of a stack overflow exception when using Cottle to dump values from a `Haulage` object.
Resolves #2593.
@Tkael
Copy link
Member

Tkael commented May 7, 2024

I think I've managed to track this down and resolve it.


As for the Mission redirected concern, it does not appear to have been accurate? (though neither EDDI nor the game currently mark the mission as failed if mission cargo is lost after leaving the salvage instance... I had to abandon the mission I tested that on).

{ "timestamp":"2024-05-06T01:15:16Z", "event":"CollectCargo", "Type":"USSCargoBlackBox", "Type_Localised":"Black Box", "Stolen":false, "MissionID":963626959 }
{ "timestamp":"2024-05-06T01:15:17Z", "event":"MissionRedirected", "MissionID":963626959, "Name":"Mission_Salvage", "LocalisedName":"Black Box Salvage Operation", "NewDestinationStation":"Pannekoek Dock", "NewDestinationSystem":"Koleti", "OldDestinationStation":"", "OldDestinationSystem":"Uterni" }
{ "timestamp":"2024-05-06T01:15:19Z", "event":"Cargo", "Vessel":"Ship", "Count":2 }

speechresponder.out: Salvage mission requirements completed. Redirected to mission origin.


Haulage data is not allocated to specific mission ids. "... both Bootleg Liquor commodities, while each having individual mission IDs in the Journal, are counted and listed as two haulage and two needed in the cargo monitor (which I guess is correct), but they also appear to be two when checking haulage cargo details."
As each cargo container picked up has it's own mission ID, could these not be listed separately in the cargo monitor, one row for each mission? Maybe with the mission ID beside them?

Haulage data is separated by mission ID but you're right that this isn't particularly easy to see at present from the UI. Honestly, I dislike having mission information split between the mission and haulage and would prefer to unify the two which might mean removing Haulage at some point). But for the immediate concern, there may be some confusion about what haulage is vs. haulageData.

  • haulage is the actual quantity of mission related cargo in your cargo hold right now.
  • haulageData is an object that tracks your mission related cargo obligations (including cargo which is needed to finish a mission but which is not currently in your cargo hold).

As a side note, I have noticed that when VA is closed (or crashes) then EDDI will no longer load as a plugin. Sometimes I have to reboot a couple of times before it will start again with VA. If I try to restart VA, it gets stuck, as in it doesn't load, and doesn't appear on screen. It does show in the list of active background processes in Task Manager. I then need to force quit (end task) VA. Still, it won't load EDDI as a plugin until after a reboot. I can run EDDI standalone fine (after 'end task'), just not with VA. But as there's nothing in the VA fault text, I'm not sure how to troubleshoot this.

Noted. I'll try to keep an out for this when I'm using VoiceAttack.

@Darkcyde13
Copy link
Author

Hiya,

Thanks for sorting out the main problem. :)

As for the Mission redirected, I kind of agree with you there. In my original testing, I wasn't getting the redirected event, but then I was only testing and checking immediately after collecting the last cargo item. In subsequent testing while trying some other ways around the problem (which I think I have a working solution for now), I realised that the redirected event seems to trigger randomly after leaving the pickup instance. Sometimes it happens as soon as I jump to supercruise, other times it will happen after a couple of jumps to other systems.

I should note though, that this is ONLY for the surface 'Rescue' missions. 'Salvage' missions seem to be unaffected and work as expected (as in your example above). Apologies if I didn't specify that before. While the in-game UI calls them surface salvage or some variation of it, the Journal calls the surface ones 'Rescue' and space USS ones 'Salvage', and considers them two separate types of mission, even though they are basically doing the same type of action.

Due to the redirect not being consistent with Rescue missions (for me at least), I've come up with a workaround for the whole recording and reporting of Rescue mission cargo. It's a bit like my original cargo recording in a State variable, before the Cargo monitor was added to EDDI. I have the surface based 'Rescue' missions all record the mission cargo, how much collected, and mission status (faking a 'completed' when the last one is collected) and store it all in a State variable. I then split it into multiple arrays when needed in various scripts. This is where I found my other problem of State variables being void during a script, as reported in #2607. I have some ideas how I might be able to work around that too, but I need to test them out first.

I started all this because I wanted to get the mission routing working correctly, but because Rescue missions don't consistently redirect at appropriate times, I needed to work around that. So that's why I've been trying to get the Rescue mission stuff sorted. :)

Anyway, thanks again. Thank you for the explanation regarding 'haulage', and thank you for continuing to work on EDDI! :)

bcthund pushed a commit to bcthund/EDDI that referenced this issue Jun 26, 2024
…ctor.

Resolves EDCD#2593 (empty constructor seems to have led to a StackOverFlow exception)?
bcthund pushed a commit to bcthund/EDDI that referenced this issue Jun 26, 2024
This DateTime? property seems to have been the source of a stack overflow exception when using Cottle to dump values from a `Haulage` object.
Resolves EDCD#2593.
bcthund pushed a commit to bcthund/EDDI that referenced this issue Jun 26, 2024
…ctor.

Resolves EDCD#2593 (empty constructor seems to have led to a StackOverFlow exception)?
bcthund pushed a commit to bcthund/EDDI that referenced this issue Jun 26, 2024
This DateTime? property seems to have been the source of a stack overflow exception when using Cottle to dump values from a `Haulage` object.
Resolves EDCD#2593.
bcthund pushed a commit to bcthund/EDDI that referenced this issue Jun 26, 2024
…ctor.

Resolves EDCD#2593 (empty constructor seems to have led to a StackOverFlow exception)?
bcthund pushed a commit to bcthund/EDDI that referenced this issue Jun 26, 2024
This DateTime? property seems to have been the source of a stack overflow exception when using Cottle to dump values from a `Haulage` object.
Resolves EDCD#2593.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
3. crash / lockup The app crashes or stops responding to input and the user must kill it, but no data is lost needs more data A developer needs more data collected for a suggested feature or needs help replicating a bug
Projects
None yet
Development

No branches or pull requests

2 participants