Elite Shipyard

Status
Thread Closed: Not open for further replies.
Updated to 3.4.1a7:
  • first attempt at responsive design (for i.e. mobile devices); outfitting and stats panel layouts now behave differently for smaller viewports
  • changed double-click/long-touch behavior on outfitting slots; now shifts focus to module picker rather than emptying the slot
  • added right-click on outfitting slot to empty it; for touch interfaces there is a new "EMPTY" module at the top of the module picker
  • added sticky headers to scrolling shipyard, outfitting slots and module details displays
  • fixed a bug in red highlighting for modules exceeding type limit (i.e. experimental weapons, shield generators, etc)
  • fixed a bug that allowed a module to exceed its type limit in non-experimental mode when copying between slots
Please let me know what you think of the updated touch-interface and small-screen support, and post your suggestions for any other ways to make the tool easier to use in these contexts.

Also note that the "preview" site is very close to feature parity with the old pre-3.0 site, which means the old version will soon be going away and permanently replaced with the new design. So if any deal-breakers remain, now's the time to speak up (again, possibly, if I forgot any issues reported awhile back).
 
I'm someone who favoured the old design, for layout, colours and fonts (we don't read individual letters, but recognize the familiar shapes of words - blocky fonts and all-caps hinder that). All of those are to do with ease and speed of reading information.

Having used the new design to the point where I mostly know where to find things, I've more or less acclimatised - no deal-breakers remain. Your improvements have helped also.

That's not to say I've changed my mind - I still feel the old design is far superior for speed of reading information, and especially information per square inch. I much prefer that far tighter layout - the dropdown menus for modules and pop-out boxes for engineering keep your focus and mouse pointer within one area rather than dragging both repeatedly all the way across the screen. So, speed and efficiency of use, as well as reading. (It might shine through that I absolutely loathe touch-screen based design.)

I do recognise that you're trying to expand on functionality beyond what that design allowed, and even if some of that is for filthy, mouth-breathing screen-touchers I've made my peace with that and thank you for your efforts. It's a brilliant tool even if I don't love the interface.

I've just noticed the 'set your own discount' option for ships and modules. Things like that will soften the blow. :) (And yes, I've spotted other advantages also. The Spread-out Design Philosophy will still never gain me as a follower.)
 
Just got back from DW2 and was updating my ships to make use of the new slots fDev added.

Found that the Diamondback Explorer in ED Shipyard is missing one of the two added class one slots.
Looks like all the other small ships did get both the new class 1s.
 
Updated to 3.4.1a8:
  • improved touch detection and handling to more reliably react to single touches and allow normal scrolling without accidental selections
  • rearranged stats panels toggles depending on display size and orientation, to more easily show/hide desired panels using a minimum of screen space
  • tucked the outfitting column toggles (mass, power, attributes, price) into a popout panel for narrow displays
  • reduced the minimum width of the outfitting slots panel so that it fits correctly even on very narrow (~300px) displays
  • added fullscreen mode button to help hide the bulky address bar on tiny (i.e. phone) displays
I'm someone who favoured the old design, for layout, colours and fonts (we don't read individual letters, but recognize the familiar shapes of words - blocky fonts and all-caps hinder that). All of those are to do with ease and speed of reading information.

Having used the new design to the point where I mostly know where to find things, I've more or less acclimatised - no deal-breakers remain. Your improvements have helped also.

That's not to say I've changed my mind - I still feel the old design is far superior for speed of reading information, and especially information per square inch. I much prefer that far tighter layout - the dropdown menus for modules and pop-out boxes for engineering keep your focus and mouse pointer within one area rather than dragging both repeatedly all the way across the screen. So, speed and efficiency of use, as well as reading. (It might shine through that I absolutely loathe touch-screen based design.)

I do recognise that you're trying to expand on functionality beyond what that design allowed, and even if some of that is for filthy, mouth-breathing screen-touchers I've made my peace with that and thank you for your efforts. It's a brilliant tool even if I don't love the interface.

I've just noticed the 'set your own discount' option for ships and modules. Things like that will soften the blow. :) (And yes, I've spotted other advantages also. The Spread-out Design Philosophy will still never gain me as a follower.)

I do sympathize with that preference; there are some ways in which I also found the dropdowns easier to manipulate quickly, but especially with the advent of engineering I felt that general layout was just not feasible to stick with. And I'm also not necessarily a huge fan of the caps font, but decided it was worth sticking close to the visual style and design of the game itself.

That said, I have no problem adding more options to let folks tweak things how they like, and one of those will be the ability to change the fonts and colors, all of which have been implemented using CSS variables precisely to make that easy to implement. Regarding the overall layout, as an experiment, have you tried shrinking your window down horizontally to trigger the new one-panel display mode, and then enabling of the slots column toggles (mass, power, attrs, price)? That will get you closer to the general scheme of the old version, so if you find that style preferable, I can certainly add an option to force that mode even on wider displays.
 
Thanks for the constant updates. It takes a bit to get used to the changes (especially on mobile for me, as I'm using the tool often on the go), but I really like it so far.
 
  • added right-click on outfitting slot to empty it; for touch interfaces there is a new "EMPTY" module at the top of the module picker
This is one feature I have rather ambivalent feelings about. On one hand, I have a certain distaste for websites that hijack the right mouse button (indeed, that’s one of many things in Coriolis that put me off); on the other hand, I do recognize the convenience of having that extra functionality available. (Although I think that using the Delete key to remove the currently selected module would be the most intuitive way for PC users…)

Anyway, if the right-click is going to stay, I suggest to use it also for cycling of power priorities in the reverse direction.

That said, I have no problem adding more options to let folks tweak things how they like, and one of those will be the ability to change the fonts and colors, all of which have been implemented using CSS variables precisely to make that easy to implement.
That is good news :)

Regarding the overall layout, as an experiment, have you tried shrinking your window down horizontally to trigger the new one-panel display mode, and then enabling of the slots column toggles (mass, power, attrs, price)? That will get you closer to the general scheme of the old version, so if you find that style preferable, I can certainly add an option to force that mode even on wider displays.
Oh yes, please do. Along with an option to display all attributes in the ‘Attributes’ column. ;)

And, as always — thank you very much for all the good work you’ve done!
 
This is one feature I have rather ambivalent feelings about. On one hand, I have a certain distaste for websites that hijack the right mouse button (indeed, that’s one of many things in Coriolis that put me off); on the other hand, I do recognize the convenience of having that extra functionality available. (Although I think that using the Delete key to remove the currently selected module would be the most intuitive way for PC users…)
That was my original position as well, and the reason the initial design did not trap right-click but instead used double-click to empty a slot. But when working out the mobile support (one-panel display mode, touch interface) I realized I needed to consistently treat double-click like a long-touch, and I needed that to jump to the module browser to replace a slot, not empty it. So I resorted to right-click as a shortcut to empty the slot, which I'm not sure I like, but on the other hand it's not like there's any meaningful interaction available from the regular context menu when right-clicking on modules and slots -- it's not like they're links you can open in a new tab or anything, and I actually had issues with my phone browser opening the context menu when I tried to long-touch, so blocking that behavior at least for touch was necessary I think.

But you may be right that for mouse interfaces (for which a keyboard is also presumed), the "delete" key may be a better solution than right-click. I'll think on that.
 
Updated to 3.4.2a9:
  • fixed the (S)ROF of all Rail Guns to correctly model the charge-up time (thanks CMDR 100.RUB for a lot of testing on this)
  • fixed the shield rebuild and regen time calculations to consider the SYS capacitor and pip allocation; rebuild time assumes an initially full capacitor, while regen assumes an initially empty capacitor
  • fixed the Auto Loader special effect to be correctly modeled for overall weapon DPS and capacitor/ammo duration calculations
  • builds are now always loaded (via import or URL hash) as if experimental mode is enabled, to avoid modules being deleted as invalid during import; if experimental mode is not actually enabled, the import will generate a warning message, but the disallowed modules will still be loaded (but shown in red)
  • fixed the visual feedback when pressing module and slot controls on touch devices
  • shifted a few stats panel labels down slightly (CUR and MAX in the HND panel; WEP in the THM panel) to more clearly indicate that they relate to two rows' worth of data values
 
Updated to 3.4.2b1:
  • added support for exporting all builds (from the help/options tab) to more easily save a local backup copy or transfer them to another browser or device
  • added support for importing multiple builds (such as from the new bulk export, or an entire Journal file) with options for which one(s) to store under what label
  • added warning icons to mark power plants with insufficient output to power all enabled modules, similar to undersized shields and thrusters
  • removed the sync of saved builds and modules from the old version, which will soon be retired and replaced
  • fixed a minor font kerning issue that has bugged me for the longest time
⚠ Loadout import seems to be broken altogether right now :(

[edit: I mean the JSON file import]

This should be fixed now. :)
 
Since, I think, 3.4.2a9 EDSY shows my grandfathered 5A Shield Generator (Optimal Mass +11%, Optimal Multi +49.3%) as not fitting in my Cutter and it shows the shield statistics as ERR.
In game it fits (~2300MJ). I think there's a lot of these Cutter 5A Shields still out there because there was a several weeks warning before the new engineering did hit.
 
Since, I think, 3.4.2a9 EDSY shows my grandfathered 5A Shield Generator (Optimal Mass +11%, Optimal Multi +49.3%) as not fitting in my Cutter and it shows the shield statistics as ERR.
In game it fits (~2300MJ). I think there's a lot of these Cutter 5A Shields still out there because there was a several weeks warning before the new engineering did hit.
Hm. I seem to recall making a number of tweaks to the optmass/maxmass relationship based on one-off anecdotes; I think I'll have to try to gather up examples of all combinations of legacy/modern thrusters/shields with negative/positive optmass modifiers to verify finally which ones also affect maxmass and which don't.

I have a sinking feeling that in at least some of those combinations, the behavior is different solely based on whether its a legacy/modern blueprint, which EDSY doesn't currently even distinguish. But we'll see. Thanks for the note! And if anyone else can offer screenshots to confirm the other test cases, that'd be great.
 
I just noticed the Minimum Mass and Maximum Mass doesn't get adjusted. With an Optimum Mass 449.4 there should be Maximun Mass at ~1124.3 but it stays at 1013/203, the original values. The Maximum Mass against the Hull weight (1124 > 1100 for my shield and Cutter) is what defines if the shield fits or not.
 
Last edited:
@taleden:

I just conducted 3 trials against the Cyclops shield, and I can conclude the following:

1) The damage per shot of unengineered C2 AMCs is indeed 2.2 MJ
2) The damage is 100% converted to AX damage.

The fact that this weapon possesses 100% AX damage presents the unique opportunity to test if human shields possess 90% or 100% AX damage resistance. I'll let you know how that goes =)
 
I just conducted 3 trials against the Cyclops shield, and I can conclude the following:

1) The damage per shot of unengineered C2 AMCs is indeed 2.2 MJ
2) The damage is 100% converted to AX damage.

I think the raw damage ought to actually be 2.19, but < 0.5% error is probably not discernible from in-game weapons tests. Thanks for confirming! Also, can you clarify for me how these weapons work? Do they always shoot 100% AX damage (so 0% conventional exp/kin/therm), or do they work like regular multicannons until you use the AX ammo synthesis recipe to load them with AX rounds?

The fact that this weapon possesses 100% AX damage presents the unique opportunity to test if human shields possess 90% or 100% AX damage resistance. I'll let you know how that goes =)

I'm fairly confident that human shields have 95% AX resist and human bulkheads have 90% AX resist, but it'd be nice to confirm or refute that based on your results.
 
Two trials yielded 2.18, and one trial yielded 2.19, but as you pointed out that falls within the experimental errors. These AMCs deal 100% kinetic damage with basic ammo, but then switch to 100% AX damage when you load the "standard" ammo that configures it to AX damage.

Some of us are not too happy with the fact that you have to grind for mats to switch the weapon to AX damage. They require Tech Components, which take a while to get.

I'll be doing shield and bulkhead tests tomorrow =)
 
Alright, here are the results fresh off the laboratory:

Human Shield AX Resistance: 95%
Human Hull AX Resistance: 90%

It's nice to see the numbers coincide with your previous estimates. It's interesting that shields and hull have different AX resistances.

I'll publish these results next week. I also plan to publish my measurements of Interceptor hull and armor ratings.
 
@taleden

So here's the formal analysis of the AMC AX damage properties, enjoy!
 
Status
Thread Closed: Not open for further replies.
Top Bottom