Issue With Memory Measurement (ModuleButtonTooltip)

I ran into the weird behavior of Sanderling. Compare two screenshots (two ModuleButtonTooltip).
First is correct. You can see 4 items in LabelText:
[0] - Hot key (hidden on screenshot)
[1] - Name (hidden on screenshot)
[2] - Optimal range
[3] - Mining yield

Now second image. LabelText on this screenshot has only 2 items: [0] Hot key and [1] Name.
Optimal range and Mining yield are lost. @Viir Why could this happen? Any ideas?

Also Iā€™ve noticed that on first image ā€˜Regionā€™ is valid; On second ā€“ it isnā€™t, all values (Min0, Min1, Max0, Max1) are zero.

P.S. Both screenshots are taken from the same instance of app, i.e. valid and invalid Tooltips exist simultaneously.

Both modules are the same? ( Miner II as i understand)
Is this bug repeated all the time, or is it possible that the reason is in the wrong parsing of the tooltip?

Yes, modules are the same (Miner II).

I donā€™t quite understand how application works. May be it is a memory reading problem, may be it related with parsing.

Is this bug repeated all the time

Most of the time the bot work fine. But if ā€œmissed items in LabelTextā€ issue comes it is persist. Next time Iā€™ll faced this issue I try get more info.

Did you unload ore on the station?
After each udock, the program recognizes the modules again. If a bug appears, try to pause bot, dock manualy, then turn on the bot. Did the bug disappear after undock?

Yes, I did.

Ok, Iā€™ll try next time.

This can happen when the eve online client removes elements in the UI tree from their previous location.
Partial reading of the ModuleButtonTooltip can happen when the eve online client removes the tooltip while Sanderling is reading this part of the UI tree. This is only a matter of time and can happen with any graph which is being read from memory, not only the ModuleButtonTooltip.

This is interesting because it shows an additional (besides multisampling) approach to prevent problems caused by the partial read tooltip: When we see that Region is invalid, we could remove the complete tooltip to prevent consumers of this data from being confused. (This way, the consumer waiting for the tooltip to appear would just wait for the next measurement)

1 Like

Thank you. This very helpful info for understanding how app works.

Good idea. Iā€™ll try to do it.

Based on your recommendation Iā€™ve added changes for Parse/Extension.cs. Is it correct changes?
https://github.com/achurilo/Sanderling/commit/fadf6ee4f8edf785b2996ef706b9fb4917f8bc9d

But now I have new type of issue.
I have ship this 3 modules:
[0] - Miner II (F1)
[1] - Hardener (Alt-F1)
[2] - Miner II (F2)

But inside API Explorer I see something absolutely weird:

As you can see, [0] and [1] are tooltips for the same module (labels are equals; compare LabelText[0], for both module it is F1). [2] donā€™t has labels at all.
@Viir How could it happen? Help me figure out, please.

1 Like

This is good to know! This must be why the overview (and other stuff) isnā€™t found on very rare occasions, and the problem becomes persistent. If this happens, can the lost elements be reacquired without restarting Sanderling?

Is there an API function we can use to cause it to find the elements again when we discover that ā€œthe eve online client removes elements in the UI tree from their previous locationā€¦ā€ Without restarting Sanderling? It would be nice to not have to wait the 10 to 30 seconds for it to start.

(One time I found that Docking didnā€™t fix the problem, and had to restart eve and Sanderling. Next time Iā€™ll try to document it better.)

Thank you. There is one thing in this commit I do not understand: Why is this commit based on a version from six months ago? On the master branch, there were several changes in the meantime, including improvements in the memory measurement part. Why not include those?

About [0] and [1], this could be simply a misunderstanding about the meaning of [0] and [1]. I am not sure what the situation was, as I am only aware of parts of memory measurements. As long as those do not appear in the same memory measurement, it is OK since those indexes do not carry a meaning across memory measurements. The index of a module within the list can change between measurements and this does not affect operation since the index is not needed to decide about the behavior of the bot. On the other hand, if these both appear in the same memory measurement, then this is a problem, then I can look further into it.

About [2]:
It seems to me that this could happen when the eve online client removes stuff while the memory reading is in progress:

A good rule of thumb is: When you cannot see the overview in the eve online client and can not make it visible by removing other UIElements, do not depend on Sanderling finding it. Sanderling can a read window which is occluded by elements in front of it, but if you close the window in the eve online client, and the closing is complete, Sanderling does not read it.

I flipped through the changes in the master branch. Iā€™ve notice the most of changes UI/UX-related. Changes related with chat window may be helpful but I use bot in hi-sec only and I donā€™t use chat window. So I decided use free version of Sanderling.

2 posts were merged into an existing topic: Memory objects getting lost

In this case, I do not see how it matches the scenario described by achurilo. If we can find a connection, or If I see a topic for this, I take a look at it. In case you already reported this issue, I might have missed it, so feel free to send me a pm with a link to the topic.

Do you need help with creating a new topic or moving posts there?

You can move the post(s) to ā€œMemory objects getting lostā€

I believe Iā€™ve found solution for OP few day ago, when I run into same issues.
take a look on my solution here

cheers