Arcitectus / Sanderling

APIs and libraries to read information directly from the EVE Online game client.
https://forum.botlab.org
Apache License 2.0
259 stars 117 forks source link

slight improvement of autopilot #10

Closed the-zorro closed 4 years ago

the-zorro commented 7 years ago
Viir commented 7 years ago

Thanks for the PR, feel free to split it into multiple Commits/PRs as you see fit.

I see some issues with merging commit f68bfeaa6a1fe6ff4932664e77aaaa3ab56626de into master:

the-zorro commented 7 years ago

All true. Just focusing more on getting it work and getting familiar with the API than keeping it pretty. But I'll change it tonight. One more thing. I'm not from .Net world, so I'm using IntelliJ Rider as my IDE and it doesn't assume some assemblies are referenced by default. Do you mind if my changes will include some of those assemblies (System.Runtime, System.IO) into project files?

On Dec 29, 2016 12:31 PM, "Michael Rätzel" notifications@github.com wrote:

I do not understand why the control flow for Undock has been implemented this way: Do we want to call Undock multiple times? If not, what is the reason that the call to Undock is contained in the loop block?

Why the fly variable? Can this not be simplified by breaking out of the loop as soon as the char is docked?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/Arcitectus/Sanderling/pull/10#issuecomment-269688939, or mute the thread https://github.com/notifications/unsubscribe-auth/ABPKE_haq49x5Du5xLp76ROQ2-Ug07T8ks5rNBiQgaJpZM4LXW3p .

Viir commented 7 years ago

I'm using IntelliJ Rider as my IDE and it doesn't assume some assemblies are referenced by default. Do you mind if my changes will include some of those assemblies (System.Runtime, System.IO) into project files?

It depends on what is in those assemblies and what the benefit of including those would be. Where would other users get these assemblies from?

the-zorro commented 7 years ago

I added second commit. I removed Undock method entirely and just placed undock code before the main loop. Script stopping is done by break instead of variable. "simple" version is reverted, mine is called Travel.zorro.cs

the-zorro commented 7 years ago

Interesting. Is there way to make it so that it will satisfy both tools? The thing is not actually in Rider itself. Rider uses M$ build to build solutions. I'll check if the solution can be built by pure M$ build later today.

Viir commented 7 years ago

Is there way to make it so that it will satisfy both tools?

I don't know.

the-zorro commented 7 years ago

After dozen tries it seems fixed by installing one of M$ development packs. I think it was 4.6.1. Now both m$build and my IDE can compile unmodified projects.

Viir commented 7 years ago

I see that you added a commit. Since commit #0d9bf3b is still in this PR, I assume the PR is not complete yet.

the-zorro commented 7 years ago

It's not complete. I found one thing I'd like to change in the autopilot script, but that other commits you see are probably from another branch. In that branch I've modified mining script a lot, but I'm not sure it's a good idea to include it into your releases. Let me know if you think otherwise.

Viir commented 4 years ago

The feature to stop the bot after docking is now implemented in the example autopilot bot at https://github.com/Viir/bots/commit/8b7ca9943601d5de1f1a6a68881ac76f9c4eae56

About the undocking feature: I am not sure this would be compatible with routes containing multiple stations: What would happen after the bot docks at the first station?

In any case, bots are now located in the dedicated repository, at https://github.com/Viir/bots