Post reply

Warning: this topic has not been posted in for at least 120 days.
Unless you're sure you want to reply, please consider starting a new topic.

Note: this post will not display until it's been approved by a moderator.

Name:
Email:
Subject:
Message icon:

shortcuts: hit alt+s to submit/post or alt+p to preview

Please read the rules before you post!


Topic Summary

Posted by: SteveAlt
« on: March 04, 2008, 02:54:06 AM »

Quote from: "Brian"
How are the changes to missiles going to effect the combat ability of fighters.

They will still be very similar in the v2.6 changes described above. The main differences will be using the new rules for missile fire control and carrying more capable missiles. Here is the updated Eagle class fighter for my current campaign. The Fire Control system is designed to shoot at targets of 2250 tons or greater and has the best range that can be achieved for that type of target using a 1 HS system. The Falchion missile has minimal fuel but matches the range of the fire control, allowing the bulk of the missile to be devoted to warhead and engine. This missile is a short-ranged (for the new rules) ship-killer. Missiles are going to be generally faster in v2.6, partly because of the 25% increase in missile power but partly because I am finding less space is being devoted to fuel. Although you can now create very long ranged missiles if you want to add a large fuel tank, targeting them becomes the issue.

Code: [Select]
Eagle class Fighter    250 tons     12 Crew     35.9 BP      TCS 5  TH 24  EM 0
4800 km/s     Armour 0.5     Shields 0-0     Sensors 1/0/0/0     Damage Control 0-0     PPV 1.8
Magazine 12    

Fighter Nuclear Pulse Engine FN-1 (1)    Power 24    Efficiency 70.00    Signature 24    Armour 0    Exp 25%
Fuel Capacity 10,000 Litres    Range 1.0 billion km   (59 hours at full power)

Mk 3 VLS Single Cell Launcher (3)    Missile Size 4    Hangar Reload 30 minutes    MF Reload 5 hours
APG-1 Fighter Fire Control (1)     Range 16.2m km    Resolution 45
Falchion Anti-Ship Missile (3)  Speed: 17500 km/s   Endurance: 15.3 minutes    Range: 16.1m km   Warhead: 10    MR: 10    Size: 4

There is a significant impact on carriers, which can now carry only 25% of the ordnance and 42% of the fuel they could carry before. Therefore the redesigned Ark Royal has had to sacrifice some engines to keep the strikegroup at 12 fighters while retaining only 40% of the magazine space. That ordnance is more considerably capable than before though. I think underway replenishment ships are going to become very important for fleet deployments and I will look at some specialised replenishment tech.

Code: [Select]
Ark Royal class Carrier    10000 tons     654 Crew     1068.6 BP      TCS 200  TH 560  EM 0
2800 km/s     Armour 1     Shields 0-0     Sensors 5/5/0/0     Damage Control 0-0     PPV 0
Hangar Deck Capacity 60     Magazine 410    Replacement Parts 10    

Nuclear Pulse Engine E7 (14)    Power 40    Efficiency 0.70    Signature 40    Armour 0    Exp 5%
Fuel Capacity 310,000 Litres    Range 79.7 billion km   (329 days at full power)

Falchion Anti-Ship Missile (102)  Speed: 17500 km/s   Endurance: 15.3 minutes    Range: 16.1m km   Warhead: 10    MR: 10    Size: 4

SPS-150/75 Active Sensor (1)     GPS 1500     Range 15.0m km    Resolution 75
SQS-1 Thermal Sensor (1)     Sensitivity 5     Detect Sig Strength 1000:  5m km
SE-1 EM Detection Sensor (1)     Sensitivity 5     Detect Sig Strength 1000:  5m km

Strike Group
12x Eagle Fighter   Speed: 4800 km/s    Size: 5

Steve
Posted by: Brian Neumann
« on: March 03, 2008, 11:02:22 PM »

How are the changes to missiles going to effect the combat ability of fighters.

Brian
Posted by: Steve Walmsley
« on: March 03, 2008, 03:19:42 PM »

Quote from: "Randy"
Quote
I do think that some type of DCQ is possible though but used as bonus to reload time rather than tracking individual deck crew actions.
I don't propose to use it to track actions. I suggest that it determines the speed the actions get done in general. You also do need to account for the "unload action" - if the missiles currently loaded are to be removed and replaced with a different kind.

  It should take longer to switch missiles that to just load new ones.

  Ie fighter lands with 4 missile "A" onboard. A second fighter also lands at thesame time, but no missiles left.
  You want both to be launched carrying 4x misslie "B". The first fighter should take twice as long to get ready to launch as the second.
At the moment the game mechanics are based on the launcher getting ready to reload. Once it is ready, it can switch missiles whenever it likes. As you say it would be more realistic to have to unload first if you want to change missiles. I'll take a look at that.

Quote
  And what about refueling time? How long does it take to refuel a fighter?

At the moment, all refuelling and resupply of magazines is done instantly. I need to look at that too for v2.6

Steve
Posted by: Randy
« on: March 03, 2008, 10:28:24 AM »

Quote
I do think that some type of DCQ is possible though but used as bonus to reload time rather than tracking individual deck crew actions.


  I don't propose to use it to track actions. I suggest that it determines the speed the actions get done in general. You also do need to account for the "unload action" - if the missiles currently loaded are to be removed and replaced with a different kind.

  It should take longer to switch missiles that to just load new ones.

  Ie fighter lands with 4 missile "A" onboard. A second fighter also lands at thesame time, but no missiles left.
  You want both to be launched carrying 4x misslie "B". The first fighter should take twice as long to get ready to launch as the second.

   And what about refueling time? How long does it take to refuel a fighter?
Posted by: Steve Walmsley
« on: March 01, 2008, 06:36:19 AM »

Quote from: "Brian"
I have 2 questions regarding the new technology.  One is that with partial hull spaces available, how will this affect jump engines.  If I design a ship for a jump engine that can take 200hs and the ship itself works out to 199.8, what happens with a companion that is 199.9.  If this is a problem, perhaps a check box that will pad a ship with null space to the next full hs increment.
Only fighters use partial HS so any ships above size 10 (500 tons) will be rounded up to the nearest full HS.

Quote
The other is that this redesign makes fighters very long range.  All of the designs that I have seen have an endurance of 2 days.  Perhaps an even smaller fuel tank so that fighters have an endurance measured in hours instead.  While I know we have aircraft that fly for a day or more there is a definite limit based on crew fatigue, and in-flight refueling.  Most combat planes do not have more than a few hours of endurance at full speed.  The only exeption is the bigger bombers, or planes that have replaced munitions with extra fuel.

Even if I created a smaller fuel tank, players could still use the existing larger ones so that wouldn't restrict range. One way to reduce range further would be to increase fuel use beyond 100x normal but I think that would make them very expensive and logistically challenging. I realise the endurance of fighters is greater than in modern warfare but the scale of Aurora is much larger than the scale of global warfare. In Aurora, ships can be deployed away from bases for years at a time so on a fighter vs ship ratio fighter endurance is probably comparable to modern warfare. In terms of practical range, the Eagle class fighters in my current campaign have a 5 day endurance and could just about manage a round trip to Jupiter. That is still very much the inner system though. They couldn't manage a round trip from Saturn to Uranus, even if the planets were at the closest point in their orbits.

As fighters are larger in v2.6, you will get less of them on a carrier so the increased range at least means the carriers have a better chance of keeping out of trouble and it gives fighters an interplanetary range within the inner system, making PDCs or orbital installations realistic fighter bases. I have only moved fighters about a little in my current campaign but it feels right so far. Also, don't forget that fighters can only attack targets they know about so in an anti-ship role, they will be probably restricted by ship sensor range rather than fuel.

Steve
Posted by: Brian Neumann
« on: February 28, 2008, 05:52:50 AM »

I have 2 questions regarding the new technology.  One is that with partial hull spaces available, how will this affect jump engines.  If I design a ship for a jump engine that can take 200hs and the ship itself works out to 199.8, what happens with a companion that is 199.9.  If this is a problem, perhaps a check box that will pad a ship with null space to the next full hs increment.

The other is that this redesign makes fighters very long range.  All of the designs that I have seen have an endurance of 2 days.  Perhaps an even smaller fuel tank so that fighters have an endurance measured in hours instead.  While I know we have aircraft that fly for a day or more there is a definite limit based on crew fatigue, and in-flight refueling.  Most combat planes do not have more than a few hours of endurance at full speed.  The only exeption is the bigger bombers, or planes that have replaced munitions with extra fuel.

Brian
Posted by: Steve Walmsley
« on: February 27, 2008, 03:58:23 PM »

Quote from: "Randy"
Couple of suggestions for launch rails.

  Instead of making them only reloadable in a hanger, make them take a specific number of action points to reload - based on the size of the missile being loaded, and location of the launch rail.

  Eg 10 action points per load point of missile inside a hanger, 100 per missile load point outside of hanger (and this is to load or unload a missile).

  Faster inside a hanger because more equipment is readily avilable, and distances involved are shorter.
At the moment the size of the launch rail is a factor. Larger launch rails take longer to reload. For game mechanic reasons I don't really want the ability to reload missiles outside a hangar, even if it takes several hours. At the moment, a ship cannot reload outside a hangar so if you want specialist ships with launch rails you will need to escort them with a mothership with a large enough hangar deck, which requires a considerable investment in terms of retooling shipyards, build time and cost, maintainance, etc. If you could reload without a hangar, you could fire a huge salvo then retire to reload your ship behind some convenient moon from either your own magazines or a collier. A few hours isn't a lot of time with the timescales of Aurora.

Quote
 Then have deck crew to perform the load - and have them generate eg 1 action point per deck crew per minute. (may need to be higher or lower rate)

  This allows you to put launch rails on a ship or a fighter, but unless you want to have a rather large crew, you wont be able to reload the external rails very quickly on a ship. Nor will you be able to land a couple dozen fighters and have them all turned around quickly unless you have a number of deck crew...

  Using Steve's new campaign as a baseline, an Eagle class fighter has 3 launch rails of 4 points each.

  It could thus carry 3 missiles of size 4 (the only size the carrier has). To load 3 Katana missiles on all 12 fighters will take 3x40x12 = 1440 action points. Meaning 144 deck crews could load all of them in 10 minutes (or 48 deck crew to load in 30 minutes).

  Have a "Deck Crew" quarters (DCQ) component to represent the equipment and men involved in the process. Maybe 1 DCQ can have 5 deck crews and takes 1 space. Meaning the carrier would have to devote about 10 spaces to deck crews to get 30 minute reload time.
At the moment deck crews are assumed by the crew requirements for the hangar deck. Although I like your suggestion of including deck crews as a specific system, I probably would go for an simpler mechanic because I wouldn't want players to have to micromanage deck crew assignments. Perhaps DCQs could provide a general bonus to reload times instead.

Quote
 To extrapolate to a ship mounting rails, assume a ship had just as many rails as the 12 fighters do combined (ie 36 rails). To load them with 50 deck crew will still take quite a while.  36x400 = 14400 action points. 50 deck crews would load this in 288 minutes (or almost 5 hours). To get it down to 30 minutes you would need 480 deck crews (using 96 spaces of DCQ + extra space for life support).
Fighters will generally have a speed advantage so they can pull out of range, reload on their carrier or mothership and come back. Take away the carrier and they are screwed. A regular ship would presumably fire and destroy the enemy, get destroyed trying to retreat or be fast enough to get away. If they are fast enough to stay out of range then reloading for 30 minutes or 5 hours is far less important than the fact they can reload their huge salvo without support. At  the moment a quarter size launcher has 100x reload time (so 50 minutes for a 30 second launcher). If I made a 1/6th size launcher with a 500x reload, the game effect would be very similar without the complexity of deck crews. I want the Launch Rail to be something different and not just an even smaller reloadable launcher.

Quote
Doing this gives two advantages - the reason you don't use rails on an average ship, and also allows you some control over how fast your rails can be reloaded (the more DCQ you use, the faster you can reload. But the bigger your carrier will be...).

The current reason for not using launch rails on an average ship is that they are loaded externally, which can only be done in a hangar bay (conveniently forgetting landing on planets with breathable atmospheres :)). If I changed the Launch Rail to reloadable without a hangar bay I am concerned it would become much more attractive to regular ships and lose its unique flavour. I do think that some type of DCQ is possible though but used as bonus to reload time rather than tracking individual deck crew actions. Perhaps something like DCQ / Hangar Decks * 10% bonus.

Steve
Posted by: Randy
« on: February 27, 2008, 02:04:52 PM »

Couple of suggestions for launch rails.

  Instead of making them only reloadable in a hanger, make them take a specific number of action points to reload - based on the size of the missile being loaded, and location of the launch rail.

  Eg 10 action points per load point of missile inside a hanger, 100 per missile load point outside of hanger (and this is to load or unload a missile).

  Faster inside a hanger because more equipment is readily avilable, and distances involved are shorter.

  Then have deck crew to perform the load - and have them generate eg 1 action point per deck crew per minute. (may need to be higher or lower rate)

  This allows you to put launch rails on a ship or a fighter, but unless you want to have a rather large crew, you wont be able to reload the external rails very quickly on a ship. Nor will you be able to land a couple dozen fighters and have them all turned around quickly unless you have a number of deck crew...

  Using Steve's new campaign as a baseline, an Eagle class fighter has 3 launch rails of 4 points each.

  It could thus carry 3 missiles of size 4 (the only size the carrier has). To load 3 Katana missiles on all 12 fighters will take 3x40x12 = 1440 action points. Meaning 144 deck crews could load all of them in 10 minutes (or 48 deck crew to load in 30 minutes).

  Have a "Deck Crew" quarters (DCQ) component to represent the equipment and men involved in the process. Maybe 1 DCQ can have 5 deck crews and takes 1 space. Meaning the carrier would have to devote about 10 spaces to deck crews to get 30 minute reload time.

  To extrapolate to a ship mounting rails, assume a ship had just as many rails as the 12 fighters do combined (ie 36 rails). To load them with 50 deck crew will still take quite a while.  36x400 = 14400 action points. 50 deck crews would load this in 288 minutes (or almost 5 hours). To get it down to 30 minutes you would need 480 deck crews (using 96 spaces of DCQ + extra space for life support).

  Doing this gives two advantages - the reason you don't use rails on an average ship, and also allows you some control over how fast your rails can be reloaded (the more DCQ you use, the faster you can reload. But the bigger your carrier will be...).

   Randy
Posted by: Steve Walmsley
« on: February 27, 2008, 07:32:47 AM »

The Fighter Ops skill will now allow Launch Rails to be reloaded more quickly. The Fighter Ops modifier is based on the fighter ops modifier of the mothership commander multiplied by the fighter ops bonus of the parent task force, if the task force HQ is in the same system.

Assuming a 30 minutes reload time, a 20% ship commander bonus and a 10% task force bonus, the reload time would be:

1.2 x 1.1 = 1.32 (32% reduction)
30 x 0.68 = 20.4 minutes

Steve
Posted by: Charlie Beeler
« on: February 22, 2008, 02:57:50 PM »

[quote="Steve Walmsley]<snip>Maybe I should rename the Launch Rail to Box Launcher or something similar to avoid confusion.[/quote]

Maybe.  Personally I like the concept change.  1 rail = 1 missile.  The rail rating limits how large that missile can be.  

A future idea could be hard points and fixtures.  A single hard point can hang a single fixture.  The class of the fixture defines the number of rails/bombs/etc that it can hold.  The hard points class defines the limit of the fixture.
Posted by: Steve Walmsley
« on: February 22, 2008, 08:20:55 AM »

Quote from: "Erik Luken"
Correct me if I am wrong, but don't the current (2.5) fighter rails allow more than 1 missile if the missile is under the maximum size? I.E. 2 size 4 rails = 2 size 4 missiles, 4 size 2 missiles, 8 size 1 missiles.

Yes that's true for the existing fighters. In v2.6, fighters will be designed in the same way as ships so they follow the same rules. The Launch Rail is a cut down missile launcher, 15% of normal size, which cannot be reloaded outside a hangar. Its more like a launch tube than a hardpoint on an F-16. So just as with ships, you can launch smaller missiles but you can't launch two missiles from the same launcher. However, you could design a multi-stage missile with two warheads for anti-fighter use.

Maybe I should rename the Launch Rail to Box Launcher or something similar to avoid confusion.

Steve
Posted by: Steve Walmsley
« on: February 22, 2008, 08:16:24 AM »

Quote from: "sloanjh"
Thanks.  Have you thought of dividing the system up into 2D "boxes" and saving an (integer) box ID with each asteroid?  If you restricted the algorithm to  "asteroid motion off" then you wouldn't ever have to update, and you could localize your search to asteroids that are nearby.  Especially if you did planets first - you could easily figure out which boxes might have a nearer asteroid and then restrict your SQL query to that range.  You might actually want to have a different set of boxes for each asteroid belt - then you could box in R and Theta.  I suspect most people have asteroid motion off anyway for performance reasons (I do).  It doesn't really help for moons, but you could check at the local planet before searching the system.  Or is the performance problem related to the DB query in a system with lots of bodies?

The problems were caused by systems with a lot of bodies. I tried a search where I only checked systems within a certain range of X and Y coordinates and then incremented the area after an unsuccessful search but that wasn't any quicker.

After some experimentation I realised that two sub-queries within the SQL were the main problem. The SQL retrieved all system bodies that were not already surveyed and not already a survey destination for another survey ship of the same race. VB code then cycled through the bodies, checked all the distances and found the closest.

Instead, I have now removed the sub-queries and added a pythagoras calculation to the order by clause of the SQL (see below for example). Now I get the bodies in order of distance straight out of the SQL. Then I cycle through them and check each one against other recordsets of surveyed system and destination systems until I get one that is not in either list. That turns out to be considerably faster.

Example code for asteroid only search
Code: [Select]
sSQL = "select SystemBodyID from SystemBody where SystemID = " & SystemID & " and BodyClass = 3 order by sqr(abs(Xcor - " & FleetX & ") + abs(Ycor - " & FleetY & "))"
Set rsSB = dbStarfire.OpenRecordset(sSQL, dbOpenDynaset)

Steve
Posted by: Erik L
« on: February 22, 2008, 08:12:16 AM »

Quote from: "Steve Walmsley"
Quote from: "Erik Luken"
Regarding Launchrails...

I've just really skimmed over the posts here, but if I have a fighter design with 2 size 4 rails, mounting 4 size 2 missiles, what is the RoF? 2 or 4?
Launch rails are handled like missile launchers, except you need to be in a hangar to reload. If you have a fighter with 2 size 4 rails you can launch two missiles of up to size 4. So that might be two Size 4 missiles or two Size 2 missiles. Once you fire, you need to return and reload before you can fire again.

Steve


Correct me if I am wrong, but don't the current (2.5) fighter rails allow more than 1 missile if the missile is under the maximum size? I.E. 2 size 4 rails = 2 size 4 missiles, 4 size 2 missiles, 8 size 1 missiles.
Posted by: Steve Walmsley
« on: February 22, 2008, 07:57:30 AM »

Quote from: "Erik Luken"
Regarding Launchrails...

I've just really skimmed over the posts here, but if I have a fighter design with 2 size 4 rails, mounting 4 size 2 missiles, what is the RoF? 2 or 4?

Launch rails are handled like missile launchers, except you need to be in a hangar to reload. If you have a fighter with 2 size 4 rails you can launch two missiles of up to size 4. So that might be two Size 4 missiles or two Size 2 missiles. Once you fire, you need to return and reload before you can fire again.

Steve
Posted by: Charlie Beeler
« on: February 20, 2008, 01:58:56 PM »

Quote from: "Haegan2005"
in version 2.5 and 2.0 if I have 6 rails I can put 2 size three missiles or one size 6 or a size 2 and a size 4, etc.


We're talking about the new tech for v2.6,  at least I am.