evemondevteam / evemon

A lightweight, easy-to-use standalone Windows application designed to assist you in keeping track of your EVE Online character progression.
184 stars 172 forks source link

Error parsing market orders #3

Open flosch42 opened 8 years ago

flosch42 commented 8 years ago

I'm currently getting an error when starting EVEMon: "An error occured while querying the personal market orders". The details say:

EVEMon 3.0.0.4631

API Error: An error occurred while querying the personal market orders. XML error: There is an error in XML document (16, 54).

<?xml version="1.0" encoding="UTF-8"?>
<eveapi version="2">
  <currentTime>2016-05-17 15:13:27</currentTime>
  <result>
    <rowset name="orders" key="orderID" columns="orderID,charID,stationID,volEntered,volRemaining,minVolume,orderState,typeID,range,accountKey,duration,escrow,price,bid,issued">
[SNIP]
    </rowset>
  </result>
  <cachedUntil>2016-05-17 16:06:01</cachedUntil>
</eveapi>

From a cursory look, the XML looks alright, though. However, I'm a bit reluctant to post it here in its entirety because of the information it contains. I could try to pseudonymize it if necessary. and/or get it to you privately.

The API key I'm using has the access mask 66051738 (i.e., has access rights to MarketOrders), and works fine otherwise. It also worked fine in EVEMon 2.x, and I even thought it worked fine for a short time after upgrading to 3.0, but now that I think about it, I'm not sure any more. EVEMon then tries to update the information every 5 minutes, and fails silently... or so I assume, because there are no additional error message,s but also no information shown in the market order tab.

flosch42 commented 8 years ago

Like always, you think of something the instant you click "submit"...

If I look at line 17 (so, line 16 if the counter is 0-based, or the xml header line isn't counted), and at column 54 (disregarding the leading whitespace), I end up at the beginning of the stationID for an order, and that is indeed the first line in that file that has a 13-digit stationID. I assume that must be a citadel, because it doesn't follow the standard "8-digit, leading-6" model of normal stationIDs.

So maybe a problem parsing the stationID and choking on either the unexpected format, or on not being able to look up the ID in the database?

Sadly, I don't know much about C#, so it would take some time to get used to the syntax, and then dig into the source and find out what's exactly happening there.

elminer commented 8 years ago

The stationID needs to be a long now, not an int. This includes the s_conqStationsByID Dictionary in ConquerableStation and the StationID in SerializableOutpost. I'm blind/dumb and don't know where the StationID -> Name mapping for citadels is exposed, but I was able to hack around the error by hard coding my corp's Fortizar into the Import method in conquerable station.

ghost commented 8 years ago

Sorry for the delay, I've been working on on-boarding to the project. I'll have a patch out for this soon!

ghost commented 8 years ago

a104370 should fix this, will close this issue once the patch is out.

flosch42 commented 8 years ago

I updated EVEMon yesterday, and it seems the bug is half-fixed. I do not get an error any more, so that is nice. However, I don't think I could see any market orders in citadels. They just did not appear. Am I missing something? Or is it even possible to get that data? Are citadels in the static dataset, or would they have to be looked up on the fly via CREST or something?

JimiC commented 8 years ago

Citadel related data don't appear in the API. CCP haven't included them yet.

flosch42 commented 8 years ago

Yes, that's what I afraid was the problem. In that case, I guess the current solution in the best that can be done without massive changes.

Just to make sure: by "API" you mean the static data dumps? Or is ID -> citadel name/location information not even available in CREST?

JimiC commented 8 years ago

By API I mean both XML and CREST API. Citadels are not static data so they aren't in the SDE.

flosch42 commented 8 years ago

Ah. Too bad.

But in that case this issue is indeed fixed as far as is possible.

Thanks for the work!