Autopilot improvements

Botting Eve Online
1

Hi and thanks for great toolkit.
I modified an autopilot script a little and thinking about more.
What I added:

  • undocking if docked, which is easy but pretty useful
  • stopping script completely upon arrival since CPU load of even idle Sanderling is significant
    I’d gladly contribute it to the project for others to use no matter how small this contribution is. I guess there is a lot of people who just uses it unmodified and could benefit from small improvements.
    If it’s ok and would be accepted, how should it be done? Fork and pull request?

Second thing I’d like to improve - using “Selected item” window to execute warp/dock commands and to check if it’s a good time to issue that command. I noticed that eve client with destination set always auto-select next gate/station in overview and I’m sure people are using it. So, when you travel on your own you’d just click jump/dock button. Also, you’d click it when it’s not disabled.
From script PoV using disabled button state would mean no pointless clicks during jump/dock process (false positives of maneuvering check) and no misclicks when destination panel “jumps” on system enter.
Am I right that right now there is no other way to determine buttons state in “selected item” window other than names of their icon? Can it be improved somehow during memory reading and are there such plans?

Also, one somewhat unrelated question. Is there easy way to put scripts to IDE (Visual studio or Intellij Rider) for development and benefit for all IDE features like better code completion, “go to definition”, etc.? Is it plain C# and all is needed - just some “using” statements or it’s some kind of script engine and additional support from IDE needed?

2

That sounds useful to me too. Thanks for considering sharing these improvements. Yes, a pull request to https://github.com/Arcitectus/Sanderling works.

3

I do not see a way to determine this state either. I think color would be a natural candidate for this purpose but it seems that color is not read on these sprites either with version 16.11.17.

I could probably find at least color or a specific flag. I have not looked into this so far.

The integrated IDE compiles C#-script which is somewhat different to the more popular C#. I have not checked if Visual Studio supports using C# script this way. For porting the script just once from C#-script to C#, I don’t expect any significant challenges here. First thing I would try is to wrap the script except the using directives in a class and method (and keep the using directives outside of the class).

4

Here it is: https://github.com/Arcitectus/Sanderling/pull/10
Nothing to thank for, it’s so small and still far from perfect. It stops only when arrives to station, but OTOH I rarely travel just to the system, while linger in space?..

1 Like
5

Color is obvious, but not knowing what’s available and only looking at API Explorer of Sanderling icon name seems more promising to me. Icon names can be mapped not only to enabled/disabled state, but to name/purpose of the button. Of course, there is drawback of coupling with some internal names which CCP can change any time.

Thanks, it works more or less. Could you hint what should be imported or defined to access Host and Sanderling globals of the script?

6

You mean the Name property of the Sprite? I looked at this for one of the sprites but saw only null values for both usable and unusable state.

When the script is contained in the method as described earlier, those two references could be passed as parameters to this method. I will take a look at how those two instances can be created.

7

I didn’t have API Explorer before me while I was writing that. I meant TexturePath property of the Sprite. I just looked at it more and it seems that order of those elements in the collection is not fixed, so maybe collection should be sorted (e.g. by horizontal position) to reliably map those paths to buttons on UI.

Don’t need them created right now. Just their types to make compiler happy. If you don’t remember them - no need to look. I guess I can find out with some reflection calls if they’re available in the script.

8

Ok, if the TexturePath contains the information, it is realtively simple to implement. I would add a new interface for the selected item window with named properties (like ApproachButton) for the different actions. I’d just need a list of the actions and both texture paths for usable and unuseable for each respectively.

I don’t understand this part. Why not use the Region for the mapping? How could you make use of a buttons index withing the enumeration from the API?

Thats the easy part:
I executed this script in the Sanderling IDE to get the types:

Host.Log(Host.GetType());
Host.Log(Sanderling.GetType());

The log then displayed their FullNames:
BotSharp.IHostToScriptImplementation.HostToScript and Sanderling.Script.Impl.HostToScript.

9

Seems it’s not that simple. Enabled/disabled sprites have the same TexturePath value. Even more Lock/Unlock which differ on UI not just by color (unlock has red cross over it) have the same value.
I’ll show some of them here, maybe they can be useful to still add them into new interface, but for enabled/disabled state we need something else. Color property is null all the time, btw.

https://docs.google.com/spreadsheets/d/1j8nO1GAmM_CebAgDHSU6aMlhJxQfFe5wINfi_tL-GGk/edit?usp=sharing

Maybe I did something wrong in the script to gather this info. Here it is, let me know if something wrong is here:

while (true)
{
    var Measurement = Sanderling?.MemoryMeasurementParsed?.Value;
    var selectedItemWindow = Measurement?.WindowSelectedItemView?.FirstOrDefault();
    var texts = (selectedItemWindow?.LabelText).EmptyIfNull().
	    Aggregate("", (current, text) => current + (" : " + text.Text));
    Host.Log("Window text: " + texts);

    var buttons = selectedItemWindow?.Sprite?.OrderByCenterDistanceToPoint(new Vektor2DInt(0, 0));
    foreach (var button in buttons.EmptyIfNull())
    {
	    Host.Log("Button: Id: " + button.Id + "; Region: " + button.Region +
	             "; TexturePath: " + button.TexturePath);
    }

    Host.Delay(5555);
    Sanderling.InvalidateMeasurement();
}

Maybe there is something else can be found in the memory for enebled/disabled and lock/unlock state?

1 Like
10

Interesting findings, I did not expect the Unlock sprite to have the same TexturePath as the Lock sprite.

Yes, I would refer to the spreadsheet to assign the actions to the sprites.

Agree, I also could not find a correlation between texture path and the action being enabled.

Since you output the Region and TexturePath from the same ISprite reference, I think it is safe enough without risk to mix up info that does not belong together.

I think it is very likely that we find suitable information in the memory contents once we take a closer look.

11

There is another feature that might be very useful to improve stability of autopilot and other scripts - so-called session change timer. I believe that some mis-clicks and timing issues could be eliminated if we could ensure that session change is over. On the interface it’s visible as “shortening sector of circle” icon in the top left corner of the screen near system info panel toggle button. It’s visible of cause when session is being changed and hidden most of the time.
Is it possible to have some method (like Sanderling.IsSessionChange() ) in the API?

12

What about reading this information from memory? To me, it sounds like there is a good chance that this information is modeled in the eve online clients UI tree. So far, we read large portions of this tree anyway, so it seems convenient to look there first.