Scoped mining laser - IsMiner

Hi,

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”

	static readonly string[] IsMinerSetIndicatorLabelRegexPattern = new string[]{
		"Civilian Miner",
		"Deep Core Mining Laser I",
		"EP-S Gaussian Scoped Mining Laser",
		"Gallente Mining Laser",
		"Miner I",
		"Miner II",
		"Modulated Deep Core Miner II",
		"ORE Deep Core Mining Laser",
		"ORE Miner",
		"Particle Bore Compact Mining Laser",
		"Single Diode Basic Mining Laser",
    };

This at least quicly fixed the mining part :slight_smile: (very happy with it)

I tried the following as to be sure the list was not limited

	static readonly string[] IsMinerSetIndicatorLabelRegexPattern = new string[]{
		@"Miner",
		@"Mining\sLaser",
    };

This seemed to work also :). Is this a potential fix ?

1 Like

There recently was a discussion about matching the text in the UI to classify as Miner and this resulted in a change of the parsing code.
You can read it at IsMinerSetIndicatorLabelRegexPattern has improper regex · Issue #38 · Arcitectus/Sanderling · GitHub

To sum it up, I guess the code you showed would not be good for all users because of modules titled ‘Mining Laser Upgrade’.

So the code I tried / found was your original intended code :slight_smile: . 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 ?

(Just thinking out loud :blush: )

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 :disappointed_relieved:

  • 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 :

It is a module to boost mining performance and not a tool used for mining
http://games.chruker.dk/eve_online/market.php?group_id=935

Should not be in IsMiner as it is no mining equipment.
And

should be changed to

All available mining equipment :

http://games.chruker.dk/eve_online/market.php?group_id=1039

Recap :

  • 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.
1 Like

How did you arrive at this conclusion?
I took those strings and fed them into this regex tester:

And that tool showed me that the pattern matches the input. With the link given, you should already see the strings filled into the form.


This seems to me a good reason to not classify it as IsMiner.

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 :

Sanderling.Accumulation.IShipUiModule SetModuleMiner =>
Sanderling.MemoryMeasurementAccu?.Value?.ShipUiModule?.Where(module => module?.TooltipLast?.Value?.IsMiner ?? false)?.ToArray()

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 :slight_smile: (and not on Git)

Where is that string coming from? I mean the part you enclosed in quotes?


Looks like this set of pattern is less restrictive than what we have on the master branch:

Because of this, I am not surprised if it matches more inputs.

If you are referring to the equipment name, from this list : EVE - Market
And from ingame :
https://image.ibb.co/javFxG/Is_Miner_False.jpg

Your guess is as good as mine :slight_smile: (allthough I’m pretty sure your knowledge of coding is much better then mine).

But to summarize :

  • Imo the original code was good from the beginning
  • The change where parser should also account for “upgrades” broke the parser.
  • If there is a need for parsing mining upgrades, “Upgrades” shouldn’t be in IsMiner but maybe in another class.

After reading the comment regarding issue #38.

Mining Laser Upgrades should not pose a problem as Display Passive modules should be disabled as suggested by “mine.ore.cs”

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",
		};
1 Like

@"“mining”"
@"laser "
and is ok

Interesting. :+1: 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?

What do you think of the approach to remove all XML tags before giving the string to the regex pattern match?

I had not thought about it. I think remove XML tags is better approach than generalize regex pattern.

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?

Sorry, I forgot remove ‘$’. I’ve edited my previous post.

Good, I think this can be done by using the method RemoveXmlTag at Sanderling/src/Sanderling/Sanderling/Parse/ModuleButtonTooltip.cs at 270d7cdc79db43ff75196f7e176d5ef108e5eaa0 · Arcitectus/Sanderling · GitHub

Looking at the changed post, the pattern there reminds me of the issue with a module titled Mining Laser Upgrade described at IsMinerSetIndicatorLabelRegexPattern has improper regex · Issue #38 · Arcitectus/Sanderling · GitHub. This is something to consider before changing the regex pattern.

I’ve changed code according to your recommendations. I’ve added RemoveXmlTag(). Here is my commit:
https://github.com/achurilo/Sanderling/commit/9ef4a81e58ffd91d5c7f0b78e4ae9e8569372151

I’ve tested. Now “EP-S Gaussian Scoped Mining Laser” is correctly recognized as a mining device.

2 Likes

Thank you, this is nice change.
If you create a pull request on github and nobody finds a problem, we can merge this into Arcitectus/Sanderling/master

Ok. Created it:
https://github.com/Arcitectus/Sanderling/pull/56

1 Like