EVE Online » ISXEVE

The problem lies with the .NET wrapper and not isxeve itself.  Using a .ISS file works perfectly fine and also using the .NET wrapper with Windows 7 works fine.

The problem is that Windows 8/8.1 (all of the needed .NET packages installed) is not reporting the correct values (-1). 

Amadeus, I use the public version, only difference being I bundle whatever version I build against into StealthBot.exe to avoid breaks if a wrapper update is pushed.

It is -not- the wrapper itself. The reason -1 is being returned is the LSO returned by GetMember is not valid (LavishScriptObject.IsNullOrInvalid returns true), therefore the wrapper returns -1 for the given members to indicate invalidity.

If I had to guess, it's actually an issue in IS, but it's weird that it's only these members and only on Windows 8/8.1. The first start in debugging this will be figuring out why those properties aren't getting valid LSOs from GetMember on the affected systems.

Amadeus can you do the same changes to the 'MarketOrder' datatype?

Rogeruk - did they fix MyOrder?

Stealthy wrote:

Rogeruk - did they fix MyOrder?

It seems to be working ok, however I was not having this problem on MyOrder,  it was MarketOrder I experienced.

OK, I made the same changes to the MarketOrder datatype in version 20141001.0015 (just released.)

If this release fixes the Windows 8/8.1 (.NET) issue with  .Price and .QuantityRemaining can you also double-check and make sure that the "Station" member of MarketOrder is working too?  It uses similar code.

Confirmed using .0021 is working now with the .Price with MarketOrder

.Station is working fine on the MarketOrder gives the complete station name.

I suppose now we let Lax know his shit's broken

There is a problem tho, it doesn't display the correct price.

.0016
60600142.1
60600142
60600141.5
60600141.43
60600135.18

.0021
60600144
60600144
60600140
60600140
60600136

This is the price data for the same typeID but different results.

Let me discuss this with Cybertech and make sure he has no ideas on what it might be before I speak to Lax.   I may also attempt another "type" of fix just to see if it makes a difference.  (We currently have a custom class that we use within ISXEVE to utilize the GetTempBuffer that Lax provides with innerspace.  I'm 99% sure that it's not the issue, but I can verify that just for sure.)

Also, I'm confused on the results you posted immediately above.   First of all, .0016 is the live version and it uses the same code as it used before -- in other words, if you were getting -1 before you should be getting it again -- so, I'm confused about this (are you sure it wasn't .0015?).    .0021 uses "float" and you should be getting float values.       I'm also not sure what you're listing -- if you're searching for orders with the same typeid you'll be getting different orders, so the prices would obviously be different.   What values were you expecting?

So, what I need to know right is with the current LIVE version on the patcher (.0016) ....does the bug exist?   If so, does the test version attached (0021) provide a value ...even if it's wrong?   I'm incredibly confused right now as to which version is working/not-working and what values are correct/incorrect and even what you're expecting them to be.   You all need to be much more verbose in what you're doing, using, and expecting.

Sorry to cause confusion.

The bug (-1) exists in .0016 with Windows 8/8.1
It is fixed in .0021 with Windows 8/8.1

However if I use Windows 7 (.0016) and pull the buy orders of TypeID 4310 (Tornado) it outputs this: (first 6 orders)
60600142.1
60600142
60600141.5
60600141.43
60600135.18

When I am using Windows 7 & 8 (.0021) and pull the buy orders of TypeID 4310 (Tornado) it outputs this: (first 6 orders)
60600144
60600144
60600140
60600140
60600136

These are exactly the same orders (verified by the Order ID) at the exact same station using the same code.  The prices are not correct to what is actually displaying ingame.

OK, yea, that makes a lot more sense.   The values are wrong because of the converstion to 'float' from 'double' is either failing on the python or .NET side of things.   BUT, it does illustrate exactly where the bug is occurring in 0016.

I may have another test version available later tonight -- so check back here often.

rogeruk,

Can you provide the code to query and print the values you pasted above, so I can make a test case using your same code?

CyberTech wrote:

rogeruk,   Can you provide the code to query and print the values you pasted above, so I can make a test case using your same code?

This is what I used to print the values, GetBuyPrice(4310);

        private double GetBuyPrice(int TypeID)
        {

            Extension Ext = new Extension();
            double price = 0.0;

            List<MarketOrder> orderList;

            Ext.EVE().ClearMarketOrderCache();
            System.Threading.Thread.Sleep(1000);

            using (new FrameLock(true))
            {
                Ext.EVE().FetchMarketOrders(TypeID);
            }

            using (new FrameLock(true))
            {
                orderList = Ext.EVE().GetMarketOrders(TypeID, EVE.ISXEVE.EVE.OrderType.Buy);
            }

            InnerSpace.Echo("Found " + orderList.Count + " orders.");

            foreach (MarketOrder order in orderList)
            {
                if (order.IsBuyOrder)
                {
                    price = (double)order.Price;
                    InnerSpace.Echo(Convert.ToString(order.Price));
                }
            }
            return price;
        }

CyberTech wrote:

Should be fixed in version 20141001.0025 (on patcher).   Please verify and let me know

Verified - working great on both Win7 & Win8.1.
Thanks!

Just for the record, this was not an ISXEVE bug ;)   Cybertech just changed the code to do the same thing a different way.    Lax will investigate why our previous code was not working properly with .NET as it should have been just fine.