esi
Ship Fit Simulation Endpoint
Feature request
And endpoint, when a fit is given, provides the statistics of that fit, for a given character (ideally with the ability to provide skill overrides. less important)
So things like the power grid, capacitor size and recharge, Weapons damage and ranges. all the resists, both heated and not.
(and the moon on a stick while we're on it :D )
Route
POST /character/{characterid}/shipfitting/
Authentication
Specific scope. (leaks some skills, if you reverse engineer it. I think that's livable with)
Use case
For ship fitting display on other sites (and so on) Basic ship fitting apps.
Example returns
kind of complex, large json blob.
If possible, an anonymous fitting simulation with suitable defaults would be fantastic. Obviously not essential especially if this strains ESI
So what is the benefit you get from this?
All the data you need to calculate this on the client side is already there or not? So the only benefit is that the developer does not need to write the fit simulation any more, which there is already multiple engines for this out there anyway.
The fitting simulation is difficult.
The engines which are currently out there are reverse engineered and not entirely accurate (mostly, but dogma expressions are a PITA). And they require time to bring up to date each time a new module type is released.
We've spoken about this internally quite a bit. Having people re-implement the moving target that is the dogma engine is not great. This is a high implementation cost but high value feature request. We have some ideas but no schedule /yet/ :)
I totally didn't remember this being mentioned at fanfest, and thought I'd put it on esi-issues ;) Honest. Totally novel idea on my part. 😇
This is an interesting concept, and I'm intrigued as to how well it could be pulled off. ESI, so far, has been a data in / data out system - basically access to database. I don't believe there's any endpoint right now that actually produces some sort of calculation.
I would be worried about the fact that the fitting "engine" used on the server to calculate attributes was probably not designed to be hooked into for an API to gain access to it. It's probably not this black box where you put fit in, and out pop stats - I would assume the fitting stuff on the server is all over the place, and integrally connected to different systems. So I would think they would have to either rewrite how they currently calculate things, or write a separate fitting engine that is designed to do just that, but then that has the same problems any other fitting engine has (becoming outdated, bugs, etc).
I also suspect that the simulation you get in-game is probably handled client side with possibly some help from the server, so might not be able to get at that code either?
obv I don't work at CCP, so I'm pulling these assumptions out of my ass. Would definitely be interesting to see where this goes, if anywhere, and I would be particularly interested in how exactly it works on the backend. It would be so amazing to have a web-based fitting tool that basically just interacts with ESI to produce results.
While this sounds super cool I am a tad skeptical of real world use cases for it.
One use case that does come to mind for me personally is that I have a page that looks like this on my auth system where a user can view all their ships. https://i.imgur.com/bQPb1gj.png . It'd be cool if I could show ship stats there too, but even that has edge cases.
Anyone else got any actual examples of how they'd use it?
It would basically do most of the work for people like @blitzmann who are developing fitting tools. Instead of having to reverse engineer how the ingame fitting simulation works those tools could use the stats provided by ESI. Whether or not that's a good thing I can't really comment on.
There is one other endpoint that similarly provides a calculation, namely the routes endpoint, though I think that still just accesses a static map for most routes, only making a new route if connection tuples are provided.
Pyfa and most fitting tools offer a lot more functionality than what is currently provided by ghost fitting. To name a few things:
- Fleet Links
- Projected Effects (e.g. reps/neuts/cap transfers/etc)
- Customisable Skills (fits are always designed and compared using all 5's)
- Customisable Implants
- Skills missing to fly a fit
- Change per second on modules (i.e. hp/sec from reps, Gj/sec from neuts/nos, Gj/sec consumption by active modules)
- EHP/sec on reps as opposed to just HP/sec which is a fairly useless number
- Heat duration until burnout
I'm not trying to shoot the idea, I'm just pointing out that ghost fitting as it stands is very limited compared to most of the popular fitting tools and their functionality actually extends quite a bit beyond what dogma usually calculates.
Anyone else got any actual examples of how they'd use it?
Checking if a user is able to fly a specific fit before giving him SRP?
Anyone else got any actual examples of how they'd use it?
basic fitting tool in a mobile app?
Fitting simulation on a website?
@skyride that's the point. Besides what BTFO and Steve pointed out, it would potentially allow tools like Pyfa to hand the dogma calc to ESI while still offering the additional functionality you pointed out. This would massively decrease maintenance effort for this sort of application.
@skyride: I can only speak for my use case: killmail stream classification. More precisely, determining potential min/max DPS & tank of a given fitting and classifying the result. In such a scenario, the character's skillpoints are certainly unknowable, hence why I above ask for a means to "anonymously" query the fitting, say by assuming all Vs. Precise fitting analysis is clear over-engineering here.
Dogma trait inference is firmly in my backlog. If this is implemented by CCP my backlog will be very grateful (thanks for the idea @fuzzysteve, I really should have thought of this myself).
For my corp this would have a high amusement value, but only that. Rage monkey CEOs who are personally affronted by failfit losses may also eagerly snap this feature up.
Another use case: implementation verification. If I were to implement yet another fitting analyser (say, a different platform to Pyfa) I'd want to verify its correctness to an obsessive degree. The trouble is that fitting correctness is extremely labour intensive and will naturally be highly error prone.
By reducing the test scenarios to "does my fitting calculation match CCP's?" I'll see significantly simpler tests. I'm sure there'll be uncovered edges somewhere, but this endpoint will help cover most test scenarios.
@skyride that's the point. Besides what BTFO and Steve pointed out, it would potentially allow tools like Pyfa to hand the dogma calc to ESI while still offering the additional functionality you pointed out. This would massively decrease maintenance effort for this sort of application.
While this is a possibility, I'm in the same boat as @skyride here: very skeptical as to the real world implications, as least as it relates to current fitting tools. I can only speak as the pyfa dev, but I would be very very cautious about usurping our current fitting engine (with all it's... little quirks) for something CCP provides, simply because what CCP provides will probably not be flexible enough (fleet calculations and different skills / characters / implants would be the top hurdles I would imagine). ofc, CCP could always develop the endpoint to accept all these additional variables, but even then the application's flexibility is capped at what the endpoint provides. I'm also kinda eeehhhhh about the prospect of making an HTTP request for every fitting calculation... that wouldn't be very user friendly due to the latency, and when ESI goes down.
Where I can see this feature shining is not on fitting tools, but on web applications that simply display a fit and wish to display stats alongside it. For example, zKillboard may want to display easily CCP-rendered stats on the killboard. A tool that tracks the makeup of a fleet along with fittings could also benefit. I absolutely see where a "fit in, stats out" type of endpoint could work.
@jameson2011 brings up an interesting point... should this endpoint get release, pyfa could very well utilize it to flag potential "problem" fittings within pyfa's logic. That would be awesome to have :D