4.0b Bugs

[Steve Walmsley]

Active Grav Sensor Strength 48 appears to have a "40" rather than a "48" in the database - it's only a hair stronger than the "36" version.

Well spotted. Fixed for v4.1

Steve

[Steve Walmsley]

I don't know if this is really a bug or me just not understanding something.  I thought that designing a turret that is faster than the researched speed would add additional mass.  This does not seem to be the case.

Increasing the tracking speed will increase the gear size, which will increase the overall size. However, a turret size is rounded up to the nearest integer so you can sometimes add a little more speed without increasing size.

Steve

[Charlie Beeler]

I don't know if this is really a bug or me just not understanding something.  I thought that designing a turret that is faster than the researched speed would add additional mass.  This does not seem to be the case.

Increasing the tracking speed will increase the gear size, which will increase the overall size. However, a turret size is rounded up to the nearest integer so you can sometimes add a little more speed without increasing size.

Steve

me thinks me needs more sleep  

I wasn't seeing the space changing, but know I do.

[rdgam]

I have conquered two NPC races and had this happen to me both times.

All the ships surrender to me except for the gravsurvey ships.  They are NPRFleetType 60.
 
They stay around with the NPR who owns no colonies or other ships.  They keep surveying and adding to his systems.

[Father Tim]

They're supposed to, at least until they run out of fuel and/or supplies.  There's always the chance they'll find a perfect colony site, or alien ruins, or a backdoor into your systems, or something else that will aid in the fight.  that is, of course, assuming they even know about the fight.  If they're in another system chances are they don't have communication with the homeworld, so they might not even know the government has surrendered.

[Erik L (OP)]

They're supposed to, at least until they run out of fuel and/or supplies.  There's always the chance they'll find a perfect colony site, or alien ruins, or a backdoor into your systems, or something else that will aid in the fight.  that is, of course, assuming they even know about the fight.  If they're in another system chances are they don't have communication with the homeworld, so they might not even know the government has surrendered.

But if they are not in contact (to surrender), then how does the central gov't know of the new systems being explored? This would require a communications chain via warpgate, jump ships or something like courier drones.

I understand why from how it's programmed, being that it's easier to assume instant knowledge from a programmatic point of view. Though that does make things interesting if the central gov't (or player) does not know about what is there until the survey ships have returned.

[rdgam]

But civilian and NPR ships don't use fuel or maintenance, so they never run out.

Plus the ships were in the system where the geosurvey ships surrendered (I checked the DB).  I had a fleet in that system as well.

[Kurt]

Steve –

This situation occurred in version 3.11, but I assume it would happen in 4.0b as well.  

I had a situation occur recently that illustrated an interesting “loophole” in Aurora’s anti-missile engagement programming.  The situation was as follows:

A large missile salvo consisting of 1,140 missiles was detected by planetary (thermal) sensors while still 38 million kilometers (mkm) away from the planet.  The planetary anti-missile missile launchers were set to 5v1, and to engage at 3 or 4 mkm’s.  Immediately after detecting the incoming missile wave the planetary launchers began launching AMM’s in large numbers, in spite of the fact that the incoming missile wave was far beyond their supposed engagement range.  After several launches the defenders had hundreds of AMM’s in space and I was thoroughly confused.   There was no way that the defenders should be launching at missiles at 38 mkm’s.  I was ready to write up an error report on the situation and post it, when I realized what was really going on.  

The real reason that the launchers were launching was that they were targeting the four enemy drones orbiting their planet at 3 mkm’s.  The drones were well within the specified engagement range, so the launchers were launching their missiles against them.  That was fine and the seeming problem was solved.  As usual I just didn’t understand Aurora’s logic.  However, having realized that, I also realized that there was still a problem.  During the time period that it took to figure this out, the defenders had launched approximately 450 AMM’s against a grand total of four drones.  Obviously that was far in excess of 5v1.  What was really going on was that Aurora was launching because there were targets within engagement range (the drones), but it was calculating the number of AMM’s to launch based on the TOTAL number of targets DETECTED, rather than within engagement range.  Using that logic, the defenders would have launched 5500 AMM”s, or at least they would have tried to, right up to the point where the drones were destroyed and the launchers would have stopped launching because there were no more targets within engagement range (which is what exactly happened).  

Now, this was not a disaster because I was using version 3.11, and was forced to design my AMM’s with a quarter MSP of endurance, giving them hours of endurance, meaning that they were still in space when the attack missile wave came into range.  In 4.0b, where people can design AMM’s with reasonable amounts of fuel appropriate to their mission, AMM’s usually have total flight times of minutes or less.  Having this happen in 4.0b would be a problem, leading to the squandering of AMM’s and the possible dilution of defenses.  

Kurt

[Erik L (OP)]

Steve –

This situation occurred in version 3.11, but I assume it would happen in 4.0b as well.  

I had a situation occur recently that illustrated an interesting “loophole” in Aurora’s anti-missile engagement programming.  The situation was as follows:

A large missile salvo consisting of 1,140 missiles was detected by planetary (thermal) sensors while still 38 million kilometers (mkm) away from the planet.  The planetary anti-missile missile launchers were set to 5v1, and to engage at 3 or 4 mkm’s.  Immediately after detecting the incoming missile wave the planetary launchers began launching AMM’s in large numbers, in spite of the fact that the incoming missile wave was far beyond their supposed engagement range.  After several launches the defenders had hundreds of AMM’s in space and I was thoroughly confused.   There was no way that the defenders should be launching at missiles at 38 mkm’s.  I was ready to write up an error report on the situation and post it, when I realized what was really going on.  

The real reason that the launchers were launching was that they were targeting the four enemy drones orbiting their planet at 3 mkm’s.  The drones were well within the specified engagement range, so the launchers were launching their missiles against them.  That was fine and the seeming problem was solved.  As usual I just didn’t understand Aurora’s logic.  However, having realized that, I also realized that there was still a problem.  During the time period that it took to figure this out, the defenders had launched approximately 450 AMM’s against a grand total of four drones.  Obviously that was far in excess of 5v1.  What was really going on was that Aurora was launching because there were targets within engagement range (the drones), but it was calculating the number of AMM’s to launch based on the TOTAL number of targets DETECTED, rather than within engagement range.  Using that logic, the defenders would have launched 5500 AMM”s, or at least they would have tried to, right up to the point where the drones were destroyed and the launchers would have stopped launching because there were no more targets within engagement range (which is what exactly happened).  

Now, this was not a disaster because I was using version 3.11, and was forced to design my AMM’s with a quarter MSP of endurance, giving them hours of endurance, meaning that they were still in space when the attack missile wave came into range.  In 4.0b, where people can design AMM’s with reasonable amounts of fuel appropriate to their mission, AMM’s usually have total flight times of minutes or less.  Having this happen in 4.0b would be a problem, leading to the squandering of AMM’s and the possible dilution of defenses.  

Kurt

Isn't this Working As Intended(tm)?

If there is 1 incoming bogey, and I fire 5 AMM at it, and 5 minutes later, the 5 miss, then I need to launch another 5. I'd much rather have backup flights of AMM out there to be diverted to another target. Just in case.

[Kurt]

Steve –

This situation occurred in version 3.11, but I assume it would happen in 4.0b as well.  

I had a situation occur recently that illustrated an interesting “loophole” in Aurora’s anti-missile engagement programming.  The situation was as follows:

A large missile salvo consisting of 1,140 missiles was detected by planetary (thermal) sensors while still 38 million kilometers (mkm) away from the planet.  The planetary anti-missile missile launchers were set to 5v1, and to engage at 3 or 4 mkm’s.  Immediately after detecting the incoming missile wave the planetary launchers began launching AMM’s in large numbers, in spite of the fact that the incoming missile wave was far beyond their supposed engagement range.  After several launches the defenders had hundreds of AMM’s in space and I was thoroughly confused.   There was no way that the defenders should be launching at missiles at 38 mkm’s.  I was ready to write up an error report on the situation and post it, when I realized what was really going on.  

The real reason that the launchers were launching was that they were targeting the four enemy drones orbiting their planet at 3 mkm’s.  The drones were well within the specified engagement range, so the launchers were launching their missiles against them.  That was fine and the seeming problem was solved.  As usual I just didn’t understand Aurora’s logic.  However, having realized that, I also realized that there was still a problem.  During the time period that it took to figure this out, the defenders had launched approximately 450 AMM’s against a grand total of four drones.  Obviously that was far in excess of 5v1.  What was really going on was that Aurora was launching because there were targets within engagement range (the drones), but it was calculating the number of AMM’s to launch based on the TOTAL number of targets DETECTED, rather than within engagement range.  Using that logic, the defenders would have launched 5500 AMM”s, or at least they would have tried to, right up to the point where the drones were destroyed and the launchers would have stopped launching because there were no more targets within engagement range (which is what exactly happened).  

Now, this was not a disaster because I was using version 3.11, and was forced to design my AMM’s with a quarter MSP of endurance, giving them hours of endurance, meaning that they were still in space when the attack missile wave came into range.  In 4.0b, where people can design AMM’s with reasonable amounts of fuel appropriate to their mission, AMM’s usually have total flight times of minutes or less.  Having this happen in 4.0b would be a problem, leading to the squandering of AMM’s and the possible dilution of defenses.  

Kurt

Isn't this Working As Intended(tm)?

If there is 1 incoming bogey, and I fire 5 AMM at it, and 5 minutes later, the 5 miss, then I need to launch another 5. I'd much rather have backup flights of AMM out there to be diverted to another target. Just in case.

I don't think that is as intended.  After all, that is the whole point of 1v1, 2v1...5v1, is that is what is providing backup.  After all, it won't provide that sort of backup unless there is a massive missile wave far beyond engagement range but within detection range.  In my example above, the defenders launched over 400 AMM's when there were only four drones within engagement range, which is far beyond overkill.  The only thing that salvaged the situation was that the AMM's have an endurance measured in hours, which is an artifact of the v3.11 design situation.  Thus, they could loiter until the massive missile wave came into engagement range.  

Kurt

[sloanjh]

On the "Fuel Report" screen (ctrl-F12), the "exclude ships in shipyard" checkbox doesn't filter out ships in an overhaul state.  I suspect this changed when overhaul responsibilities were taken away from shipyards, since technically ships in overhaul aren't in a shipyard anymore.

John

[Charlie Beeler]

This one appears to be in the events screen.  

I have a Geo Survey TG that was part of a group manually split from the original survey tg sent to survey a new system with the transit and divide tg order.  Primary default is survey nearest planet with secondary of survey nearest planet or moon.  Default actually works as specified.  

Here's the screwy part.  When the secondary is switched too the events log lists a plotted move from a task group in another system as the secondary default being ordered.  When I review the TG screen for the Survey TG the correct order was assigned.


Heres another one.  

A Grav survey TG had a conditional order to refuel at 30% condition.  Orders triggered as expected.  When I reviewed the fuel report to verify the range remaining and the TG's time/distance (set to all orders) it should have had enough fuel to get home without refueling with fuel to spare.  The ship ranout about half way.  


One last one.

The system map tool for range/bearing checking appears too be a decimal place off to the right.

[Charlie Beeler]

This one appears to be in the events screen.  

I have a Geo Survey TG that was part of a group manually split from the original survey tg sent to survey a new system with the transit and divide tg order.  Primary default is survey nearest planet with secondary of survey nearest planet or moon.  Default actually works as specified.  

Here's the screwy part.  When the secondary is switched too the events log lists a plotted move from a task group in another system as the secondary default being ordered.  When I review the TG screen for the Survey TG the correct order was assigned.


Heres another one.  

A Grav survey TG had a conditional order to refuel at 30% condition.  Orders triggered as expected.  When I reviewed the fuel report to verify the range remaining and the TG's time/distance (set to all orders) it should have had enough fuel to get home without refueling with fuel to spare.  The ship ranout about half way.  


One last one.

The system map tool for range/bearing checking appears too be a decimal place off to the right.

[Steve Walmsley]

I have conquered two NPC races and had this happen to me both times.

All the ships surrender to me except for the gravsurvey ships.  They are NPRFleetType 60.
 
They stay around with the NPR who owns no colonies or other ships.  They keep surveying and adding to his systems.

That was intentional for a couple of reasons. Firstly, they may find some assistance and where there is life there is hope. Unlike other ships they can find and explore new systems. As a secondary effect they may activate new NPRs, which is a way for the program to add new NPRs to the game that you don't meet by entering their home system.

Steve

[Steve Walmsley]

The system map tool for range/bearing checking appears too be a decimal place off to the right.

I can't reproduce this one. Do you mean it is showing 50m kilometers when it should be showing 5m?

Steve