Monthly Archives: August 2013

Ship EHP Evaluator – The making of

As stated in my last post, making this tool was both easier and more difficult than I was expecting. I thought I’d explain that, and shed a little light on a couple of libraries that made this oh so much easier than originally expected.

The libraries in question are LibDogma and PHP-Dogma. These libraries meant that I didn’t have to think about what any modules did. I just tell them ‘This ship, these skills, these modules and rigs’ and I get back an answer saying ‘this hp, these resists’.

This is the core of any fitting tool, and what makes writing fitting tools so much, umm, fun. So many little caveats, the various stacking rules, and so on, and so on. Libdogma takes care of all of it. php-dogma lets me access libdogma from inside a php page.

With that out of the way, it was a straight run home, tying it into the code I’d already written for the evaluator to parse the input. And just a little for calculating and outputting the EHP. That’s the ‘Easier than expected’ bit.

The more difficult than expected comes from the expectations that I had, when I found libdogma. I’m using a Centos 6 server, which comes with gcc 3.4.4. That won’t compile libdogma. So I found an updated rpm and tried that. No dice.

Eventually I downloaded and compiled clang (the latest version) from source. That built libdogma fine, and it passed all the tests.

At which point php-dogma refused to compile. It appears to have been a problem with php 5.3.27, as after an upgrade to 5.4, it all worked fine. And the first time I tried, I’d forgotten to set PKG_CONFIG_PATH, so it didn’t find libdogma. Took me a little time to run that one to ground.

Short sentences, to cover quite a lot of time banging on things, and hoping they’d work.

Anyway, as php-dogma is agpl, I’ve released the code on github under the agpl as well. Short version, if you don’t know the license: Add it to what you want, but if you let people use it, then you have to let them have access to the source, including if it’s as a service. Obviously, IANAL, so you’ll want to look at the license in more detail, if you’re not happy releasing your code.

Ship EHP Evaluator – The Tool

The idea for an update to my scan evaluator tool came up on twitter and it struck me as interesting. Turned out to be both more and less complicated than I thought it might be, but I’ll go into that in a different post, in case you’re interested in the techy details.

The non-techy details are pretty simple. Take a ship scan, paste it into the tool and bang, you get an estimation of how much EHP the ship has.

Now, because I don’t have a huge database of people’s stats (and if I did, I wouldn’t use it, as I wouldn’t have people’s permission for it. So they’d stop giving me the stats), it’s assuming that they have all relevant skills at 5. And the irrelevant ones, but those aren’t relevant. It’s also not giving them any fleet boosts. And there’s the possibility the ship scan missed a tank module, so you didn’t tell the tool about it.

Aside from those caveats, all the test ships I’ve thrown at this have come out with the figures (+/- 1 hp) that pyfa was telling me (aside from one bug that I’ve reported.)

Of course, No warranty is given for people using this for nefarious purposes such as scanning cargo ships and deciding how many ships to commit to attacking them.

Credit is due to Artefact2, without whom I couldn’t have done this (at least, not in the short period of time it took.)

I have some thoughts about functionality to add, such as alerts about open slots. But that’s a future update. This is the initial release.

No warranty is given for any purpose, If your computer explodes when using the tool, it’s all your fault, you should have been nicer to it.

Blueprint calculator update: ISK/HR normalized for 24 hour production runs

This only applies for T2 things with the blueprint calculator.

You’ll find a new row in the Time Calculations box. This is called iskh 24H rounding

This is taking the time taken to manufacture all the runs for the invented blueprint, rounding it up to the next 24 hours (so a 3 hour run takes 24 hours, a 25 hour run takes 48 and so on) and then calculating the isk/hr as if that’s the time taken.

This is so you can have an idea of how much isk/hr you’re making, if you’re only putting jobs in once a day, at the same time. It’s not perfect, of course. If you have a window of several hours, then a 25 hour job probably won’t consume 48 hours of a slot.

But if you look at something like a Hobgoblin II then you can see how it affects your profitability if you’re doing a single run per day.

 

As it’s not relevant for non-limited runs, it’s not added for those.

Modular Assembly Arrays and Labs

We’re not going to get modular POS for a long time. That’s pretty much a given, with what’s been said. It’s just too complicated to modify the POS code to allow it, due to the big ball of mud programming that plagues any large software project. (Just slap new features onto older code, because doing it any other way would take a really long time, relatively)

But, perhaps, we could have a smaller change done, which should require less interaction with the main POS code. I’m making a number of assumptions when I’m talking about this, which may or may not be valid.

There are a number of places where working with POS is somewhat painful. The changes which have happened recently with the removal of the 3km limit have helped a lot, but I’d like things to go a little further.

The main change I’d like is: Change assembly arrays and labs modular. So you can deploy a single array (of each type would be fine) and then expand it. So no more having a POS with 4 advanced labs. You’d have a Lab that you could expand with more lab slots, of the varying types. Probably in packs, to reduce the min/maxing potential.

If you could do it with a single Industry structure, that would be even better. Storage modules, assembly modules for each of the different types, and so on. But I can see the restricted manufacturing slots, and the different speeds of labs being a trifle complicated to manage.

Once that’s all in place, you may be able to expand it further, to include more and more of the functionality of the POS.

Ideally the space factories could be anchored somewhere other than at a POS. Just give it a fuel bay module, and a module for power generation. (Yes, I know the ‘Just’ is making it sound simple. It’s not.) Possibly shield extenders modules, hardeners and so on. Tying them to moons is less than ideal, in my mind. Deep space factories would be neat.

As I’m wanting the moon mining to be shifted off into a totally different structure, to allow for raiding, perhaps once that’s all done, the old POS code could just be retired?

And yes, I know this would get rid of bubble shields. Which some people consider to be very important. If they’re really needed, how about an anchorable structure, such as the warp disruption bubbles? Though I’m a fan of my other suggestion, for having it possible to switch off your warp core, and then be unable to be scanned down. Which would be a similar result, if you’re not unlucky enough to be scanned down at your safe before you switch off.

 

 

 

 

And yes, this all came to mind by me being annoyed about moving materials between assembly arrays. A single storage pool would be nice.

BP Calculator: T2 Invention update

Just another quick update.

The Form Entry page now has another submit button, called ‘Enter list – T2 Invention’. If you use this, it will take a list of T1 blueprints which can be invented from (ignoring anything else) and produce a list of everything you can make, along with a basic price for them. It doesn’t deal with decryptors, so it’s not doing all the work for you. And I’m not going to simplify it to just take a list of blueprints without the rest of the line.

But if you already have a list of blueprints, it’ll help pick out the ones you might want to look at. Just remember, there’s no market volume data. Just price data.

Quick update for the blueprint list

Just a quick update on the blueprint calculator. (Well, It wasn’t that quick to do. But it should be very simple to understand.)

The blueprint list created by the form, https://www.fuzzwork.co.uk/blueprints/enterlist.php, will now show an ISK/hr, an ISK/HR for POS manufacturing (basic arrays only.) and isk/hr for POS, with the datacores cost removed, for -4ME -4 PE blueprints.

It’s not perfect; T2 Ships can’t be made in regular ship arrays. This doesn’t pay attention to that. And R.A.M’s are kinda ignored, due to the rounding to less than 1 unit. But it’s indicative enough, and simple to check up on. All skills are assumed to be 3, when determining the cost of the datacores.

Long term, I’m planning on having it being possible to override the skills, but that probably won’t happen till SSO is available, as I don’t want to go to the trouble of writing a full user management system when something should be coming out some time in the next 6 months or so.

The github is mostly up to date, but I need to add in the details for how to manage the infrastructure needed, like a copy of price data in the database, possibly with a data loader, to pull it from my archived copy.