Not a member yet? Why not Sign up today
Create an account  

Thread Rating:
  • 2 Vote(s) - 5 Average
  • 1
  • 2
  • 3
  • 4
  • 5
2020-01-10 Spacecraft Damage and Modules, Organ Models

#21
(01-10-2020, 10:54 PM)Haxus Wrote: XML export restored to starmap.

Awesome!

I Better go update HazeronProspector tomorrow then. ^^
Hazeron Forum and Wiki Moderator
hazeron.com/wiki/User:Deantwo
Reply

#22
Quote:I'll get to updating my designs to use the new system.

If you end up republishing designs, take note that all the user interfaces involved now support multiple select. If you refinalize a bunch of designs, the republishing part is a snap.
Reply

#23
(01-10-2020, 10:54 PM)Haxus Wrote: XML export restored to starmap.
This kindness will be remembered.
Reply

#24
Ahh, finally clubbed the Windows 32 bit build back into submission. It was the strangest thing. One of the resource libraries got too big because I added the vulcium power armor model to it. The strange part was that I had to break it up into three libraries before any of them would build again.

I have run into this problem before, when compiling Qt resources in Windows. The compiler fails, claiming to be out of heap space. However, there are plenty of other libraries 3x the size of each of these three libraries that build just fine so I am convinced it isn't strictly a memory issue. Also, sometimes the heap space error seems to be influenced by what is built immediately prior to the bad library. :/

Luckily it was finally happy. Each of those libraries now contains only one model of power armor and its texture file. I suppose I could have split those into their own separate libraries if it still didn't like it.

Some day I won't be able to keep this one working. Whenever I test it on my Windows box, I am amazed at how well it runs, considering that computer has only two cpu cores.
Reply

#25
(01-10-2020, 05:35 PM)Haxus Wrote: Spacecraft Modules
...

One consequence of this change is that building spacecraft off the exchange is a lot harder.

For example if you get a spacecraft blueprint off the exchange that can handle warp9, but at the time of publishing the architect only had warp3 reseached. Once you have warp9 and buy the blueprint, you need to manufacture a bunch of warp3 modules in order to construct the spacecraft, and then you need an equal amount of warp9 modules to upgrade the ship to warp9 after constructing it.

I think the best solution to this would be to totally alter the way to manufacture spacecraft. Let us choose which modules to install in the ship when setting up the manufacturing order. It would be even better if construction of a spacecraft was more similar to building construction (labor, not placement), so that you can apply labor to the manufacturing process while not all materials are added to the process yet. Could even be constructed in sections, each module section at a time so the quality is different between spacecraft subsystems.
Hazeron Forum and Wiki Moderator
hazeron.com/wiki/User:Deantwo
Reply

#26
Very nice and neat changes, I am excited to see how it progresses.

(01-10-2020, 10:54 PM)Haxus Wrote: XML export restored to starmap.

This makes me very happy! Glad to see :)

(01-11-2020, 12:31 AM)Deantwo Wrote:
(01-10-2020, 05:35 PM)Haxus Wrote: Spacecraft Modules
...

One consequence of this change is that building spacecraft off the exchange is a lot harder.

For example if you get a spacecraft blueprint off the exchange that can handle warp9, but at the time of publishing the architect only had warp3 reseached. Once you have warp9 and buy the blueprint, you need to manufacture a bunch of warp3 modules in order to construct the spacecraft, and then you need an equal amount of warp9 modules to upgrade the ship to warp9 after constructing it.

I think the best solution to this would be to totally alter the way to manufacture spacecraft. Let us choose which modules to install in the ship when setting up the manufacturing order. It would be even better if construction of a spacecraft was more similar to building construction (labor, not placement), so that you can apply labor to the manufacturing process while not all materials are added to the process yet. Could even be constructed in sections, each module section at a time so the quality is different between spacecraft subsystems.

What if blueprints actually became more like actual blueprints, and the module assignment occurred during the construction stage? So when designing, you don't actually select modules (or you can select the 'default modules' for convenience) but it doesn't lock those choices in. Then when you bring it to the factory, you get a window with all of the systems and then you can choose what type they are.
So to walk through that process, designing a ship:
Architect indicates the design will have 2 FTL drives, they select the defaults as a Warp 9 and a PNN Wormhole. The design additionally has a shield system that they indicate would default to energy shields.

Player buys blueprint and runs it to the shipyard, the shipyard building now asks them to confirm the module choices:
The player doesn't have Warp 9, so they change that drive to instead be Warp 3. They keep the PNN wormhole drive. The player decides they actually want kinetic shields, so they change it to a kinetic shield. They then pay and the ship construction starts.

It uses the blueprint, but the design is actually a blueprint and the shipyard can change modules types, but it never adds or removes actual systems, only the types!
Reply

#27
(01-11-2020, 02:43 AM)martianant Wrote: Very nice and neat changes, I am excited to see how it progresses.

(01-10-2020, 10:54 PM)Haxus Wrote: XML export restored to starmap.

This makes me very happy! Glad to see :)

(01-11-2020, 12:31 AM)Deantwo Wrote:
(01-10-2020, 05:35 PM)Haxus Wrote: Spacecraft Modules
...

One consequence of this change is that building spacecraft off the exchange is a lot harder.

For example if you get a spacecraft blueprint off the exchange that can handle warp9, but at the time of publishing the architect only had warp3 reseached. Once you have warp9 and buy the blueprint, you need to manufacture a bunch of warp3 modules in order to construct the spacecraft, and then you need an equal amount of warp9 modules to upgrade the ship to warp9 after constructing it.

I think the best solution to this would be to totally alter the way to manufacture spacecraft. Let us choose which modules to install in the ship when setting up the manufacturing order. It would be even better if construction of a spacecraft was more similar to building construction (labor, not placement), so that you can apply labor to the manufacturing process while not all materials are added to the process yet. Could even be constructed in sections, each module section at a time so the quality is different between spacecraft subsystems.

What if blueprints actually became more like actual blueprints, and the module assignment occurred during the construction stage? So when designing, you don't actually select modules (or you can select the 'default modules' for convenience) but it doesn't lock those choices in. Then when you bring it to the factory, you get a window with all of the systems and then you can choose what type they are.
So to walk through that process, designing a ship:
Architect indicates the design will have 2 FTL drives, they select the defaults as a Warp 9 and a PNN Wormhole. The design additionally has a shield system that they indicate would default to energy shields.

Player buys blueprint and runs it to the shipyard, the shipyard building now asks them to confirm the module choices:
The player doesn't have Warp 9, so they change that drive to instead be Warp 3. They keep the PNN wormhole drive. The player decides they actually want kinetic shields, so they change it to a kinetic shield. They then pay and the ship construction starts.

It uses the blueprint, but the design is actually a blueprint and the shipyard can change modules types, but it never adds or removes actual systems, only the types!


This here is exactly what we need.  The ability to change modules from default at manufacture would save those of us publishing designs from bloating the exchange with 3-10 versions of the same ships to make them new empire friendly.
Reply

#28
(01-11-2020, 03:27 AM)jakbruce2012 Wrote: This here is exactly what we need.  The ability to change modules from default at manufacture would save those of us publishing designs from bloating the exchange with 3-10 versions of the same ships to make them new empire friendly.
I completely agree! I had to publish two small shuttles, one to use the rocket drive and one to use the gravity drive. Felt very silly to have to do that. I just wanted to edit with why this would be powerful, it fully leverages the adaptability of the new design WITHOUT requiring flooding the exchange/servers with new designs for every iteration.

You could produce one generic warship design, and then when rolling them out change the weapons of each. Want to use one as an atmosphere collector? Just change the default energy weapons to the atmosphere collector, no need to boot into the designer and change, save, validate, publish.
Reply

#29
(01-11-2020, 02:43 AM)martianant Wrote: ...

It uses the blueprint, but the design is actually a blueprint and the shipyard can change modules types, but it never adds or removes actual systems, only the types!

Yes that is exactly what I meant.

(01-11-2020, 04:20 AM)martianant Wrote: Just change the default energy weapons to the atmosphere collector,

I still think that Harvesters and Weapons should be two separate Bays so we couldn't do this, but I guess people like this too much. I like to think of lower tech harvester bays as being an actual small hanger bay with harvester drones.
Hazeron Forum and Wiki Moderator
hazeron.com/wiki/User:Deantwo
Reply

#30
I've always liked that harvesters and weapons were interchangeable.
It makes repurposing a design quick and easy.
Reply



Forum Jump:


Users browsing this thread:
2 Guest(s)