ESI Giving Large Numbers For Ore and Mineral Mass

I’m working with the ESI API and my code ran into some problems while collecting item data. When entering the item type_id into the /universe/types/{type_id} endpoint for ores and minerals, the ouput states that mass is 1e+35. This is both not true game-wise and too large of a number for my program to handle. Any reason why they all have that mass value?

1 Like

This very much looks like a bug in ESI to me. Would suggest to open an issue here: GitHub - esi/esi-issues: Issue tracking and feature requests for ESI

Your program should technically be able to handle that value though. I do not know which programming language you are using, but the data type is float32, which usually has a range of -3.4e+38 to 3.4e+38.

I just checkout in my app and it looks weird, but works:

1 Like

Ok I didn’t know if it was setup like this for some specific reason and i didn’t want to automatically jump to a bug in ESI, but now it looks that way. Im using python with a sqlite database and whatever type the mass gets converted to by the module is too small to hold it. Thanks for the info!

No worries. happy to help.

I’ve been building apps with ESI for a while and in general I would recommend to use the ESI model types you can see on the ESI website as reference for your implementation to avoid any surprises. I got burned couple of times when I tried to use a different type in my apps :wink:

Are you using any 3rd party library to fetch from ESI? If that is returning the mass as something other then float that might be a bug too.

Im using the peewee library in python to setup a sqlite3 database, it is taking the value in as a double, but somewhere in the library it does a conversion of some sort and thats where my error comes from. It may still be an issue with my code, but it at least pointed out the value being weirdly big

I’ve been working mostly with Django in Python, but peewee looks like a cool ORM too.

I checked and sqlite is storing floating point numbers as float64, so that should work fine too. So my guess is that somewhere on the way between ESI and sqlite the number is converted to an integer.