2.5 Suggestions

[James Patten]

What do you mean by crash in this context? Does the program crash to desktop or is it an error message? There is sometimes an error if you zoom in too far but it can be corrected by zooming out again.

It crashes to the desktop before the window appears, giving me no opportunity to zoom out.  Looks more like a Windows-style error than one of your errors.

This "crash to desktop" happens on Win98.  I just tried it on a WinXP machine, and it zoomed in much further than it did on Win98, and gave me one of your errors.

[MWadwell]

I like the concept of you just can't switch yards between projects willy-nilly, but I think the concept of tooling up is at least a little outdated.

I'm a fan of shows like Modern Marvels and Build it Bigger (which are especially cool in HD) and the new catch phrase seems to be 'Design-Build'.

The concept behind this is that the workers start building some parts of the ship before every single bolt and cable run is laidout. Assisted by 'walk through CAD' this seems to work very well.

To me the concept of tooling up appllies to large scale manufacturing in the 60's-90's where the workers would first make the rigs to make the parts to make the ship (or plane - I saw this myself at Boeing in the late 80's).

With current computer controled equipment this is less of a factor - tooling up pretty much just requires downloading the CAD file of a part into the right tool (cutter, welder etc.) and off you go.

Considering all of this I think that some first of class surcharge is appropriate but that taking about 1/2 as long as a ship takes to build to be ready to start building is excessive. (I think that if any current commercial shipyards did this they would be out of business very quickly.)

My thought would be about a 120% time for the first of any ship and maybe 105% material cost - which in aurora is significant. These could even start higher and be researched down like most everything else, call it racial Design Efficency.

This would only apply to the first one ever and others could be started as soon as the first got to 'normal time' remaining. Each shipyard could then keep a record of the procedures and could switch to another class, then switch back ad a very low (say 105% time only) or no cost.

The question of trading these between shipyards might depend on gonvermental or industrial factors, ie a comunist govt all the yards are owned by the state so transfer is automatic, while in a corporate each corp protects its own designs and govt contracts).

I want the decision to change what a shipyard builds to be a significant decision for the player. "Retooling" is the way the game represents this but it is more than changing the tools in the shipyard, it simulates the planning for the new ship class, getting the maintenance setup, training crews, etc.. Even modern Navies plan to build ships in a series of production runs. They don't tend to build one-offs, or if they do it is an expensive proposition in terms of unit cost.

Steve

The problem is, is that (at the moment) Aurora is trying to simulate both government (e.g. warship) AND civilian (freighter) construction - but they each work to a different method.

A government yard (or more accurately, a yard working on a government contract) knows that "The Plan" calls for a number of warships of the same (or similar) design to be constructed - and so it is cost effective for them to specialise their yard to build just that design. Wheras a civilian yard will often be working on a number of different designs at the same time, and so it is more cost effective of them to have the yards as "generalist" yards (e.g. able to build any civilian design).

The fact that Aurora is a 4X game (especially the last X - "eXterminate") means that the shipyards follow the "government yard" design philosophy. To me (and I accept that everyone has a different opinion) this means that Aurora doesn't handle the civilian construction side that well.....

[Steve Walmsley]

What do you mean by crash in this context? Does the program crash to desktop or is it an error message? There is sometimes an error if you zoom in too far but it can be corrected by zooming out again.

It crashes to the desktop before the window appears, giving me no opportunity to zoom out.  Looks more like a Windows-style error than one of your errors.

This "crash to desktop" happens on Win98.  I just tried it on a WinXP machine, and it zoomed in much further than it did on Win98, and gave me one of your errors.

That is weird. The zoom-in error on the WinXP machine is fixed in v2.6 but I have no idea why the Win98 machine is behaving differently and I have no Win98 machine on which to test it. Can you use the WinXp machine with the database from the Win98 machine to unzoom it so you can at least fix the crash problem?

Steve

[Steve Walmsley]

A government yard (or more accurately, a yard working on a government contract) knows that "The Plan" calls for a number of warships of the same (or similar) design to be constructed - and so it is cost effective for them to specialise their yard to build just that design. Wheras a civilian yard will often be working on a number of different designs at the same time, and so it is more cost effective of them to have the yards as "generalist" yards (e.g. able to build any civilian design).

The civilian designs have a lot more in common then military designs, which is why its is easier to build slightly different types and why you can often build more than one "civilian" type in an Aurora shipyard.

The fact that Aurora is a 4X game (especially the last X - "eXterminate") means that the shipyards follow the "government yard" design philosophy. To me (and I accept that everyone has a different opinion) this means that Aurora doesn't handle the civilian construction side that well.....

I am very happy with the current shipyard rules so I think we will just have to agree to disagree.

Steve

[vergeraiders]

It does make things less painful now that i noticed you can retool for the next build while still doing the current one

It just makes you plan ahead more rather than being a huge time waste!

Mike

[Steve Walmsley]

It does make things less painful now that i noticed you can retool for the next build while still doing the current one

It just makes you plan ahead more rather than being a huge time waste!

Yes, it is a good idea to be retooling as you build. That happens in reality (I think Kevin Stubbs pointed it out) which is why I added the ability to Aurora.

Steve

[MWadwell]

The fact that Aurora is a 4X game (especially the last X - "eXterminate") means that the shipyards follow the "government yard" design philosophy. To me (and I accept that everyone has a different opinion) this means that Aurora doesn't handle the civilian construction side that well.....

I am very happy with the current shipyard rules so I think we will just have to agree to disagree.

Steve

O.K.

One of the reasons I was pushing this though, was that you had mentioned (in the past) creating civilian infrastructure (such as civilian freighters - which would require civilian shipyards), and I was hoping to see how you would handle it (as well as changing the way non-warships were created).

Oh well, I guess that I'll have to wait until you introduce the civilian infrastructure into Aurora....  

[Randy]

A couple of other consideratons for the retool process:

1.  The current system compares the difference in cost as a percentage of the current class. This  leads to the unusual situations where you can transition from class A to class B, but not from class B to class A.

  An alternative would be to always make the comparison from the same direction. Eg always consider the difference as a fraction of the more or less expensive ship.

Class A costs 300 BP
Class B costs 375 BP

Under the current rules, you could switch from B to A without retooling (20% of 375 = 75). But you could not go from A to B (20% of 300 = 60).

If you used the lower cost class as the basis, then neither change would be allowed (75 is > 60). If you used the higher cost class then both changes would be allowed (75 is <=75).
 
 Personaaly, I'm leaning towards using the higher cost class for the comparison.

2.  When considering which classes are interchangeable, you should base it on amount of hull space changed. IE allow 20% of the hull to be changed (regardless of cost)  before a retool is required [or some other percentage].

Class A costs 500 BP; 200 spaces
Class B costs 675 BP; 210 spaces
Assume the only differences are due to new sensors being added to the class A (real expensive high tec ones...) to make class B. Net change of 10 spaces as no other systems were changed.

Using cost as a basis, you cannot switch between them.  But using size as a basis you could.

  The higher level the tech change, the more likely a cost based change will not be allowed.

3. Can we get the retooling process as an option that can be cotrolled on the game creation screen? I'm guessing some really like the process as it stands, and others really don't like it...  

[Steve Walmsley]

A couple of other consideratons for the retool process:

1.  The current system compares the difference in cost as a percentage of the current class. This  leads to the unusual situations where you can transition from class A to class B, but not from class B to class A.

  An alternative would be to always make the comparison from the same direction. Eg always consider the difference as a fraction of the more or less expensive ship.

Class A costs 300 BP
Class B costs 375 BP

Under the current rules, you could switch from B to A without retooling (20% of 375 = 75). But you could not go from A to B (20% of 300 = 60).

If you used the lower cost class as the basis, then neither change would be allowed (75 is > 60). If you used the higher cost class then both changes would be allowed (75 is <=75).
 
 Personally, I'm leaning towards using the higher cost class for the comparison.

That's not how it works. It's based on refit cost, not build cost, so just because class B costs 375 and class A costs 300, that doesn't mean you can build both in the same shipyard. The reason it works in one direction and not the other is that a shipyard setup to build a complex design can often build a simpler, much less expensive design but a shipyard setup to build a simple, cheap class cannot build an expensive complex one. In my current campaign a shipyard setup to build to 944 BP Jamestown class can also build the 367 BP Alaska class but a shipyard setup to build the Alaska cannot build the Jamestown.

2.  When considering which classes are interchangeable, you should base it on amount of hull space changed. IE allow 20% of the hull to be changed (regardless of cost)  before a retool is required [or some other percentage].

Class A costs 500 BP; 200 spaces
Class B costs 675 BP; 210 spaces
Assume the only differences are due to new sensors being added to the class A (real expensive high tec ones...) to make class B. Net change of 10 spaces as no other systems were changed.

Using cost as a basis, you cannot switch between them.  But using size as a basis you could.

  The higher level the tech change, the more likely a cost based change will not be allowed.

Relative cost or size should not be a factor. A 6000 ton destroyer is nothing like a 6000 ton colony ship even though they are the same size and perhaps have similar cost. The reason an Aurora shipyard can build a different class is based on whether they use similar components even though the build cost of the two ships might be very different (like the Jamestown/Alaska).

3. Can we get the retooling process as an option that can be cotrolled on the game creation screen? I'm guessing some really like the process as it stands, and others really don't like it...  

Its a key part of the game. There are plenty of games out there that do not require retooling but Aurora is very much about planning ahead and
I am not going to accept the idea that you can design a ship this morning and start building it this afternoon, whatever its intended purpose.

Steve

[Randy]

Steve wrote

The reason it works in one direction and not the other is that a shipyard setup to build a complex design can often build a simpler, much less expensive design but a shipyard setup to build a simple, cheap class cannot build an expensive complex one. In my current campaign a shipyard setup to build to 944 BP Jamestown class can also build the 367 BP Alaska class but a shipyard setup to build the Alaska cannot build the Jamestown.

So... you have a shipyard building Jamestown. Does it for 2 years.

  Nov 30 - finish building last current Jamestown.
  Dec 1 - you switch it to build some Alaska class ships.
Dec 2 you start retooling to build Jamestown class again. This will take eg 14 months.  

Make sense to you? Did someone send out a firing squad or something??

Thats how it works right now in Aurora...

You really need to make the switch restrictions bi-directional. If you can switch A to B, then you should also be able to switch from B to A. Anything else is just really strange...

You also need to implement some sort of memory of previous classes that a specific shipyard has been tooled up for.  Perhaps something along the lines of remembering for as long as the shidyard was tooled for that class.

Eg. Tooled to build a class for 2 years. Switches to a different class. For the next 2 years it can switch back for reduced cost and in less time. Use some sort of sliding scale so that at eg 1.8 years the retool cost is only 90% of normal.

 

Relative cost or size should not be a factor

I agree. But I think it wasn't clear what I was trying to say.

What should be a factor is the % of original systems (in terms of spaces) retained in the alternate version that impacts this option.

Building two versions of a ship with differing sensors (only) should be interchageable no matter what the cost of the two different sensors. And currently, as long as the sensors are cheap enough, this is true in Aurora.  I don't see how the cost of the sensors should determine if the classes are similar enough to allow free switching between them...

Trying to use some numbers here:
Class A is 150 spaces, has 5 spaces in sensors.
Class B is 152 spaces, has 7 in sensors. _ALL_ other components on the two classes are identical.

The sensors in B cost 30% of ship cost (yah - they are real good...). Those in A cost 5% of ship cost.  Retooling between them is not currently allowed. (refit cost of A to C is 25% ship cost)

Class C is 150 spaces. Has no sensors, adds in jump drive, removes an engine. Net cost is the same as a class A. Refit cost from A to C is 20% of A cost. Retooloing is allowed...??

A 6000 ton destroyer is nothing like a 6000 ton colony ship even though they are the same size and perhaps have similar cost.

Correct. And refitting one to the other would likely require >50% of hull contents (by size of components). Since this is over the limit of % change allowed, then there would be a retooling cost to switch. This is why you need to look at the size of the components changed between one design and the other to determine if the retooling is free or not...

  Does that make sense?

[sloanjh]

Steve wrote

The reason it works in one direction and not the other is that a shipyard setup to build a complex design can often build a simpler, much less expensive design but a shipyard setup to build a simple, cheap class cannot build an expensive complex one. In my current campaign a shipyard setup to build to 944 BP Jamestown class can also build the 367 BP Alaska class but a shipyard setup to build the Alaska cannot build the Jamestown.

So... you have a shipyard building Jamestown. Does it for 2 years.

  Nov 30 - finish building last current Jamestown.
  Dec 1 - you switch it to build some Alaska class ships.
Dec 2 you start retooling to build Jamestown class again. This will take eg 14 months.  

Make sense to you? Did someone send out a firing squad or something??

Thats how it works right now in Aurora...

Um actually it's not.

The point of the 20% (or whatever it is) cost difference is that that's the limit for building a different class without retooling.  Even though the SY is tooled for Jamestown, you can still build an Alaska.  After the Alaska is done, you can instantly start a Jamestown.  If the SY has more than one slipway, you can (I'm pretty sure) even be building Alaska and Jamestown simultaneously in series production (on different slipways).

In other words, your Dec 1 event is not "switch it to build some Alaska class ships" it's "lay down some Alaska class ships" - the tooling of the SY is unaffected.

[edit - added following]
As for the sensor example, I think you and Steve are in violent agreement  It's just that Steve is abstracting the "these two ships are almost identical comparison" to use refit cost (which is the cost of ripping out and (possibly) replacing the non-identical systems), while you're using HS.  The refit cost abstraction makes sense to me since (in Aurora) it's a direct measure of the complexity/cost of the job.  In other words, if 30% of the cost of a 200 HS ship is in 10HS of sensors, then 30% of the SY's time is spent building those sensors, even though they're only 5% of the ship's mass.

John

[Steve Walmsley]

The point of the 20% (or whatever it is) cost difference is that that's the limit for building a different class without retooling.  Even though the SY is tooled for Jamestown, you can still build an Alaska.  After the Alaska is done, you can instantly start a Jamestown.  If the SY has more than one slipway, you can (I'm pretty sure) even be building Alaska and Jamestown simultaneously in series production (on different slipways)

Yes that is exactly how it works and you can be building Alaskas and Jamestowns at the same time in different slipways of the same shipyard without retooling.

As for the sensor example, I think you and Steve are in violent agreement  It's just that Steve is abstracting the "these two ships are almost identical comparison" to use refit cost (which is the cost of ripping out and (possibly) replacing the non-identical systems), while you're using HS.  The refit cost abstraction makes sense to me since (in Aurora) it's a direct measure of the complexity/cost of the job.  In other words, if 30% of the cost of a 200 HS ship is in 10HS of sensors, then 30% of the SY's time is spent building those sensors, even though they're only 5% of the ship's mass.

Yes, I used refit cost because it provides a much better idea of the complexity involved than either HS or build cost.

Steve

[vergeraiders]

Its way to easy to mistakenly reassing a shipyard form re-tool to add slipway/increase size.

This can wipe out months of progress in a single click. Even with the warning its easy to click through the warning.

Could there be a SM function that could do a single level undo on the last shipyard task assignment?

thanks

mike

[Erik L (OP)]

Its way to easy to mistakenly reassing a shipyard form re-tool to add slipway/increase size.

This can wipe out months of progress in a single click. Even with the warning its easy to click through the warning.

Could there be a SM function that could do a single level undo on the last shipyard task assignment?

thanks

mike

There is. Click the button labeled SM and the box on the right has fields where you can change slips and tonnage.

[vergeraiders]

It doesn't help restore a retooling that was due to be finished in less than a month

And the set Start Class button is always grayed out.