Asteroid belt is represented by the line which includes text “Belt”. If the line includes the string “Asteroid” but not the string “Belt” then we can safely assume its an ore asteroid but feel free to do it the easiest way.
1 Like
Im old school from Cobol days and have not done almost any coding since then. Seems logical it would be quite different from what you guys do nowadays. Hope my contribution is useful.
I think we may have to address belt depletion quite quickly. The belts in HS 1.0 systems deplete quite quickly during the day. Very often by the end of the day there is only a few belts left with asteroids that contain ore. None the less you are right, step by step. First without this logic will be easier.
Seeing this example is very helpful, beyond the development of the mining bot. It will also benefit the people who want to learn how to develop bots. I see now many people landing here could be familiar with the sequential/looping approach. As a result, they might have a hard time following the current guides on bot development. Adding a comparison of the different design approaches to the guides should support readers from a more diverse range of previous experience.
I started development on the sensor/seeing side of this mining bot.
I am using this bot description from above, to find out what information the bot needs about the game:
- Something to initiate undock: → Undock button in station window? Now I remember seeing somewhere you could also undock with a context menu on the active ship in the inventory window. So maybe that would be an alternative.
- Decide ‘if ore hold full’ → Probably using the capacity gauge in the inventory window.
- Context menu (for warp, approach, lock target): Seems already covered: The travel bot uses the context menu and the structure should be the same for context menus opened on other objects, such as overview entries.
- In overview window:
- Tabs, each with region and title.
- Entries, each with region, name and distance.
- Modules in the ship UI. For each module:
- Indication if it is active.
- Region (for the click)
- In the inventory window:
- Representation of the item hangar (Region)
- Items in the selected container (Regions)
I think reusing the Sanderling memory reading framework is the fastest way to get all the input we need. I collected samples of what we get from this framework. It looks like two snapshots of the game are sufficient to cover these parts of memory reading. One in station, and one in the belt. I uploaded these samples here:
I am not sure about these parts:
Where would we read this station name from when docked?
Anyway, by using a bookmark instead we can avoid waiting for this.
Yes Undock from context menu works, this would seem to be more future proof than the button.
Keep in mind that the ore bay is sometime full while being a fraction short of full simply coz space left available is smaller than a single ore unit.
I expected the system info panel in the top left corner could provide this info. Clicking the small sun icon there toggles this panel on/off but a BM seems more reliable, then for sure.
BTW Travel Bot CMD window flickering is very annoying and could cause issues for some people. Is it possible to stop it from doing that?
I implemented another batch of the memory reading functions for the mining bot here:
That is good to know; I will try to undock via the inventory window context menu first. It looks like we will anyway depend on reading the entries in the tree on the left of the inventory window, to be able to drop items to the item hangar.
Currently detecting whether it is full is based on the text which is displayed in the inventory capacity gauge. For example, the following is classified as full:
5,000.0/5,000.0 m³
If we find other cases we should consider full, I can adapt the bot.
Probably it can be at least reduced somehow. Does it flicker as much when you start it using the Windows PowerShell app?
Sometime we mine ore where unit size is for example 15 m3. which means 333 units will fit in the hold. 333 *1 5 = 4,995 m3. This is also considered as full since another unit will not fit. I think there are a few different ores that fill the hold in this way. We may be able to identify most of the cases one by one and hard code them as we do but not sure we will get all of them that way. Option is algorithm that would decide when the hold is full even if short of 5k. If you are able to read the ore unit m3 size this might be a very simple math equation that decides if the hold is full.
This is what it looks like for the venture or a ship with 5k ore hold. So to declare it full you would need to consider which ore and m3 in hold. Off course if you change the ship you would need a whole new table for each ship.
Ore, Full with m3
Veldspar 5000.0
Concentrated Veldspar 5000.0
Dense Veldspar 5000.0
Scordite 5000.0
Condensed Scordite 5000.0
Massive Scordite 5000.0
Pyroxeres 4999.8
Solid Pyroxeres 4999.8
Viscous Pyroxeres 4999.8
Plagioclase 4999.8
Azure Plagioclase 4999.8
Rich Plagioclase 4999.8
Omber 4999.8
Silvery Omber 4999.8
Golden Omber 4999.8
Kernite 4999.2
Luminous Kernite 4999.2
Fiery Kernite 4999.2
Jaspet 5000.0
Pure Jaspet 5000.0
Pristine Jaspet 5000.0
Hemorphite 4998.0
Vivid Hemorphite 4998.0
Radiant Hemorphite 4998.0
Hedbergite 4998.0
Vitric Hedbergite 4998.0
Glazed Hedbergite 4998.0
Gneiss 5000.0
Iridescent Gneiss 5000.0
Prismatic Gneiss 5000.0
Dark Ochre 5000.0
Onyx Ochre 5000.0
Obsidian Ochre 5000.0
Spodumain 4992.0
Bright Spodumain 4992.0
Gleaming Spodumain 4992.0
Crokite 4992.0
Sharp Crokite 4992.0
Crystalline Crokite 4992.0
Bistot 4992.0
Triclinic Bistot 4992.0
Monoclinic Bistot 4992.0
Arkonor 4992.0
Crimson Arkonor 4992.0
Prime Arkonor 4992.0
Mercoxit 5000.0
Magma Mercoxit 5000.0
Vitreous Mercoxit 5000.0
This is why Im thinking a formula might be a better idea then hard coding something that Eve could change with any update. In Excell the formula would look something like this with the final result at 1 decimal digit.
=(Rounddown((Hold Size m3 / Ore unit m3),0))*(ore unit m3)
Basically you would need to read hold size and ore unit size m3 to be able to do it, but this should be eve future update proof.
Travel bot flickering is pretty much the same in PowerShell but the bot is not working any more. It doesnt see a route in the system panel so just waiting for a route to be set. I though can see it and keep wandering who is blind…
I light of these discoveries, I will adapt the bot to read the number and compute the percentage of the ore hold fill. Parsing the numbers out of the text is not so difficult. The original reading function was so simple only because I did not have any example to justify going beyond just comparing the text.
If I read the table correctly, a threshold of 99 percent should cover all cases.
I just implemented the expansion of the inventory capacity reading here:
Following is an excerpt of the code containing cases which are automatically tested to work:
That works too and is much simpler.
Travel bot works again. 
Do you think it might be interesting to implement a bounce of a random celestial where the route takes one through a system other than high sec?
I don’t know, I would first ask people who are familiar with the game. I don’t remember reading about this before.
Its a standard strategy for trying to avoid gate campers deploying bubbles and smart bombs. Normally a traveler is expected to warp from gate to gate so his trajectory is reasonable foreseeable. Gate campers would often deploy bubbles on this trajectory or wait for a traveler to come out of warp on this trajectory. To avoid the trajectory traps we often warp from the system entry gate to some celestial and then from there to the exit gate. this changes the foreseeable trajectory and adds a bit of a safety margin. If its not a major development task it may be worth while considering.
Thank you for the clarification. I understand it is not related to mining asteroids. To ensure it can be found in spite of that, I added it here: bots/eve-online-players-strategies.md at a272acde3fd79bc834cf6e0f6ef0c41c82419c7d · Viir/bots · GitHub
Today I further expanded the memory reading side; this should cover the remainder of what we need for the bot you described:
https://github.com/Viir/bots/commit/1b93524d8c43bd7a66d3c0cbd09a37eeaccc4534
Along with the productive parsing implementation, this change also adds automated tests, for example, for parsing the distance from overview entries:
This is significantly more complex than I imagined. I hope people appreciate your work and the time you put into it. I certainly do!
Part of this complexity is building a framework that guides bot developers and people who want to customize bots. Up until now, the changes I linked were all on the sensor/reading side, and the framework developed here can be used for other bots too. This framework reduces the effort spent on live testing a bot because it helps detect problems before even starting the bot.
I made another addition on the seeing side of the EVE Online bot framework:
https://github.com/Viir/bots/commit/0c450595663d1aa3d67e673e579d3dc4c4fae1c6
This addition will make the ‘lock target’ part of the mining bot more robust, as it enables the bot to see and count the number of locked targets.
sound pretty good. whatever I can do to help in any way, feel free to let me know.