Author Topic: Ship, Sensor, Missile, Turret Design: G Sheets & OpenOffice & O365 excel — v13  (Read 9588 times)

0 Members and 1 Guest are viewing this topic.

Offline skoormit

  • Commodore
  • **********
  • Posts: 773
  • Thanked: 312 times
I've tried a couple times, no good way to wedge it into excel that i've figured out, yet, lol.

Oh, it's certainly possible.
After all, every piece of custom business software merely implements a subset of the functionality of Excel.
And the ship design screen certainly acts like a piece of custom business software.
 

Offline amram (OP)

  • Lieutenant
  • *******
  • a
  • Posts: 154
  • Thanked: 79 times
Note that I said no good way, rather than just no way.  Without macros, we get one of either way too many rows, or way to many columns, way too many sheets, or all of the above.  Otherwise its too limited to be useful.

Look at how many columns there are now, and that's just deployment, range, engines, fuel, shields, and armor.

Suppose I make a new table for weaponry.  You design a weapon there, and in Fleet Comp sheet, we want to reference it.  You'd need two columns, one for quantity and one for the reference.  Two columns doesn't sound bad, but then, you aren't limited to one weapon, should the sheet?  Probably not since that would hobble its usefulness pretty badly, say we make it 5 weapons, its 10 columns now.

Repeat this for every component type, be it racial or otherwise needing at minimum two entries for item and quantity, and more if its sensible to expect multiple types.

I could compress that a bit moving to two rows per hull, so the quantities can exist in the same column, compressing it horizontally by spending vertical space.  It will still be extremely wide, there's how many separate components it would make sense to have in one ship together?

I could go vertical, it would not be as tall as it would be wide. It does make it more difficult to keep more than a couple designs on screen at once since the columns become quite wide to fit the widest entry, it just moves the overview problem.

I could take a different approach, and have a mission package sheet, whose whole point is collecting up multiple component names and quantities under a single reference, and then only have to reference a couple mission packages in Fleet Composition, that solves the UI problem....by sweeping it off to another sheet, making a UX problem, scattering stuff all over the place.

Couple that with keeping fleet Composition, but treating it less as a design page and instead as an overview of a new designs page, that keeps the overview functionality, but also expands the number of sheets to manage and switch between.

It'll certainly fit into excel, we have more than enough rows, columns and sheets, but I've yet to work out a sensible way to build it and keep it both functional, manageable, and useful, I've got a couple abortive attempts, they get out of hand pretty quickly.
 

Offline amram (OP)

  • Lieutenant
  • *******
  • a
  • Posts: 154
  • Thanked: 79 times
Finally had some time to sit down in Aurora and play a game, so I was actively using the sheet again.

Found I had horribly broken the ship engine calculation before when I added the helper cell, so it typically suggested only that you max out the engine multiplier since it was ignoring fuel due to looking at an empty cell.  Hadn't realised until I used the sheet in a game again and it gave me nonsense suggestions.

V13 changes
  • Fixed a minor formatting issue in the PD Turret Calculator when the estimated PD active Search sensor would exceed HS 50:  a value of 75.76 would end up as 575 as a consequence.  Fixed that.
  • Forgot to make the PD Turret Calculator section for determining an appropriate active sensor also use 15 tons as MCR when set for C#, fixed.
  • Stopped Missile Velocity from showing when there is negative fuel, just as range and endurance do not show in such case.
  • Found and fixed a flaw in Missile Data where the ENG/AGI calc's could end up referencing the text MR instead of a number, and become unhappy about that.
  • Stopped the boost increase/decrease indicators from seeing "" as a value that could be greater than any actual number.
  • Fixed a math error in the MSP required estimate for PD Turret Calculator, because I am a derp.
  • Added more notes to PD Turret Calculator for the results section.
  • Changed formatting to flag a failure to obtain the requested bonus, rather than max bonus.
  • Pushed some values out to helper cells in missile data, to facilitate better matching aurora's rounding of values, and so better match C#'s missile results.
  • Missile engines in c# now change step sizes as happens in C#, with 0.01 until 3.0, 0.1 from there until 10.0, 0.5 from there until 50
  • Had managed to break the engine calcs when I last altered them to use the new helper columns, a cell reference didn't adjust correctly, they were ignoring fuel quantity, fixed.

Main post updated.
« Last Edit: May 14, 2020, 10:20:23 AM by amram »