Post by: sloanjh on November 04, 2007, 01:13:36 AM
John
Post by: Steve Walmsley on November 04, 2007, 07:41:03 AM
Steve
Post by: sloanjh on November 04, 2007, 02:03:35 PM
Here's the difficulty I'm having:
At startup, I try to fill every command slot with an officer, even if that officer isn't a good fit. In practice, this means that end up with a bunch of equivalent commands (garrison divisions for example, or ground troops to be more general), some of which have "good" officers and some of which have "warm bodies". Now lets say a few months go by, and I get a new commander that's suited for one of these commands (ground combat +10%, for example). What I'd like to do is go through each of the garrison units in "potential assignments" and quickly see the commander and his statistics, so that I know which ones are warm bodies and therefore up for replacement.
I realize that this is what the "commands" mode is supposed to support, but I'm not having a lot of luck with it - mainly because the sorting results in the commands being a lot more jumbled than on the main screen.
[EDIT] - I think a checkbox that would ignore the currently selected officer and instead drive the "Additional Details" and "Ratings and Bonuses" at the top off of the commander of the currently selected "Potential Assignment" would do the trick. In other words, a checkbox that controls whether the (potential) new commander or the old commander of the potential assignment is displayed at the top.
John
Post by: Þórgrímr on November 04, 2007, 03:06:42 PM
Cheers,
Post by: sloanjh on November 04, 2007, 07:52:23 PM
Thanks,
John
Post by: Father Tim on November 05, 2007, 10:46:41 AM
Quote from: "sloanjh"
On the F4 screen, I'd like the statistics for the current commander to show up somewhere when I click on an occupied command (while looking for someplace to assign a new commander).
John
I'm not sure where you'd find the screen real estate for it, but I'd like to be able to do a side-by-side comparison of two commanders. Ideally, I'd be able to scroll independantly through the lists, so I could compare any two commanders and not just the currently asigned one versus potential replacements.
[quote="
Post by: Erik L on November 05, 2007, 11:30:51 AM
Quote from: "Father Tim"
Quote from: "sloanjh"Do training ships refuel automagically (either from a tanker or planet)? They should
John
Aye, I'd love it if training ops included automatic refueling orders when necessary.
Does the conditional order to refuel break into the Training Exercises?
Post by: Þórgrímr on November 05, 2007, 11:56:18 AM
Quote from: "Father Tim"
I believe all four types of (non-survey) sensors are non-combat systems if they're small enough. One hull space or less.
Nope, put any type of sensor on them and they immediately lose their non-combatant status.
Cheers,
Post by: Laurence on November 06, 2007, 03:41:08 PM
Post by: sloanjh on November 06, 2007, 07:04:38 PM
Post by: Steve Walmsley on November 08, 2007, 08:20:26 AM
Post by: Steve Walmsley on November 08, 2007, 08:22:31 AM
Post by: Steve Walmsley on November 08, 2007, 08:33:16 AM
Quote from: "sloanjh"
Do training ships refuel automagically (either from a tanker or planet)? They should :-) ). What I would like to have happen (at least) is that when they notice that they're beginning to run low on fuel (50%?) they head home and refuel. I suppose this could be handled through conditional orders if there were a fuel level higher than 20%, although I'm not sure if conditionals are checked during training. It might be easier just to send them for a tank-up if they're low on fuel in training mode. I don't think you'd have to worry about what-if cases for fuel shortage, since they're unlikely to be training if fuel is in short supply.
As an easy short-term measure I have added a line of code to the training cycle so that task groups on training will automatically refuel from any tankers in the task group during each 5-day increment. BTW, if you can afford fuel for FAC training, you are in a better situation than me at the moment
Hmm! As well as the FAC-AEW variant, I guess you could create the FAC-Tanker variant
Code: [Select]
Tarantul II class Fast Attack Craft 1000 tons 97 Crew 198 BP TCS 20 TH 176 EM 0
8800 km/s Armour 1 Shields 0-0 Sensors 1/0/0/0/0 Damage Control 0-0 PPV 4
Replacement Parts 1
Sorokin SC176 Magneto-Plasma Drive (1) Power 176 Efficiency 8.40 Signature 176 Armour 0 Exp 30%
Fuel Capacity 20,000 Litres Range 10.3 billion km (13 days at full power)
12cm C4 Near Ultraviolet Laser (1) Range 72,000km TS: 8800 km/s Power 4-4 RM 3 ROF 5 4 4 4 3 2 2 1 0 0 0
Kite Screech (1) Max Range: 72,000 km TS: 6400 km/s 86 72 58 44 31 17 3 0 0 0
Small Gas-Cooled Fast Reactor (1) Total Power Output 4 Armour 0 Exp 5%
Cross Dome B (1) GPS 120 Range 1.2m km Resolution 15Code: [Select]
Mainstay class Early Warning Craft 1000 tons 77 Crew 244 BP TCS 20 TH 176 EM 0
8800 km/s Armour 1 Shields 0-0 Sensors 1/0/0/0/0 Damage Control 0-0 PPV 0
Replacement Parts 1
Sorokin SC176 Magneto-Plasma Drive (1) Power 176 Efficiency 8.40 Signature 176 Armour 0 Exp 30%
Fuel Capacity 20,000 Litres Range 10.3 billion km (13 days at full power)
Vega-A Search Sensor (1) GPS 9600 Range 96.0m km Resolution 75
Cross Dome B (1) GPS 120 Range 1.2m km Resolution 15Code: [Select]
Midas class Tanker 1000 tons 78 Crew 197 BP TCS 20 TH 176 EM 0
8800 km/s Armour 1 Shields 0-0 Sensors 1/0/0/0/0 Damage Control 0-0 PPV 0
Replacement Parts 1
Sorokin SC176 Magneto-Plasma Drive (1) Power 176 Efficiency 8.40 Signature 176 Armour 0 Exp 30%
Fuel Capacity 450,000 Litres Range 231.4 billion km (304 days at full power)
This design is classed as a non-combatant for maintenance purposesSteve
Post by: Steve Walmsley on November 08, 2007, 09:01:46 AM
Code: [Select]
Konev class Pinnace 500 tons 38 Crew 96 BP TCS 10 TH 80 EM 0
8000 km/s Armour 1 Shields 0-0 Sensors 1/0/0/0/0 Damage Control 0-0 PPV 0
Replacement Parts 1
Sorokin S80 Magneto-Plasma Drive (1) Power 80 Efficiency 0.70 Signature 80 Armour 0 Exp 5%
Fuel Capacity 10,000 Litres Range 123.4 billion km (178 days at full power)
Palm Frond B Navigation Sensor (1) GPS 240 Range 2.4m km Resolution 15
This design is classed as a non-combatant for maintenance purposesThis could be used as a ship's boat for a large warship with a parasite hangar and could conduct negotiation missions, drop off teams, etc. It has a much greater endurance than a regular FAC.
Steve
Post by: Steve Walmsley on November 08, 2007, 09:11:33 AM
Quote from: "sloanjh"
On the F4 screen, I'd like the statistics for the current commander to show up somewhere when I click on an occupied command (while looking for someplace to assign a new commander).
When you click on an assignment in the possible assignents list, the Officer History section just to the right is replaced with the name and rank of the current commander for that assignment plus a list of his bonuses.
Steve
Post by: Steve Walmsley on November 08, 2007, 09:17:18 AM
Quote from: "Erik Luken"
Does the conditional order to refuel break into the Training Exercises?
No, training exercises are excluded from conditional orders. In effect, once you give ships an order to go on training exercises, you have no control over them except for an order to break off. Someone suggested in a previous thread that it would be good to have training orders last for a specified amount of time and then the ships would return to normal orders, allowing for maintenance and (in this case) refuelling before starting training again. I think that is probably the way to handle it if I can figure out a straightforward way to do it.
Steve
Post by: mavikfelna on November 08, 2007, 09:26:15 AM
In my startup recently I ended up with 10 shipyards and 23 slipways, but the distribution is not to my liking and so I'd like to adjust thing, like moving slipways and removing a few yards to represent a few big yards and better respresent my class sizes and distributions.
Thanks,
--Mav
Post by: SteveAlt on November 08, 2007, 12:47:33 PM
Quote from: "Steve Walmsley"
On the subject of FACs, I also created a 500 ton pinnace using a FAC style ship but with a normal engine.
Also, how about the Light Survey Ship? There appear to be a lot more uses for the fast attack type ship than I first thought
Code: [Select]
Grisha class Gravsurvey Ship 850 tons 70 Crew 218 BP TCS 17 TH 80 EM 0
4705 km/s Armour 1 Shields 0-0 Sensors 1/0/0/1/0 Damage Control 0-0 PPV 0
Replacement Parts 2
Sorokin S80 Magneto-Plasma Drive (1) Power 80 Efficiency 0.70 Signature 80 Armour 0 Exp 5%
Fuel Capacity 40,000 Litres Range 290.4 billion km (714 days at full power)
Cross Dome B (1) GPS 120 Range 1.2m km Resolution 15
Gravitational Survey Sensors (1) 1 Survey Points Steve
Post by: sloanjh on November 08, 2007, 11:21:26 PM
Quote from: "mavikfelna"
I don't see any way in SM mode to add shipyards and slipways or adjust slipways. Or remove just slipways for that matter.
In my startup recently I ended up with 10 shipyards and 23 slipways, but the distribution is not to my liking and so I'd like to adjust thing, like moving slipways and removing a few yards to represent a few big yards and better respresent my class sizes and distributions.
Thanks,
--Mav
I had the same issue, but I think it would be REALLY yuckky for Steve to try to figure out a simple mechanism to allow adjustments (other than just direct editting in SM mode).
John
Post by: sloanjh on November 08, 2007, 11:52:04 PM
Quote from: "SteveAlt"
Quote from: "Steve Walmsley"On the subject of FACs, I also created a 500 ton pinnace using a FAC style ship but with a normal engine.Also, how about the Light Survey Ship? There appear to be a lot more uses for the fast attack type ship than I first thought :-)
Oh yeah, one more. I really like the idea of my home system's initial system defense being a squadron of fast attack craft, rather than a bunch of long-range heavy missiles. With the missiles, I was always worried that someone else could design a missile with just a bit longer range, at which point my planet would be effectively defenseless. The FAC feel like they don't have that problem (even if in reality they'll get their clocks cleaned by an invading fleet).
Thanks,
John
Post by: sloanjh on November 08, 2007, 11:54:58 PM
Quote from: "Steve Walmsley"
Quote from: "sloanjh"On the F4 screen, I'd like the statistics for the current commander to show up somewhere when I click on an occupied command (while looking for someplace to assign a new commander).When you click on an assignment in the possible assignents list, the Officer History section just to the right is replaced with the name and rank of the current commander for that assignment plus a list of his bonuses.
Is this in 2.41, or new to 2.42/2.5? I just looked for this and didn't see it, although that could just be blindness on my part
Assuming it's new - Thanks!!
John
Post by: sloanjh on November 09, 2007, 12:04:57 AM
Quote from: "Steve Walmsley"
As an easy short-term measure I have added a line of code to the training cycle so that task groups on training will automatically refuel from any tankers in the task group during each 5-day increment. BTW, if you can afford fuel for FAC training, you are in a better situation than me at the moment :-)
Exploit warning - if I drop a slow ship (e.g. a normal tanker) into an FAC squadron (TG) that's training, I think the fuel consumption per unit time will drop a lot (this actually would work with any TG, I think). I'm not sure you should plug this hole, however, since it's not obvious to me that ships in training will be darting around at flank speed all the time, and if someone is going to exploit they'll do it anyway (simply add fuel in SM mode, for example). The fix would probably be to have ships in training consume fuel as if they were at max speed, independent of the actual TG speed.
John
Post by: SteveAlt on November 09, 2007, 02:22:38 AM
Quote from: "sloanjh"
Quote from: "mavikfelna"I don't see any way in SM mode to add shipyards and slipways or adjust slipways. Or remove just slipways for that matter.I had the same issue, but I think it would be REALLY yuckky for Steve to try to figure out a simple mechanism to allow adjustments (other than just direct editting in SM mode).
In my startup recently I ended up with 10 shipyards and 23 slipways, but the distribution is not to my liking and so I'd like to adjust thing, like moving slipways and removing a few yards to represent a few big yards and better respresent my class sizes and distributions.
Yes, I need to give this some thought because it isn't straightforward.
Steve
Post by: SteveAlt on November 09, 2007, 02:23:37 AM
Quote from: "sloanjh"
Quote from: "Steve Walmsley"Is this in 2.41, or new to 2.42/2.5? I just looked for this and didn't see it, although that could just be blindness on my partQuote from: "sloanjh"On the F4 screen, I'd like the statistics for the current commander to show up somewhere when I click on an occupied command (while looking for someplace to assign a new commander).When you click on an assignment in the possible assignents list, the Officer History section just to the right is replaced with the name and rank of the current commander for that assignment plus a list of his bonuses.
It is in the next version. I have made some data changes so the next version will be v2.5
Steve
Post by: Brian Neumann on November 10, 2007, 11:08:02 AM
Also, how about breaking up the component display on the right hand side of the design view tab. Maybe having a few broad sections like weapons, power plant and engine, fire control and sensors, etc. Similiar to what you have for the other half of the page where you pick the items in the ship. It does not need to be as broken down as that is because there will be far fewer choices onboard most ships.
Brian
Post by: sloanjh on November 10, 2007, 12:44:50 PM
John
Post by: sloanjh on November 10, 2007, 03:17:57 PM
John
Post by: Kurt on November 10, 2007, 06:46:26 PM
I've been playing around with 2.4, and I've got a question/comment/request. I'd like a little more flexibility with the races/governments, but it is possible that I'm just missing things.
Mostly, I'd like to be able to create a new government, seperate of any race, then once the government is created, be able to assign an existing race to the government. This would facilitate setting up multiple governments on the same planet for the same race.
Like I said, it's possible that this can be done now and I just haven't figured it out.
Kurt
Post by: Kurt on November 11, 2007, 12:27:19 AM
Quote from: "SteveAlt"
Quote from: "sloanjh"Yes, I need to give this some thought because it isn't straightforward.Quote from: "mavikfelna"I don't see any way in SM mode to add shipyards and slipways or adjust slipways. Or remove just slipways for that matter.I had the same issue, but I think it would be REALLY yuckky for Steve to try to figure out a simple mechanism to allow adjustments (other than just direct editting in SM mode).
In my startup recently I ended up with 10 shipyards and 23 slipways, but the distribution is not to my liking and so I'd like to adjust thing, like moving slipways and removing a few yards to represent a few big yards and better respresent my class sizes and distributions.
Steve
I would third a call for something along these lines.
How about giving having the program ask the player what he wants at that point in the setup process? Aurora could generate the total construction capacity for the race, then ask the player if that is acceptable and how he wants to divide it up. The player could then create as many shipyards and slipways as he wants, as long as he stays within the maximum construction capacity determined at the start.
For example, Aurora would determine based on the population that this race should have 40,000 tons of construction capacity. The player then decides how he wants to divide that up. One shipyard with one slip that has 40,000 tons capacity, one SY with four slips with 10,000 each, or 4 SY, each with 2 slips, each with 5,000 tons capacity, whatever the player wants.
Kurt
Post by: sloanjh on November 11, 2007, 10:01:58 AM
Quote from: "Kurt"
How about giving having the program ask the player what he wants at that point in the setup process? Aurora could generate the total construction capacity for the race, then ask the player if that is acceptable and how he wants to divide it up. The player could then create as many shipyards and slipways as he wants, as long as he stays within the maximum construction capacity determined at the start.
The concern I've got with this idea is that I'm only going to know what distribution of shipyards and slipways I'm going to need after I've designed my initial classes, which means after the race has been generated. I think the easiest thing all around is to have it work (kind of) like initial tech - Aurora generates the SY/SW during setup, then there's a screen in SM mode that allows the player to rearrange the total capacity. There could be a little capacity counter that adjusts as you add or remove SY and SW. To make it even easier on himself, Steve could disallow changes to the number of SY - then the possible commands would just be the same ones he has now (add SW, add capacity, retool) plus corresponding remove commands (SW and capacity). Otherwise, I would say that the first 1000 tons of SY capacity should cost double, e.g. 2000 tons.
Note that I'm not opposed to having Aurora check with the player as Kurt suggests during startup, I just think it's going to cause me headaches that don't make sense from a gameplay point of view if the SM mode isn't available after setup.
John
Post by: sloanjh on November 11, 2007, 02:13:03 PM
If I'm interpreting the class summary page correctly, I think Grav Pulse Detection Sensors need to be a LOT more sensitive.
I've got an active sensor MR15000-R15, which the tech report page (ctrl-F7) says has detection strength 100 and a max range of 15m km. I'm at lowest sensor tech, so this thing takes up 10 HS.
I've also got a GPD10-50 sensor that takes up the same hull size (again, lowest tech), which the class summary page says has a detection range of 5m km at strength 100. It seems to me that this means that the active sensor has a range that's 3 times as big as an equivalent size passize sensor. For the same hull size (and tech level), I can make an active MR500000-R500 sensor, which has a range of 500m km - 300 times as large as the corresponding passive sensor.
[time passes]
I was going to say "I think you should crank the sensitivity of GPD up by a factor of 100" until I realized the last bit above - that would still leave passive detectors a factor of 3 shorter ranged than the longest range equivalent active sensor (and something like a factor of 2500 longer ranged than an MR200-R0.2, which seems too much). I now think that the thing to do is change the model for active sensors - I think the problem lies in the range/resolution trade-off.
This combines with something else that's been bothering me about active sensors - the fact that a high-resolution fire control for detecting missiles is blind as a bat when looking for things that are bigger than a missile. I think that the resolution idea is a really important one, I just think it needs to be modeled in a way similar to beam weapons - it's essentially exactly the same concept that you deal with through the "focal length" tech line. The idea is that an active sensors range depends on how much energy it can concentrate along a particular bearing - a more focused emitter should have a longer range. The range/size trade-off would just come from the relative cross-sections - if a missile is 100x smaller than a ship, you can only detect it at 1/100th of the range. (Note that this is using "linear physics" - the real answer for active sensors should be something like the fourth root of (1/100), i.e. about a factor of 1/3.)
So the idea is the following - introduce a new "Active Grav Sensor Focusing" tech line that behaves the same way as focal length for beam weapons - it's a straight multiplier on the range. Since the passive GPD tech is an indicator of how sensitive your receivers are, I would include that factor in the range as well. So the detection range would go something like (again, using linear physics):
Emitter strength = (Antenna size)*(Active strength tech)*(Active focusing tech)
Range = (Emitter strength)*(target size)*(GPD tech)
Note that the emitter strength is just the relative strength of a pulse hitting the target, the middle term is the amount of energy reflected from the target, and the last term is the efficiency of detecting the returned energy. This also gives one 4 knobs to twiddle when designing active sensors - 3 tech levels plus antenna size.
Passive detection range now becomes something like:
Detector strength = (Antenna size)*(GPD tech)
Range = (source emitter strength)*(fudge factor)*(detector strength)
where "fudge factor" is a fairly large factor (like maybe 1000 or 10000)intended to account for the fact that the emitted energy doesn't have to bounce off a target and return (which is why passive detection is so much longer-ranged than active). I think this is pretty much what you've already got coded up. Now that I think of it, this whole proposal is probably pretty close to what you originally had for active sensors.
From a gameplay point of view I think this has the following advantages:
- Puts the interaction between active sensors and passive detectors on a more understandable footing - passive always has a huge range advantage.
You can't squeeze more and more range out of an active sensor by going to coarser resolutions.
Eliminates the "all or nothing" effect in active sensor design - currently if I guess wrong about minimum hull size (say 50 HS when the target is actually 45 HS) then I can't see target ships that are too small at all, even if they're 100x closer.
Puts the target size/detection range back in. A particular active sensor should be able to see a bigger target from further away. Unless I misunderstand, the present system doesn't have that effect - to detect a bigger target farther away, you have to have a longer ranged sensor installed. Now that I think of it, I think this is the fundamental issue with the present system - all targets are treated the same (visible or invisible) for a given active sensor design.
Hope you like the idea,
John
PS - I realize you were tyring to model things like pulse repetition rates and emitter frequency with the current system - I just think the abstraction for them isn't working. If you're concerned about wanting to simulate the fact that there are a lot of specialized radars on a naval warship, I would say that that's already in the game with the speed/tracking range tradeoffs in fire control.
Post by: sloanjh on November 12, 2007, 11:14:14 PM
More on the subject of commanders:
I find I'm micro-managing commanders too much - every time I get a new one out of the academy with a decent bonus I'm sorting through already-occupied commands looking for someone to replace. It occurs to me that what I'd like to be able to do (most of the time) is filter on commanders who have had a full "tour of duty" in a particular command slot, and treat them as potential replacees. There several ways that I can think of that you could put this in - the bad news is that I think all of them will require adding a "date of assignment" field to the DB.
The first idea is a simple (optional) filter on the F4 screen that highlights any potential assignments whose commander has been assigned longer than X months as "unassigned" (grey). I would have said a third color, but it looks like you've only got two in the box (white and grey). :-) ) tour to an officer in his current command slot.
Thanks,
John
Post by: Erik L on November 13, 2007, 08:26:27 AM
Maybe you can add this?
Post by: Erik L on November 13, 2007, 11:36:42 AM
On the commander screen, when you select a commander, can you have it filter out commands he is not high enough (or too high) a rank for?
Post by: Erik L on November 15, 2007, 01:14:38 PM
Post by: SteveAlt on November 24, 2007, 05:29:00 AM
Steve
Post by: Kurt on November 25, 2007, 02:37:35 PM
On the shipyard screen, when assigning new build tasks on the bottom portion (construction/repair/refit), I really, really like it if Aurora didn't reset the drop down menu selections every time I assigned a task.
For example, I select refit as the task, and then select the refit from class and the new class, then select the ship name to refit. Then I hit the add task button. When I hit the new task button the refit from selection, the new class, and the ship name selections all reset to the top of the list. If there is only one class to select from this isn't a problem, but sometimes there are multiple classes to select from, and having to reset each drop down each time is annoying.
Thanks.
Kurt
Post by: Kurt on November 25, 2007, 02:52:34 PM
Kurt
Post by: Laurence on November 26, 2007, 08:55:35 AM
Post by: sloanjh on November 26, 2007, 07:36:45 PM
Quote from: "Kurt"
I've noticed that the Time and Distance field, on the Task Group screen, when set to "All orders", does not correctly calculate the time if loading or unloading is involved. It does not seem to take into account the time associated with those tasks.
Kurt
This might be part of the "quick and dirty" aspect of the original request (Steve was worried that he wouldn't be able to get it exactly right, at which point he was told "that's ok - a ballpark figure will do"). OTOH, it probably would be easy to assign the cost to be whatever it takes to fully load the freighter.
While we're on time-and-distance: it seems to count "transit" orders as taking zero time in "All orders" mode - you have to do "move to" then "transit" to get the correct time. And hyperspace legs are still broke for "All orders", although I view that as lower priority.
John
Post by: Kurt on November 26, 2007, 10:10:54 PM
I wonder if it would be a good idea to introduce some sort of installation that augments the wealth production of a population. Say, a financial center, that requires 50,000 population and produces some base amount of wealth. This would give a race that is short on wealth a way to increase its wealth production without requiring a tech increase.
Kurt
Post by: sloanjh on November 26, 2007, 10:59:26 PM
Quote from: "Kurt"
Steve -
I wonder if it would be a good idea to introduce some sort of installation that augments the wealth production of a population. Say, a financial center, that requires 50,000 population and produces some base amount of wealth. This would give a race that is short on wealth a way to increase its wealth production without requiring a tech increase.
Kurt
Seconded
John
Post by: Brian Neumann on November 28, 2007, 07:08:51 PM
Thanks
Brian
Post by: SteveAlt on November 29, 2007, 03:08:26 PM
Quote from: "Kurt"
Steve -
I wonder if it would be a good idea to introduce some sort of installation that augments the wealth production of a population. Say, a financial center, that requires 50,000 population and produces some base amount of wealth. This would give a race that is short on wealth a way to increase its wealth production without requiring a tech increase.
I need to spent some serious time going through this suggestion list and making additions but I spotted this one tonight and I have implemented it. Each "Financial Centre" costs 300 wealth, 150 Corbomite and 150 Uridium and acts as an extra one million pop for wealth generation. It requires 50,000 pop to operate. Starting wealth level is 20 per million pop so with basic tech it will take 15 years to recover the investment. After two wealth tech increases (30) it will only take 10 years to recover investment and after four wealth tech increases (45), it will only require 7 years.
Steve
Post by: SteveAlt on November 29, 2007, 03:27:05 PM
Steve
Post by: Kurt on December 01, 2007, 12:22:33 PM
In addition to being able to upgrade PDC's, I'd like to be able to put engineering spaces on my PDC's, so that they can be equipped with damage control, so that they can repair themselves.
Hmmm...this leads inevitably to the realization that currently, there is no way to repair PDC's, except for "fudging" it.
Kurt
Post by: Brian Neumann on December 03, 2007, 05:21:18 AM
The second point was that for large shipbuilding projects the retooling time should not take more than one year. If the retooling is going to take more time than this then they would start the ship while continuing to retool. I would suggest a cap of one year time and just force the expenditure of all the minerals that are needed for the full project at the end of the year for convienience sake.
Brian
Post by: SteveAlt on December 03, 2007, 05:56:13 AM
Quote from: "sloanjh"
On the F9 screen SM mode, it would be good to be able to set "Body Surveyed" at the component (start) or system body level, in addition to the system as a whole. I've got a race with a distant companion and want them to start with their own component's system surveyed but the companion not surveyed.
I have added buttons to the F9 window that allow you to set an individual system body, or all the system bodies for one star, as surveyed.
Steve
Post by: SteveAlt on December 04, 2007, 05:13:03 AM
Quote from: "mavikfelna"
I don't see any way in SM mode to add shipyards and slipways or adjust slipways. Or remove just slipways for that matter.
In my startup recently I ended up with 10 shipyards and 23 slipways, but the distribution is not to my liking and so I'd like to adjust thing, like moving slipways and removing a few yards to represent a few big yards and better respresent my class sizes and distributions.
I have added an "SM SY Mod" button to the Shipyard Complex tab. When you click it, it brings up a new area (covering the Required Materials section) that allows you to add and delete shipyards and edit the number of slipways and amount of capacity for existing shipyards. If you delete a shipyard, you will delete any associated tasks. However, for editing you will be unable to reduce the number of slipways below the number of existing tasks for the shipyard and you will unable to reduce capacity below that needed for any current tasks.
Steve
Post by: SteveAlt on December 04, 2007, 05:34:57 AM
Quote from: "sloanjh"
I've been meaning to write a philosphical post on what I like about 2.41 (it's been several releases since I've gotten a game going). One of these is that, GB engines aside, I REALLY like the flexibility associated with the "small" fuel tanks, crew quarters, and engineering systems (plus the "no bridge below 1000 tons" change). Basically, it allows much more granularity in the design of small ships, making small ships much more enjoyable to design. One example is that going 1 crew member over life support capacity (e.g. 251 crew) no longer requires a sacrifice of 50,000 units of fuel - one need only give up 10,000 units. Similarly, one can add a few extra spares (plus some fuel) if one only has a ton or two left in a design. This has resulted in a size reduction of ~20% (I think) in my standard low-cost picket ship (non-warp capable). I think these used to be 25-30 HS for me - now they're down to 20 HS (with standard engines like your pinnace or survey ship).I really enjoy reading this type of post because with bugs threads concentrating on what is wrong and suggestion threads often concentrating on what is missing, its good to see a post on what someone liked about a new release. Finding out what people like is as important to me as finding out what is wrong or missing because it tells me what I am getting right and helps me understand the type of features that people enjoy.
I have also enjoyed playing about with the new 'small ships' because they have added an entirely new element to ship design and they do feel like a different ship type between fighters and 'normal' ships.
Quote
Another thing that I really like is the new overhaul rules. I've only racked up about 6 months of game-time, but I find that I'm interspersing shorter maintainence down-times (major overhaul) much more frequently, plus I'm doing a lot less micro-management of spares (a good thing). I think the reason for this is that major overhaul time is now proportional to cruise time - previously (IIRC) it was a fixed cost no matter how long was spent between overhauls. The old way incentivized delaying overhauls as long as possible, since that drove down the overhaul/deployment time ratio. Now the overhaul/deployment time ratio is fixed, so I'm doing (short) major overhauls "after each cruise". I think this is a good thing - it seems more like real-world naval overhaul tempos, especially if you consider SLEP to the be equivalent of refitting to a new class.Yes, they do feel much more realistic and seem to fit better in the flow of the game. Definitely more enjoyable than the old rules.
Quote
I haven't used minor overhauls at all (since they don't take time off the clock, I think they actually drive up the overhaul/deployment ratio), but I don't think that's a bad thing. I think minor overhauls will be needed during a war - when you might need to "surge" your combatants at the expense of deferring major overhauls. Minor overhauls will allow one to sustain the fleet longer (albeit at greater and greater overhaul cost) without requiring a major overhaul. BTW, do major overhauls replace spares now, or do they just rewind the clock?Major overhauls do replace spares as well. I have also found myself carrying out far fewer minor overhauls because the only real disadvantage of the major overhaul is the month-long abort period. In peacetime that isn't a major factor (unless you suffer a pearl harbour type attack) but in wartime, you will often not be given a month's warning of an attack so major overhauls can be dangerous if carried out in threatened sectors. Even in 'safe' sectors, its possible than hostile raiders may be operating as Aurora's 'density' in terms of populations and ships makes it difficult to picket every jump point.
Quote
I also like the fact that maintainence is decoupled from SY - it avoids a lot of micromanagement that I don't think added to gameplay. I'm still undecided if I like the slipway changes, although it does feel more realistic in the sense that you can no longer design a new class and start building it all in one day, plus it really incentivizes series production. It's also nice to see a SY named "Electric Boat" on the screenI have got used to the new shipyards now and it would feel weird going back to the old system. Bringing a new class into service now feels like an accomplishment and requires a degree of planning. As you mention above, in the past you could develop new tech, design a class and start building it immedidately. I also find myself continuing to build classes with older technology until I have several new technologies to incorporate into a new class, which is also more realistic.
Quote
Oh yeah, one more. I really like the idea of my home system's initial system defense being a squadron of fast attack craft, rather than a bunch of long-range heavy missiles. With the missiles, I was always worried that someone else could design a missile with just a bit longer range, at which point my planet would be effectively defenseless. The FAC feel like they don't have that problem (even if in reality they'll get their clocks cleaned by an invading fleet).
Yes, the FACs do provide a very useful system defence force, especially as their maintenance requirements (in terms of the size of the maintenance facilities) are far less than larger ships, which allows you to deploy a FAC force to guard a small population when a Task Group of 'normal' ships may not have sufficient maintenance facilities to remaiin on station for long periods
Steve
Post by: SteveAlt on December 04, 2007, 05:50:01 AM
Quote from: "Brian"
How about a button on the F5 class design screen to give a ship class a new name. I quite frequently build a primary class of ship and have several varients. I would like to use the autonaming for this but currently this means that I have to completely design the ship from scratch again.
I have added an Auto Rename button that will pick a themed name for the class.
Steve
Post by: Brian Neumann on December 04, 2007, 06:18:06 AM
Quote from: "SteveAlt"
Quote from: "Brian"How about a button on the F5 class design screen to give a ship class a new name. I quite frequently build a primary class of ship and have several varients. I would like to use the autonaming for this but currently this means that I have to completely design the ship from scratch again.I have added an Auto Rename button that will pick a themed name for the class.
Steve
Thanks. I really appreciate the work you put into this. I have enjoyed playing around with it and plan on continuing.
Brian
Post by: SteveAlt on December 04, 2007, 07:49:57 AM
Quote from: "Brian"
How about breaking up the component display on the right hand side of the design view tab. Maybe having a few broad sections like weapons, power plant and engine, fire control and sensors, etc. Similiar to what you have for the other half of the page where you pick the items in the ship. It does not need to be as broken down as that is because there will be far fewer choices onboard most ships.
This was easier to accomplish than I thought it might be and it definitely improves the window. Items on the right are now split into six categories for display purposes:
1) Weapons and Fire Control (includes power plant for energy weapons and magazines for missile launchers)
2) Defences (includes ECM and Damage control)
3) Engines
4) Special Functions (terraforming, hangar bays, cryogenic transport, etc.)
5) Sensors
6) General (engineering, life support, fuel, etc.)
Here is a screenshot for the component list of a missile ship. There are no special function systems so that category does not appear.
(http://www.pentarch.org/aurorafiles/Screenshots/Components.GIF)
On a side note, looking at this made me realise the "Gunboat" systems are badly named so I have renamed them to "Small" systems for v2.5
EDIT: In case anyone prefers the older method I have added a checkbox so you can turn off the headings and the blank lines on the right. You will still get systems in the same order but they won't be grouped.
Steve
Post by: Father Tim on December 04, 2007, 08:41:37 AM
Post by: SteveAlt on December 04, 2007, 08:54:48 AM
Quote from: "sloanjh"
The ability to set a race-specific color in the "Race" column of the events window (ctrl-F3). It helps in SM mode to know where the messages are coming from.
Each race already has a colour associated with it that can be set on the F2 Race window. Therefore I have added a checkbox on the Events window allowing you to set the race column to use the race-specific colours.
Steve
Post by: SteveAlt on December 04, 2007, 09:02:04 AM
Quote from: "Father Tim"
Ooh, one quick suggestion/request I have: Could you please add a column on the F5 (Ship Design) window, Design tab, that lists the crew requirement for each system? Currently the only way to discover how much crew a (non-racial tech) system requires is to add it to the ship and watch the numbers in the 'life support required' window change.
Added for v2.5
Steve
Post by: SteveAlt on December 04, 2007, 09:28:57 AM
Quote from: "sloanjh"
Hi Steve,
If I'm interpreting the class summary page correctly, I think Grav Pulse Detection Sensors need to be a LOT more sensitive.
I've got an active sensor MR15000-R15, which the tech report page (ctrl-F7) says has detection strength 100 and a max range of 15m km. I'm at lowest sensor tech, so this thing takes up 10 HS.
I've also got a GPD10-50 sensor that takes up the same hull size (again, lowest tech), which the class summary page says has a detection range of 5m km at strength 100. It seems to me that this means that the active sensor has a range that's 3 times as big as an equivalent size passize sensor. For the same hull size (and tech level), I can make an active MR500000-R500 sensor, which has a range of 500m km - 300 times as large as the corresponding passive sensor.
I want to tackle this first and then I will respond to the rest of the post. In Aurora I want active sensors to generally outrange equal tech/size thermal and EM sensors but generally be outranged by equal tech/size GPD sensors. I think the reason you believe GPD sensors are outranged is a misunderstanding over mechanics. Active sensors have a strength and a resolution and from those two factors, the range is determined. So a strength-80 sensor with a resolution of 20 would have a range of 1600. in Aurora each unit of range is 10,000 km so the sensor has a max range of 16,000,000 km. If you double the resolution to 40, you double the sensor range to 32,000,000 km but lose the ability to detect smaller ships. You will also notice that on the ship display, each active sensor has a value called GPS. This value is equal to strength x resolution and is the base value of the sensor for purposes of detection by a GPD sensor.
So the strength-80, resolution-40 active sensor above would have a GPS of 3200. Which means the low tech GPD sensor you described above, with a detection range of 5m km for a strength 100 signal, would detect this active sensor at a range of 160,000,000 km. (which is 32x5m as the GPS is 32x stronger than 100).
This interaction is simulating that long range search sensors will be detected more easily by GPD sensors than high power but short range active sensors designed to track small objects at close range (because the strength x resolution (GPS) value for those active sensors will be much lower for the same basic strength).
Steve
Post by: SteveAlt on December 04, 2007, 10:11:19 AM
Quote from: "sloanjh"
(snipped description of new sensor model). From a gameplay point of view I think this has the following advantages:What you are describing is similar to the method I used before the current one :). The sensor designer faces a choice between detecting large objects at long range and having a high GPS or smaller objects at medium range and having a lower GPS. A sensor with a resolution of 200 isn't much good for detecting ships smaller than 10,000 tons but it is superb at giving your position away to anyone within a billion kilometers.
Quote
Eliminates the "all or nothing" effect in active sensor design - currently if I guess wrong about minimum hull size (say 50 HS when the target is actually 45 HS) then I can't see target ships that are too small at all, even if they're 100x closer.I agree that this element is unrealistic but I wanted some way to give players a decision between range and sensitivity (as in the real world). I am trying to model in a very simple way the complexities of radar systems. Perhaps one option is to add technology to give a sensor multiple modes (which has a real world equivalence) so that it alternates between 2 or more different resolutions but with some disadvantage associated with the ability (more below)
Quote
Puts the target size/detection range back in. A particular active sensor should be able to see a bigger target from further away. Unless I misunderstand, the present system doesn't have that effect - to detect a bigger target farther away, you have to have a longer ranged sensor installed. Now that I think of it, I think this is the fundamental issue with the present system - all targets are treated the same (visible or invisible) for a given active sensor design.
PS - I realize you were tyring to model things like pulse repetition rates and emitter frequency with the current system - I just think the abstraction for them isn't working. If you're concerned about wanting to simulate the fact that there are a lot of specialized radars on a naval warship, I would say that that's already in the game with the speed/tracking range tradeoffs in fire control.
Simulating the fact that there are a lot of specialized radars on a naval warship is a major part of the sensor changes. The fire control radar partly helps with that but not completely. Take the Kirov in the nineties for example
She has Top Pair and Top Steer 3D radars, which are used to provide bearing, range and height data on a number of targets, two Top Dome radars, which provide specific fire control for the SA-N-6 SAM, two Pop Group radars for the SA-N-9 SAMs, two Eye Bowl radars for the SS-N-14 anti-sub weapons, one Kite Screech radars for the 130mm guns, four Bass Tilt radars for the point defence (AK-630s) and three Palm Frond navigation radars. The only thing that doesn't have a specific radar system is the Shipwreck anti-ship missiles. There are also 20+ EW systems as well. I obviously don't want to get into that level of detail, but I want to reflect specialization rather than simply applying more strength to a radar and getting better at everything.
Going back to the idea of multiple modes. How about an active sensor that has one or more alternative modes which are less effective. For example, a sensor with a strength of 50 and a resolution of 40 would have a secondary antenna with a strength of 25 and a resolution of 20 (although that might be over-generous). This would automatically function when the system was activated. This provides a shorter range ability against smaller targets. In fact, this secondary (and perhaps even tertiary) ability could be another tech line and form part of active sensor design. For example, the baseline might be a secondary function with 10% strength and 80% resolution. The next step would be a secondary function with 15% strength and 75% resolution, etc.
I really want to avoid a straightforward more strength = more range vs all sizes of target (which is the case even if we use active focusing as a second type of "strength"). In the real world, radars are specialised for different tasks and I want to reflect that within Aurora.
Steve
Post by: SteveAlt on December 04, 2007, 11:50:54 AM
Quote from: "Erik Luken"
I was writing up a new player guide for 2.41, and during the race creation when it asked for jump point survey, I thought, "Why doesn't it ask for planetary survey too?"
Maybe you can add this?
Added for v2.5
Steve
Post by: SteveAlt on December 04, 2007, 01:14:04 PM
Quote from: "Erik Luken"
On the commander screen, when you select a commander, can you have it filter out commands he is not high enough (or too high) a rank for?
I have added an "Eligible Only" checkbox to the Potential Assignments section
Steve
Post by: SteveAlt on December 04, 2007, 01:49:16 PM
Quote from: "sloanjh"
Hi Steve,
More on the subject of commanders:
I find I'm micro-managing commanders too much - every time I get a new one out of the academy with a decent bonus I'm sorting through already-occupied commands looking for someone to replace. It occurs to me that what I'd like to be able to do (most of the time) is filter on commanders who have had a full "tour of duty" in a particular command slot, and treat them as potential replacees. There several ways that I can think of that you could put this in - the bad news is that I think all of them will require adding a "date of assignment" field to the DB.
The first idea is a simple (optional) filter on the F4 screen that highlights any potential assignments whose commander has been assigned longer than X months as "unassigned" (grey). I would have said a third color, but it looks like you've only got two in the box (white and grey). :-) This lets you go through unassigned officers with high modifiers and decide who best to replace.
A complementary idea would be to allow the player (not SM) to set a tour length in the racial characteristics screen and then (optionally) send an event in the update cycle where a commander's time in command crosses the threshold. (Update cycle to avoid generating a ton of event interrupts.) This lets you notice that you've got an underperformer in a particular command slot, and allows you to replace him or her with a better officer from the pool. The problem with this one is that it will tend to generate an event per command slot per tour length, which could end up being hundreds of events per year.
In either case, you would probably also want to have a "Kirk button" - some way of giving a second (or third, or fourth, or ... :-) ) tour to an officer in his current command slot.
I also find myself having to micromanage officers so I have been thinking about various ways to handle your suggestion, especially as it overlaps a slightly different idea I have been considering, which is having Aurora handle most command assignments automatically. Your idea of a "tour" would help that idea because I was wondering how to handle in-post officers. Perhaps Aurora could regularly look at unemployed officers and try to assign them to either vacant command slots or those occupied by officers who have completed their "tour". Any officers who had to leave their command to make way for someone else would be handled in the next round (5 days later) of command assignments, or perhaps later in the same round (see below). The way I was considering handling this would be as follows:
1) Officers could be flagged as manually assigned, so Aurora would ignore them for automatic assignment (this covers the Kirk situation and a few others)
2) All ship classes would be ranked, probably by Rank Required then PPV, then cost.
3) Fighter Squadrons would be ranked by Rank Required and Fighter Cost
4) Ground Units would be ranked by Type: Heavy Assualt, Light Assault, etc.
5) Aurora would then follow a step by step process of assignment, looking at different assignments and finding commanders to fit them
One possible ordering would be:
1) For each vacant command slot (including those with an incumbent who has finished his tour) for a ship of R3 or above, a list of commanders with sufficient rank and a crew training above zero would be created in descending order of training rating. Assuming the highest available had a training rating equal to or higher than the existing commander, he would be given the assignment. Although perhaps that restriction shouldn't exist or some commanders might never move to a larger ship. As someone left a command slot, they could be included in the list of possible commanders for the next command slot (or more likely they should be excluded until the next round in 5 days in case they had been recently promoted and would be eligible to command a larger ship, which they couldn't do in the current assignment round because larger ships would have already been checked.)
2) Next the R3 fighter squadron commands would be handled the same way
3) Now the R2 ships
4) R2 Fighter Squadrons
5) Survey Ships, except this time the sort order is based on Survey Skill, followed by Crew Training
5) HQs for commanders with Ground Unit Training
6) Ground Units for commanders with Ground Combat
7) The various specialities (Terraforming, etc.)
8) R1 ships.
This wouldn't handle colonies, which have specialised requirements, or sectors. However, if you move someone into that type of command, Aurora would then find someone to fill their old job during the next round of assignments. That is a rough outline but how does that sound?
Steve
Post by: SteveAlt on December 04, 2007, 01:56:00 PM
Quote from: "SteveAlt"
For each vacant command slot (including those with an incumbent who has finished his tour) for a ship of R3 or above, a list of commanders with sufficient rank and a crew training above zero would be created in descending order of training rating. Assuming the highest available had a training rating equal to or higher than the existing commander, he would be given the assignment. Although perhaps that restriction shouldn't exist or some commanders might never move to a larger ship. As someone left a command slot, they could be included in the list of possible commanders for the next command slot (or more likely they should be excluded until the next round in 5 days in case they had been recently promoted and would be eligible to command a larger ship, which they couldn't do in the current assignment round because larger ships would have already been checked.)
Rereading this, I realised I am over complicating the above. Far easier to handle is that once an officer completes a tour, they would automatically be unassigned and go into the pool for the next round of assignments. In that way, I don't have to worry about replacing in-post officers, checking ratings against incumbents or promotion to larger classes. That would all happen by itself using the automatic assignment system.
Steve
Post by: SteveAlt on December 04, 2007, 01:58:15 PM
Quote from: "Erik Luken"
Standardize the names of Compact ECCM and ECM. One is called Compact, the other is (c).
Done. They are now Compact ECM and Compact ECCM.
Steve
Post by: Erik L on December 04, 2007, 01:59:11 PM
Or maybe (and this would add a crapload of complexity), a Marine officer pool. Marine officers would be eligible only for ground/fighter commands (and governorships/sector commands). Naval officers would be eligible only for ship commands and governorships/sector commands. Of course, one would need a Marine Training Academy too
Post by: SteveAlt on December 04, 2007, 01:59:35 PM
Quote from: "Brian"
Could we have some way of scrapping shipyards. Even if it is just a button to delete them when in SM mode it would be usefull. I like to set up scenarios with specific restrictions on different races. One restriction can be a lack of shipyards.
I have added some new SM mods for shipyards for v2.5, including deleting them.
Steve
Post by: Erik L on December 04, 2007, 02:08:28 PM
Quote from: "SteveAlt"
Quote from: "SteveAlt"For each vacant command slot (including those with an incumbent who has finished his tour) for a ship of R3 or above, a list of commanders with sufficient rank and a crew training above zero would be created in descending order of training rating. Assuming the highest available had a training rating equal to or higher than the existing commander, he would be given the assignment. Although perhaps that restriction shouldn't exist or some commanders might never move to a larger ship. As someone left a command slot, they could be included in the list of possible commanders for the next command slot (or more likely they should be excluded until the next round in 5 days in case they had been recently promoted and would be eligible to command a larger ship, which they couldn't do in the current assignment round because larger ships would have already been checked.)Rereading this, I realised I am over complicating the above. Far easier to handle is that once an officer completes a tour, they would automatically be unassigned and go into the pool for the next round of assignments. In that way, I don't have to worry about replacing in-post officers, checking ratings against incumbents or promotion to larger classes. That would all happen by itself using the automatic assignment system.
Steve
I hope tour length would be configurable. And it most likely should only occur if a ship is docked. Wouldn't be good to remove the captain of a ship that's just about to assault the fleet of the Evil Aliens.
Post by: SteveAlt on December 04, 2007, 02:09:05 PM
Quote from: "Erik Luken"
Or maybe (and this would add a crapload of complexity), a Marine officer pool. Marine officers would be eligible only for ground/fighter commands (and governorships/sector commands). Naval officers would be eligible only for ship commands and governorships/sector commands. Of course, one would need a Marine Training Academy too
There might be a way to handle this without the extra complexity of separate officer corps. Its a little bit of a fudge (well, a lot actually) but I'll make the suggestion anyway.
All officers remain in one pool and get trained by the Naval Academy. If they have a ground combat rating, they are classed as Marines and get a Marine rank (one major pain would be defining all the Marine Rank structures for every theme). You could filter Marines and non-Marines on the officer window, seeing just Naval Officers (using naval ranks), just marines (using marine ranks) or combined (using naval ranks). They would still have their correct rank shown as part of their name in all views. Marines would only be eligible in the areas you mentioned above and naval officers could not command ground units. This would fit in easily with the automated assignments I suggested in another post.
There would only be one overall command structure though and marines and naval officers would effectively compete against each other for promotion. It depends whether you just think it would be cool to see Colonel O'Neill commanding a Division or a Fighter Squadron (which the above would allow) or you want to see an entirely separate military structure, which is far, far more complex.
Steve
Post by: SteveAlt on December 04, 2007, 02:10:32 PM
Quote from: "Erik Luken"
I hope tour length would be configurable. And it most likely should only occur if a ship is docked. Wouldn't be good to remove the captain of a ship that's just about to assault the fleet of the Evil Aliens.
Tour length would be configurable and that is a good idea about only relieving commanders while in dock. I should also mention this whole idea only works if you are using the "Assign Anywhere" option for commanders.
Steve
Post by: SteveAlt on December 04, 2007, 02:20:48 PM
Quote from: "Erik Luken"
One thing I'd like to see (and this may or may not happen depending on how you did it), would be configurable ranks for ground/fighter units.
Its possible. I assume you mean ground units by type and I guess fighters by individual squadron?
Steve
Post by: Erik L on December 04, 2007, 02:22:58 PM
Quote from: "SteveAlt"
Quote from: "Erik Luken"One thing I'd like to see (and this may or may not happen depending on how you did it), would be configurable ranks for ground/fighter units.Its possible. I assume you mean ground units by type and I guess fighters by individual squadron?
Steve
Well... Most ground units I build get R3 ranks... I'd like to reserve R3/R4 for HQ, then move the rest down. Similar for fighter squads. Maybe R2 for them.
Post by: SteveAlt on December 04, 2007, 03:19:26 PM
Quote from: "Erik Luken"
Well... Most ground units I build get R3 ranks... I'd like to reserve R3/R4 for HQ, then move the rest down. Similar for fighter squads. Maybe R2 for them.
At the moment, fighter squadrons of 18 fighters or less are R2 and squadrons with 19 or more fighters are R3. It's probably easiest just to make all fighter squadrons R2 anyway, regardless of the number of fighters. I'll do that for v2.5.
As far as ground units go, HQ are currently R3, Heavy Assault and Assault Infantry are R2, Mobile Infantry, Garrison and Engineer are R1. I have changed them within the last few weeks so if you are seeing a lot of R3 ground units in version 2.41, I must have changed them since that was released.
Steve
Post by: Erik L on December 04, 2007, 03:40:51 PM
Quote from: "SteveAlt"
Quote from: "Erik Luken"Well... Most ground units I build get R3 ranks... I'd like to reserve R3/R4 for HQ, then move the rest down. Similar for fighter squads. Maybe R2 for them.At the moment, fighter squadrons of 18 fighters or less are R2 and squadrons with 19 or more fighters are R3. It's probably easiest just to make all fighter squadrons R2 anyway, regardless of the number of fighters. I'll do that for v2.5.
As far as ground units go, HQ are currently R3, Heavy Assault and Assault Infantry are R2, Mobile Infantry, Garrison and Engineer are R1. I have changed them within the last few weeks so if you are seeing a lot of R3 ground units in version 2.41, I must have changed them since that was released.
Steve
I want to say the Assault units are R3 at the moment.
Post by: SteveAlt on December 04, 2007, 03:47:44 PM
Quote from: "Erik Luken"
I want to say the Assault units are R3 at the moment.
I must have modified them since v2.41 then. How do the newer rank requirements sound?
Steve
Post by: Erik L on December 04, 2007, 03:52:01 PM
Quote from: "SteveAlt"
Quote from: "Erik Luken"I want to say the Assault units are R3 at the moment.I must have modified them since v2.41 then. How do the newer rank requirements sound?
Steve
About what I was planning on doing myself
Post by: Charlie Beeler on December 04, 2007, 03:58:28 PM
Quote from: "SteveAlt"
Quote from: "Erik Luken"Well... Most ground units I build get R3 ranks... I'd like to reserve R3/R4 for HQ, then move the rest down. Similar for fighter squads. Maybe R2 for them.At the moment, fighter squadrons of 18 fighters or less are R2 and squadrons with 19 or more fighters are R3. It's probably easiest just to make all fighter squadrons R2 anyway, regardless of the number of fighters. I'll do that for v2.5.
As far as ground units go, HQ are currently R3, Heavy Assault and Assault Infantry are R2, Mobile Infantry, Garrison and Engineer are R1. I have changed them within the last few weeks so if you are seeing a lot of R3 ground units in version 2.41, I must have changed them since that was released.
Steve
I was wondering about that. I've built some light carriers that had squadrons of only 5 fighters with squadron commanders that out ranked the ships commander.
Post by: Erik L on December 04, 2007, 04:09:25 PM
On a related note. Some way to set criteria for a commendation/medal and have the program automatically award it, i.e. Stellar Explorer Medal - Survey 5 systems. SEM with Clusters - Survey 10 systems, etc.
Post by: sloanjh on December 08, 2007, 05:49:05 PM
Quote from: "SteveAlt"
Quote from: "sloanjh"Hi Steve,I want to tackle this first and then I will respond to the rest of the post. In Aurora I want active sensors to generally outrange equal tech/size thermal and EM sensors but generally be outranged by equal tech/size GPD sensors. I think the reason you believe GPD sensors are outranged is a misunderstanding over mechanics.
If I'm interpreting the class summary page correctly, I think Grav Pulse Detection Sensors need to be a LOT more sensitive.
I've got an active sensor MR15000-R15, which the tech report page (ctrl-F7) says has detection strength 100 and a max range of 15m km. I'm at lowest sensor tech, so this thing takes up 10 HS.
I've also got a GPD10-50 sensor that takes up the same hull size (again, lowest tech), which the class summary page says has a detection range of 5m km at strength 100. It seems to me that this means that the active sensor has a range that's 3 times as big as an equivalent size passize sensor. For the same hull size (and tech level), I can make an active MR500000-R500 sensor, which has a range of 500m km - 300 times as large as the corresponding passive sensor.
Nope - I was confused by names. I thought that the "detection strength" rating for an active sensor was filling the role of what you call GPS - that it was the "Strength" that is used to calculate GPD range. Since GPS is proportional to range, this gets rid of a lot of my concerns - if you double the range and halve the resolution of an active sensor (which keeps the GPS the same) the pulse is just as easily detected by a GPD.
Another naming confusion - everywhere I said "passive" in my initial post, I meant "GPD", not thermal or EM.
Thanks,
John
Post by: sloanjh on December 08, 2007, 06:34:38 PM
Quote from: "SteveAlt"
What you are describing is similar to the method I used before the current one :)QuoteSorry - my bad. By "passive" I meant "GPD" throughout the post.QuotePuts the interaction between active sensors and passive detectors on a more understandable footing - passive always has a huge range advantage.With the current system, as in the real world, GPD (Real world ESM) sensors do have a huge range advantage over active search sensors. Also, as in the real world active sensors outrange thermal sensors. EM sensors are just an Aurora-ism used vs shields. I think one point of potential confusion in that in the real world, EM sensors are used to detect radar emissions and in Aurora that role is taken by GPD sensors that are being used to detect gravitic emissions (to explain FTL sensors). One option is for me to combine EM and GPD sensors into a single system that accomplishes both tasks, which would avoid confusion and simplify things a little.QuoteQuoteYou can't squeeze more and more range out of an active sensor by going to coarser resolutions.But I want players to be able to do that :-) Just out of curiosity, does anyone know how many radars there are on an Aegis CA or DDG? I suspect there's a LOT fewer - my recollection is that the electronic steering/phased array nature of the system lets it pretend to be a whole bunch of different antena types that used to require different systems.QuoteGoing back to the idea of multiple modes. How about an active sensor that has one or more alternative modes which are less effective. For example, a sensor with a strength of 50 and a resolution of 40 would have a secondary antenna with a strength of 25 and a resolution of 20 (although that might be over-generous). This would automatically function when the system was activated. This provides a shorter range ability against smaller targets. In fact, this secondary (and perhaps even tertiary) ability could be another tech line and form part of active sensor design. For example, the baseline might be a secondary function with 10% strength and 80% resolution. The next step would be a secondary function with 15% strength and 75% resolution, etc.
I really want to avoid a straightforward more strength = more range vs all sizes of target (which is the case even if we use active focusing as a second type of "strength"). In the real world, radars are specialised for different tasks and I want to reflect that within Aurora.
Steve
That would help - thanks. I think I'm pushing the line "Aegis-like systems (phased array) are a lot more tunable (multi-mode) than those with mechanical antennae, plus we've already got complexity in fire control."
I realize I'm probably not going to convince you on this, which is ok
One side note - you could still have GPD tech help improve active range if you wanted to (simulating more sensitive detectors). I think I confused you by saying "passive" rather than GPD in my discussion.
Thanks,
John
PS - Thanks for spending time on the detailed reply.
Post by: sloanjh on December 08, 2007, 06:53:37 PM
Post by: sloanjh on December 09, 2007, 04:54:39 PM
John
Post by: Brian Neumann on December 16, 2007, 09:00:50 AM
Brian
Post by: SteveAlt on December 28, 2007, 07:29:05 AM
Quote from: "sloanjh"
It would be nice to have a query for all known alien ruins/installations. Maybe through the "potential colony sites" screen?
There is a list of known ruins on the display2 tab of the system map
Steve
Post by: SteveAlt on December 28, 2007, 07:37:05 AM
Quote from: "Kurt"
Steve -
I've been playing around with 2.4, and I've got a question/comment/request. I'd like a little more flexibility with the races/governments, but it is possible that I'm just missing things.
Mostly, I'd like to be able to create a new government, seperate of any race, then once the government is created, be able to assign an existing race to the government. This would facilitate setting up multiple governments on the same planet for the same race.
Like I said, it's possible that this can be done now and I just haven't figured it out.
I have added an extra step to the manual race creation process so you can select an existing species for the new Empire or generate a new species based on the environment of the selected planet.
Steve
Post by: Kurt on January 10, 2008, 11:47:03 AM
I'm at work, so forgive me if the things I'm suggesting are already available in 2.41.
I've had a nifty idea for a new campaign. I probably won't use it for a while, particularly if I can get the Quad-System campaign back up after 2.5 comes out, but I like it enough that I'll let it percholate around in my head to develop for a while.
The thing is, multi-system NPR's would be necessary for this new campaign. Therefore, I'd need the following:
1. Some way to link systems together via their warp points. IIRC, SA already has something like this for linking warp points in two different systems, and will also allow you to either delete warp points or create them, which would be nice too.
2. Some way to grant survey data to a race, both geo and gravitic. This could either be done on the system view, where you could give this information to the race viewing the system, or could be done during race creation, for whatever race is active at the time. I'd really like something that would let me do this at any time, not just during system creation.
As far as I can see, these two things are the bare minimum necessary for the creation of a multi-system NPR, as you would need to link systems and you'd need to have explored the systems to exploit them.
Kurt
Post by: sloanjh on January 10, 2008, 09:52:56 PM
1) Allow the NPR to shift some percentage of factories from ordnance/fighters to construction
2) Put in some sort of exponential growth rate for the economy for the 10 years I "wasn't watching". I'm thinking of something like 3% or 5%, even though the actual rate of economic expansion in Aurora is a lot lower, especially at lower production techs. I'll do this by just figuring out the multiplicative factor and multiplying the various factory/mine types by that factor. I should probably do the same for population - maybe that rate (2%) should be the growth rate for the economy.
3) Give additional research, ship construction, and ground unit construction points.
I can do all of this on my own using SM mode (I think); I'm just putting it out there for people. It would be good to be able to do multi-system too, but that's a lot harder.
The other thing I've been thinking about is some sort of "war check" rules. It would be nice to be able to hit a war check button at first contact, or if negotiations are dragging on, or if the negotiation modifier goes exceptionally low.
John
Post by: Charlie Beeler on January 11, 2008, 11:31:58 AM
Quote from: "Charlie Beeler"
Quote from: "SteveAlt"Quote from: "Erik Luken"Well... Most ground units I build get R3 ranks... I'd like to reserve R3/R4 for HQ, then move the rest down. Similar for fighter squads. Maybe R2 for them.At the moment, fighter squadrons of 18 fighters or less are R2 and squadrons with 19 or more fighters are R3. It's probably easiest just to make all fighter squadrons R2 anyway, regardless of the number of fighters. I'll do that for v2.5.
As far as ground units go, HQ are currently R3, Heavy Assault and Assault Infantry are R2, Mobile Infantry, Garrison and Engineer are R1. I have changed them within the last few weeks so if you are seeing a lot of R3 ground units in version 2.41, I must have changed them since that was released.
Steve
I was wondering about that. I've built some light carriers that had squadrons of only 5 fighters with squadron commanders that out ranked the ships commander.
I've been thinking about this one some more. It would perhaps be better to allow the player to determine the rank requirements vs program hardcoding. At least I think it's hard coded since I didn't find a control on the database tables I looked related to commanders and fighters.
At least modifiable in SM mode, preferably a player/race setup control.
Post by: Brian Neumann on January 11, 2008, 12:56:56 PM
Quote from: "Kurt"
Steve -
I'm at work, so forgive me if the things I'm suggesting are already available in 2.41.
I've had a nifty idea for a new campaign. I probably won't use it for a while, particularly if I can get the Quad-System campaign back up after 2.5 comes out, but I like it enough that I'll let it percholate around in my head to develop for a while.
The thing is, multi-system NPR's would be necessary for this new campaign. Therefore, I'd need the following:
1. Some way to link systems together via their warp points. IIRC, SA already has something like this for linking warp points in two different systems, and will also allow you to either delete warp points or create them, which would be nice too.
2. Some way to grant survey data to a race, both geo and gravitic. This could either be done on the system view, where you could give this information to the race viewing the system, or could be done during race creation, for whatever race is active at the time. I'd really like something that would let me do this at any time, not just during system creation.
As far as I can see, these two things are the bare minimum necessary for the creation of a multi-system NPR, as you would need to link systems and you'd need to have explored the systems to exploit them.
Kurt
Both of these are already available. You can do a grav, or geo survey while in SM mode in the system display screen (F9) on the first tab that shows the system bodies. The warp points can be connected while in SM mode if you are in the Jump point tab.
I have set up a 25 system and 18 inhabited planet government in the past.
Brian
Post by: Steve Walmsley on January 18, 2008, 07:16:36 AM
Steve
Post by: Steve Walmsley on January 18, 2008, 03:09:51 PM
Steve
Post by: Steve Walmsley on January 21, 2008, 03:33:47 PM
Steve
Post by: Erik L on May 03, 2008, 02:08:19 AM