Hey peoples! Have not had an issue in a few months that I was not able to fix by tweeking the mining script. It has been smooth sailing. Up until today that is. Looks like CCP push an update last night that stops the script from targeting multiple asteroids, and even when I have manually targeted a few, it puts both lasers on the same rock.
Anyone notice this issue start today?
Thank you,
Hacksaw
Am I the only one with this issue? Anyone else mining with this bot? Let me know if you are not having this issue so I can figure out what is causing it.
Miners ho!
Hacksaw
I will bring my outsiders perspective here, maybe this helps.
From your post I understand that what the script does is not leading to multiple roids being targeted while yourself can target multiple roids.
This brings me to the question what are the differences between those two approaches regarding the interaction with the UI?
The following section of code in the mining script is where I noticed the change in behavior after the CCP upgrade:
var setTargetAsteroidInRange = SetTargetAsteroid?.Where(target => target?.DistanceMax <= MiningRange)?.ToArray();
var setTargetAsteroidInRangeNotAssigned = setTargetAsteroidInRange?.Where(target => !(0 < target?.Assigned?.Length))?.ToArray();
Host.Log("targeted asteroids in range (without assignment): " + setTargetAsteroidInRange?.Length + " (" + setTargetAsteroidInRangeNotAssigned?.Length + ")");
if(0 < setTargetAsteroidInRangeNotAssigned?.Length) { var targetAsteroidInputFocus = setTargetAsteroidInRangeNotAssigned?.FirstOrDefault(target => target?.IsSelected ?? false);
if(null == targetAsteroidInputFocus) Sanderling.MouseClickLeft(setTargetAsteroidInRangeNotAssigned?.FirstOrDefault());
ModuleToggle(moduleMinerInactive);
return InBeltMineStep; }
var asteroidOverviewEntryNext = ListAsteroidOverviewEntry?.FirstOrDefault(); var asteroidOverviewEntryNextNotTargeted = ListAsteroidOverviewEntry?.FirstOrDefault(entry => !((entry?.MeTargeted ?? false) || (entry?.MeTargeting ?? false)));
Host.Log("next asteroid: (" + asteroidOverviewEntryNext?.Name + " , distance: " + asteroidOverviewEntryNext?.DistanceMax + ")" + ", next asteroid not targeted: (" + asteroidOverviewEntryNext?.Name + " , distance: " + asteroidOverviewEntryNext?.DistanceMax + ")");
When the script now runs it seems setTargetAsteroidInRange and setTargetAsteroidInRangeNotAssigned always point to the same asteroid and there is either null or 1 even when the overview.roids show a lot more available and acctually in range:
ore hold fill: 0%, mining range: 25000, mining modules (inactive): 2(2), shield.hp: 100%, EWO: False, JLA: , overview.rats: 0, overview.roids: 31, offload count: 27, nextAct: InBeltMineSteptargeted asteroids in range (without assignment): ()next asteroid: (Asteroid (Condensed Scordite) , distance: 23000), next asteroid not targeted: (Asteroid (Condensed Scordite) , distance: 23000)Debug: MiningRange = 25000, range to current = 23000, range to next = 23000initiate lock asteroidore hold fill: 0%, mining range: 25000, mining modules (inactive): 2(2), shield.hp: 100%, EWO: False, JLA: , overview.rats: 0, overview.roids: 31, offload count: 27, nextAct: InBeltMineSteptargeted asteroids in range (without assignment): 1 (1)toggle module using F1ore hold fill: 0%, mining range: 25000, mining modules (inactive): 2(2), shield.hp: 100%, EWO: False, JLA: , overview.rats: 0, overview.roids: 31, offload count: 27, nextAct: InBeltMineSteptargeted asteroids in range (without assignment): 1 (1)toggle module using F2ore hold fill: 0%, mining range: 25000, mining modules (inactive): 2(0), shield.hp: 100%, EWO: False, JLA: , overview.rats: 0, overview.roids: 31, offload count: 27, nextAct: InBeltMineStep
Any idea?
hacksaw.
Pondering the problem a bit more… If “entry?.MeTargeted” and “entry?.MeTargeting” were no longer working then it would appear as if the currently targetted asteroid with an active strip miner on it was in fact not targetted.
var asteroidOverviewEntryNext = ListAsteroidOverviewEntry?.FirstOrDefault(); var asteroidOverviewEntryNextNotTargeted = ListAsteroidOverviewEntry?.FirstOrDefault(entry => !((entry?.MeTargeted ?? false) || (entry?.MeTargeting ?? false)));
Host.Log("next asteroid: (" + asteroidOverviewEntryNext?.Name + " , distance: " + asteroidOverviewEntryNext?.DistanceMax + ")" + ", next asteroid not targeted: (" + asteroidOverviewEntryNextNotTargeted?.Name + " , distance: " + asteroidOverviewEntryNextNotTargeted?.DistanceMax + ")");
Did some more debugging. The “entry?.MeTargeted” test is working correctly.
When the script now runs it seems setTargetAsteroidInRange and setTargetAsteroidInRangeNotAssigned always point to the same asteroid and there is either null or 1 even when the overview.roids show a lot more available and acctually in range:
I spotted a problem here: It seems there is a misunderstanding about what those two properties represent. From what you wrote, I infer you expect them to depend on the overview, but I do not see such a dependency.
setTargetAsteroidInRange should be the set of targets which are in mining range.setTargetAsteroidInRangeNotAssigned should be the subset of the set above which has no module and no drone assigned.Did you observe a mismatch between the value of those properties and what was visible in the client window?
I had been focusing on those two variables in my debugging. They only ever seem to have two values: NULL or a single element. When a single element they both point to the same element. I have modified the code to lock onto four asteroids and verified the states of setTargetAsteroidInRange, setTargetAsteroidInRangeNotAssigned, asteroidOverviewEntryNext, and asteroidOverviewEntryNextNotTargeted.
It was about 1 am and I was tired so i need to validate what I was seeing again tonight, but it appeared that for asteroidOverviewEntryNext and asteroidOverviewEntryNextNotTargeted the MeTargeted and MeTargeting were correct. However, it looked like the setTargetAsteroidInRange and setTargetAsteroidInRangeNotAssigned IsSelected was wrong.
I will let you know how debugging go this evening.
Hacksaw/
However, it looked like the setTargetAsteroidInRange and setTargetAsteroidInRangeNotAssigned IsSelected was wrong.
Why did they seem wrong? Did you compare to what was visible in the game client? If so, what did you see?
Hacksaw, I have some questions about further development of tooling:
Why did they seem wrong? Did you compare to what was visible in the game client? If so, what did you see?
Iike I said, it was late so I may have miss read what I saw, but it looked like it was reporting the wrong asteroid as selected. Now it have have been I didn’t realized I selected the third asteroid, but it was reporting it as selected. I will verify tonight.
Also, how do I determine if an asteroid already has an active miner on it?
Thanks,
Hacksaw/
Hacksaw, I have some questions about further development of tooling:
- How much time did you spent on the issues you wrote about in this thread?
- Do you think the possibility of recording the information that can be displayed in the API Explorer along with screenshots from the eve client could save you time? If so, how much?
When it first occured it might have been a couple hours looking at the code trying to figure out why it suddenly started happening. Although I though I had an idea of where the issue was occuring I really didn’t have a grasp on what each of the variables was really modeliing.
I spent a few more hours over the last couple nights once again trying to figure the problem out. I would rather try to ask more pointed questions than say “broke please fix”.
I keep forgetting about the API explorer and use logging statements. I will have a look at it tonight. Yes, if the tools speed things up then I am happy to use them. Having a basic grasp of C# would probably help more though 
Hacksaw/
Okay, I think I got to the bottom of the issue. IsSelected is working correctly but Assigned is not.
var setTargetAsteroidInRangeNotAssigned = setTargetAsteroidInRange?.Where(target => !(0 < target?.Assigned?.Length))?.ToArray();
In this evaluation the variable “Assigned” is always null. I assume it should be a list of active mining modules on the asteroid? I did a dump of the setTargetAsteroidInRange array while my two miners were active and “Assigned” is null for all asteroids including the ones being mined.
Here is a memory dump.
Hacksaw
Thank you for giving a more detailed explanation of the process applied and the challenges you faced. This helps me getting an idea of how a better development environment would look like.
On the Assigned property:
No, this contains groups of objects which are assigned to the target. An element can be a single module and there is no distinction between modules and drones.
I detailed the documentation on the Assigned property to avoid such confusion in the future: https://github.com/Arcitectus/Sanderling/commit/2e86dc7d474b0fdb14f9d67fdf4a3cba2b4dbe2e
Thank you for the dump, I am loading it and will take a look at it.
No problem. I am use to using Java in Netbeans (or just basic vi) so find the script editor a bit clunky. It has been getting better since I started using it. The method completion was a nice add but with the long list of possible options on each object it take a bit to find what I want. I have still not clued into looking at the code in github for answers. I will try to add that to my steps.
On the
Assignedproperty:No, this contains groups of objects which are assigned to the target. An element can be a single module and there is no distinction between modules and drones.
So based on this definition Assigned should not be null then when a mining module is active on it. Looks like the CCP change impacted the computation of Assigned members the.
Thank you for the help. Love this bot framework!
Hacksaw/
I am use to using Java in Netbeans (or just basic vi) so find the script editor a bit clunky.
I do not know how Netbeans looks like, but if you want to try using a proper IDE with Sanderling, I recommend Visual Studio 2015 or Visual Studio 15. The script editor is only offered to enable fastest possible entry for beginners.
So based on this definition Assigned should not be null then when a mining module is active on it.
Yes, that is correct.
Looks like the CCP change impacted the computation of Assigned members the.
Such breaking changes happen sometimes, last time was about half a year ago I think. In such cases I often found a corresponding entry in their changelog.
I do not know how Netbeans looks like, but if you want to try using a proper IDE with Sanderling, I recommend Visual Studio 2015 or Visual Studio 15. The script editor is only offered to enable fastest possible entry for beginners.
Can I edit the C# script in Visual Studio and have the same context sensitive feature work for the API? I think I tried that a while back and couldn’t figure it out. I do have Visual Studio installed.
Yes, the completion list at the cursor is available in Visual Studio too. It works better there. Simplest way to see this in action is probably opening the bot from https://github.com/botengine-de/A-Bot in Visual Studio.
I received the dump, so far it looks like I will be able to use this to adjust the reading code. I do not know yet when I have time to take a closer look. Tomorrow I will be busy with moving to another accommodation 
I released a new version with improved reading based on Hacksaws report and sample: https://github.com/Arcitectus/Sanderling/releases
That fixed it. Thank so much!