Post by: Erik L on January 24, 2008, 01:39:38 PM
Post by: Erik L on January 25, 2008, 11:22:54 AM
I.E. building new ship, 60% done. Need it NOW type of situation, use wealth to finish it off. Not cheaply enough that it's done on a regular basis, but not so expensive you'd never do it.
Or use wealth to increase the construction speed. Say a 10% increase in speed costs 10,000 wealth (or 20k/50k/etc). I'd say no more than a 50% increase could be purchased this way.
Post by: Steve Walmsley on January 26, 2008, 10:13:46 AM
Steve
Post by: Erik L on January 28, 2008, 09:50:30 AM
Couple suggestions.
1. Max rank for a design. I don't want my admirals puttering around in freighters.
2. Inclusion of staff assignments. After the auto-assigning, I need to go refill a few staff assignments.
3. Some notification of the qualification of why said officer was put into said slot.
4. Some way to lock out a slot from the auto-assigning.
Probably a couple more when I think of them
Post by: Erik L on January 28, 2008, 10:01:24 AM
Quote from: "Erik Luken"
Now that the check box is checked for auto-assigning...
Couple suggestions.
1. Max rank for a design. I don't want my admirals puttering around in freighters.
2. Inclusion of staff assignments. After the auto-assigning, I need to go refill a few staff assignments.
3. Some notification of the qualification of why said officer was put into said slot.
4. Some way to lock out a slot from the auto-assigning.
Probably a couple more when I think of them
5. In addition to #3, if the officer was previously assigned, what the assignment was. I.E. 9th Captail Jamel Hazelton has been assigned to Antietam (Fleet Move Rating 159). Previous assignment commander Airedale.
Post by: Erik L on January 28, 2008, 10:21:51 AM
Quote from: "Erik Luken"
Quote from: "Erik Luken"Now that the check box is checked for auto-assigning...
Couple suggestions.
1. Max rank for a design. I don't want my admirals puttering around in freighters.
2. Inclusion of staff assignments. After the auto-assigning, I need to go refill a few staff assignments.
3. Some notification of the qualification of why said officer was put into said slot.
4. Some way to lock out a slot from the auto-assigning.
Probably a couple more when I think of them
5. In addition to #3, if the officer was previously assigned, what the assignment was. I.E. 9th Captail Jamel Hazelton has been assigned to Antietam (Fleet Move Rating 159). Previous assignment commander Airedale.
6. A way to set tour length by assignment. I want survey ships to have a 36 month tour, while warships have an 18 month tour.
Post by: Erik L on February 01, 2008, 01:34:28 PM
Way to filter obsolete designs out of the Class droplist.
Post by: Erik L on February 01, 2008, 02:25:15 PM
Post by: Father Tim on February 02, 2008, 12:55:16 AM
Do you mean halt a current retooling operation, or soemthing else?
Post by: Erik L on February 02, 2008, 10:35:59 AM
Quote from: "Father Tim"
De-tool?
Do you mean halt a current retooling operation, or soemthing else?
I mean to remove the class completely. I.E. you bugger up and assign your only large capacity yard to a FAC or something. You then need to retool it to put in anything larger.
Post by: Erik L on February 04, 2008, 01:39:28 PM
It'd be nice to know which fleet/population made the contact from the Event message.
Post by: sloanjh on February 04, 2008, 06:55:32 PM
John
Post by: Erik L on February 04, 2008, 07:15:57 PM
Quote from: "sloanjh"
And "hailing" - being able to announce a TG to another race (so that it's "auto-detected"). It's actually hard to arrange a rendezvouz without this.
John
Hand in hand with this, have the hails be unintelligible on the race's event log unless they have established communications. (I don't know if you do this yet or not, the SDW survey ships fled before anyone made contact).
Post by: Erik L on February 05, 2008, 08:34:07 AM
Post by: Father Tim on February 05, 2008, 09:41:04 AM
Quote from: "Erik Luken"
Make the Auto-assign feature part of the game setup and make it global.
I'm not so sure about that. For a solo campaign (a la Rigellian Diary) I think I'd set the NPC races to auto-assign, but leave 'my' race under manual control. Certainly I'd like the option.
Post by: sloanjh on February 05, 2008, 09:58:18 AM
Quote from: "Erik Luken"
Quote from: "sloanjh"And "hailing" - being able to announce a TG to another race (so that it's "auto-detected"). It's actually hard to arrange a rendezvouz without this.
John
Hand in hand with this, have the hails be unintelligible on the race's event log unless they have established communications. (I don't know if you do this yet or not, the SDW survey ships fled before anyone made contact).
Ooooh - I'd just been thinking in terms of boosting the signature to a bazillion. Hadn't thought of sending actual messages (although since it's a solo game not sure this actually needs to be handled through game mechanics).
John
Post by: Erik L on February 05, 2008, 01:02:18 PM
I.E. 523rd Fregattenkapitan Alfred Fleischer has been promoted to Kapitan zur Stern.
One Thousand, Threee Hundred and Third Korvettenkapitan Matthias Knapp has developed a severe medical problem... etc.
Post by: Erik L on February 05, 2008, 06:27:30 PM
Quote from: "Father Tim"
Quote from: "Erik Luken"Make the Auto-assign feature part of the game setup and make it global.
I'm not so sure about that. For a solo campaign (a la Rigellian Diary) I think I'd set the NPC races to auto-assign, but leave 'my' race under manual control. Certainly I'd like the option.
How about if it's set/unset in the game options, that's a global toggle, but on the Commander screen you can toggle per race.
Post by: Erik L on February 05, 2008, 06:29:33 PM
Quote from: "sloanjh"
Quote from: "Erik Luken"Ooooh - I'd just been thinking in terms of boosting the signature to a bazillion. Hadn't thought of sending actual messages (although since it's a solo game not sure this actually needs to be handled through game mechanics).Quote from: "sloanjh"And "hailing" - being able to announce a TG to another race (so that it's "auto-detected"). It's actually hard to arrange a rendezvouz without this.
John
Hand in hand with this, have the hails be unintelligible on the race's event log unless they have established communications. (I don't know if you do this yet or not, the SDW survey ships fled before anyone made contact).
John
If you have a contact targeted, one of your available orders is "Send Message". This is a 255 character limit. I see it basically as "Hail Alien Vessel. This is the SDS Graf Spee." type of thing. Then for RP/story purposes, if it's programmatically munged up, you don't need to munge it yourself.
Post by: Father Tim on February 06, 2008, 06:36:24 AM
Quote from: "Erik Luken"
Quote from: "Father Tim"Quote from: "Erik Luken"Make the Auto-assign feature part of the game setup and make it global.
I'm not so sure about that. For a solo campaign (a la Rigellian Diary) I think I'd set the NPC races to auto-assign, but leave 'my' race under manual control. Certainly I'd like the option.
How about if it's set/unset in the game options, that's a global toggle, but on the Commander screen you can toggle per race.
That would be great.
Post by: Erik L on February 06, 2008, 09:32:42 AM
Post by: Erik L on February 06, 2008, 03:33:53 PM
Post by: Erik L on February 06, 2008, 03:45:03 PM
Post by: Erik L on February 11, 2008, 01:00:04 PM
Post by: Charlie Beeler on February 12, 2008, 10:17:03 AM
Additional suggestion:
Allow fighters the option to fire less than an alpha strike. (ie fighters are loaded with 4 missiles to be able to select to fire 1, 2,3, or all 4) This would allow for mixed loads on fighters.
Say you have a heavy fighter squadron of 10 fighters that each have 12 rails per fighter. Your engaging a flotilla of destroyers. An alpha strike from this squadron should be massive overkill for a single destroyer, dependent on the loadout of course. The ability to select less than an alpha would allow the option of engaging multiple targets (not in the same fire order) successively from a single loadout.
Or
You have a "multi-role" fighter that you load partially with longer ranged missiles for anti-shipping and partially with shorter ranged anti-fighter missiles. Yes, I've been able to engage fighter to fighter with missiles successfully.
Another idea I've had is for a second type of point defense that has conditional controls for fighter defense instead of missile defense.
Post by: Valhawk on February 13, 2008, 04:05:37 AM
Post by: Steve Walmsley on February 16, 2008, 05:16:13 AM
Quote from: "Charlie Beeler"
link to mechanics discussion from last year. http://aurora.pentarch.org/viewtopic.php?p=7376&highlight=#7376I have added your points from last year's post to my reply. Please check out my post on proposed new fighter rules because I think they will probably include many of your suggestions.
http://aurora.pentarch.org/viewtopic.php?t=998 (http://aurora.pentarch.org/viewtopic.php?t=998)
Quote
1) Is there a way to issue conditional combat orders? I found how to tell the task group to try to standoff at X range in the TG screen. But nothing similiar to when you reach range XX fire Z weapon. It appears to be fire or hold fire, when fire execution being dependent on whether your within weapons and fire control range and have a sensor lock.With the proposed fighter rules, you can give the same orders and conditional orders as you can for ships. I could add an open fire order to the fleet orders list that will function like any other order. The problem may be that if you have low initiative, you might move before your opponent and activate weapons then find he has moved out of range before you actually fire. Commanders with high initiative can help this but its not a sure thing. It doesn't matter with beam weapons because they won't fire if they are out of range. Missiles will fire though because they may be in flight for a minute or more and there is no way for the program to know your intent. You might be firing on a closing target or firing to keep an enemy away. The best way is to wait until after moves and then activate weapons. The F8 combat overview window has a button that will open fire with every weapon in a fleet with a single click.
Quote
In fighter construction I see that Sensors can be constructed into the fighter but appear to have no effect other than to take space. Actual function appears to be dependent on the carrier only. What have I missed?
As you noted in the original thread, fighter sensors are affected by thermal sensor technology. Under the proposed fighter rules, they would use the same sensors and same mechanics as every other ship.
Quote
3) Do fighters have the same ability to be issued a standoff range as the task group?All the above is possible with the new rules
4) It appears that fighters cannot be pre-loaded for an initial sortie. The ability to seperate arming/fueling from luanch orders would be useful and probably already there, I just haven't figured it out yet. (ie I get a sensor contact and want to ready my strike group but not launch since it could be hours before I'm in fighter range)
5) Allow fighters the option to fire less than an alpha strike. (ie fighters are loaded with 4 missiles to be able to select to fire 1, 2,3, or all 4) This would allow for mixed loads on fighters.
Say you have a heavy fighter squadron of 10 fighters that each have 12 rails per fighter. Your engaging a flotilla of destroyers. An alpha strike from this squadron should be massive overkill for a single destroyer, dependent on the loadout of course. The ability to select less than an alpha would allow the option of engaging multiple targets (not in the same fire order) successively from a single loadout.
Or
You have a "multi-role" fighter that you load partially with longer ranged missiles for anti-shipping and partially with shorter ranged anti-fighter missiles. Yes, I've been able to engage fighter to fighter with missiles successfully.
Quote
Another idea I've had is for a second type of point defense that has conditional controls for fighter defense instead of missile defense.
That's a very good idea. I'll have to look at the mechanics but it would fit in well with the proposed rules for fighters
Steve
Post by: Steve Walmsley on February 16, 2008, 05:19:22 AM
Quote from: "Erik Luken"
Similar to the Fast OOB screen where you put in suggested values. Do the same for Fighters and Ordnance.
I have added the ability to add Ordnance as part of ship creation. Ordnance can already be added to pops in SM mode on the Industrial Production tab.
If I go ahead with the new fighter rules, you will be able to add fighters in the same way as ships.
Steve
Post by: Steve Walmsley on February 16, 2008, 05:39:53 AM
Steve
Post by: Steve Walmsley on February 16, 2008, 08:19:43 AM
Quote from: "Erik Luken"
1. Max rank for a design. I don't want my admirals puttering around in freighters.Because of the way I have coded the auto-assign this is really difficult to do on a class by class basis. A much easier option would be to place a maximum overall rank on assignments.
Quote
2. Inclusion of staff assignments. After the auto-assigning, I need to go refill a few staff assignments.I am looking at this now so I'll post when I complete the work
Quote
3. Some notification of the qualification of why said officer was put into said slot.There is a notification in the officer history so I will add the same information to the event log.
Quote
4. Some way to lock out a slot from the auto-assigning.You can click the Do Not End Tour option on the officer window to prevent his current assignment being ended and auto-assigned.
Quote
5. In addition to #3, if the officer was previously assigned, what the assignment was. I.E. 9th Captail Jamel Hazelton has been assigned to Antietam (Fleet Move Rating 159). Previous assignment commander Airedale.
This isn't very easy to do because only unassigned officers are auto-assigned. When an officer completes his tour he is returned to the pool. Sometimes he will be reassigned during the same turn though. However, If you want information on a promotion, just click on the event and it will open the details for the officer concerned.
Steve
Post by: Steve Walmsley on February 16, 2008, 08:50:35 AM
Quote from: "Erik Luken"
Inclusion of staff assignments. After the auto-assigning, I need to go refill a few staff assignments.
Staff assignments are now auto-assigned in v2.6. Task Force commanders are not auto-assigned because I think that requires a player decision in the same way as planetary governors
Steve
Post by: Brian Neumann on February 17, 2008, 05:57:48 AM
Brian
Post by: Brian Neumann on February 29, 2008, 05:08:02 PM
Brian
Post by: Erik L on March 10, 2008, 08:25:10 PM
Post by: Steve Walmsley on March 11, 2008, 11:00:17 AM
Quote from: "Erik Luken"
Put the version number on the game select screen.
Done.
Steve
Post by: Steve Walmsley on March 12, 2008, 08:58:29 AM
Steve
Post by: Randy on March 12, 2008, 10:05:09 AM
Quote
I have added the option to show hostile active sensor ranges on the system map. If an active sensor is detected, EM sensors can already determine its strength and resolution. From that they can calculate the range of the sensor and display it on the map.
Which inevetibly leads to the thought of why not have a tech that alters the receiver efficiency of an active sensor? eg for power X, efficiency 1 = normal situation.
Go to efficiency level 2, detection range increased 10% for same power.
Thus both sensors would look the same to EM sensors but the effective range would differ because the receiver for the second one can detect weaker signals...
Post by: Steve Walmsley on March 13, 2008, 07:30:15 AM
Quote from: "Randy"
QuoteI have added the option to show hostile active sensor ranges on the system map. If an active sensor is detected, EM sensors can already determine its strength and resolution. From that they can calculate the range of the sensor and display it on the map.
Which inevetibly leads to the thought of why not have a tech that alters the receiver efficiency of an active sensor? eg for power X, efficiency 1 = normal situation.
Go to efficiency level 2, detection range increased 10% for same power.
Thus both sensors would look the same to EM sensors but the effective range would differ because the receiver for the second one can detect weaker signals...
That's a very interesting idea. It would make active sensors and missile fire control systems more varied. The only drawback is that the Strength x Resolution range calculation is used in a lot of places now and I would have to find and modify every case. Leave that with me for a day or two to see how difficult it will be to make the change.
Steve
Post by: Steve Walmsley on March 13, 2008, 07:32:41 AM
Steve
Post by: Steve Walmsley on March 13, 2008, 11:27:33 AM
The first one I have fixed by letting the system map remove duplicate missile salvos and replace them with a (x3), (x4), etc. on a single message. You can still see the individual salvos if required by selecting the Show Salvo Launch Platform option.
The event log is actually easier to handle. Once the missiles are fired, you can tell the fighter fleet to stop firing and the fire control messages will not longer be shown. The missiles are still guided to their target. Alternatively you can switch off the fire control event on the Events window.
Steve
Post by: Erik L on March 14, 2008, 01:47:00 AM
Post by: Haegan2005 on March 14, 2008, 07:06:59 AM
Quote from: "Erik Luken"
I suggest Steve release 2.6
Post by: Steve Walmsley on March 16, 2008, 09:00:16 AM
Quote from: "Erik Luken"
I suggest Steve release 2.6 :). On that basis, I'll probably leave the "wonders" for the next version.
Steve
Post by: James Patten on March 18, 2008, 06:31:44 AM
Post by: Kurt on March 18, 2008, 11:25:16 AM
Two things, both related to ground bases. First, is there a way to upgrade them? If not, there really needs to be a way to do that. I know this has been brought up before, but I think the only reason it hasn't been a bigger issue is because Aurora keeps changing so much that no one has had a particularly long campaign yet. I know I can't resist upgrading to the latest version.
Second, in the Twin Moons campaign a ground base on one of the home planets was destroyed in the Five Minute War, and it left wreckage that is now hanging in space, stationary in the orbit of the main planet. I think that ground bases probably shouldn't leave wreckage, or that they should remain on the planet where the base was located.
Kurt
Post by: Erik L on March 19, 2008, 02:36:55 PM
Of course, this approach would not always generate the most efficient designs, but it could ease the start of a new NPC race.
For missiles, this would be a lot more complicated. Maybe a selection for missile size, and then an automated routine to create a size xx missile. Of course, this will probably not create missiles that most of us would use.
Post by: Steve Walmsley on March 20, 2008, 09:16:30 AM
Quote from: "James Patten"
Wouldn't it make sense when refitting a ship to reset the overhaul clock? After all, while shipyard crews in there replacing engines and upgrading systems and whatnot, they should also be replacing worn widgets.
You can overhaul a ship at the same time as refitting it. Give it an overhaul order and then start the refit once the ship is in overhaul. The problem with resetting the overhaul clock due to a refit is that you can have refits that cost a lot less in time and money than an overhaul.
Steve
Post by: Steve Walmsley on March 20, 2008, 09:41:09 AM
Quote from: "Erik Luken"
How about, in line with what Truezuluwiz was saying about complexity, a button on the design screen that creates "max" tech projects. For example, a race has up to 12 cm focal length, Cap recharge 4 and UV laser. The max button would create a 12cm/R4 UV laser. The same would occur for each of the tech areas.
Of course, this approach would not always generate the most efficient designs, but it could ease the start of a new NPC race.
For missiles, this would be a lot more complicated. Maybe a selection for missile size, and then an automated routine to create a size xx missile. Of course, this will probably not create missiles that most of us would use.
I coded something like this for lasers a few months ago but never got on to any other systems. I will be adding autodesign for components and even ships at some point but given the variety in possible designs, it may be a while before it happens.
Steve
Post by: Steve Walmsley on March 20, 2008, 09:46:40 AM
Steve
Post by: James Patten on March 20, 2008, 11:03:36 AM
Post by: Steve Walmsley on March 21, 2008, 05:29:51 AM
Quote from: "James Patten"
Starfire had the "hidden" types of jump points, which could only be discovered if someone went through from the other direction. Does Aurora have the same type?
Aurora has dormant jump point, which are not quite the same as Starfire closed jump points. Dormant jump points are invisible until a ship enters them from the far side. After that they become visible to anyone who surveys the system. In Starfire, closed jump points were hidden unless you actually saw a ship transiting.
Steve
Post by: James Patten on March 21, 2008, 06:28:48 AM
Quote from: "Steve Walmsley"
Dormant jump points are invisible until a ship enters them from the far side. After that they become visible to anyone who surveys the system.
Does that mean I have to re-survey a system I've already surveyed, if one of these appears?
Post by: Steve Walmsley on March 21, 2008, 07:22:34 AM
Quote from: "James Patten"
Quote from: "Steve Walmsley"Dormant jump points are invisible until a ship enters them from the far side. After that they become visible to anyone who surveys the system.
Does that mean I have to re-survey a system I've already surveyed, if one of these appears?
If you are the one who finds it, then it will appear automatically. In v2.6, if you see another ship transit a previously unknown jump point, then that too will appear automatically. If you suspect a dormant jump point is in a system but don't know where it is, then a re-survey would find it.
Steve
Post by: Randy on March 25, 2008, 11:20:19 AM
Quote
You can overhaul a ship at the same time as refitting it. Give it an overhaul order and then start the refit once the ship is in overhaul. The problem with resetting the overhaul clock due to a refit is that you can have refits that cost a lot less in time and money than an overhaul.
How about a single command to do both? - Refit and Overhaul would be real handy at times instead of trying to remember to give both orders...
Post by: vergeraiders on March 25, 2008, 01:18:07 PM
thx
Mike
Post by: vergeraiders on March 26, 2008, 10:56:49 AM
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).
Mike
Post by: James Patten on March 26, 2008, 11:06:13 AM
Quote from: "vergeraiders"
Can the maps (system and galatic) be made to come up in window mode and remember their location and size like most of the other windows?
And in the same vein, can we have a zoom reset external to those windows? I accidentally zoomed in too far in one system and now Aurora crashes every time I try to bring up that system's map.
Post by: Steve Walmsley on March 26, 2008, 12:44:33 PM
Quote from: "Randy"
QuoteYou can overhaul a ship at the same time as refitting it. Give it an overhaul order and then start the refit once the ship is in overhaul. The problem with resetting the overhaul clock due to a refit is that you can have refits that cost a lot less in time and money than an overhaul.
How about a single command to do both? - Refit and Overhaul would be real handy at times instead of trying to remember to give both orders...
The problem is that one is a movement order and the other is a shipyard task so there is no mechanism within the code to create a joint order.
Steve
Post by: Steve Walmsley on March 26, 2008, 12:45:56 PM
Quote from: "James Patten"
Quote from: "vergeraiders"Can the maps (system and galatic) be made to come up in window mode and remember their location and size like most of the other windows?
And in the same vein, can we have a zoom reset external to those windows? I accidentally zoomed in too far in one system and now Aurora crashes every time I try to bring up that system's map.
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. In v2.6, I have changed the code so you can zoom in a lot further than before.
Steve
Post by: Steve Walmsley on March 26, 2008, 12:54:33 PM
Quote from: "vergeraiders"
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
Post by: James Patten on March 26, 2008, 01:29:20 PM
Quote from: "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.
Post by: MWadwell on March 26, 2008, 11:20:15 PM
Quote from: "Steve Walmsley"
Quote from: "vergeraiders"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 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.
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).
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.....
Post by: Steve Walmsley on March 27, 2008, 10:07:41 AM
Quote from: "James Patten"
Quote from: "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
Post by: Steve Walmsley on March 27, 2008, 10:11:51 AM
Quote from: "MWadwell"
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.
Quote
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
Post by: vergeraiders on March 27, 2008, 11:28:55 AM
It just makes you plan ahead more rather than being a huge time waste!
Mike
Post by: Steve Walmsley on March 27, 2008, 12:44:13 PM
Quote from: "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!
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
Post by: MWadwell on March 28, 2008, 07:20:53 AM
Quote from: "Steve Walmsley"
Quote from: "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....
Post by: Randy on March 28, 2008, 11:50:45 AM
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...
Post by: Steve Walmsley on March 28, 2008, 12:31:45 PM
Quote from: "Randy"
A couple of other consideratons for the retool process: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.
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.
Quote
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].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).
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.
Quote
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
Post by: Randy on March 28, 2008, 05:05:03 PM
Quote
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.
Quote
Relative cost or size should not be a factorI 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...??
Quote
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?
Post by: sloanjh on March 28, 2008, 06:25:21 PM
Quote from: "Randy"
Steve wroteQuoteThe 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
Post by: Steve Walmsley on March 28, 2008, 09:01:10 PM
Quote from: "sloanjh"
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.
Quote
As for the sensor example, I think you and Steve are in violent agreement
Yes, I used refit cost because it provides a much better idea of the complexity involved than either HS or build cost.
Steve
Post by: vergeraiders on April 01, 2008, 01:03:19 PM
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
Post by: Erik L on April 01, 2008, 03:19:09 PM
Quote from: "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
There is. Click the button labeled SM and the box on the right has fields where you can change slips and tonnage.
Post by: vergeraiders on April 01, 2008, 03:25:22 PM
And the set Start Class button is always grayed out.
Post by: MWadwell on April 01, 2008, 06:40:48 PM
We've got missiles that can mount active sensors, and so can detect their own targets or act as recon missiles. However, their endurance is limited (as in it is measured in minutes - not days or months).
What might be an idea, is that if you strip out the engines, you can put in a long-term power source (i.e. a mini reactor) used to power the bouy/mine for a LONG time.
In this manner, you can convert a recon missile to a sensor bouy, and convert a missile to a contact mine (although I would recommend leaving the ability to have a small engine and fuel supply to allow the mine to be semi-mobile - similar to a Captor mine).
Comments?
Post by: Steve Walmsley on April 03, 2008, 05:17:00 AM
Quote from: "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?
Unfortunately that's quite tricky. I will add an "Are you really, really sure?" second warning box.
Steve
Post by: Steve Walmsley on April 03, 2008, 05:21:43 AM
Quote from: "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.
The Set Start class button is enabled if you choose a shipyard that has no class set and you select the class to which you want to retool it. In v2.6, the Set Start class button is not required because if you use the set activity button for retooling on an empty shipyard, it happens instantly.
Steve
Post by: Steve Walmsley on April 03, 2008, 05:24:55 AM
Quote from: "MWadwell"
After reading Haegen's latest post (about using bouys as decoys) it got me thinking about a new technology to create mines/bouys.
We've got missiles that can mount active sensors, and so can detect their own targets or act as recon missiles. However, their endurance is limited (as in it is measured in minutes - not days or months).
What might be an idea, is that if you strip out the engines, you can put in a long-term power source (i.e. a mini reactor) used to power the bouy/mine for a LONG time.
In this manner, you can convert a recon missile to a sensor bouy, and convert a missile to a contact mine (although I would recommend leaving the ability to have a small engine and fuel supply to allow the mine to be semi-mobile - similar to a Captor mine).
That's a really good idea. I need to give some thought to how I would implement it but perhaps a reactor could use fuel at the normal rate, instead of the 10,000x rate of a missile engine. There would still be a question of the mechanics involved in terms of how the missile actually attacked the target. As you suggest, perhaps an engine that only activates once a target is detected. I'll give it some thought.
Steve
Post by: vergeraiders on April 03, 2008, 10:24:38 AM
Quote from: "Steve Walmsley"
Unfortunately that's quite tricky. I will add an "Are you really, really sure?" second warning box.
Steve
I think what i would find more useful is more info in the warning box.
Something like
"You are trying to reassign the Imperial Starworks shipyard to retool to build Imperial Class Stardestoyers. It is currently 98.5% done retooling to build Super Class Stardestroyers. Are you sure you want to continue?"
At least for me the trick is telling me the SY selected (cause it has a habit of unselecteng the 'current' one after you complete the previous operation) and letting me know the current project.
Post by: Randy on April 03, 2008, 10:43:01 AM
Quote
Unfortunately that's quite tricky. I will add an "Are you really, really sure?" second warning box.
Steve
How about adding a check box to allow/disallow early termination of retooling?
Have it by default unselected so that you can't order retooling of a SY that is currently retooling...
(You could also do somethng similar for the option to assign to a new Task force
)
Post by: vergeraiders on April 03, 2008, 01:30:28 PM
Specifically armed ships 1000 tons and under.
My 1000 ton fast attack craft with 1 10 cm laser have the same officer requirements as my 10,000 ton battleships with 3 tripple 20cm laser turrets!
Maybe a -1 (or R2 whichever is lower) minumum grade for any ship that does not require a bridge?
Post by: Steve Walmsley on April 04, 2008, 10:35:09 AM
Quote from: "vergeraiders"
Could you look at the criteria for assigning minimum officer grade to ships.
Specifically armed ships 1000 tons and under.
My 1000 ton fast attack craft with 1 10 cm laser have the same officer requirements as my 10,000 ton battleships with 3 tripple 20cm laser turrets!
Maybe a -1 (or R2 whichever is lower) minumum grade for any ship that does not require a bridge?
I'll take a look at this but in the meantime you can assign your own minimum grade for each class on the class window.
Steve
Post by: Steve Walmsley on April 04, 2008, 10:36:03 AM
Quote from: "vergeraiders"
I think what i would find more useful is more info in the warning box.
Something like
"You are trying to reassign the Imperial Starworks shipyard to retool to build Imperial Class Stardestoyers. It is currently 98.5% done retooling to build Super Class Stardestroyers. Are you sure you want to continue?"
At least for me the trick is telling me the SY selected (cause it has a habit of unselecteng the 'current' one after you complete the previous operation) and letting me know the current project.
I have changed the message as you suggested above.
Steve
Post by: Erik L on April 08, 2008, 04:48:41 PM
Post by: Randy on April 09, 2008, 08:43:47 AM
Have it by default unselected so that you can't order retooling of a SY that is currently retooling...
(You could also do something similar for the option to assign to a new Task force )
Quote
vergeraiders wrote:
I think what i would find more useful is more info in the warning box.
Something like
"You are trying to reassign the Imperial Starworks shipyard to retool to build Imperial Class Stardestoyers. It is currently 98.5% done retooling to build Super Class Stardestroyers. Are you sure you want to continue?"
At least for me the trick is telling me the SY selected (cause it has a habit of unselecteng the 'current' one after you complete the previous operation) and letting me know the current project.
Steve replied:
I have changed the message as you suggested above.
Steve
Post by: Erik L on June 04, 2008, 05:09:17 PM