Author Topic: 2.4 Suggestions  (Read 4050 times)

0 Members and 1 Guest are viewing this topic.

Offline sloanjh

  • Global Moderator
  • Admiral of the Fleet
  • *****
  • Posts: 2715
  • Thanked: 62 times
(No subject)
« Reply #30 on: November 11, 2007, 02:13:03 PM »
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.

[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.
« Last Edit: December 31, 1969, 06:00:00 PM by sloanjh »
 

Offline sloanjh

  • Global Moderator
  • Admiral of the Fleet
  • *****
  • Posts: 2715
  • Thanked: 62 times
(No subject)
« Reply #31 on: November 12, 2007, 11:14:14 PM »
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). :-) ) tour to an officer in his current command slot.

Thanks,
John
« Last Edit: December 31, 1969, 06:00:00 PM by sloanjh »
 

Offline Erik Luken

  • Administrator
  • Admiral of the Fleet
  • *****
  • Posts: 5144
  • Thanked: 114 times
  • Discord Username: icehawke
(No subject)
« Reply #32 on: November 13, 2007, 08:26:27 AM »
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? :)
« Last Edit: December 31, 1969, 06:00:00 PM by Erik Luken »
 

Offline Erik Luken

  • Administrator
  • Admiral of the Fleet
  • *****
  • Posts: 5144
  • Thanked: 114 times
  • Discord Username: icehawke
(No subject)
« Reply #33 on: November 13, 2007, 11:36:42 AM »
Steve,

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?
« Last Edit: December 31, 1969, 06:00:00 PM by Erik Luken »
 

Offline Erik Luken

  • Administrator
  • Admiral of the Fleet
  • *****
  • Posts: 5144
  • Thanked: 114 times
  • Discord Username: icehawke
(No subject)
« Reply #34 on: November 15, 2007, 01:14:38 PM »
Standardize the names of Compact ECCM and ECM. One is called Compact, the other is (c).
« Last Edit: December 31, 1969, 06:00:00 PM by Erik Luken »
 

Offline SteveAlt

  • Global Moderator
  • Rear Admiral
  • *****
  • Posts: 820
  • Thanked: 2 times
(No subject)
« Reply #35 on: November 24, 2007, 05:29:00 AM »
I have changed Parasite Hangars in v2.5 so they can added to PDCs, creating an underground sanctuary for FACs or even full size ships if necessary.

Steve
« Last Edit: December 31, 1969, 06:00:00 PM by SteveAlt »
 

Offline Kurt

  • Global Moderator
  • Rear Admiral
  • *****
  • Posts: 957
  • Thanked: 52 times
(No subject)
« Reply #36 on: November 25, 2007, 02:37:35 PM »
Steve -

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
« Last Edit: December 31, 1969, 06:00:00 PM by Kurt »
 

Offline Kurt

  • Global Moderator
  • Rear Admiral
  • *****
  • Posts: 957
  • Thanked: 52 times
(No subject)
« Reply #37 on: November 25, 2007, 02:52:34 PM »
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
« Last Edit: December 31, 1969, 06:00:00 PM by Kurt »
 

Offline Laurence

  • Warrant Officer, Class 1
  • *****
  • Posts: 78
(No subject)
« Reply #38 on: November 26, 2007, 08:55:35 AM »
Is it possible to add time delays on orders?  Maybe a simple "Wait XX:XX:XX time" command?
« Last Edit: December 31, 1969, 06:00:00 PM by Laurence »
 

Offline sloanjh

  • Global Moderator
  • Admiral of the Fleet
  • *****
  • Posts: 2715
  • Thanked: 62 times
(No subject)
« Reply #39 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
« Last Edit: December 31, 1969, 06:00:00 PM by sloanjh »
 

Offline Kurt

  • Global Moderator
  • Rear Admiral
  • *****
  • Posts: 957
  • Thanked: 52 times
(No subject)
« Reply #40 on: November 26, 2007, 10:10:54 PM »
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
« Last Edit: December 31, 1969, 06:00:00 PM by Kurt »
 

Offline sloanjh

  • Global Moderator
  • Admiral of the Fleet
  • *****
  • Posts: 2715
  • Thanked: 62 times
(No subject)
« Reply #41 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
« Last Edit: December 31, 1969, 06:00:00 PM by sloanjh »
 

Offline Brian

  • Vice Admiral
  • **********
  • Posts: 1213
  • Thanked: 2 times
(No subject)
« Reply #42 on: November 28, 2007, 07:08:51 PM »
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.

Thanks
Brian
« Last Edit: December 31, 1969, 06:00:00 PM by Brian »
 

Offline SteveAlt

  • Global Moderator
  • Rear Admiral
  • *****
  • Posts: 820
  • Thanked: 2 times
(No subject)
« Reply #43 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
« Last Edit: December 31, 1969, 06:00:00 PM by SteveAlt »
 

Offline SteveAlt

  • Global Moderator
  • Rear Admiral
  • *****
  • Posts: 820
  • Thanked: 2 times
(No subject)
« Reply #44 on: November 29, 2007, 03:27:05 PM »
As a side effect of my new campaign, I have added a "Knights Templar" theme to Aurora and a "Medieval France" commander names theme.

Steve
« Last Edit: December 31, 1969, 06:00:00 PM by SteveAlt »
 

 

Sitemap 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53