Open kbmorris opened 3 years ago
i think the problem is here: https://github.com/skai2/EDAutopilot/blob/master/dev_autopilot.py#L229
i think it is taking the first instance of StarClass
it finds and in this case that is infact the class of the target system not the curent one. it should be easy to add some more conditions to prevent this. i think this has been fixed in one of the forks but need to confirm that.
Yes @TomW1605 it appears the reliable message in the ED Journal for StarClass of the current system would be the current "event":"StartJump" event and the current "event":"FSDTarget" event should be ignored for StarClass of the current system.
Yes @TomW1605 it appears the reliable message in the ED Journal for StarClass of the current system would be the current "event":"StartJump" event and the current "event":"FSDTarget" event should be ignored for StarClass of the current system.
Should I submit a pull request?
go for it but please test it first
This is working for non-scoopable stars now. Simple fix really. I didn't see any testing files in the repo but I did test on a 300LY route through scoopable and non-scoopable stars with no issues. I had the threshold turned up to a fairly high percentage to see plenty of refuel activity. Pull request is inbound.
So essentially EDAutoPilot parks on this star at Col 285 Sector JX-T d3-76 even though it is Class:T. In the Python debugger the ship() method returns 'star_class': 'M' so is mistaken on the star class. It looks as if the Star Class of the FSDTarget (the next star) is being populated too early for the fuel scoop decision. I need to understand how EDAutoPilot determines star_class in ship() to work on a fix.
ED Log:
EDAutoPilot Log:
Debug Console: