Update 2017-01-17 Design Analysis

Details about updates to Shores of Hazeron

Update 2017-01-17 Design Analysis

Postby Haxus » Tue Jan 17, 2017 2:36 pm

This update is mostly just the next milestone in the new designer. I'll start with the one item that has nothing to do with the new designer.

Retail Import Radioactives
Someone made the case that retail stores should import radioactives. I don't recall the rationale. Perhaps just because it is fuel, at least for a nuclear reactor, and retail stores are supposed to import fuel. They now import radioactives.

Hydrogen Power Plant Module
The current power plant module got a slight name change. It is now a Hydrogen Power Plant Module. This is in preparation for other kinds of power plant modules, as suggested by a player.

Water Vehicle Parking Spots
Why not? You can now place them in your ship designs. It might be difficult to load/unload them without a vehicle transporter but having a submarine aboard might be handy sometimes.

Capacitor Module
New ship designs now have a capacitor module that is separate from the power plant module. The space for these is allocated separately. Capacitor size determines how much power the capacitor can hold. Power plant size determines the rate at which it can convert fuel to power. This change was also suggested by a player. This change does not affect old-style ship designs.

Sensor and Shield Systems
It was possible to place more than one shield station with different shield modules. This is ambiguous as I only intend to support one shield system and one sensor system per spacecraft. A shield or sensor station, added to a design that already has one, now gets the same module as the existing station, regardless of what you choose on the UI.

Obstruction Model
The obstruction model was buggy and took way to long to construct. In somewhat of a setback, I had to spend most of a day rewriting that code. The freighter model from Gravity Well was taking minutes to generate the model; now it's less than a second. The new model has some improvements, like it can handle holes through a hull part. As an added bonus, the resulting model is much faster at giving me the answers I need</understatement>. The cost was a little more memory, not a lot, well worth it.

A button was added to the tool bar to refresh the obstruction model. It is invalidated by most edits to the design. It must be up-to-date to bump into things or to get a design analysis report.

Hull Allocation to Systems
Design properties now has a block of slide bars to allocate hull volume to different systems. After a ship is made, the values of those sliders can be changed through a refit process. The presence or absence of a slider bar cannot be changed after a ship is made, just their hull volume allocations.

This is similar to modules, which can be changed after a ship is built, but not added or removed.

Design Analysis Report
Design properties window now shows a design analysis that will look familiar to old timers. It isn't quite done, but it's done enough for me to start making a real ship.
  • I have not checked the numbers for weapon systems and turrets.
  • Hit points and manufacturing process are not reported yet.
  • Performance results should translate closely to similar sized spacecraft from the old designer. Instead of units, things are now specified in cubic meters. Equipment units in the old designs were 256 cubic feet. That is approximately 7.25 cubic meters. The numbers are suppose to match up closely, not exactly; I went over them pretty carefully; please let me know of major discrepancies.
  • Tech level does not increase fuel or hold capacity as it does on old designs.
  • Tech Level progression is based on hull volume. It is vastly different from what it used to be. TL1 goes up to 1000 cubic meters, a fairly small ship. The maximum size at each subsequent tech level is calculated by this formula: NextMaxHull = MaxHull ^ 1.0325. This creates a nice progression up to a maximum size of 121M cubic meters at TL32. That makes an Imperial Star Destroyer a TL31 ship, at 66M cubic meters.
  • A hull that exceeds TL32 is reported as TL33, no matter how big it is. I'll change this to an error message.
Here is the table of hull size thresholds, in cubic meters, at each tech level.
    TL1 = 1,000
    TL2 = 1,251
    TL3 = 1,578
    TL4 = 2,004
    TL5 = 2,567
    TL6 = 3,313
    TL7 = 4,311
    TL8 = 5,659
    TL9 = 7,494
    TL10 = 10,015
    TL11 = 13,510
    TL12 = 18,404
    TL13 = 25,324
    TL14 = 35,209
    TL15 = 49,479
    TL16 = 70,305
    TL17 = 101,045
    TL18 = 146,948
    TL19 = 216,320
    TL20 = 322,468
    TL21 = 486,982
    TL22 = 745,346
    TL23 = 1,156,670
    TL24 = 1,820,807
    TL25 = 2,908,857
    TL26 = 4,718,386
    TL27 = 7,774,845
    TL28 = 13,020,847
    TL29 = 22,175,071
    TL30 = 38,424,270
    TL31 = 67,780,585
    TL32 = 121,791,292
A button was added to the tool bar to display the design properties window.

Hold Access
Room voids now have a hold access property, to enable access to various things in the hold. This used to be automatic, according to room type. It controls what you can access using the cargo transfer window. The choices match the categories created by the old room types.
  • Inaccessible - The default offers no access to the hold.
  • Armory - Weapons, ammo, armor.
  • Bar - Food and drinks.
  • Feeder - Food and water.
  • Fuel Coupling - Fuel in fuel cells.
  • Garage - Tools and spare parts. Possibly fuel and ammo, not sure.
  • Hold - All cargo.
  • Pantry - Food and drinks.
  • Pharmacy - Medical supplies.
  • Wardrobe - Clothing and environment suits.
User avatar
Haxus
Site Admin
 
Posts: 2709
Joined: Fri Jan 14, 2011 8:00 pm

Re: Update 2017-01-17 Design Analysis

Postby Haxus » Tue Jan 17, 2017 2:57 pm

I created a spherical hull 1,600m in diameter, the largest possible sphere within current imposed limits.

The volume was almost 2B cubic meters. A bunch of values in the design analysis rolled over to negative numbers. This could be fixed but...

I guess that's too big.

So much for the Death Star.

The sphere was created with 100 sides at the equator. Obstruction model took slightly more than a second to generate. It seemed too big. I don't feel a need to increase the limits to support that.
User avatar
Haxus
Site Admin
 
Posts: 2709
Joined: Fri Jan 14, 2011 8:00 pm

Re: Update 2017-01-17 Design Analysis

Postby Celarious » Tue Jan 17, 2017 3:00 pm

Thanks for this! Getting close to being able to properly manufacture a ship haha
Image
User avatar
Celarious
 
Posts: 407
Joined: Sat Apr 09, 2011 1:20 pm
Location: EVA

Re: Update 2017-01-17 Design Analysis

Postby Deantwo » Tue Jan 17, 2017 3:35 pm

Haxus wrote:Hydrogen Power Plant Module
as suggested by a player.

Capacitor Module
This change was also suggested by a player

Understatement much? XD
Should do a search on the forum and see how many asked for that over the years.
Also plenty requesting that same treatment for shields, but I guess that is more complicated when it comes to combat balance.

Haxus wrote:Water Vehicle Parking Spots
Why not? You can now place them in your ship designs. It might be difficult to load/unload them without a vehicle transporter but having a submarine aboard might be handy sometimes.

Nice, I like it. I guess it wouldn't be that hard if we use the vehicle launcher and vehicle retriever thingies.

Helicopter pad on top of my ship? o.o
Because: (Idea thread) Ship Water Vehicle Drydock

Haxus wrote:Sensor and Shield Systems
This is ambiguous as I only intend to support one shield system and one sensor system per spacecraft.

I was kind of thinking that multiple types of sensors could be interesting, like if surveying required a specific module type. Then having both types would be of interest.
Can always do that later I guess.
Last edited by Deantwo on Tue Jan 17, 2017 4:21 pm, edited 3 times in total.
AnrDaemon is the solution to the [s]Fermi Paradox[/s] Hazeron suggestion flood problem, the great suggestion filter.
User avatar
Deantwo
 
Posts: 4925
Joined: Fri Jan 25, 2013 4:38 am
Location: Rævehale

Re: Update 2017-01-17 Design Analysis

Postby Ikkir Isth » Tue Jan 17, 2017 3:37 pm

Do note: if the fuel container on a ship is going to be potentially more than just hydrogen... then we will need a neutral cargo hold that can hold anything (including hydrogen) with the option to load things from cargo into fuel (or buy things to fill fuel or to fill cargo).
Making things with OpenGL: Image
Working on- an exploration game.
@Ikkir_Isth
User avatar
Ikkir Isth
 
Posts: 2376
Joined: Fri Jan 14, 2011 9:22 pm

Re: Update 2017-01-17 Design Analysis

Postby Deantwo » Tue Jan 17, 2017 3:39 pm

Ikkir Isth wrote:Do note: if the fuel container on a ship is going to be potentially more than just hydrogen... then we will need a neutral cargo hold that can hold anything (including hydrogen) with the option to load things from cargo into fuel (or buy things to fill fuel or to fill cargo).

I was thinking this too yeah.

Also small problem with rocket-drives. as they consume hydrogen directly. So in that case I guess split the "fuel container" in two, allowing us to control what system gets to use the fuel.

Would also allow for other direct fuel maneuver-drive types?
Last edited by Deantwo on Tue Jan 17, 2017 3:41 pm, edited 1 time in total.
AnrDaemon is the solution to the [s]Fermi Paradox[/s] Hazeron suggestion flood problem, the great suggestion filter.
User avatar
Deantwo
 
Posts: 4925
Joined: Fri Jan 25, 2013 4:38 am
Location: Rævehale

Re: Update 2017-01-17 Design Analysis

Postby Ikkir Isth » Tue Jan 17, 2017 3:40 pm

Haxus wrote:
Sensor and Shield Systems
It was possible to place more than one shield station with different shield modules. This is ambiguous as I only intend to support one shield system and one sensor system per spacecraft. A shield or sensor station, added to a design that already has one, now gets the same module as the existing station, regardless of what you choose on the UI.


Do note: shields could also potentially benefit from the charge rate vs capacitance module idea as in capacitors (and since they are sided, such modules could also be rigged to increase specific sides only or be general units).

Sensors as they are: probably no real use, but could potentially in the future have multiple sensor types (deep scan for finding cloaked ships, system scanners, tactical scanners for focusing on equipment in combat, etc)
Making things with OpenGL: Image
Working on- an exploration game.
@Ikkir_Isth
User avatar
Ikkir Isth
 
Posts: 2376
Joined: Fri Jan 14, 2011 9:22 pm

Re: Update 2017-01-17 Design Analysis

Postby Haxus » Tue Jan 17, 2017 3:52 pm

Fuel space allocation can be changed after the ship is built. It is one of the sliders for hull volume allocation. This could be changed to accommodate different fuel requirements due to installation of a new power plant module.

Fuel is maintained separately from cargo because it must be used in fractional portions. Regular cargo does not allow for partial units.

I suppose I should have said "many players" and acknowledged every one of them but I just don't have time for that. Please accept my apologies for being so insensitive. Just know that your suggestions do not fall on deaf ears. Understand that they must wait until it is time. Not all great ideas can be implemented right away.
User avatar
Haxus
Site Admin
 
Posts: 2709
Joined: Fri Jan 14, 2011 8:00 pm

Re: Update 2017-01-17 Design Analysis

Postby Deantwo » Tue Jan 17, 2017 4:16 pm

Haxus wrote:Fuel space allocation can be changed after the ship is built. It is one of the sliders for hull volume allocation. This could be changed to accommodate different fuel requirements due to installation of a new power plant module.

Fuel is maintained separately from cargo because it must be used in fractional portions. Regular cargo does not allow for partial units.

Ah good point. But then as Ikkir said, make the fuel space and cargo totally separate, and add a way to transfer fuel from the cargo hold into the fuel space. Have it be an one-way transfer if need be, could allow for better reading of fuel quality giving different amounts of fuel.

But as I was saying, if the maneuver-drive type uses fuel directly, split the fuel space into two (equally slipt) fuel spaces and allow us to transfer into them separately.

This would also allow us to actually transport fuel in the cargo hold. ^^;

Haxus wrote:I suppose I should have said "many players" and acknowledged every one of them but I just don't have time for that. Please accept my apologies for being so insensitive. Just know that your suggestions do not fall on deaf ears. Understand that they must wait until it is time. Not all great ideas can be implemented right away.

Oh I know, I was just kidding. XD
Just the kind of weird little details that i find funny. ^^;
Last edited by Deantwo on Wed Jan 18, 2017 6:34 am, edited 1 time in total.
AnrDaemon is the solution to the [s]Fermi Paradox[/s] Hazeron suggestion flood problem, the great suggestion filter.
User avatar
Deantwo
 
Posts: 4925
Joined: Fri Jan 25, 2013 4:38 am
Location: Rævehale

Re: Update 2017-01-17 Design Analysis

Postby Phenoix12 » Tue Jan 17, 2017 6:50 pm

A few questions:

1. How do we view the collision shapes for our ships? The collision detection on the ship I've been working on is a big wonky and I'd like to actually see what the collision mapper is doing wrong.


2. Would it be possible to have more then one slot for custom textures?


3. Will the ability to export the DNA of your species from the game into the offline designer so we can walk around as our species for the purposes of checking to make sure everything is sized correctly be coming soon?



Also thanks for another great update Haxus. Keep up the good work.
User avatar
Phenoix12
 
Posts: 165
Joined: Sat Aug 27, 2016 4:28 pm

Next

Return to Updates

Who is online

Users browsing this forum: No registered users and 2 guests