search

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

measurement.WindowOverview.ListView.Entry is null #11

Closed asdfasdf100500 closed 7 years ago

asdfasdf100500 commented 7 years ago

WindowOverview.ListView.Entry is null

Seems to affect other ListViews too

Probably due to recent EVE update

Viir commented 7 years ago

I will add guidance about how to go about such an issue soon. It will probably start with how to reproduce the issue in Visual Studio using a process sample from the eve online client.

Anyone who wants to work on this will need such a sample. See the guide at http://forum.botengine.de/t/collecting-samples-for-memory-reading-development/50 for how to collect such a sample.

asdfasdf100500 commented 7 years ago

I'm more than willling to try and fix this according to your guide.

I work as a software engineer, but I have very little experience with Python memory management and memory reading in general.

Statter commented 7 years ago

I can confirm, that the Entry object is "null ". It has become that right after the latest update. WindowInventory.[Long path].[AnyViewType].Entry is null WindowOverview.[AnyViewType].Entry is null I think, that all windows are affected. They are null both in Parsed and not Parsed memory measurments.

Viir commented 7 years ago

@asdfasdf100500 Thanks for offering to help with this. Usually, adjustments to python reading code are not needed. Most of the time when something broke, CCP simply changed some symbols for types or type members in their code.

I added the memory reading code to the repository as well as guidance on how to reproduce the memory reading and inspect its results. See the guide at https://github.com/Arcitectus/Sanderling/blob/master/guide/Adapt-memory-reading.md

Viir commented 7 years ago

WindowOverview.ListView.Entry is null Seems to affect other ListViews too

@asdfasdf100500, what about WindowOverview.ListView? Is this null too? As far as I see, everything that could end up in the Entry property has to go through SictAuswertGbsListViewport<EntryT>.Berecne. If the ListView itself is found, we should take a closer look at that method and the intermediate results there. Is there the Scroll in there found?

Statter commented 7 years ago

image 2

Viir commented 7 years ago

Ok, so in the screenshot of the API explorer @Statter posted I see that the Scroll property the instance of ListViewAndControl<EntryT> is not null. Now there is not much more left in between computation of Scroll and Entry:

dreambottle commented 7 years ago

The ScrollClipperContentAst itself is not null, but the ScrollClipperContentAst.ListeChild returns null for the Overview window

dreambottle commented 7 years ago

How does Bib3.Glob.SuuceFlacMengeAstMitPfaad() translate to English?

dreambottle commented 7 years ago

Ok, I think I found the root cause. Please review #12.

P.S. Sanderling works notably faster with the sensor branch, where you removed linking to the memreading dll.

Viir commented 7 years ago

P.S. Sanderling works notably faster with the sensor branch, where you removed linking to the memreading dll.

@dreambottle Thank you for reviewing the functionality of this change. I merged this into master together with your fix.

Viir commented 7 years ago

A summary of what I see in the commit ad1c44f647a733bb4e67d0425be90c48f5444ee1 contributed by dreambottle:

First some context

The memory reading expects the ListViews items to be contained in a Scroll. The scroll UIElement contains the actual item in one of its child nodes. The scroll can also contain other stuff like a scroll handle the user can interact with. So when reading the Scroll, we want to find different things in there and the items are to be found in the portion labeled as Content in the code.

Dreambottle changed how the Content node is selected

The SuuceFlacMengeAstFrüheste method used for this selection step first does a Breadth-first search within the node passed as the first argument and returns the first node which matches the predicate which is passed as the second argument. The changed line only affects the predicate and makes it more restrictive. So the reason for the old version failing could be the introduction of another node in the UITree which matches the predicate and comes first in the breadth-first order but is not the node which contains the nodes for the items in the list view.

Viir commented 7 years ago

I created release v17.02.17 containing the fix from dreambottle. @asdfasdf100500 does that release resolve the issue?

asdfasdf100500 commented 7 years ago

Yup, works perfectly.