Capital Size Validation

[DarkFenX]

Posted by @Ebag333

Making this a separate issue to avoid contaminating #18 anymore.

From Kadesh:

It's the way it was done in EVE. I added this verification after i was playing with abaddon fit on SiSi and noticed that EVE doesn't let me to do that. The limitations in game client were exactly the same as implemented in this file: https://github.com/pyfa-org/eos/blob/master/eos/fit/restriction_tracker/register/capital_item.py I repeat, it is not a hack or my assumption, i took this data from reaction of server to my actions and from error message which client shown me.

if you find any discrepancies between ingame stuff and eos implementation, file new issue. Current CCP implementation might be different indeed (something based on ship's base PG and turret base pg requirement, for example - to prevent not just capital guns being fit on subcaps, but also large guns being fit onto frigs).

To be fair, I haven't hacked the client to see how exactly they limit this, but here's what I've seen (and this was happening on TQ, not SiSi).

Everyone knows that you can't fit dread guns on sub-caps, but then CCP went and added a ton of modules for caps (so they could stop using battleship sized stuff). We're talking afterburners, shield extenders, armor plates, the works. They went nuts.

Hilarity ensued.

You had 500k EHP capital LSE shield Bhaals running around (with insane regen), someone put stuff on the mega hull (can't remember if it was a Mega or one of the variants), basic chaos.

CCP blocked that, but missed a few modules. They they later fixed the modules they missed (none of those modules were particularly useful anyway).

So I believe (and very well could be wrong) that CCP has a hand done list somewhere that blocks capital mods.

Anyway. All that to say.

There's a couple issues with this validation in general:

• It assumes all modules over 500 volume are capital modules. This is not true.
• It assumes that all modules under 500 volume are not capital modules. This may or may not be true (but even if it's true today, there's nothing guaranteeing us that it will be true next patch).
• It assumes that all "capital modules" have a skill with a capital type. This is not true.

Okay, so to break this down.

It assumes all modules over 500 volume are capital modules.

So we have the code which checks if:
MAX_SUBCAP_VOLUME = 500

It is true that capital modules are very large in volume (doing a search in the database, they mostly seem to be exactly 4000 actually, but a lot of them also have special volumes).

The problem isn't so much with saying that "capital modules are over 500" as it is saying "all modules over 500 are capital modules."

There are many things in game that aren't a capital module that are over 500 in volume. The big one that we'll care about is structure modules. Now, granted, we can check if it's a structure module or not fairly easily, but coding in a one off exception to the rule is something that we should handle with care.

On the flip side, we assume that anything under 500 volume is not a capital module, when this actually isn't true.

Unit W-634's Modified Fighter Support Unit is a carrier module (so a capital module), yet it only has a volume of 200, and the capital module validation check would not apply (even though it should).

So validating things larger than 500 is problematic, because of the modules in game that are large yet aren't capital.

Validating things that are less than 500 is problematic, because of the couple capital modules that are very small.

We can't lower that threshold, because if we set it to 200 (to grab Unit W-634's Modified Fighter Support Unit) we'll grab subcap modules (like Bastion Module I).

So the TL;DR is....filtering based on size is problematic. :(

A further check is done (and this one actually isn't called out in the exception that gets returned) on the skill.

if (Type.capital_ships in ship_item.required_skills):

The problem is that many of the capital items added in game don't require any special skills to use. For example, Capital Shield Extender II has the exact same requirements as Large Shield Extender II. So this check will incorrectly not validate these modules as capital modules, when it should.

Unfortunately I don't have a magic bullet that will fix this. This is a really difficult thing to tackle because there's no single clear cut value that identifies these modules as capital or not.

Most likely our best solution is probably to maintain a list of groupID and/or marketGroupID to filter on. I don't like it, as it's hard coding stuff, but I don't see many other options.

[DarkFenX]

Posted by @Ebag333

So according to a conversation on Slack, cap vs subcap is all hard coded in EVE.

So CCP doesn't have a better option, even though they have access to stuff that we don't.

[DarkFenX]

Posted by @regner

On the EVE side they validate this with a hard coded restriction, if volume >= 4000 then capital only.

[DarkFenX]

Posted by @Ebag333

On the EVE side they validate this with a hard coded restriction, if volume >= 4000 then capital only.

Volume >= 4000 makes sense, but there's still modules that don't meet this requirement so wouldn't match (mostly officer stuff, for some weird reason). Most capital mods are exactly 4k volume, so it's potentially something we could check against, but still quite hacky.

I think our best bet is to just hard code this against a list of capital item groups. If CCP adds a new group we won't catch that until we update it, but at least then we know we're cleanly filtering and not doing something hack that breaks because of weird officer mods, or CCP adds something, or decides that all capital mods need to be 4123 in volume for reasons.

Also, if we don't update, then we're allowing something and not blocking it, so it's not preventing functionality. I'd rather operate on a blacklist (allowing anything other than what we flag) rather than a whitelist (allowing nothing, except what we flag as okay).

Along the lines of what @DarkFenX said in the other thread regarding T3D stances/modes, I think we should put this in the framework/skeleton, since Eos doesn't really know so much about markets, groups, names, etc. The more we keep Eos purely hard data driven (what's found in the attribute/effect stats and what's fed into it) the better.

[DarkFenX]

Restriction tracker implements all the knowledge we have about EVE fit restrictions. I'd prefer it to mimic EVE as closely as possible - we do not create any restrictions out of the blue (apart from few technical ones, like class-specific validation).

For now, by the looks of it, CCP just changed number. If EVE detects capital modules as modules with volume over 4k, and if they haven't changed definition of 'capital ship' (needs skill Capital Ships), then let's just change size from 500 to 4000 and keep it this way. I doubt there're any benefits in doing it any other way.

All such changes must be tested in actual client, if possible - including boundary values (4k in this case). Only after we have somewhat reliable proof that EVE implements it this way - we change it in eos.

[DarkFenX]

Posted by @Ebag333

For now, by the looks of it, CCP just changed number. If EVE detects capital modules as modules with volume over 4k, and if they haven't changed definition of 'capital ship' (needs skill Capital Ships), then let's just change size from 500 to 4000 and keep it this way. I doubt there're any benefits in doing it any other way.

Except that there are capital modules that aren't 4k in size (officer stuff). Not to mention other modules that are over 4k that we want to be able to use on non-capitals (structure modules, primarily). So hard coding in something that says "all modules 4k and up are capital modules" just shoots us in the foot down the road, and will not catch all capital modules while catching modules that aren't capital modules (fails both directions, both up and down).

All such changes must be tested in actual client, if possible - including boundary values (4k in this case). Only after we have somewhat reliable proof that EVE implements it this way - we change it in eos.

We don't need to test this in the client. We know the client blocks cap mods from being used. There's also no way to "prove" that the client works in a particular fashion unless you're going to start decompiling and looking through source code.

We can see what would/wouldn't get blocked by a 4k boundary easily enough, it's not a clean test by any measure. We'd have to create a custom list to capture the 4-6 cap mods that are smaller than 4k, and then another list to filter out the non-capital stuff that's over 4k.

Also, about 90% of the capital modules are either 4k or 8k, so we'd be better off filtering on just those two exact numbers than >=4k. We would then need to figure out how to filter out everything that's 4k that's not a capital module, which means a custom list to remove those items (the structure modules are the big one there). And then another custom list to include the officer capital items that aren't 4k/8k.

That's a lot of hard coding.....

[DarkFenX]

Posted by @Ebag333

Here's a query you can use to see all the capital modules.

SELECT DISTINCT IT.typeName, IT.marketGroupID, IT.groupID, IT.*, * FROM dgmtypeattribs DTA
INNER JOIN dgmAttribs DA on DTA.attributeID = DA.attributeID AND DA.attributeName LIKE "%Volume%"
LEFt JOIN invtypes IT on DTA.typeID = IT.typeID
WHERE IT.marketGroupID IN ("1052","1056","1063","131","1642","2240","2241","2242","2243","2244","2245","2246","2247","2250","2251","542","600","615","671","771","772","773","774","775","776","777","778","801","872","910","938")
ORDER BY IT.marketGroupID

Think I got them all.

You can see that's pretty clean except for the prop mod section and a few others (DCU).

[DarkFenX]

Except that there are capital modules that aren't 4k in size (officer stuff).

Alright. Let's stop here. Give me examples of such modules and i will test them.

What is definition of a capital module? It's a module which can't be fitted to subcapital EVEN if it satisfies fitting requirements. Put all the PG mods you can to abaddon and try to fit officer module. If it fits onto Abaddon, then it is not a capital module. If it doesn't, then it is a capital module.

Not to mention other modules that are over 4k that we want to be able to use on non-capitals (structure modules, primarily).

This is yet another point for doing structures separately. And such questions are the reason why i'd like to put structures out of scope for now - because they require maintenance, or additional effort when you are trying to solve other questions.

[DarkFenX]

I just tested capital shield booster and it doesn't fit despite having sufficient resources to be fit (75000/101578.7 PG, 300/584.5 CPU). Message is

Capital Shield Booster I is too big to be fitted on Abaddon

I tried officer modules too. I didn't know which one to try, so did webs. Always thought of them as of battleship-class modules btw. And, well, they do fit:

[Abaddon, Abaddon fit]

Draclira's Modified Reactor Control Unit
Draclira's Modified Reactor Control Unit
Draclira's Modified Reactor Control Unit
Draclira's Modified Reactor Control Unit
Draclira's Modified Reactor Control Unit
Draclira's Modified Reactor Control Unit
Draclira's Modified Reactor Control Unit

Tobias' Modified Stasis Webifier
Domination Heavy Stasis Grappler
[Empty Med slot]
[Empty Med slot]

[Empty High slot]
[Empty High slot]
[Empty High slot]
[Empty High slot]
[Empty High slot]
[Empty High slot]
[Empty High slot]
[Empty High slot]

Large Ancillary Current Router II
Large Ancillary Current Router II
Large Ancillary Current Router I

This fit is legal in EVE.

[lunedis]

Yes, because Stasis Grapplers are modules designed for both Battleships and Capitals.

I have access to Thunderdome where I can spawn any item, so I might be able to test e.g. the Unit W-634's Modified Fighter Support Unit

[DarkFenX]

I've used thunderdome too, just wasn't aware which module @Ebag333 was talking about.

But there's no sense in testing Unit W-634's Modified Fighter Support Unit - because it can't be fit to subcaps because of carrier/supercarrier-only limitation. I am inclined to think that from technical point of view they are subcap modules with aforementioned limitation. Players' point of view doesn't matter at all in this case.

[DarkFenX]

Also, this has been fixed in c48de92