while trying out the framework with the included mining script I noticed that the “EP-S Gaussian Scoped Mining Laser” was not correctly registered as a “mining device”
As a quick hack I add all the variants for mining equipment into the “ModuleButtonTooltip.cs”
So the code I tried / found was your original intended code . At least its clear for me why the change was submitted.
What is not clear for me is that (if I am correct) all “Laser Upgrades” are passive modules and are not manually activated.
So hence their should be no need for it to show up in isMiner, where only “switchable” mining equipment should be (imo) as otherwise the mining script will not run as it won’t detect usable equipment. (At least in my case with the Scoped mining laser)
Would it be an option to add the static names (but as a disadvantage you need to “update” when there are changes). Or would it be better for the “Laser Upgrades” to get their own name e.g. isMinerUpgrade ?
Deciding whether classification should treat them as different classes needs knowledge about how the game works. What would be the differences between IsMiner and isMinerUpgrade?
An example for a difference: What is an example where a user wants to use only one of those two classes on a given target?
Class IsMiner
Is used in included “Mine.ore.cs”. Is used for “scraping” tool-tip data regarding Mining equipment stats:
A. Determine if equipment is used for mining
B. If equipment is used for mining, getting maximum range (optimal range), get Shortcut Key to Toggle
C. Veryif equipment is active (assign asteroid if equipment is not active)
D. etc.
Breaks part A as (some) true mining equipment are not recognized by the parser as such (e.g. “EP-S Gaussian Scoped Mining Laser”)
As part A is broken, part B doesn’t read the tool-tip information as it disregarded for not being “IsMiner”
A + B result in script halting. No automatic mining
Class IsMinerUpgrade
The only usecase I can think of for using of IsMinerUpgrade. Is for very specific mining scripts. Where an efficiency calculation is made based on what passive module are installed.
As it is a passive module which has no function but to boost mining equipment efficiency. It is not something you turn on and off during playing a game. It’s just a performance enhancing module in a ship.
From the included “Mine.ore.cs”
Meaning installed modules (e.g. “Mining Laser Upgrade II”) are not visible for the parser scraping the tool-tips (as it is a passive module. When you do enable “Display Passive Modules” it only shows the name of the module e.g. “Mining Laser Upgrade II”. There is no more information in the tooltip.
Clicking on that module will give an onscreen message :
By removing “mining upgrades” from “mining equipment” the script will function with all available mining equipment (or at least all equipment will be recognized) resulting script not halting due to no mining equipment found.
By adding a new class e.g. IsMinerUpgrade, those with specific needs can still parse for installed modules. And do math based on modules found.
When using the included vanilla “mine.ore.cs” script. I noticed that the moment it wanted to read the tooltips (“measure tooltips of all modules”) it always came up with “mining modules (inactive): 0(0)”.
First thing I did was browse the script for instances where that value would be “filled” so I came across :
Watching the API Explorer for ModuleButtonTooltip I noticed that value IsMiner was false for the “EP-S Gaussian Scoped Mining Laser”
Notice that it did get the “Optimal Range” from the tooltip.
In comparison one for the “Miner II”
Maybe I jumped the conclusion on what part of that string “broke” the parser.
I can only conclude from my own observation that
static readonly string IsMinerSetIndicatorLabelRegexPattern = new string{
@“Miner”,
@“Mining\sLaser”,
};
Fixed the issue I had with making the “mine.ore.cs” script work for me.
Btw, I want to thank you for taking interest in this issue and answering so swiftly on my updates.
I did download full source and build my own version (with changed IsMiner) but because of my inexperience I didnt want to upload it straight to Git as I dont want to break this nice project. Hence the reason I am discussing this on the forum (and not on Git)
To clarify, todays bot will not consider these sources. It will not read from screenshots and not from the list you linked. Because of this, I do not see a reason to try to extract information from those to compare to the bots Behaviour.
Instead, the bot uses the information from the memory measurement.
For example, in this case quoted below:
I looked into the source code and found this:
This looks like the bot uses the patterns on all the LabelText in the IContainer which is used to parse the ModuleButtonTooltip.
while trying out the framework with the included mining script I noticed that the “EP-S Gaussian Scoped Mining Laser” was not correctly registered as a “mining device”`
I have the same issue. Bot stops mining when I use “EP-S Gaussian Scoped Mining Laser”. We should figure out why this happens. I’ll try to debug app to get more info about problem.
“EP-S Gaussian Scoped Mining Laser” was not correctly registered as a “mining device”`
I’ve figure out why this happens. It happens because real text we parsed is <b>EP-S Gaussian Scoped Mining Laser</b>. No one of patterns below matches it.
I believe we should change IsMinerSetIndicatorLabelRegexPattern to variant below:
static readonly string[] IsMinerSetIndicatorLabelRegexPattern = new string[]{
@"Miner",
@"Mining\sLaser",
};
Interesting. This looks like the String you observed contains XML or HTML tags. XML tags are common in some parts of the eve online client UI tree and therefore the parsing code takes care to apply a function to remove those in places where they have been observed.
What do you think of the approach to remove all XML tags before giving the string to the regex pattern match?
Why? If we change it, should we not use a pattern which matches the string <b>EP-S Gaussian Scoped Mining Laser</b> you mentioned?