Post by: Erik L on January 24, 2008, 10:43:15 AM
Post by: Erik L on January 24, 2008, 01:25:51 PM
Event type - Civilian Constructio
Issue - Field seems to be a tad short for the data stuffed in.
As a side, is there any window to view all civilian construction? Are the civs limited by jump gates, or lack there of? Are there any limitations on where they will build?
Post by: Erik L on January 24, 2008, 03:22:53 PM
Post by: Erik L on January 24, 2008, 04:05:18 PM
High Power Microwave does not populate the grid below. It stayed with the Plasma Carronade info.
Post by: Erik L on January 24, 2008, 04:31:25 PM
The officers do not get auto-assigned to slots on vacancies (death, retirement). When I click the Auto-assign button, it fills vacancies (except staff positions).
Post by: Haegan2005 on January 25, 2008, 09:33:39 PM
Post by: Steve Walmsley on January 26, 2008, 09:49:35 AM
Quote from: "Erik Luken"
Event Update window.
Event type - Civilian Constructio
Issue - Field seems to be a tad short for the data stuffed in.
As a side, is there any window to view all civilian construction? Are the civs limited by jump gates, or lack there of? Are there any limitations on where they will build?
Field was one character too short - fixed for next version. This shouldn't have been in v2.5 but I forgot to comment out the check for civilian construction
This facility doesn't do anything in version 2.5. In later versions it will act as the construction location for civilian traffic, with larger civilian spaceports meaning more traffic. I need to think about this a little more but I will probably allow jump-capable civilian ships after the parent civ has had them for several years.
Steve
Post by: Steve Walmsley on January 26, 2008, 09:50:19 AM
Quote from: "Erik Luken"
The 20% fuel option doesn't seem to work. Set my survey group with a conditional at 20% fuel, refuel at the nearest colony with fuel. Simple minded gits surveyed on until they ran out.
This will only work if there is a colony in the same system.
Steve
Post by: Kurt on January 26, 2008, 12:21:08 PM
Quote from: "Haegan2005"
I used the instant order of battle and put in 5 ships twice and received 30 instead. I put in 2 for the survey ships and got 24 instead. Did I do soething wrong? It works fine in 2.0, but methods change as versions grow. Ideas?
Check and see if you really only have a 2 or 5 in the amount box. I have had this same error, and ultimately I found it was because I had the number I wanted, followed by another number that I couldn't actually see in the box because there were a lot of spaces or carriage returns (lines).
The way I figured this out was to highlight the number I put in by clicking the mouse cursor to the left of the number, then dragging it to the right to select everything entered into the field. What I found was that there was another number that would appear after either spaces or line breaks.
Kurt
Post by: Steve Walmsley on January 26, 2008, 12:36:06 PM
Quote from: "Kurt"
Quote from: "Haegan2005"I used the instant order of battle and put in 5 ships twice and received 30 instead. I put in 2 for the survey ships and got 24 instead. Did I do soething wrong? It works fine in 2.0, but methods change as versions grow. Ideas?
Check and see if you really only have a 2 or 5 in the amount box. I have had this same error, and ultimately I found it was because I had the number I wanted, followed by another number that I couldn't actually see in the box because there were a lot of spaces or carriage returns (lines).
The way I figured this out was to highlight the number I put in by clicking the mouse cursor to the left of the number, then dragging it to the right to select everything entered into the field. What I found was that there was another number that would appear after either spaces or line breaks.
I checked and it is a multi-line textbox so Kurt is probably correct as to the cause. I have changed it to single-line for the next version.
Steve
Post by: Steve Walmsley on January 26, 2008, 12:44:11 PM
Quote from: "Erik Luken"
Not sure if this is a bug or working as intended.
The officers do not get auto-assigned to slots on vacancies (death, retirement). When I click the Auto-assign button, it fills vacancies (except staff positions).
Not sure why this isn't working. The Check Assignment code runs after the Check Commander Health code so any positions left vacant should be picked up. Deaths in combat won't get picked up until the following 5-day increment but anyone retiring or dying through ill-health or accident during the 5-day increment should be replaced immediately.
How is the auto-assign shaping up so far apart from the above?
Steve
Post by: Erik L on January 26, 2008, 12:49:52 PM
Quote from: "Steve Walmsley"
Quote from: "Erik Luken"Not sure if this is a bug or working as intended.Not sure why this isn't working. The Check Assignment code runs after the Check Commander Health code so any positions left vacant should be picked up. Deaths in combat won't get picked up until the following 5-day increment but anyone retiring or dying through ill-health or accident during the 5-day increment should be replaced immediately.
The officers do not get auto-assigned to slots on vacancies (death, retirement). When I click the Auto-assign button, it fills vacancies (except staff positions).
How is the auto-assign shaping up so far apart from the above?
Steve
It doesn't seem to fill staff positions. Though it will empty them. I can't say I've seen it do any automatic assignments, just when I click, but it seems to do okay. Some choices I wouldn't make, but that's the point I think
Post by: Steve Walmsley on January 26, 2008, 01:53:02 PM
Quote from: "Erik Luken"
Quote from: "Steve Walmsley"How is the auto-assign shaping up so far apart from the above?It doesn't seem to fill staff positions. Though it will empty them. I can't say I've seen it do any automatic assignments, just when I click, but it seems to do okay. Some choices I wouldn't make, but that's the point I think
It should handle automated assignments every 5-day increment. I know this is a stupid question but is the automated feature it switched on (just under the Empire name on the commander window)
Steve
Post by: Erik L on January 26, 2008, 02:04:11 PM
Quote from: "Steve Walmsley"
Quote from: "Erik Luken"It should handle automated assignments every 5-day increment. I know this is a stupid question but is the automated feature it switched on (just under the Empire name on the commander window)Quote from: "Steve Walmsley"How is the auto-assign shaping up so far apart from the above?It doesn't seem to fill staff positions. Though it will empty them. I can't say I've seen it do any automatic assignments, just when I click, but it seems to do okay. Some choices I wouldn't make, but that's the point I think
Steve
I'll have to check Monday.
Post by: Kurt on January 27, 2008, 11:16:48 AM
A nifty new feature for 2.5 is that a race can gather sensor data on tech systems that they can see. This is converted into RP's, which can then be downloaded into research centers. This is a very cool feature, but it has given me quite a bit to think about in terms of letting other races get close to my ships/bases.
At any rate, RP's are gathered for individual systems, like, say, "Fire Control Speed Rating 4,000 kps", and the RP's gathered are subtracted off of the total amount of RP's you have to research to develop the system.
The exploit is related to the fact that you can continue accumulating RP's for that system even when you've accumulated enough to develop the system. In other words, the amount of RP's needed to develop the system will go into negative numbers, and when you do develop the system, those negative RP's will be applied to whatever you develop next. Free RP's!
The solution is either to make sure that no research project can have negative RP's, or, when any given research project reaches zero or negative RP's it is automatically developed rather than having to wait for the player to schedule it for R&D.
Kurt
Post by: Steve Walmsley on January 27, 2008, 12:04:14 PM
Quote from: "Kurt"
I think I've discovered a big fat exploit.With this ability in the game, I think many races would regard the use of active sensors as a potentially hostile act. There may also be a few "Russian Trawlers" following non-hostile alien fleets. The detail of which tech different sensors can detect under different circumstances is covered in the following thread:
A nifty new feature for 2.5 is that a race can gather sensor data on tech systems that they can see. This is converted into RP's, which can then be downloaded into research centers. This is a very cool feature, but it has given me quite a bit to think about in terms of letting other races get close to my ships/bases.
http://aurora.pentarch.org/viewtopic.php?t=891 (http://aurora.pentarch.org/viewtopic.php?t=891)
Quote
At any rate, RP's are gathered for individual systems, like, say, "Fire Control Speed Rating 4,000 kps", and the RP's gathered are subtracted off of the total amount of RP's you have to research to develop the system.
The exploit is related to the fact that you can continue accumulating RP's for that system even when you've accumulated enough to develop the system. In other words, the amount of RP's needed to develop the system will go into negative numbers, and when you do develop the system, those negative RP's will be applied to whatever you develop next. Free RP's!
The solution is either to make sure that no research project can have negative RP's, or, when any given research project reaches zero or negative RP's it is automatically developed rather than having to wait for the player to schedule it for R&D.
Thanks for spotting this. I have added some code to automatically develop any tech that accumulates sufficient points.
Steve
Post by: Manekaalecto on January 27, 2008, 03:22:01 PM
Game started 1st January 2000. When game has reached 1st January 2002, it showed an error message:
Error 3075 was generated by DAO.Database
Syntax error (comma) in query 's.SystemID = 2550 and s.Xcor = 70581806,8592 and s.Ycor =
-99943232,1695 and p.SystemBodyID = s.SystemBodyID and p.Race = 563'.
followed by a lot of:
Error 91 Object variable or With block variable not set
I have deleted game and started a new one, also 1st January 2000. 2nd January 2002 similar error message has popped out (different coordinates and different race ID). This time followed by only a few Error 91's, so after a lot of clicking game goes forward.
In event updates for 2nd January there is lot of command assignment events. With length of tour set for 24 months and automatic assignment on, I suppose that the errors are connected with automatic assignment code. I can send a database with this game, if it helps.
Wieslaw Juda
Post by: Steve Walmsley on January 27, 2008, 05:19:03 PM
Quote from: "Manekaalecto"
Game started 1st January 2000. When game has reached 1st January 2002, it showed an error message:
Error 3075 was generated by DAO.Database
Syntax error (comma) in query 's.SystemID = 2550 and s.Xcor = 70581806,8592 and s.Ycor =
-99943232,1695 and p.SystemBodyID = s.SystemBodyID and p.Race = 563'.
followed by a lot of:
Error 91 Object variable or With block variable not set
I have deleted game and started a new one, also 1st January 2000. 2nd January 2002 similar error message has popped out (different coordinates and different race ID). This time followed by only a few Error 91's, so after a lot of clicking game goes forward.
In event updates for 2nd January there is lot of command assignment events. With length of tour set for 24 months and automatic assignment on, I suppose that the errors are connected with automatic assignment code. I can send a database with this game, if it helps.
I don't think its the assignment code itself because I have been running with it for several years of game time without a similar error. However, it might be referencing some data that is a problem. Do you have any commander names, system names or ship/class names that contain an apostrophe or a comma?
Steve
Post by: Manekaalecto on January 28, 2008, 03:10:23 AM
When looking at individual units, "Error in PopulateLocationPops" shows up with similar message body as previous errors.
I am afraid that it could be a comma thing, specific to national Windows installation. (In Polish notation comma is used as decimal places separator instead of dot used in English - speaking countries).
Wieslaw Juda
Post by: Erik L on January 28, 2008, 09:35:01 AM
Quote from: "Steve Walmsley"
Quote from: "Erik Luken"Quote from: "Steve Walmsley"How is the auto-assign shaping up so far apart from the above?It doesn't seem to fill staff positions. Though it will empty them. I can't say I've seen it do any automatic assignments, just when I click, but it seems to do okay. Some choices I wouldn't make, but that's the point I think :oops:
Post by: Erik L on January 28, 2008, 09:53:19 AM
Post by: Erik L on January 28, 2008, 09:57:58 AM
Post by: Erik L on January 28, 2008, 11:00:07 AM
Post by: Manekaalecto on January 28, 2008, 12:57:30 PM
Sorry to take time that could have been spent on making 2.6 even better.
Wieslaw Juda
Post by: Valhawk on January 28, 2008, 02:19:26 PM
1. Pressing the Research button in the system menu brings up the shipyard task screen.
2. I keep getting
Code: [Select]
"Error 3421 was generated by DAO.Field data type conversion error" after every five day period" for Add to race wealth and get race weath. Considering wealth is still being added and displayed it seems strange that this should pop up over and over again.
Post by: Erik L on January 28, 2008, 02:58:06 PM
I deployed the 5 units for transport via the Economic/Ground Unit window. I then realized I had moved troops to a couple ships undergoing refit. I went to the ship window and transfered them to available, mobile ships. Looking at the fleet, I see a capacity of 4, and 5 units loaded.
Post by: Erik L on January 28, 2008, 03:00:19 PM
Post by: Erik L on January 28, 2008, 03:02:28 PM
Post by: Father Tim on January 28, 2008, 05:03:32 PM
Quote from: "Erik Luken"
Troops units deployed to a planet affect protection (I'm guessing, since the political stability went back to 100%), but do not show on the Summary page.
They don't affect protection, they remove unrest points through martial law - although they do so in a manner that's vastly more cost-efficient than building massive PDCs or fleets of parasite ships. So the low protection level causes unrest, which the 'security battalions' then remove. As an added bonus, they remove Unrest points from all sources, not just low defenses.
Post by: Erik L on January 28, 2008, 06:55:50 PM
Quote from: "Father Tim"
Quote from: "Erik Luken"Troops units deployed to a planet affect protection (I'm guessing, since the political stability went back to 100%), but do not show on the Summary page.
They don't affect protection, they remove unrest points through martial law - although they do so in a manner that's vastly more cost-efficient than building massive PDCs or fleets of parasite ships. So the low protection level causes unrest, which the 'security battalions' then remove. As an added bonus, they remove Unrest points from all sources, not just low defenses.
I've always gone the PDC route prior. I was constructing a PDC on the colony, and shipped in the garrison early.
Post by: Valhawk on January 31, 2008, 01:40:55 AM
Relatedly has anyone had any problems after you get to 1mil wealth with several errors kicking out everyturn relating to the wonky sheet. Also I am pretty sure it's not just a corrupt download becaue all the different versions of the patches and such still wont read it.
Any help would be greatly apprericated because this game is some of the most fun I've had with a space game ever.
Post by: Steve Walmsley on January 31, 2008, 09:10:15 AM
Quote from: "Valhawk"
There seems to be some error in DAO.field for me. I cant view past it with an MDB viewer as soon as it gets to it I get some error message about a misplace FROM or somthing.Could you zip up your Stevefire.mdb file and send it to me at stevewalmsley@btinternet.com It will be easier to find this type of problem if I step through the code using your game.
Relatedly has anyone had any problems after you get to 1mil wealth with several errors kicking out everyturn relating to the wonky sheet. Also I am pretty sure it's not just a corrupt download becaue all the different versions of the patches and such still wont read it.
Quote
Any help would be greatly apprericated because this game is some of the most fun I've had with a space game ever.
Glad to hear you are enjoying it! I have a lot of fun creating the game.
Steve
Post by: Erik L on February 01, 2008, 11:43:11 AM
Post by: Erik L on February 01, 2008, 12:40:30 PM
Post by: Erik L on February 01, 2008, 03:04:11 PM
Also like to renew the suggestion for being able to refit PDCs
Post by: Erik L on February 01, 2008, 03:59:48 PM
Post by: Erik L on February 01, 2008, 04:05:40 PM
Edith frakk.
Post by: Erik L on February 01, 2008, 04:38:06 PM
Post by: Steve Walmsley on February 02, 2008, 05:02:49 AM
Quote from: "Erik Luken"
Technology Report.
High Power Microwave does not populate the grid below. It stayed with the Plasma Carronade info.
I forgot to add the HPM section to the report. Added for v2.6
Steve
Post by: Steve Walmsley on February 02, 2008, 05:07:22 AM
Quote from: "Manekaalecto"
Nope. No apostrophes in commander names (Chinese), planet names or ship names (Mongol theme). When restarted from earlier date database (1 Jan 2001) same thing - "Error in RemoveCommander". Tried a few times - 50% chance for infinite loop, 50 % for about 20 Error91's.
When looking at individual units, "Error in PopulateLocationPops" shows up with similar message body as previous errors.
I am afraid that it could be a comma thing, specific to national Windows installation. (In Polish notation comma is used as decimal places separator instead of dot used in English - speaking countries).
I noticed the comma as decimal separator but thought you wouldn't have made it through two years with that as an issue. Is it possible to temporarily switch your PC to the dot as decimal separator to see if that cures the problem?
Steve
Post by: Steve Walmsley on February 02, 2008, 05:14:40 AM
Quote from: "Erik Luken"
Marking "Eligible Only" on the commander filters does not filter out slots that are too low.
Fixed for v2.6
Steve
Post by: Steve Walmsley on February 02, 2008, 05:27:15 AM
Quote from: "Erik Luken"
When showing the PP Rules window, the Officer traits box does not go to the background.
Fixed for v2.6. I also corrected the text on the bonus rules as they were out of date.
Steve
Post by: Steve Walmsley on February 02, 2008, 05:30:27 AM
Quote from: "Erik Luken"
Are trade convoys not working? I've got 2 spaceports in different systems, connected by a jumpgate network. Both spaceports are sitting at 0 days to next convoy. Have been for months. I don't see any convoy messages in the log.
You need to setup Trade Routes for any routes you would like the convoys to follow. New convoys will always go for the shortest available route that doesn't already have a convoy in transit. This can be accessed from the main menu or the button on the system map in-between mineral report and sectors
Steve
Post by: Steve Walmsley on February 02, 2008, 05:39:12 AM
Quote from: "Valhawk"
1. Pressing the Research button in the system menu brings up the shipyard task screen.Oops! That's because I moved the tabs around and forgot to update the buttons. Fixed for v2.6
Quote
2. I keep gettingCode: [Select]"Error 3421 was generated by DAO.Field data type conversion error"after every five day period" for Add to race wealth and get race weath. Considering wealth is still being added and displayed it seems strange that this should pop up over and over again.
When I checked your database I found that the fields for the date Wealth was added and the date of Last Overhaul for ships were both too small for games beyond a certain length. I think your game was 119 years old. I have corrected both of these for v2.6. The problem will only exist for long games in v2.5
Steve
Post by: Steve Walmsley on February 02, 2008, 05:42:05 AM
Quote from: "Erik Luken"
Can you fix the spelling of "Antietam" from "Antienam"?
Corrected, or rather deleted because both spellings were in the list of ship names.
Steve
Post by: Steve Walmsley on February 02, 2008, 05:43:32 AM
Quote from: "Father Tim"
Quote from: "Erik Luken"Troops units deployed to a planet affect protection (I'm guessing, since the political stability went back to 100%), but do not show on the Summary page.
They don't affect protection, they remove unrest points through martial law - although they do so in a manner that's vastly more cost-efficient than building massive PDCs or fleets of parasite ships. So the low protection level causes unrest, which the 'security battalions' then remove. As an added bonus, they remove Unrest points from all sources, not just low defenses.
Yes, that is how it works. At some point I need to do an analysis on this area because I suspect the ground forces are a little too efficient.
Steve
Post by: Steve Walmsley on February 02, 2008, 05:48:16 AM
Quote from: "Erik Luken"
Random name generated... Using the Germanic name scheme. Not really a bug, but a potentially offensive last name.
Edith frakk.
Oops
. I have removed that surname from the database. There must be people called that in Germany because I used data from a German surnames list.Steve
Post by: Steve Walmsley on February 02, 2008, 05:49:36 AM
Quote from: "Erik Luken"
Harvesters unloading fuel generate 3 errors. Does not seem to affect anything.
I have seen this one as well. Next time my harvesters unload, I'll sort it out because I have a breakpoint set in the code.
Steve
Post by: Manekaalecto on February 02, 2008, 11:15:45 AM
Quote from: "Steve Walmsley"
I noticed the comma as decimal separator but thought you wouldn't have made it through two years with that as an issue. Is it possible to temporarily switch your PC to the dot as decimal separator to see if that cures the problem?
Steve
(Thumping head on the wall, muttering to self "Stupid, stupid...")
Yes, changing decimal separator type in Windows' regional options worked like a charm.
All hail Steve, Great Admiralissimo !
Wieslaw Juda
Post by: Steve Walmsley on February 03, 2008, 03:02:08 PM
Quote from: "Steve Walmsley"
Quote from: "Erik Luken"Harvesters unloading fuel generate 3 errors. Does not seem to affect anything.I have seen this one as well. Next time my harvesters unload, I'll sort it out because I have a breakpoint set in the code.
I have fixed it for v2.6. A side effect of the bug for v2.5 is that if an Unload Fuel order is created automatically as a result of a Conditional Order, the fuel is not credited to the receiving population. For v2.5, I suggest setting manual Unload Fuel orders. Easiest way is probably to leave the conditional order on but then delete and replace the automatic order when you get the conditional order event.
Steve
Post by: Erik L on February 04, 2008, 01:11:56 PM
Unless DC has been separated from Engineering?
Post by: Erik L on February 05, 2008, 09:13:57 AM
Post by: Erik L on February 06, 2008, 03:29:45 PM
Post by: Steve Walmsley on February 09, 2008, 06:19:17 AM
Quote from: "Erik Luken"
On the Available Colony Analysis window, the "Exclude alien-controlled systems" toggle does not seem to work. Unless I need to explicitly set control of the system to the alien via the System View window? *edit* nope.
You need to set the system control. The viewing Empire will be excluding systems that it believes are alien controlled. Otherwise the window might reveal that certain systems have alien populations previously unknown to the viewing race.
Steve
Post by: Erik L on February 09, 2008, 09:04:17 AM
Quote from: "Steve Walmsley"
Quote from: "Erik Luken"On the Available Colony Analysis window, the "Exclude alien-controlled systems" toggle does not seem to work. Unless I need to explicitly set control of the system to the alien via the System View window? *edit* nope.You need to set the system control. The viewing Empire will be excluding systems that it believes are alien controlled. Otherwise the window might reveal that certain systems have alien populations previously unknown to the viewing race.
Steve
Did that. Puts a flag on the system in the galaxy map, but the system still shows up in the available colony list.
Post by: Steve Walmsley on February 09, 2008, 09:19:34 AM
Quote from: "Erik Luken"
Did that. Puts a flag on the system in the galaxy map, but the system still shows up in the available colony list.
I've checked and there is a bug. Fixed for v2.6.
Steve
Post by: Brian Neumann on February 10, 2008, 09:30:47 PM
Brian
Post by: Charlie Beeler on February 12, 2008, 08:49:25 AM
Quote from: "Charlie Beeler"
Error in MoveFleets
Error 3265 was generated by DAO.fields
Item not found in collection
3 times per time advance for each fighter group in flight.
Still getting this one. [sarcasim]Big surprise
[/sarcasim] Didn't really expect this to be fixed in 2.5.I was running a one off game that had 21 squadrons in flight between both sides that appears to have caused a loop. After hitting enter over 300 times instead of the expected 63 I had to kill the app which in turn killed that game. This appears to be making fighters untenable at this time.
Post by: Steve Walmsley on February 22, 2008, 08:01:19 AM
Quote from: "Brian"
Got another one of those anoying names with apostrophe's in them. Solov'yanen in the ancient egyptian theme.
I am struggling to find it. Was it a system name, a class name or a commander name?
Steve
Post by: Brian Neumann on February 22, 2008, 01:11:01 PM
Brian
Post by: Steve Walmsley on February 23, 2008, 12:43:14 PM
Quote from: "Brian"
It was a system name. Sorry about that, I thought I had put it in the original post
I still can't find it
. Its entirely possible though I ran into this myself and already removed it from the database. Are you running v2.5 at the moment?Steve
Post by: Brian Neumann on February 24, 2008, 10:29:49 AM
Quote from: "Steve Walmsley"
Quote from: "Brian"It was a system name. Sorry about that, I thought I had put it in the original postI still can't find it
Steve
I am running 2.5 currently. I was in SM mode using the SM race to generate some systems. I also found another one just today. same situation. The theme says it is ancient egypt, but the name doesn't really match. System name of Lac D'Orien. It was within the first 30 systems I generated.
I hope this helps with the other one as well.
Brian
Post by: Steve Walmsley on February 24, 2008, 11:00:00 AM
Quote from: "Brian"
Quote from: "Steve Walmsley"I am running 2.5 currently. I was in SM mode using the SM race to generate some systems. I also found another one just today. same situation. The theme says it is ancient egypt, but the name doesn't really match. System name of Lac D'Orien. It was within the first 30 systems I generated. I hope this helps with the other one as well.Quote from: "Brian"It was a system name. Sorry about that, I thought I had put it in the original postI still can't find it
Thanks, that did help. I had forgotten that I created a list of about 15000 asteroid names to serve as backup once the theme names run out. Solov'yanen and Lac d'Orien were both in that list. By coincidence Solov'yanen sounded Egyptian enough for me to fail to make the connection but Lac d'Orien plainly isn't so I quickly realised the problem. Both names have now been removed from the database
Steve
Post by: Brian Neumann on February 24, 2008, 12:17:56 PM
Quote
Thanks, that did help. I had forgotten that I created a list of about 15000 asteroid names to serve as backup once the theme names run out. Solov'yanen and Lac d'Orien were both in that list. By coincidence Solov'yanen sounded Egyptian enough for me to fail to make the connection but Lac d'Orien plainly isn't so I quickly realised the problem. Both names have now been removed from the database
Glad that helped. I bet you wish that you knew what a pain those aphostrophe's would be before you loaded the names into the database. O well hindsight is supposed to be 20/20.
Brian
Post by: Steve Walmsley on February 24, 2008, 01:28:52 PM
Quote from: "Brian"
Glad that helped. I bet you wish that you knew what a pain those aphostrophe's would be before you loaded the names into the database. O well hindsight is supposed to be 20/20.
They have been a pain for years so I am aware of the problem. I just couldn't check the 15,000 names in the asteroid list. It can also be a problem writing SQL to find them because the aphostrophes mess that up too. This problem was even reported on CNN a couple of days ago, although not specifically relating to Aurora
http://edition.cnn.com/2008/TECH/ptech/ ... index.html (http://edition.cnn.com/2008/TECH/ptech/02/21/apostrophe.trouble.ap/index.html)
Steve
Post by: Brian Neumann on February 25, 2008, 07:10:56 AM
Quote from: "Steve Walmsley"
Quote from: "Brian"Glad that helped. I bet you wish that you knew what a pain those aphostrophe's would be before you loaded the names into the database. O well hindsight is supposed to be 20/20.They have been a pain for years so I am aware of the problem. I just couldn't check the 15,000 names in the asteroid list. It can also be a problem writing SQL to find them because the aphostrophes mess that up too. This problem was even reported on CNN a couple of days ago, although not specifically relating to Aurora
http://edition.cnn.com/2008/TECH/ptech/ ... index.html (http://edition.cnn.com/2008/TECH/ptech/02/21/apostrophe.trouble.ap/index.html)
Steve
I had not realized that you loaded that many names in one batch. No wonder you keep running into them. The french have a habit on naming things with apostrophe's and they have been active over the years in astronomy.
Thanks for all the work you do. I really like the program and have enjoyed playing around with it. I am eagerly awaiting the next version as I had an idea years ago for a race that startet out in a nebula and never developed those shields and missle tech.
Brian
Post by: Steve Walmsley on February 25, 2008, 07:46:37 AM
Quote from: "Brian"
I had not realized that you loaded that many names in one batch. No wonder you keep running into them. The french have a habit on naming things with apostrophe's and they have been active over the years in astronomy.I have added some code to the routine that gets the next themed system name (or the next asteroid name) that should extract any apostrophes before using the name. That should fix the problem of apostrophes being used in the system names. Its easier than trying to check every existing name and also prevents the use of any names with apostrophes that get added in the future.
Quote
Thanks for all the work you do. I really like the program and have enjoyed playing around with it. I am eagerly awaiting the next version as I had an idea years ago for a race that startet out in a nebula and never developed those shields and missle tech.
That sounds like a really good idea. They also may not develop any significant engine tech because they can't go beyond a certain speed either, or more likely they would only develop such tech in conjunction with heavily armoured ships.
Steve
Post by: Erik L on February 25, 2008, 08:15:37 AM
Quote from: "Steve Walmsley"
Quote from: "Brian"I had not realized that you loaded that many names in one batch. No wonder you keep running into them. The french have a habit on naming things with apostrophe's and they have been active over the years in astronomy.I have added some code to the routine that gets the next themed system name (or the next asteroid name) that should extract any apostrophes before using the name. That should fix the problem of apostrophes being used in the system names. Its easier than trying to check every existing name and also prevents the use of any names with apostrophes that get added in the future.
Steve
How about replacing them with reversed apostrophe's? Those may look odd, but SQL doesn't gag on them.
Post by: Charlie Beeler on March 12, 2008, 12:23:11 PM
I had an attacking fleet pummel a planetary PDC with 20cm lasers while the PDC was unable to return fire with it's Fusion Torpedoes do to atmospheric pressure being 1.0. I seam to recall lasers being restricted in atmosphere, but is this restriction on all beam weapons? If so, does this mean that the only effective weapons that can be installed in PDC's for use on planets with atmospheres is missiles? Should the attacking laser ship have been restricted as well?
Post by: Steve Walmsley on March 13, 2008, 07:33:52 AM
Quote from: "Charlie Beeler"
Not sure if this is a bug or "undocumented feature".
I had an attacking fleet pummel a planetary PDC with 20cm lasers while the PDC was unable to return fire with it's Fusion Torpedoes do to atmospheric pressure being 1.0. I seam to recall lasers being restricted in atmosphere, but is this restriction on all beam weapons? If so, does this mean that the only effective weapons that can be installed in PDC's for use on planets with atmospheres is missiles? Should the attacking laser ship have been restricted as well?
Yes, it sounds like a bug. All beam weapons except mesons should be restricted in atmosphere. I'll take a look at the code.
Steve
Post by: Brian Neumann on March 16, 2008, 06:51:54 PM
Also how about an improved version of meson's base them off of the improved lasers range should work fine.
Brian
PS. Looking forward to 2.6
Post by: James Patten on March 18, 2008, 06:17:32 PM
Unless I'm reading it completely wrong and one commander is a much better harvester than the other.
Post by: Steve Walmsley on March 20, 2008, 09:48:11 AM
Quote from: "James Patten"
I have some fuel harvesting ships, the commanders of which appear to have some sort of fuel saving abilities (one ship has a Grade Bonus of 11%). However it not only saves me in using up fuel, it takes longer to harvest fuel! Both started with the same amount of fuel and now one has about 5% or more fuel than the other ship.
Unless I'm reading it completely wrong and one commander is a much better harvester than the other.
I think either mining or factory production bonuses affect fuel harvesting rates. Does the commander in queston have either of those bonuses?
Steve
Post by: James Patten on March 20, 2008, 11:02:19 AM
Can't remember what the bonuses are, but I thought they were around the same. Will have to check when I get home.
Post by: Steve Walmsley on March 21, 2008, 05:27:47 AM
Quote from: "James Patten"
Both commanders have mining bonuses. Don't recall if they have factory production bonuses.
Can't remember what the bonuses are, but I thought they were around the same. Will have to check when I get home.
I checked and it is mining bonuses that affect fuel harvesting. Here is a link to a thread with all the commander bonuses and their effects.
http://aurora.pentarch.org/viewtopic.php?t=525 (http://aurora.pentarch.org/viewtopic.php?t=525)
Steve
Post by: vergeraiders on March 26, 2008, 05:35:55 PM
My ever so efficent cyber team reactivated a precursor fuel plant and messed up my finely balanced workforce that was just big enough running 4 factories to produce infrastructure.
Mike
Post by: James Patten on March 26, 2008, 07:00:20 PM
Quote from: "vergeraiders"
... messed up my finely balanced workforce ...
That reminds me of something - there ought to be a way to stop researching something once started. I accidentally started research in a colony that wasn't prepared for it, and ended up with a severe worker shortage. The only way out of it was to start pumping the colonists to the colony. I couldn't figure out how to stop research, since there didn't seem to be a way to clear it.
Post by: Steve Walmsley on March 27, 2008, 10:28:44 AM
Quote from: "vergeraiders"
Not sure if this is a bug or a feature, but if a refinery is shut down, workers for one are still listed as withdrawn from the workforce.
My ever so efficent cyber team reactivated a precursor fuel plant and messed up my finely balanced workforce that was just big enough running 4 factories to produce infrastructure.
Quote from: "James Patten"
That reminds me of something - there ought to be a way to stop researching something once started. I accidentally started research in a colony that wasn't prepared for it, and ended up with a severe worker shortage. The only way out of it was to start pumping the colonists to the colony. I couldn't figure out how to stop research, since there didn't seem to be a way to clear it.
In Aurora, workers are allocated to installations whether they are operating or not. This is partly for simplicity but partly because I don't want to allow workers to jump easily between working in a fuel refinery and a shipyard. In reality, you couldn't just keep temporarily closing down different sections of your industrial base, redeploying the workers and then a few months later switch them all around again.
I have considered changing factories to the same model as shipyards so instead of having construction factories, fighter factories, etc, so you would just have factories. You could then "retool" a number of factories to do a specific task, such as building shipyards or a particular model of fighter. One option in this model would be to close down factories to free up workers and if you did that, you would have to retool them once you needed them again to reflect opening up the factories and training the workers. All new factories, including those found in ruins, would start as unused.
Steve
Post by: vergeraiders on March 27, 2008, 11:23:29 AM
Steve[/quote]
I was wondering if that was the reason.
[quote="Steve Walmsley]
I have considered changing factories to the same model as shipyards so instead of having construction factories, fighter factories, etc, so you would just have factories. You could then "retool" a number of factories to do a specific task, such as building shipyards or a particular model of fighter. One option in this model would be to close down factories to free up workers and if you did that, you would have to retool them once you needed them again to reflect opening up the factories and training the workers. All new factories, including those found in ruins, would start as unused.
Steve[/quote]
I think I like that idea, a lot. I also kind of think it may balance fighter and missile races better if all of the production came out of one pot. Though figuring out exactly how much fuel production is worth how much mine production is worth how much factory production is worth how much shipyrad creation may be delicate
.Mike
Post by: Randy on April 02, 2008, 09:02:12 AM
Quote
I have considered changing factories to the same model as shipyards so instead of having construction factories, fighter factories, etc, so you would just have factories. You could then "retool" a number of factories to do a specific task, such as building shipyards or a particular model of fighter
Put me n the Opposed category. No real advantage to doing this, and a lot of extra micromanagement required. Much simpler to leave it as it stands
Post by: Haegan2005 on April 02, 2008, 02:00:06 PM
[quote="Randy"
Put me n the Opposed category. No real advantage to doing this, and a lot of extra micromanagement required. Much simpler to leave it as it stands
[/quote]
Post by: vergeraiders on April 02, 2008, 02:46:40 PM
Just because a cybernetic team was lucky enough to reactivate a precursor fuel refinery, there no reason for my carefully selected construction workers, that I paid to ship to the colony, to suddenly decide they prefer to work in a refinery that I neither started production in or have any sorium on the planet to start doing so.
Mike
Post by: Erik L on April 02, 2008, 03:45:02 PM
Quote from: "vergeraiders"
Well there should be some way to solve my basic problem.
Just because a cybernetic team was lucky enough to reactivate a precursor fuel refinery, there no reason for my carefully selected construction workers, that I paid to ship to the colony, to suddenly decide they prefer to work in a refinery that I neither started production in or have any sorium on the planet to start doing so.
Mike
Making the basic assumption you are still shipping things like infrastructure to the site, have your freighters pick up the refinery on one of their trips. The workers go back to what they should, and everyone is happy.
Post by: sloanjh on April 02, 2008, 07:46:37 PM
Quote from: "Erik Luken"
Quote from: "vergeraiders"Well there should be some way to solve my basic problem.
Just because a cybernetic team was lucky enough to reactivate a precursor fuel refinery, there no reason for my carefully selected construction workers, that I paid to ship to the colony, to suddenly decide they prefer to work in a refinery that I neither started production in or have any sorium on the planet to start doing so.
:-)
John
PS - I'm a little worried about the micromanagment aspects of retooling factories too. I wouldn't be opposed to a "layoff N factories/SY/whatever" command coupled to a "rehire N" command that freed up workers then slowly recovered the capacity, i.e. "rehire N" increase the "active" factories by N over 6 months. It would probably be pretty yuckky to code up, however, for something that I don't think comes up often and can be worked around in SM mode.
Post by: Steve Walmsley on April 03, 2008, 05:39:55 AM
Steve
Post by: MWadwell on April 04, 2008, 02:39:54 AM
Quote from: "Steve Walmsley"
Based on the general response, I'll forget the retooling factories idea. I might try and come up with something that allows you to shut down a particular section of industry but with some penalty involved to restarting it.
Steve
What about imposing a time penalty to the workers - such as when you shut a factory down, the workers are considered as still in use for 30 days afterwards (and so only after the period, are they available for other uses)?
Post by: Kurt on April 06, 2008, 11:28:24 AM
During a recent battle, I got a large number of error messages when missiles started hitting planetary targets. The error was:
Error in Planetary Bombardment
Error 3265, Item Not Found
I entered through the errors, and the bombardment results seemed right. I suspect that you've changed something, and that the combat results routine is looking for something that is no longer there.
Kurt
Post by: Kurt on April 06, 2008, 01:27:12 PM
I seem to have run into a bit of a problem, either in my understanding of the game or a bug. Probably a bug, but we?ll see.
The situation is as follows: A group of FAC?s launch missiles at a group of four cruisers. The missiles are launched at 167,000 km?s, and travel at 18,000 kps. The cruisers are armed with three dual 12 cm laser turrets each, each of which have a ROF of five. I calculated things out and realized that the cruisers should be able to get in two point defense shots with their lasers, once at approximately 77,000 km?s and the second time at point blank range. Accordingly, I set the ship?s fire control to area point defense 8, so that they would engage targets out to 80,000 km?s.
The first course of fire against the incoming missiles went off okay, although there was something strange. The four cruisers have a total of twelve double turrets, for a total of twenty-four lasers. They fired as planned, but only two of the three turrets on each ship engaged, strangely enough. While it is possible that this is due to an error in setting up the fire on my part, I don?t think it was as I set up one ship and copied its fire control settings throughout the fleet, then hit the open fire button for the entire fleet. Still, it is possible that I set that last turret on each ship to something different.
At any rate, after this course of fire, I reset the fire control for the entire fleet to point blank 1, and hit the open fire button for the entire fleet. This time none of the lasers engaged, not even the turrets that hadn?t fired in the first round. The notation in the Event Update screen noted for the first two turrets on the first cruiser as follows: ?Twin 12cm C4 Near Ultraviolet Laser Turret recharging. 0 power in capacitor. 8 power required to fire.? None of the other ship?s turrets are listed as even trying to fire.
The ship design is as follows:
Code: [Select]
Tharsis Montes Flt II class Escort Cruiser 8000 tons 783 Crew 1214.4 BP TCS 160 TH 320 EM 780
2000 km/s Armour 1 Shields 26-400 Sensors 32/0/0/0 Damage Control 0-0 PPV 33
Replacement Parts 10
Nuclear Pulse Engine (8) Power 40 Efficiency 0.80 Signature 40 Armour 0 Exp 5%
Fuel Capacity 150,000 Litres Range 101.3 billion km (585 days at full power)
Gamma R400/16 Shields (13) Total Fuel Cost 208 Litres per day
Twin 12cm C4 Near Ultraviolet Laser Turret (3x2) Range 96,000km TS: 12800 km/s Power 8-8 RM 3 ROF 5 4 4 4 3 2 2 1 1 1 0
PD Fire Control (3) Max Range: 96,000 km TS: 12800 km/s 90 79 69 58 48 38 27 17 6 0
Gas-Cooled Fast Reactor (2) Total Power Output 28 Armour 0 Exp 5%
Missile Sensor, Small (1) GPS 12.8 Range 128k km Resolution 0.2
Ship Sensor, Small (1) GPS 2560 Range 25.6m km Resolution 40
Thermal Sensor, Small (1) Sensitivity 32 Detect Sig Strength 1000: 32m km
One question occurs immediately ? what does ?Power 8-8? mean. Eight units of power in eight seconds? If so, what does ROF 5 mean?
Looking at the tech report screen, the 12cm C4 NU Laser has the following stats:
Power: 4
Recharge Rate: 4
Max Rate of Fire: 5 seconds
The class design screen shows that the ship has a power requirement of 24, and has a power generation capability of 28, and none of the ships were damaged, and all had fuel.
If I did something wrong, I can?t understand what it would have been. It is always possible that I don?t understand something that I think I understand, of course. Otherwise, the problem may be in the recharge calculations, or in the turn sequence. Do weapons recharge after firing, or before?
Kurt
Post by: Erik L on April 06, 2008, 04:27:14 PM
Quote from: "Kurt"
One question occurs immediately ? what does ?Power 8-8? mean. Eight units of power in eight seconds? If so, what does ROF 5 mean?
I've always interpreted the power statement to read "8 required, 8 charged/5 seconds" (in this case).
Post by: Kurt on April 06, 2008, 05:11:56 PM
Quote from: "Erik Luken"
Quote from: "Kurt"One question occurs immediately ? what does ?Power 8-8? mean. Eight units of power in eight seconds? If so, what does ROF 5 mean?
I've always interpreted the power statement to read "8 required, 8 charged/5 seconds" (in this case).
That is what I thought as well, but based on this ship's performance in battle, it doesn't appear that that interpretation is correct. Unless something is wrong, of course.
Kurt
Post by: Haegan2005 on April 07, 2008, 01:11:17 AM
Post by: Steve Walmsley on April 07, 2008, 06:01:06 AM
Quote from: "Kurt"
Steve ?I haven't come across this particular problem before and I have handled a lot of similar situations. It does sound like the third turret may not have been assigned to the fire control. Can you remember checking the fire control summary, or can you remember if you used assign all, or assigned them individually?
I seem to have run into a bit of a problem, either in my understanding of the game or a bug. Probably a bug, but we?ll see.
The situation is as follows: A group of FAC?s launch missiles at a group of four cruisers. The missiles are launched at 167,000 km?s, and travel at 18,000 kps. The cruisers are armed with three dual 12 cm laser turrets each, each of which have a ROF of five. I calculated things out and realized that the cruisers should be able to get in two point defense shots with their lasers, once at approximately 77,000 km?s and the second time at point blank range. Accordingly, I set the ship?s fire control to area point defense 8, so that they would engage targets out to 80,000 km?s.
The first course of fire against the incoming missiles went off okay, although there was something strange. The four cruisers have a total of twelve double turrets, for a total of twenty-four lasers. They fired as planned, but only two of the three turrets on each ship engaged, strangely enough. While it is possible that this is due to an error in setting up the fire on my part, I don?t think it was as I set up one ship and copied its fire control settings throughout the fleet, then hit the open fire button for the entire fleet. Still, it is possible that I set that last turret on each ship to something different.
Quote
At any rate, after this course of fire, I reset the fire control for the entire fleet to point blank 1, and hit the open fire button for the entire fleet. This time none of the lasers engaged, not even the turrets that hadn?t fired in the first round. The notation in the Event Update screen noted for the first two turrets on the first cruiser as follows: ?Twin 12cm C4 Near Ultraviolet Laser Turret recharging. 0 power in capacitor. 8 power required to fire.? None of the other ship?s turrets are listed as even trying to fire.The problem here is that the lasers did not have time to recharge. Weapons recharge during the fire phase, which follows the movement phase. As you fired the lasers in the fire phase of the first increment, they didn't have time to recharge before the movement phase of the second increment. Here is a link to the sequence of play:
http://aurora.pentarch.org/viewtopic.php?t=532 (http://aurora.pentarch.org/viewtopic.php?t=532)
This is one of the reasons I added the options for point blank and area fire so you can decide whether to hold lasers back for last second defensive fire during the movement phase or use them for long range interceptions. It's interesting that the third turret didn't fire though as that should still have been charged. Can you check it is assigned to the fire control in question?
Quote
One question occurs immediately ? what does ?Power 8-8? mean. Eight units of power in eight seconds? If so, what does ROF 5 mean?ROF = Rate of Fire. Given enough power the turrets will fire every 5 seconds. Power 8-8 means the turrets require 8 power to fire (the first digit) and they can receive that power at up to 8 every 5 second increment (the second digit). For example the following laser requires 6 power to fire and can receive that power at 2 per five second increment (due to the type of capacitor), which gives it a ROF of 15 seconds.
15cm C2 Visible Light Laser (4) Range 96,000km TS: 3200 km/s Power 6-2 RM 2 ROF 15
Quote
Looking at the tech report screen, the 12cm C4 NU Laser has the following stats:That is the basic laser but once you combine lasers into a turret, the turret itself effectively becomes a new weapon type. In this case a 12cm laser that fires 2 shots every 5 seconds and requires 8 power every 5 seconds.
Power: 4
Recharge Rate: 4
Max Rate of Fire: 5 seconds
Quote
If I did something wrong, I can?t understand what it would have been. It is always possible that I don?t understand something that I think I understand, of course. Otherwise, the problem may be in the recharge calculations, or in the turn sequence. Do weapons recharge after firing, or before?
Weapons charge at the start of the firing phase, which follows movement. As you guessed, the sequence of play was the reason the lasers couldn't fire. Without completing a full cycle of the sequence of play they would have fired twice in less than 5 seconds, or put another way the missiles would have travelled the distance from the first firing point to the ship in less than 5 seconds. By holding them for point blank fire the lasers would be ready to fire at exactly the right moment.
Steve
Post by: Kurt on April 07, 2008, 11:30:05 AM
Quote from: "Steve Walmsley"
Quote from: "Kurt"Steve ?I haven't come across this particular problem before and I have handled a lot of similar situations. It does sound like the third turret may not have been assigned to the fire control. Can you remember checking the fire control summary, or can you remember if you used assign all, or assigned them individually?
I seem to have run into a bit of a problem, either in my understanding of the game or a bug. Probably a bug, but we?ll see.
The situation is as follows: A group of FAC?s launch missiles at a group of four cruisers. The missiles are launched at 167,000 km?s, and travel at 18,000 kps. The cruisers are armed with three dual 12 cm laser turrets each, each of which have a ROF of five. I calculated things out and realized that the cruisers should be able to get in two point defense shots with their lasers, once at approximately 77,000 km?s and the second time at point blank range. Accordingly, I set the ship?s fire control to area point defense 8, so that they would engage targets out to 80,000 km?s.
The first course of fire against the incoming missiles went off okay, although there was something strange. The four cruisers have a total of twelve double turrets, for a total of twenty-four lasers. They fired as planned, but only two of the three turrets on each ship engaged, strangely enough. While it is possible that this is due to an error in setting up the fire on my part, I don?t think it was as I set up one ship and copied its fire control settings throughout the fleet, then hit the open fire button for the entire fleet. Still, it is possible that I set that last turret on each ship to something different.QuoteAt any rate, after this course of fire, I reset the fire control for the entire fleet to point blank 1, and hit the open fire button for the entire fleet. This time none of the lasers engaged, not even the turrets that hadn?t fired in the first round. The notation in the Event Update screen noted for the first two turrets on the first cruiser as follows: ?Twin 12cm C4 Near Ultraviolet Laser Turret recharging. 0 power in capacitor. 8 power required to fire.? None of the other ship?s turrets are listed as even trying to fire.The problem here is that the lasers did not have time to recharge. Weapons recharge during the fire phase, which follows the movement phase. As you fired the lasers in the fire phase of the first increment, they didn't have time to recharge before the movement phase of the second increment. Here is a link to the sequence of play:
http://aurora.pentarch.org/viewtopic.php?t=532 (http://aurora.pentarch.org/viewtopic.php?t=532)
This is one of the reasons I added the options for point blank and area fire so you can decide whether to hold lasers back for last second defensive fire during the movement phase or use them for long range interceptions. It's interesting that the third turret didn't fire though as that should still have been charged. Can you check it is assigned to the fire control in question?QuoteOne question occurs immediately ? what does ?Power 8-8? mean. Eight units of power in eight seconds? If so, what does ROF 5 mean?ROF = Rate of Fire. Given enough power the turrets will fire every 5 seconds. Power 8-8 means the turrets require 8 power to fire (the first digit) and they can receive that power at up to 8 every 5 second increment (the second digit). For example the following laser requires 6 power to fire and can receive that power at 2 per five second increment (due to the type of capacitor), which gives it a ROF of 15 seconds.
15cm C2 Visible Light Laser (4) Range 96,000km TS: 3200 km/s Power 6-2 RM 2 ROF 15QuoteLooking at the tech report screen, the 12cm C4 NU Laser has the following stats:That is the basic laser but once you combine lasers into a turret, the turret itself effectively becomes a new weapon type. In this case a 12cm laser that fires 2 shots every 5 seconds and requires 8 power every 5 seconds.
Power: 4
Recharge Rate: 4
Max Rate of Fire: 5 secondsQuoteIf I did something wrong, I can?t understand what it would have been. It is always possible that I don?t understand something that I think I understand, of course. Otherwise, the problem may be in the recharge calculations, or in the turn sequence. Do weapons recharge after firing, or before?Weapons charge at the start of the firing phase, which follows movement. As you guessed, the sequence of play was the reason the lasers couldn't fire. Without completing a full cycle of the sequence of play they would have fired twice in less than 5 seconds, or put another way the missiles would have travelled the distance from the first firing point to the ship in less than 5 seconds. By holding them for point blank fire the lasers would be ready to fire at exactly the right moment.
Steve
Okay, I understand now. If the firing in the second turn was taking place during the fire sequence, then the lasers would have fired because they would have had time to charge, but because point blank point defense fire takes place during movement, the lasers didn't have time to charge. All is clear now.
I still don't understand what is happening with the third turret, and unfortunately, the battle where this came up is over and the involved ships were destroyed. I'll check the other ships of the same class in the same system to see how their turrets were set up.
I am 100% certain that the third turret was assigned to a fire control, but it is possible that in error they were assigned to the same fire control as turrets one or two, instead of a different fire control. I'll check.
Kurt
Post by: Charlie Beeler on April 07, 2008, 02:27:40 PM
If I understand correctly, Kurt could set point defense to point blank and 9 and petentially get 2 shots at the incoming missiles during movement (fire during missile movement turn 1, recharge weapons turn 1, fire again during missile movement turn 2).
Post by: Kurt on April 07, 2008, 05:41:38 PM
Quote from: "Haegan2005"
Kurt, wouldn't a missile moving at 18,000 kps move 90,000 km in 5 seconds? Your PD should, at best, get one shot at it. This assumes that the rules for this have not changed since 2.0.
You are correct that the missile moved 90,000 km's, however, my plan was that the missiles started at 167,000 km's on turn 0, and on turn 1 they moved to 77,000 km's and my lasers engaged with area point defense 8 setting. They did engage as I planned, and after firing at 77,000 km's, I reset the point defense fire control to point blank 1, and it was my hope (and belief) that they would engage a second time at 10,000 km's. They did not, and I was confused until Steve pointed out that the turn sequence meant that the lasers didn't have time to recharge.
Standard charging and firing takes place during combat, which is after moving. Point blank point defense firing takes place during movement, which means that the lasers, which fired last turn at 77,000 km's, didn't have time to recharge yet.
Kurt
Post by: Erik L on April 07, 2008, 06:06:30 PM
Quote from: "Kurt"
Quote from: "Haegan2005"Kurt, wouldn't a missile moving at 18,000 kps move 90,000 km in 5 seconds? Your PD should, at best, get one shot at it. This assumes that the rules for this have not changed since 2.0.
You are correct that the missile moved 90,000 km's, however, my plan was that the missiles started at 167,000 km's on turn 0, and on turn 1 they moved to 77,000 km's and my lasers engaged with area point defense 8 setting. They did engage as I planned, and after firing at 77,000 km's, I reset the point defense fire control to point blank 1, and it was my hope (and belief) that they would engage a second time at 10,000 km's. They did not, and I was confused until Steve pointed out that the turn sequence meant that the lasers didn't have time to recharge.
Standard charging and firing takes place during combat, which is after moving. Point blank point defense firing takes place during movement, which means that the lasers, which fired last turn at 77,000 km's, didn't have time to recharge yet.
Kurt
So if you'd have set the PD to 10, they should have engaged during movement at 96,000km, recharged in the fire phase and engaged again the next move phase. Correct?
Post by: Haegan2005 on April 07, 2008, 08:17:43 PM
Quote
You are correct that the missile moved 90,000 km's, however, my plan was that the missiles started at 167,000 km's on turn 0, and on turn 1 they moved to 77,000 km's and my lasers engaged with area point defense 8 setting. They did engage as I planned, and after firing at 77,000 km's, I reset the point defense fire control to point blank 1, and it was my hope (and belief) that they would engage a second time at 10,000 km's. They did not, and I was confused until Steve pointed out that the turn sequence meant that the lasers didn't have time to recharge.
Standard charging and firing takes place during combat, which is after moving. Point blank point defense firing takes place during movement, which means that the lasers, which fired last turn at 77,000 km's, didn't have time to recharge yet.
Kurt
Post by: Steve Walmsley on April 08, 2008, 05:36:19 AM
Quote from: "Charlie Beeler"
Steve please correct any misconception I've injected here.
If I understand correctly, Kurt could set point defense to point blank and 9 and petentially get 2 shots at the incoming missiles during movement (fire during missile movement turn 1, recharge weapons turn 1, fire again during missile movement turn 2).
The only time that point defence gets to fire during movement is for point blank defence. The reason that point blank defence has a range is for those situations where one ship is using point blank defence to guard a second ship. In gameplay terms, setting missiles to point blank defence gives you the advantage of intercepting missiles during movement and at the best possible chance to hit. Setting area defence allows you to attack any missile in range during the fire phase, regardless of its target or when it will arrive at its target. Area defence is best for either escort ships positioned on the threat axis (probably through setting up a formation), because they can shoot at missiles as they approach and again as they pass, or for ships with long range armament that will get two shots or more before point blank defence is required.
In any event, the player would also presumably want the point defence system to fire at the moment where it has the best chance to hit, which is either at the end of the movement phase anyway, if the missile hasn't reached its target yet, or at the point just before it reaches its target, which is covered by point blank defence. However, you can't have the best of both worlds where you fire at the end of movement in the first increment and then fire again before the end of movement in the next increment, because less than 5 seconds will have passed and the point defence system won't have recharged.
The exception to the best chance of hitting being after movement might be when an escort is firing at a passing target where the best chance to hit is actually halfway through the movement phase. However, to handle this I would have to calculate the chance to hit for every point defence system vs every missile salvo for each location through which each missile salvo would pass during an increment. That would be extremely complex and would have a significant hit on performance. Besides, it may be that by firing during the fire phase rather than mid-movement the escort gets two shots as the missile approaches and then leaves, rather than one shot at the closest point, and those two shots combined give it a better chance. Ther permutations are just too complex to calculate, which is why I went for the two options of area defence or point blank defence
Steve
Post by: Steve Walmsley on April 08, 2008, 05:49:39 AM
Quote from: "Erik Luken"
So if you'd have set the PD to 10, they should have engaged during movement at 96,000km, recharged in the fire phase and engaged again the next move phase. Correct?
If you set area defence with range of 100,000km, the point defence will engage the closest missiles within 100,000km during each fire phase. If you set point blank defence with 100,000 range, the point defence will fire to defend any ship within 100,000km that is about to be hit by a missile during the movement phase. In effect, point blank mode prevents the point defence system from firing during the fire phase phase so it is guaranteed to be ready to fire against a missile about to hit its target during the following movement phase.
Steve
Post by: Charlie Beeler on April 08, 2008, 08:03:01 AM
Area Mode - assigned weapons fire during Fire Phase, if charged/loaded, at nearest missile salvo within set range provided weapon (beam anyway since missiles will launch even if target is out of actual missile range), fire control, and sensors are able to function at actual target range.
Point Blank Mode - assigned weapons fire during Missile Salvos movement sub-phase of the Movement Phase at the nearest missile salvo with the same range cavets as Area Mode. The other functional difference is that fire will be attempted at effective range too missile at the missiles target just prior to impact/detonation. (do laser heads affect this?)
Point Blank Mode (self defense) - Not sure how much of a programatic/functional difference there is here from non-self defense Point Blnak Mode.
For example purposes I'm assuming that the defending fire control is set to Point Blank Mode with range set at 9 for 90K km and that the beams assigned have a 5 sec ROF and sufficent reactor power to support.
An enemy missile traveling at 18k/kps moves to 90k/km from the defending ship. These missiles are the closest identified enemy missiles so they are engaged during the same movement phase that they entered range. Not all missiles in the salvo attacked are killed.
During the first sub-phase of the following Fire Phase the beams are recharged.
Time increment set 5 seconds.
My assumption to this point was that since the weapons are 5 sec ROF and recharged the previous Fire Phase they would be available for Point Blank/Intercept fire during the next Missile Salvo Movement sub-phase of the Movement phase. If I understand you correctly, intercept is not considered to be less than 5 seconds for ROF purposes and the beams are not allowed to fire for final intercept. But... if the missiles target had been moving away so that the missiles did not intercept thier target during this movement phase then the 5 seconds is satisfied and the beams will again attempt to fire.
I just realized I've been making the assumption that both Area and Point Blank modes have thier maximum range limited by the fire control. Is there a seperate maximum range that is less than the fire control range for Point Blank Mode?
Post by: Steve Walmsley on April 08, 2008, 08:35:38 AM
Quote from: "Charlie Beeler"
I'm probably over simplifying this in my own mind.Correct
Area Mode - assigned weapons fire during Fire Phase, if charged/loaded, at nearest missile salvo within set range provided weapon (beam anyway since missiles will launch even if target is out of actual missile range), fire control, and sensors are able to function at actual target range.
Quote
Point Blank Mode - assigned weapons fire during Missile Salvos movement sub-phase of the Movement Phase at the nearest missile salvo with the same range cavets as Area Mode. The other functional difference is that fire will be attempted at effective range too missile at the missiles target just prior to impact/detonation. (do laser heads affect this?)Point Blank mode will only work against missiles that are just about to hit their targets (i.e. at point blank range). They won't fire at any other targets. They don't fire at the nearest target; they fire at the first qualifying target during the movement phase. They also will not fire at any missiles that do not reach their targets during that movement phase. The actual mechanics are that missile salvos move in ascending order of speed. If any salvo reaches its target, resolution of the salvo vs the target is halted while the program checks for any point defence set to point blank mode. The first ship to be checked is the target ship which is treated as firing at 10,000 km. Next to be checked are any other ships set to point blank mode that are within the range set for that mode. So if another ship is 60,000 kilometers away with point defence set to point blank mode and a range of 100,000 kilometers, it will also be eligible to protect the attacked ship. Point blank mode is a way to prevent a ship from firing during the fire phase so its weapons are charged and ready during the movement phase and can engage missiles as they attack their targets.
Quote
Point Blank Mode (self defense) - Not sure how much of a programatic/functional difference there is here from non-self defense Point Blank Mode.The difference is that a ship with this setting will only use its point defence to protect itself whereas a ship with the first setting will protect any ship within its range. So you might set a capital unit to only protect itself while its escorts would be set to protect any ship in range.
Quote
For example purposes I'm assuming that the defending fire control is set to Point Blank Mode with range set at 9 for 90K km and that the beams assigned have a 5 sec ROF and sufficent reactor power to support.The point defence will not engage the missiles in this example because it will only engage missiles that reach their targets. The reason for this is to ensure the point defence is available when needed the most. For example, assume the attacking missiles are travelling at 20,000 km/s and the point defence is set to 60,000 km in PB mode. The missiles appear at 160,000 kilometers. In the next 5 seconds they move to 60,000 kilometers. If the PD was in Area mode it would engage these missiles during the fire phase. As it is in point-blank mode it ignores them. During the second increment the missiles reach the ship and the point blank mode point defence engages before the missiles attack is resolved. Note that if the point defence had fired at 60,000 kilometers, it would not have recharged in time because the missiles would cover the 60,000 kilometers in 3 seconds and attack mid-way through the movement phase. By setting the PD to point blank, it doesn't fire and is therefore available to shoot at the missiles midway through the movement phase.
An enemy missile traveling at 18k/kps moves to 90k/km from the defending ship. These missiles are the closest identified enemy missiles so they are engaged during the same movement phase that they entered range. Not all missiles in the salvo attacked are killed.
Quote
During the first sub-phase of the following Fire Phase the beams are recharged. Time increment set 5 seconds.Point blank mode point defence will recharge between movement phases as it recharges during the fire phase. However, it can only be used against missiles actually attacking their targets. It cannot fire after movement is completed because then it would effectively be firing in the fire phase and would not be able to recharge fast enough (in reality) to hit something midway through the next movement phase, which would less than 5 seconds later. If you want point defence to fire at missiles that have completed movement, it needs to be set to area mode.
My assumption to this point was that since the weapons are 5 sec ROF and recharged the previous Fire Phase they would be available for Point Blank/Intercept fire during the next Missile Salvo Movement sub-phase of the Movement phase. If I understand you correctly, intercept is not considered to be less than 5 seconds for ROF purposes and the beams are not allowed to fire for final intercept. But... if the missiles target had been moving away so that the missiles did not intercept their target during this movement phase then the 5 seconds is satisfied and the beams will again attempt to fire.
Quote
I just realized I've been making the assumption that both Area and Point Blank modes have thier maximum range limited by the fire control. Is there a seperate maximum range that is less than the fire control range for Point Blank Mode?
The maximum range is based on the fire control range, point defence mode range and weapon range, whichever is the least. The range for area mode is the maximum range at which the point defence wil engage any missile target. The max range for point blank mode is that maximum range at which the fire control will protect another ship that is currently resolving an attack by missiles
Steve
Post by: Charlie Beeler on April 08, 2008, 10:01:06 AM
So, for anything other than final defense you need to use area mode. But, if you plan to switch modes from area to point blank you need to plan for 10 seconds leed not 5.
Post by: Steve Walmsley on April 08, 2008, 10:33:22 AM
Quote from: "Charlie Beeler"
Steve thanks for the quick reply. I knew that I had to be missing/overlooking something obvious.
So, for anything other than final defense you need to use area mode. But, if you plan to switch modes from area to point blank you need to plan for 10 seconds leed not 5.
I think using your term of final defence is actually a better description than point blank fire. So for v3.0 point blank mode becomes Final Defensive Fire and Final Defensive Fire (Self Only). Area Mode is now Area Defence.
Steve
Post by: Haegan2005 on April 08, 2008, 01:27:47 PM
Post by: sloanjh on April 08, 2008, 02:09:15 PM
In Kurt's case, the missiles were going to be within the engagement envelope for 9 seconds. Assuming the capacitors were already charged up, that means he should be able to get two shots off - one at e.g. 5.5 seconds before impact (SBI) and the next at 0.5 SBI. In this simple case, I think it's reasonable to assume that the ship's computers would be able to figure out that they should fire at 5.5 SBI and again at 0.5 SBI, rather than taking a single shot at 4.5 SBI.
The issue is that the time granularity in Aurora is 5 seconds, so that the end of the first timestep that the missiles are in range is only e.g. 4.5 SBI. So, due to the 5 second granularity, the final defensive fire only gets one shot at 4.5 SBI rather than two at 5.5 and 0.5. Even though the hit probability at 4.5 SBI is probably bettern than at 5.5, it's probably not as good as the combined 2-shot probability. If the timestep were 0.1 seconds, Kurt would have been able to get two shots in by doing what he tried to do.
The only thing I can think of to address this issue is to make the final defensive fire calculator smart enough to figure out when the next salvo will be hitting and adjust the time of the first shot so that the capacitors are recharged just in time for an additional point-black shot. In terms of the code, I suspect this means putting e.g. a 0.1 second granularity on the charge state of capacitors, so that they can be fractionally charged at the end of a 5 second timestep.
John
Post by: Charlie Beeler on April 08, 2008, 03:07:34 PM
I don't think that Steve is advancing time in smaller increments than 5 seconds. (Steve correct this if I wrong)
In that case, with a 9 second window point defense will only get 1 shot. If the mode is area then it is at longer range. If it is point(final) mode then just prior to impact. Because of the sequence of play there isn't enough time for engagement at longer range with area mode, switch mode during the next time hack, recharge the lasers and engage in point blank/final defense mode.
I was having a problem with this in most of my games. I tend to design 10cm lasers with fairly long range (wave lengths that allow at least 150k) so that I can use longer range area mode and then switch to point blank for final defense. I had miss were in the sequence the capacitors recharge so I was constantly swithing the modes when the range to the missiles was too short to get that last shot. With recharge at the beginning of the Firing Phase and not the start of the turn means you have to plan for a non-firing "turn" for mode switch and capacitor recharge.
Post by: Erik L on April 08, 2008, 03:48:55 PM
Quote from: "Haegan2005"
Steve, could you also condense and post this PD explaination in the Academy as well? It is the best explaination I have seen yet and don't want it lost due to aging of posts.
I've made sure that is turned off after the last time it happened. The only issue will be the posts being pushed down past page 1.
Post by: Steve Walmsley on April 08, 2008, 04:33:48 PM
Quote from: "sloanjh"
I think there is an issue here, but I don't have a good suggestion for how to solve it.Only if they knew that their own lasers wouldn't be needed to protect another ship less than 5 seconds later and the incoming missile didn't have a faster second stage and the ship wouldn't be changing direction or course in the next movement phase and it wouldn't take engine damage and a different ship's area defence wasn't going to take the missile out anyway and the hostile fire control guiding the missile didn't change targets or the missile wasn't on internal guidance and was going to change targets because something else moved closer, etc. It would just get completely out of hand in terms of complexity. Its far easier to have one mode that fires during the certainty of the fire phase and a second mode that waits until the certainty of the last fraction of a second for the best possible shot.
In Kurt's case, the missiles were going to be within the engagement envelope for 9 seconds. Assuming the capacitors were already charged up, that means he should be able to get two shots off - one at e.g. 5.5 seconds before impact (SBI) and the next at 0.5 SBI. In this simple case, I think it's reasonable to assume that the ship's computers would be able to figure out that they should fire at 5.5 SBI and again at 0.5 SBI, rather than taking a single shot at 4.5 SBI.
Quote
The issue is that the time granularity in Aurora is 5 seconds, so that the end of the first timestep that the missiles are in range is only e.g. 4.5 SBI. So, due to the 5 second granularity, the final defensive fire only gets one shot at 4.5 SBI rather than two at 5.5 and 0.5. Even though the hit probability at 4.5 SBI is probably bettern than at 5.5, it's probably not as good as the combined 2-shot probability. If the timestep were 0.1 seconds, Kurt would have been able to get two shots in by doing what he tried to do.
The only thing I can think of to address this issue is to make the final defensive fire calculator smart enough to figure out when the next salvo will be hitting and adjust the time of the first shot so that the capacitors are recharged just in time for an additional point-black shot. In terms of the code, I suspect this means putting e.g. a 0.1 second granularity on the charge state of capacitors, so that they can be fractionally charged at the end of a 5 second timestep.
Its just not possible with the way Aurora works. Final Defensive Fire can be used to protect any ship in range so you would have to know at what time each missile is going to hit each ship, assuming all the missiles in flight and ships in motion hold their current course and speed. As each move is handled in order of initiative for fleets and speed for missiles, I would have to run the movement phase once to check what was going to happen and then run it again to do the firing, which actually might affect some of the outcomes from the first time so you would have to run it a third time, etc. Not to mention that because of the other reasons mentioned above, such as area defence taking out missiles, missile second stages kicking in, ships taking engine damage or changing speed/course or missiles changing direction or hostile fire control changing targets, etc. there is just no way to know what is going to happen in the following movement phase so you certainly can't figure out exactly when to fire in this movement phase to leave yourself exactly 5 seconds to recharge.
Steve
Post by: Steve Walmsley on April 08, 2008, 04:49:13 PM
Quote from: "Charlie Beeler"
John,
I don't think that Steve is advancing time in smaller increments than 5 seconds. (Steve correct this if I wrong)
In that case, with a 9 second window point defense will only get 1 shot. If the mode is area then it is at longer range. If it is point(final) mode then just prior to impact. Because of the sequence of play there isn't enough time for engagement at longer range with area mode, switch mode during the next time hack, recharge the lasers and engage in point blank/final defense mode.
I was having a problem with this in most of my games. I tend to design 10cm lasers with fairly long range (wave lengths that allow at least 150k) so that I can use longer range area mode and then switch to point blank for final defense. I had miss were in the sequence the capacitors recharge so I was constantly swithing the modes when the range to the missiles was too short to get that last shot. With recharge at the beginning of the Firing Phase and not the start of the turn means you have to plan for a non-firing "turn" for mode switch and capacitor recharge.
I think the issue is really that Final Defensive Fire and Area Defence are two completely different types of point defence modes designed for different situations, not two modes that a single fire control will often toggle between.
Area Defence is for escort ships away from the main body that can take several shots at missiles as they fly past or Aegis type ships that are covering a large area around the main body. Final Defensive Fire mode is for ships with short-range point defence that are waiting until the last possible moment to ensure they get the best from that point defence. Ships designed for the two modes will occupy two or three different roles within a defensive formation. Because of the uncertainty around when missiles will reach their targets, the Final Defensive Fire ships are foregoing the possibility of two shots to make sure their one shot really counts. Area Defence mode ship are using their long range weapons to get as many shots as possible with the understanding that they may not be able to time those attacks to get the best possible chances to hit, again because of the uncertainty around the actual time the missiles will reach their targets.
If a ship is going to use both modes, it needs long enough range to engage once and then change modes, which will require it to miss a fire phase so it can engage during the following movement phase at exactly the right moment. Unless it is actually the target, that ship will be far better off positioned between the target and the missiles (using the formation options on the Fleet window) so it can get several shots instead of changing modes and staying close to the target.
In v3.0 I can see four roles for escort ships. The long range defence will be provided by missile-armed escorts. Second may be ships deployed on the threat axis on the edge of a formation using long range beam weapons in area mode. Third will be units with long range beam weapons in area mode located in the main body. Finally units with fast firing, close range weapons in Final Defensive Fire mode will protect the heart of the formation.
Steve
Post by: Charlie Beeler on April 09, 2008, 08:18:59 AM
Quote from: "Steve Walmsley"
I think the issue is really that Final Defensive Fire and Area Defence are two completely different types of point defence modes designed for different situations, not two modes that a single fire control will often toggle between.
Oh, I agree that they are two different types with seperate functionality. Where they are toggled by a single fire control suite is more of a player function. It has a lot to do with the differences in fleet design concepts.
Quote
Area Defence is for escort ships away from the main body that can take several shots at missiles as they fly past or Aegis type ships that are covering a large area around the main body. Final Defensive Fire mode is for ships with short-range point defence that are waiting until the last possible moment to ensure they get the best from that point defence. Ships designed for the two modes will occupy two or three different roles within a defensive formation. Because of the uncertainty around when missiles will reach their targets, the Final Defensive Fire ships are foregoing the possibility of two shots to make sure their one shot really counts. Area Defence mode ship are using their long range weapons to get as many shots as possible with the understanding that they may not be able to time those attacks to get the best possible chances to hit, again because of the uncertainty around the actual time the missiles will reach their targets.
At a certain level I agree with these design concepts. Keep in mind that not every play will want, or even be able to afford, a balanced fleet.
In my case, until recently I've been playing one off games with the sole intent of getting ships into combat. With a starting race it's difficult, but not impossible, to have an initially balanaced fleet. (ie you don't always see fleets with missile defense escorts)
Quote
If a ship is going to use both modes, it needs long enough range to engage once and then change modes, which will require it to miss a fire phase so it can engage during the following movement phase at exactly the right moment. Unless it is actually the target, that ship will be far better off positioned between the target and the missiles (using the formation options on the Fleet window) so it can get several shots instead of changing modes and staying close to the target.
In most of my starting games I've run laser wavelength up too at least Ultra-Violet which gets me 10cm lasers with a functional range of 120k/km. Take beam fire control range to 32k and beam tracking speed to 3200kps plus capacitor 3's and you can have adiquate starting PD suites with either twin or quad turrets on each combat ship in the fleet. Yes it is mass and hull space expensive(PD fire control is 4x for range and 4x for tracking speed plus the PD turret), but it also provides a better defense in depth that having a seperate dedicated defense ship. Especially in the early game this also allows enough engagement range for 1 or 2 shots at incoming missiles in area mode and then a switch to final defense mode. The play must be on his toes and correctly run the numbers or he ends up, as I have several times, with the missiles impacting without the final shot because the capacitors are still recharging.
My point isn't that it's the correct way to design and built, but that there are other fleet concepts that other players concieve and run with.
Quote
In v3.0 I can see four roles for escort ships. The long range defence will be provided by missile-armed escorts. Second may be ships deployed on the threat axis on the edge of a formation using long range beam weapons in area mode. Third will be units with long range beam weapons in area mode located in the main body. Finally units with fast firing, close range weapons in Final Defensive Fire mode will protect the heart of the formation.
Steve
Don't get me wrong, I also think that the best defense in depth is a mix of PD suites on core ships with short range beams for final defense, intermediate escorts with long range beams for area defense and additional escorts with very long range dedicated counter missiles batteries (which is why I asked for PD capability for missiles). It's just that this type of fleet stratagy, for me anyway, is for a mature fleet.
Post by: Kurt on April 09, 2008, 09:57:21 AM
Another little bit of strangeness regarding planetary bombardment. I have a situation where twenty-two FAC's, each with two missile launchers, are firing on a planetary population. They are firing forty-four size four missiles, all of which are hitting the target.
The Event Update screen shows that the missiles hit, and an entry is generated for each missile indicating that it destroyed .5 million in population (everything else was destroyed in earlier salvoes). Forty-four missiles each doing .5 million in casualties equals 22 million dead. At the very end of the events listed on the Event Update screen for that time advance Aurora sums up the damage to the colony and correctly lists the dead as 22 million, however, when I check the main economic screen it appears that the colony only lost a couple of million. It is possible that the colony lost exactly 2.2 million, making it exactly 1/10 of the amount listed on the Event Update screen, but I didn't record the actual amounts so I'm not sure if that is true.
In any case, the colony started out with approximated 20 million in population, so based on the numbers listed on the Event Update screen it should have been wiped out in one salvo, but instead, after three salvoes, it is down to around 14 million.
It is possible that you've changed the damage missiles inflict at some point, and the Event Update screen is still displaying the old damage, or something like that.
Kurt
Post by: Kurt on April 12, 2008, 02:54:13 PM
Two more fairly minor bugs.
Bug #1: During bombardment of a planetary population, it appears that mass drivers are immune to damage from bombardment. I've had two seperate populations that suffered near total economic devastation from bombardment, and both retained all of their mass drivers.
Bug #2: I built a salvage ship, the first I've ever used, and sent it out to begin eliminating all of the numerous wrecks cluttering my system. It began working on the first wreck, and when it finally completed salvage operations, I received the following error popup:
"Error in CompleteWreckSalvage, Error 94, Invalid use of null"
I clicked through the error message and the wreck in question disappeared, as it should have, and the salvage ship moved on to the next scheduled wreck. In addition, 200 duranium were deposited in the salvage ship's hold.
Kurt
Edit: Okay, I identified the source of the error message relating to salvage. I realized that I designed my salvage ships with too little storage capacity for the resources they were salvaging. Aurora generated the error when it tried to cram the salvaged resources into a cargo area with 0 capcity.