add implant icons

[zmsMarc]

small QoL change to see which of your jumpclones have implants
Could use a mouseover to show the name of a given implant, but I could not find how to map the ID to text

[recursivetree]

You can get the type name by following the type relation on the implant model, and then getting the name from the InvType model: https://github.com/eveseat/eveapi/blob/master/src/Models/Clones/CharacterImplant.php#L43-L47
If I'm right, it should work like this:

$implant->type->typeName

Also thanks for the contribution!

[zmsMarc]

Hey, thanks for the quick feedback!

Sadly the jumpclones come via character->jump_clones
https://github.com/eveseat/eveapi/blob/master/src/Models/Clones/CharacterJumpClone.php
and that one doesnt seem to publish the type relationship.

I'll see if I can extend the model here without breaking anything and will update the PR in a bit

[recursivetree]

Sorry, I did take a closer look. It does indeed look like seat does a weird thing with jump clone implants so that there can't be relations. The best way would probably be either InvType::find($implant_type_id)->typeName or redesigning how this data is stored.

Also, please confirm that you're really targeting seat 4? The master branch is still seat 4, for seat 5, target the 5.0.x branch

[zmsMarc]

Glad to hear it wasnt just me struggling with the laravel model :)

I've added the mapping between type_id/name in the controller because I think the model always must return a relationship which was far above what I know about php.

The PR now points at 5.0.x and i fixed the styleCI complaints

[Crypta-Eve]

I would prefer if the link to the typeName come from the model as opposed to the controller. The reason is that we can then use eager loading in order to reduce the number of sequential DB calls. I will post an example of how this is done tomorrow so you can have a look :)

[recursivetree]

I would prefer if the link to the typeName come from the model as opposed to the controller. The reason is that we can then use eager loading in order to reduce the number of sequential DB calls. I will post an example of how this is done tomorrow so you can have a look :)

I tend to agree, but that would require some refactoring in eveapi. Implants are of a jump clone not stored as a column in a tables, but as a json array in a column of the jump clone:

https://github.com/eveseat/eveapi/blob/5.0.x/src/database/migrations/2018_01_07_112709_create_character_jump_clones_table.php#L44
https://github.com/eveseat/eveapi/blob/5.0.x/src/Jobs/Clones/Clones.php#L109

I do agree that this is a unconventional way and that implants of jump clones probablly deserve their own table so we can add relations, but the changes required for this are probably not trivial for a first-time contributor like zmsMarc.

On the other hand, being worried about the performance of character sheets is justified, as this is viewed quite often.

Lastly, if we go down the route of redesigning eveapi, we have to ask if this will be a breaking change to eveapi. While I'm generally not worried about making a small breaking change, we at least should look if it could break anything else.

[tmas]

It would certainly be nice to have a proper relationship, but for now we could make the existing implementation in this PR a bit more efficient. Instead of this:

$jumpclone_implants = [];
foreach ($character->jump_clones as $jump_clone) {
    foreach($jump_clone->implants as $implant_id) {
        $jumpclone_implants[$implant_id] = InvType::find($implant_id)->typeName;
    }
}

Something like this should reduce DB queries significantly:

$jumpclone_implant_ids = collect($character->jump_clones)
    ->pluck('implants')
    ->flatten()
    ->unique();

$jumpclone_implants = InvType::whereIn('typeID', $jumpclone_implant_ids)
    ->get()
    ->pluck('typeName', 'typeID')
    ->toArray();