EVE Technology Lab

Yes, the follwing method calls never return:

crest.GetRoot().Query(x => x.ItemTypes).Query(x => x.Single(r => r.Name == "Medium Remote Armor Repairer II"))
crest.GetRoot().Query(x => x.ItemTypes).AllItems();
crest.GetRoot().Query(x => x.MarketTypes).AllItems();


Update:

Even if the ItemType is in the first page of https://public-crest.eveonline.com/types/ the method call does not return.

Example:

crest.GetRoot().Query(x => x.ItemTypes).Query(x => x.Single(r => r.Name == "720mm Howitzer Artillery I"));


Update 2:

This works because the ItemType is on the first Crest page and thereby in the "Items" collection:

crest.GetRoot().Query(r => r.MarketTypes).Items.Single(i => i.Type.Name == "720mm Howitzer Artillery I");


This gives an exception (InvalidOperationException) because the ItemType is not on the first page:

crest.GetRoot().Query(r => r.MarketTypes).Items.Single(i => i.Type.Name == "Medium Remote Armor Repairer II");

Try updating to EveCrest v3.3.3 and let me know if you still have any issues.

I updated EveCrest to V3.3.3.0 via NuGet.

It seems that nothing changed. The following calls still timeout / never return:

crest.GetRoot().Query(x => x.ItemTypes).AllItems();



crest.GetRoot().Query(x => x.MarketTypes).AllItems();



This gives me between 3 to 5 regions:

EveCrest crest = new EveCrest();

var root = crest.GetRoot();
var regions = root.Query(r => r.Regions).Items;

foreach(var re in regions)
{
Console.WriteLine(re.Href);
var reg = crest.Load(re);
}




Yes, the defference between Items and AllItems is pretty clear. The first one gives the results from the current Crest page the later should iterate over all pages.

This gives an error as "r" does not have a property "Items":

crest.GetRoot().Query(r => r.MarketTypes).Query(r => r.Items.Single(i => i.Type.Name == "Medium Remote Armor Repairer II"));

Thanks for your help!

If you are experiencing any issues with deadlocking, ie. methods never returns, please update to Core v3.0.5.

Hello,
Thank you for your tremendous efforts on creating this .NET library !!!
It is very useful.
One question, when are you going o implement fetching Buy and Sell region orders ?
I see that currently the maximum I can get is the URI of market orders.

Thanks !

Some neat new features coming up.

All CollectionResource objects implement IEnumerable, which works with automatic pagination. That is, any operation defined on IEnumerable will work across all pages in the collection by default. The CollectionResource.Items property will still only hold the local items for the specific page the object represents.

The pagination logic is also improved, only loading the next page when required. LINQ queries will be smarter and can perform better if you pay attention to how you write them. Operations such as Where(), ToList() and Single() will still enumerate the complete collection, while First() will stop and return the first match it finds. Using First() on collections with many pages can provide huge performance benefits and decrease the amount of requests considerably.

This also makes the code slightly neater, and is backwards compatible.
Previously, the Query() API let you omit the .Items property and would use automatic pagination to operate on all items in the collection. However, outside the Query() methods, you would have to get the Items property explicitly, and all operations were on the local items unless AllItems() were used.

Now, all operations on the collection object default to all items, adhering to general LINQ guidelines, and works similarly to ie. Entity Framework. The default implementation of ToList() and my ToListAsync() mostly replace AllItems() and AllItemsAsync(), with the exception that if Automatic Pagination is disabled, ToList() only returns the local list, while AllItems() always return the full collection.

Examples:

// Inside a Query statement, the API remains the same


The difference is that previously all the pages in the collection would be queried. Now we query one page at a time until we find a match, and return that.

// Outside a query statment

var alliances = _crest.GetRoot().Query(r => r.Alliances);
var old = alliances.AllItems().First(a => a.ShortName == "MZR");
var now = alliances.First(a => a.ShortName == "MZR");

Now, operating directly on the Collection object is similar to operating on AllItems() previously, except we now have the smarter IEnumerable implementation. Using .Items is still the same as before, only operating on local items.

Another new feature is simpler query parameters. You no longer need to specify the parameter name, all tho that option remains. Resources that can be used as parameters are bound to a default parameter name, and you can pass the whole Entity object as a parameter.

Examples:

var itemLink = _crest.GetRoot().Query(r => r.ItemTypes).First();
var itemResource = crest.Load(itemLink);
var region =  _crest.GetRoot()
                .Query(r => r.Regions)
                .Query(r => r.Items.First());
var old = region.Query(r => r.MarketBuyOrders, "type", itemLink.Uri);
var now = region.Query(r => r.MarketBuyOrders, itemLink);
var now2 = region.Query(r => r.MarketBuyOrders, itemResource);

As you can see, this works with both a LinkedEntity object, and a CrestResource object.

Haven't updated in a while, but this version broke some stuff.

Today I went from...
Core 3.0.3.0 to 3.0.5.0
EveCrest 3.2.4.0 to 3.3.3.0
EveXml 3.0.5.0 to 3.0.6.0
NewtonSoft.Json 8.0.2 to 8.0.3

Currently using .net 4.5.2 in case that has relevance.

This call now causes an exception but I am guessing it has to do with some of the updates shown above.

var sellordercollection = await toolbox.eveCrest.LoadAsync(region.MarketSellOrders, "type", item.type);

item.type = "https://public-crest.eveonline.com/types/27912/"

I get "Invalid URI: The URI scheme is not valid."

EDIT: Also the exception being thrown is 'System.UriFormatException'. I have a try catch but for AggregateException, which I though that you mentioned somewhere is how you throw exceptions from inside your library.

So I updated to 3.0.6 core and 3.4.0 crest but still does not work. I can fall back to a previous version and it works.

I tried to copy the example that you had in earlier post but the line

var old = region.Query(r => r.MarketBuyOrders, "type", itemLink.Uri);

gives error that itemLink.Uri does not exist and had to change to itemLink.Href.Uri.

Also that code appears to look for MarketBuyOrders of type #System.

I am guessing that is just an example, but it does work.

UPDATE: The problem was on my end, apparently either the Crest formats for some of the endpoints changed or the models used in the library changed or both. In order to reduce the need to access some of the endpoints (regions, markettypes, etc) due to the time necessary to access them all, I gather them once and store them locally in a file. I have not implemented a way for my program to automatically determine that it needs to get the data again so I just delete the file and it will get it again. Is there a way to determine if the information in a linked entity has changed (i.e. a version property)? I had thought of checking to see if the item count had changed but they could update an item for any reason and not change the count.

So the issue with the link is that parsing of the old data did not line up with the new data and caused properties to contain incorrect values. So the endpoint for the regions market orders contained something that was not even a Uri. After downloading the data again the problem has gone away.

The "type" is a named parameter that actually gets appended to the Uri used to access the market order endpoint.

Here is the console output of the actual command generated for a concussion bomb from Domain.

https://public-crest.eveonline.com/market/10000043/orders/sell/?type=https://public-crest.eveonline.com/types/27912/&

You can see the endpoint for sell orders from domain

https://public-crest.eveonline.com/market/10000043/orders/sell/

has a type parameter

?type=

which is set to the Concussion Bomb (Type.ID = 27912) endpoint's Uri

https://public-crest.eveonline.com/types/27912/&

Is the & at the end necessary? or an artifact of possibly adding more parameters?

If the nuget version isnt working, but the master branch is, I suspect I just didnt update the nuget version correctly, so it's referring to an older version of Core, which causes that error. I'm 99% sure that's the reason, I'll have a look later.
ZKillboard currently isn't able to parse all the data from the statistics endpoint they provide, I ran into some issues with parsing some of the more complex data.

About your previous question, the & at the end of the url isn't necessary.