Brilliant. Is there a way to import my builds from the actual game, ot from Inara?
Never mind... I was just being stupid. Found it
Never mind... I was just being stupid. Found it
Regarding the Overcharged G5 x 1 issue: this seems to occur when you change your module values manually on the outfitting page (instead of choosing 100%, 80%....). I think a way to solve this could be to just use the settings on the analysis page for module grades and number of rolls..................
- In the checklist under details it states Overcharged G5 x 1, despite I entered a 6 in the box. And in G1-4 it states x 5, but I also entered a 6 there...
That's because in the build you've linked, the target modification on the weapon is flagged as a "legacy" blueprint, rather than having a progress percentage like modern modifications. If you click the 100% button on that module and then re-run the analysis, it then prescribes the expected six G5 rolls with corresponding material costs.A bit confused by the "Analysis" Tab. I want to figure out what materials I need to create a specific, engineered build.
When I put a six into every field in "Rolls to complete each grade", it calculates that I need five materials for each grade. For G5 its always only one material, despite what I put in the field. In this case it should be for example 6 Zirconium, as I put grade 5 100%, 6 rolls and you need 1 Zirconium per Grade 5 roll.
Questions:
- How does the calculation work exactly? Am I missing something or is there a bug.
- In the checklist under details it states Overcharged G5 x 1, despite I entered a 6 in the box. And in G1-4 it states x 5, but I also entered a 6 there...
Took a quick look and adding position: relative toIf anyone has any webdev/CSS expertise and wants to take a look, I'm certainly open to ideas!
Thanks for the tip! Changing the position on that container from static to relative did the trick. I don't understand why either, but it works for me at least.Took a quick look and adding position: relative to
#outfitting_modules_group_hardpoint
#outfitting_modules_group_utility
#outfitting_modules_group_component
#outfitting_modules_group_internal
Seems to fix it, possibly even without breaking anything else. I didn't test it too thoroughly.
This is probably some issue with css containers-within-containers sometimes, maddeningly, not working as expected if the parent/child containers don't have the exact right positioning style set. I mostly try to do backend programming and only vaguely understand this so I don't really have a good explanation for the "why" here (or even if this is the correct way to fix it).
EDSY specifically supports SLEF format, which is a community-defined JSON format based on the Journal Loadout event format. EDSY can import and export in this format, as can Inara, but Coriolis does not support it yet; you'd have to ask them when they plan to implement it.
edit to clarify: once upon a time I reverse engineered Coriolis' own JSON export format and built up all the mapping tables to convert them to EDSY's internal representations, which allowed for import from Coriolis. But of course they made changes to their format after that and it wasn't feasible to keep trying to maintain that support, so I dropped it. But the code to detect the Coriolis format is still in there, hence the message that it isn't supported.