Thank you to everyone who has helped with Coriolis. I really like that site better. Nothing wrong with EDSY, and I use that too, but
Coriolis.io / ship builds
- Thread starter VR SenseiMatty
- Start date
I noticed many errors and missing items on my Coriolis perils. EnhAx Missles, PreEng Guard Shards come to mind, can't recall what else. Wish I knew how to code, I'd be more helpful but my brain isn't wired for letters and numbers. Is the GitHub page OK to report issues? I tried once and someone directed me to the source files and to make the changes myself.So, the 58m is actually wrongIt should be 67m. I haven't seen the maintainer come online today yet, but I wouldn't expect it to take him long.
... I can knock up an idea for a build in no time with coriolis, and see instant results.
EDSY, slightly slower, then search for the results I intended. It's accuracy is first rate though!
If the two developers could merge their ideas it would be sweet. Edsy for background database, Coriolis for UI.
And then Fdev implanting the whole thing into outfitting. I'm dreaming again..
Cook up a ship in Outfitting, press "Build"
"Don't bother to wrap it, I'll wear it now..."
And if something's missing? "I suggest you go here or go there." "Mine this, collect that." The less Googling the better.
More dreaming..
Last edited:
For ship building tool I'd also recommend having a look at EDO Material Helper. It has a new ship building tool, has added the P2 and many odd modules. Still a work in progress but as far as I can tell works very well and presents all the information that I need. It also allows creating a material wish list showing exactly what mats I have and what's missing, the most efficient route to visit the engineers, and much more.
Funny how many people find Coriolis UI better than EDSY. I'm exactly the opposite: EDSY has a nice compact UI with no unnecessary popup menus, next to no wasted space and really good grouping/separation of data. Eg I find the way Coriolis shows shield/hull stats simply horrible--needing to scroll horizontally on some of my devices is straight deal-breaking. Comparing two builds with EDSY is incredibly easy, just select the module you need to compare and switch between tabs; with Coriolis there's way too much scrolling, cursor hovering and moving eyes to see what the exact differences between two engineered modules are. This here from someone who uses (Excel and other) tables, datasheets, modern Javascript and Vue-based UI-s for all sorts of different apps, services and devices from AV equipment to networking gear to container management (Portainer) on a daily basis, so my idea of a good UI may differ from other people.
Side note: don't get me started on what a schizo mess Win 10/11 UI is...
Side note: don't get me started on what a schizo mess Win 10/11 UI is...
Yup, log issues on github, then I or some other contributor can see them easily and work on them directly there.
Sadly, they're not really compatible. Despite being built with the same language, about the same game and therefore, are trying to achieve the same thing, their 'database' is in code, rather than an SQL database of some kind and merging the two, would basically be writing a new app.
Why are you scrolling horizontally, sorry? If I'm comparing builds, I just open a build on each monitor, like I do when comparing code...
Mobile phone, tablet in portrait orientation?
I only ever use my PC screen for PC related tasks, so have plenty of real estate to play around with,
Mobile. Plus my single 16:9 PC monitor gets just too narrow for Coriolis to fit--vertical taskbar and vertical sidebar for bookmarks/downloads/RSS/whatever on Vivaldi leave me effectively with a 1300x1080 resolution for web content, and even then most websites have awful lot of unused whitespace to the sides of their actual content. Can't do multi-monitors, either: no room for that. Plus, all that aside, I'm used with vertical flow of data from years and years of perusing various data sheets and data entry. Horizontally arranged data just looks off and is hard to read for me, just like as if someone started
Code:
w t b v
r h l e
i e o r
t i g t
i r i
n c
g a
l
l
y
.But, Coriolis is responsive... it shrinks to the screen size... you could literally have two chrome windows open, side by side even on your 1080 monitor and they would be identical, with no horizontal scroll bar, so you could simply scroll down, rather than horizontally... maybe I'm being dumb, I just don't get the issue sorryMobile. Plus my single 16:9 PC monitor gets just too narrow for Coriolis to fit--vertical taskbar and vertical sidebar for bookmarks/downloads/RSS/whatever on Vivaldi leave me effectively with a 1300x1080 resolution for web content, and even then most websites have awful lot of unused whitespace to the sides of their actual content. Can't do multi-monitors, either: no room for that. Plus, all that aside, I'm used with vertical flow of data from years and years of perusing various data sheets and data entry. Horizontally arranged data just looks off and is hard to read for me, just like as if someone started
Code:w t b v r h l e i e o r t i g t i r i n c g a l l y .
Please no. No offense to the dev, but I hate the Coriolis UI in terms of summarizing the properties, and the engineering interface is just weird. The weirdly formatted top row is a pain to read at a glance, it always takes me way too long to find stuff like shield strength or resistances. I very much prefer the table-like property boxes at the bottom of the EDSY screen.
Horses for courses I guess. I am firmly in camp EDSY.
Not really, this is what it looks like on mobile (screenshot not taken on mobile, but it functions identically)--note the top bar is not scaled to window width in any way:
Also the module stats are basically a long text string, which for me is slower to parse than the tabulated presentation (with hover-over explanations for many stats!) of EDSY.
Of course, at the end of the day it's all personal preference--I'm just so used to working with tables and data sheets (including fast A-B-C...n comparisons to find differences between different products) that anything that doesn't follow that format is harder to parse. People who work with eg code with horizontal lines and long strings might find Coriolis just fine. I work with code, mostly .yml or .json files, sometimes, too, but not as often as with tables since most applications are moving away from manual config files in favour of GUI--Home Assistant is one great example of this. Pretty much only place I work with .yml anymore is Docker compose in Portainer, and that's more of a set-it-and-forget-it--until Watchtower updates something that has seen breaking changes in it's config, like changed ports
On a side note, .xml is the handwork of the Devil himself--that... thing... is barely human-readable
No no, I see exactly what you mean, the top bar still needs to be scrolled horizontally... that's pretty horrible in a smaller screen! I hadn't done the comparison myself, as I am lucky enough to have a 2k screen, flanked by a 1080 screen on either side, so if I wanna look at something, I tend to go to my PC... I simply knew the page 'appeared' to be 'responsive' and wasn't seeing the issue before! I'll add this to the list of concerns I'm compiling with Coriolis. Whilst I'm a mere Python (among other languages) Developer trying to tussle with a NodeJS App, my wife is a graphic designer and full on XHTML/CSS Hero, so will see what I/we can do, about making Coriolis truly 'responsive'.Not really, this is what it looks like on mobile (screenshot not taken on mobile, but it functions identically)--note the top bar is not scaled to window width in any way:
View attachment 392816
Also the module stats are basically a long text string, which for me is slower to parse than the tabulated presentation (with hover-over explanations for many stats!) of EDSY.
Of course, at the end of the day it's all personal preference--I'm just so used to working with tables and data sheets (including fast A-B-C...n comparisons to find differences between different products) that anything that doesn't follow that format is harder to parse. People who work with eg code with horizontal lines and long strings might find Coriolis just fine. I work with code, mostly .yml or .json files, sometimes, too, but not as often as with tables since most applications are moving away from manual config files in favour of GUI--Home Assistant is one great example of this. Pretty much only place I work with .yml anymore is Docker compose in Portainer, and that's more of a set-it-and-forget-it--until Watchtower updates something that has seen breaking changes in it's config, like changed ports
On a side note, .xml is the handwork of the Devil himself--that... thing... is barely human-readable
Just to make clear I mean no ill will towards EDSY. It is a very well thought out and good ship crafting tool. I just find it cluttered for my taste and a bit hard on my eyes. I always have to search for what I'm looking for. I can use Coriolis upside down and left handed. In the dark. After 5 beers. In my imagination. Maybe I'm just used to it.
I think there's an element of familiarity involved. I've always had a lot of respect for any community tool, but I moved from Coriolis to EDSY years ago (can't even remember why), and I now find Coriolis to be the more awkward to use. It's great we have options and all horses get their courses.
I'm currently working on a more 'elegant' import system for Coriolis, the intention is that instead of just erroring and spitting out some fairly useless data at you, it instead, replaces any modules that don't exist in Coriolis yet, with a 'missing' module and imports everything else. I think this is better... here's an example of an import that has the new AX Multicannons in... these don't currently exist in Coriolis, but in my local build, instead of erroring, it builds the rest of the ship and substitutes the hardpoint module it doesn't recognise:
I've tested this on hardpoints, as you can see, but I now need a couple of import links to test it on optional and core modules... I'm thinking V1 FSD and an optional module that isn't currently in Coriolis should do it. So, if anyone has a ship with a V1 FSD in (I think I do... but can't actually remember which one it is and am currently farming raw modules, so nowhere near my ships) or an optional module that isn't in Coriolis yet, can I please ask you to try importing it from EDDI/EDMC/Inara and then send me the '/import?data=jbwkhgo3hhgh' type string that is generated for the URL? These are only useful to me if they currently fail to import to Coriolis live or beta sites. I don't need imports that fail due to hardpoints or utility mounts that don't yet exist in Coriolis, I've got that covered, I think.
EDIT: Currently the V1 FSD seems to import almost correctly, despite it not being in Coriolis, it gets the optimised mass right (which I'm guessing it pulls from the data in the import link)
I've tested this on hardpoints, as you can see, but I now need a couple of import links to test it on optional and core modules... I'm thinking V1 FSD and an optional module that isn't currently in Coriolis should do it. So, if anyone has a ship with a V1 FSD in (I think I do... but can't actually remember which one it is and am currently farming raw modules, so nowhere near my ships) or an optional module that isn't in Coriolis yet, can I please ask you to try importing it from EDDI/EDMC/Inara and then send me the '/import?data=jbwkhgo3hhgh' type string that is generated for the URL? These are only useful to me if they currently fail to import to Coriolis live or beta sites. I don't need imports that fail due to hardpoints or utility mounts that don't yet exist in Coriolis, I've got that covered, I think.
EDIT: Currently the V1 FSD seems to import almost correctly, despite it not being in Coriolis, it gets the optimised mass right (which I'm guessing it pulls from the data in the import link)
Last edited:
I found a way to test for both Core and Optional Modules... this is shaping up nicely
