Aurora 4x

C# Aurora => C# Bug Reports => Topic started by: Steve Walmsley on October 11, 2020, 07:26:16 AM

Title: v1.12.0 Bugs Thread
Post by: Steve Walmsley on October 11, 2020, 07:26:16 AM
Please post potential bugs in this thread for v1.12.0.

Please check the Known Issues post before posting so see if the problem has already been identified or is working as intended.
http://aurora2.pentarch.org/index.php?topic=10637.0

'Me too' posts for unresolved bugs are fine as it shows they are affecting more than one person. Any extra information you can provide in 'me too' posts is very welcome.

Please do not post bugs from previous versions unless you confirm they are still present in v1.12.0

When you post, please post as much information as possible, including:
The function number
The complete error text
The window affected
What you were doing at the time
Conventional or TN start
Random or Real Stars
Is your decimal separator a comma?
Is the bug is easy to reproduce, intermittent or a one-off?
If this is a long campaign - say 75 years or longer - let me know the length of the campaign as well
Title: Re: v1.12.0 Bugs Thread
Post by: Steve Walmsley on October 11, 2020, 07:57:03 AM
I'll report the first bug myself :)

Using the update all formations option for Change Template causes an object reference problem - fixed for v1.12.1.
Title: Re: v1.12.0 Bugs Thread
Post by: Demonius on October 11, 2020, 09:30:29 AM
Select Name in Class Design did not work immediately - I had to manually rename a ship before the funtion started to work as intended.

New 1.12 standard known stars start in Sol with Planet X.

Unconfirmed: works perfectly for me. -Garfunkel
Title: Re: v1.12.0 Bugs Thread
Post by: Llamageddon on October 11, 2020, 11:54:48 AM
It might be a once off, but I just started a new game to regenerate the Sol system and the game just hung (Not responding) when I clicked Create Race. I waited a while to see if it was just sorting out something complicated in the background. The New Game options window stayed open and in colour whilst the System Map window went blank. I just thought I'd mention it in case other people have the same thing happen and it wasn't just my computer glitching. I didn't do anything unusual, unchecked Known Star Systems, generated Planet X and, set system bodies and jump points to surveyed.

Unconfirmed: works perfectly for me. -Garfunkel
Title: Re: v1.12.0 Bugs Thread
Post by: Tikigod on October 11, 2020, 01:05:24 PM
Select Name in Class Design did not work immediately - I had to manually rename a ship before the funtion started to work as intended.

New 1.12 standard known stars start in Sol with Planet X.

I've found that typically happens when I am using (or have used) the 3rd party mod that allows UI customisation in a campaign. Just wanna check you're not using that mod and potentially reporting a bug related to it as a vanilla Aurora bug.
Title: Re: v1.12.0 Bugs Thread
Post by: Iceranger on October 11, 2020, 02:50:16 PM
Hi Steve,

I guess this is an oversight: in C# fuel tank costs are reduced, but the compressed tanks still have their VB6 costs, making them 7~10x more expensive than the normal version.

(https://cdn.discordapp.com/attachments/402321466839793664/764937464720523284/unknown.png)

SJW: Fixed for the next DB release
Title: Re: v1.12.0 Bugs Thread
Post by: SerBeardian on October 11, 2020, 04:05:04 PM
Railguns have a spinal dropdown when designing. No effect on the actual component stats though.

Confirmed. Both Spinal Mount and Advanced Spinal Mount show up and neither has any effect. -Garfunkel

SJW: I was playing around with Spinal Railguns and forgot to remove it :)
Title: Re: v1.12.0 Bugs Thread
Post by: MarcAFK on October 11, 2020, 11:16:55 PM
Minor display issue.
Formation Templates window doesn't show the number of HQ capacity correctly under 'template attributes' .  The Number appears to be stuck at 1000 no matter what.
I believe this issue was present in older versions too.

Unconfirmed. Shows HQ58 instead of HQ58600 so it is shortened but it is not stuck at 1000. This works regardless of the position of the HQ in the unit list. Both in "Template Attributes" and in "Element Attributes" -Garfunkel
Title: Re: v1.12.0 Bugs Thread
Post by: Demonius on October 12, 2020, 03:04:20 AM
Select Name in Class Design did not work immediately - I had to manually rename a ship before the funtion started to work as intended.

New 1.12 standard known stars start in Sol with Planet X.

I've found that typically happens when I am using (or have used) the 3rd party mod that allows UI customisation in a campaign. Just wanna check you're not using that mod and potentially reporting a bug related to it as a vanilla Aurora bug.

not using any mods, but as it worked for others might have been a fluke on my side.
Title: Re: v1.12.0 Bugs Thread
Post by: dlathro1 on October 12, 2020, 10:18:42 AM
Select Name in Class Design did not work immediately - I had to manually rename a ship before the funtion started to work as intended.

New 1.12 standard known stars start in Sol with Planet X.

I've found that typically happens when I am using (or have used) the 3rd party mod that allows UI customisation in a campaign. Just wanna check you're not using that mod and potentially reporting a bug related to it as a vanilla Aurora bug.

not using any mods, but as it worked for others might have been a fluke on my side.

Did you click on the ship class before attempting to rename it? The class name should be highlighted in blue before you attempt to use "Select Name". Weirdly, "Rename" does not require the name to be highlighted.
Title: Re: v1.12.0 Bugs Thread
Post by: arty on October 12, 2020, 10:29:09 AM
Hi all

I cant find the order transfer fuel to colony anymore ? ship is a harvester with a fuel hub  or tanker with fuel hub cant transfer also

when i select earth there is no order to transfer fuel

thanks

arty
Title: Re: v1.12.0 Bugs Thread
Post by: Llamageddon on October 12, 2020, 10:42:10 AM
Hi all

I cant find the order transfer fuel to colony anymore ? ship is a harvester with a fuel hub  or tanker with fuel hub cant transfer also

when i select earth there is no order to transfer fuel

thanks

arty

There is a bug where 0.001 of an instilation can be missing but will display as 1 on the Economics window. If you try to load an installation it might show up there as missing. Maybe one of your ships somehow did something strange, it happened to me. Try building a new Refuelling Station until a construction phase happens and then see if that fixes it.
Title: Re: v1.12.0 Bugs Thread
Post by: Steve Walmsley on October 12, 2020, 10:46:15 AM
Hi all

I cant find the order transfer fuel to colony anymore ? ship is a harvester with a fuel hub  or tanker with fuel hub cant transfer also

when i select earth there is no order to transfer fuel

thanks

arty

Is the class flagged as a tanker?
Title: Re: v1.12.0 Bugs Thread
Post by: arty on October 12, 2020, 10:48:21 AM
yes
Title: Engineless sensor buoys not following planets.
Post by: Llamageddon on October 12, 2020, 10:48:41 AM
I wasn't certain if this was a bug or feature but I asked elsewhere and someone said it used to work in VB6 Aurora.

If you make an engineless buoy with a sensor on it and want to leave it at a planet, dropping it at the planet either with a waypoint and fire control or with the "Drop ready ordnance" order leaves the buoy floating in space and it gets left behind as the body orbits. I surprised as I thought the probe would obvious be orbiting the body and therefore follow it.

If you put an engine on the buoy it does follow the body but the buoy is destroyed when it runs out of fuel, not so useful for either efficiency of design or for listening posts/survey probes. If you put engineless buoys on a second stage of a probe engine then it is deployed and will follow the body forever or until the survey is complete. I would have thought this is how deployed engineless buoys would be supposed to act, which it why I thought the first example, of just an engineless buoy being left behind an orbiting body is not working as intended.

SJW: Fixed
Title: Re: v1.12.0 Bugs Thread
Post by: bankshot on October 12, 2020, 11:30:22 AM
Colony Governor tab - backspace on the Colony Importance field to change it gives the following error:

1.12.0 Function #3319 Input string was not in a correct format.

You can then OK and enter the value without a problem.  You can also select the number and key over it without an error.

Confirmed. You can also add a number in front of 0 without a problem, it's only when you Backspace it. I assume this is because the field is read immediately instead of after pressing Enter or such. -Garfunkel

SJW: Fixed for 1.12.1
Title: Re: v1.12.0 Bugs Thread
Post by: LoSboccacc on October 12, 2020, 02:48:02 PM
obsolete a ship class, stay on the class page

copy class (copied class will be obsolete)

rename class

it will throw an error unless you have 'show obsolete' is checked on the left menu

Confirmed. Error is 1.12.0 Function #248: Object reference not set to an instance of an object. -Garfunkel

SJW: Fixed for 1.12.1
Title: Re: v1.12.0 Bugs Thread
Post by: mike2R on October 12, 2020, 03:01:27 PM
There does not seem to be any protection for sector governors against being picked by the colony governor auto-assign.

To reproduce, find a governor running an automated colony with high enough rank to run a sector, then assign that governor to run the sector.  Advance time and the auto-assign will yank them back to the colony.  Priority of the colony does not seem to be a factor.

Confirmed. Also, the sector governor does not show in the Economics window but does show up in the Commanders window and Sector Management window. -Garfunkel

SJW: Fixed for 1.12.1
Title: Re: v1.12.0 Bugs Thread
Post by: Romalar on October 12, 2020, 04:00:39 PM
I'm getting errors which seem to be when a ship is set to auto-overhaul when it has exceeded deployment.   Right as the auto-order message would normally come up I get these two errors in succession:

1.  12.  0 Function #730: Object reference not set to an instance of an object. 
1.  12.  0 Function #722: Object reference not set to an instance of an object. 

It still sets up the movement orders to the colony (only one with maintenance facilities) and the overhaul order.   Don't see a separate order for refuel/resupply (I forget if it's supposed to be there.  ) The Orders Assigned message is missing though I see the Deployment Time Exceeded message in the previous tick. 

My full orders for these ships:

These orders seemed to work as I'd expect with no errors at first, but after a few started showing these errors.  Only thing I can think of so far is that they're now 3 jumps out from the colony instead of 1-2.

Following up on this later in the thread. -Garfunkel
Title: Re: v1.12.0 Bugs Thread
Post by: Kev on October 13, 2020, 12:11:23 AM
Hi, everybody! New adept here.
Decided to finally try Aurora after 1. 12 came out.

But I've stumbled on some issues almost immediately.  I use system-wide font scaling because i can't see anything on 4k screen otherwise.  For Aurora I've set system scaling override so it looks sharp.  But some windows (Class Design and Game Information) don't scale properly - some controls go out of "client" area of form.  I've attached two screenshots.
It should be an easy fix (I'm c# dev myself).  So i hope it will be fixed.  I really like the idea of this game.

Thanks.  Apologies for bad English.

Working as intended, not a bug. -Garfunkel
Title: Re: v1.12.0 Bugs Thread
Post by: LoSboccacc on October 13, 2020, 05:36:07 AM

note: the cargo task group has 2 cargo ship that don't have a cargo shuttle, because well I didn't know, and one ship that has the shuttle, so maybe it's that what's giving issues

It's not the cargo ships because you cannot issue an order to unload on a body without a spaceport/shuttle station if all ships in your fleet do not have shuttles of their own. Please detail more carefully about what you were doing. -Garfunkel



please read the full description, it's a 3 ship tg of which 1 has a cargo shuttle, all unloading on an empty colony
Title: Re: v1.12.0 Bugs Thread
Post by: Garfunkel on October 13, 2020, 07:49:18 AM

note: the cargo task group has 2 cargo ship that don't have a cargo shuttle, because well I didn't know, and one ship that has the shuttle, so maybe it's that what's giving issues

It's not the cargo ships because you cannot issue an order to unload on a body without a spaceport/shuttle station if all ships in your fleet do not have shuttles of their own. Please detail more carefully about what you were doing. -Garfunkel

please read the full description, it's a 3 ship tg of which 1 has a cargo shuttle, all unloading on an empty colony

Right - I forgot that we must create the destination colony beforehand now. Confirmed.

(https://i.imgur.com/ors8DcY.png)

Combination of shutless ships and shuttle-equipped ships causes this error. However, game works - the ships with shuttles unload while the ships without shuttles do not. My earlier understanding was that the ship with shuttles should then help unload the ships without shuttles but maybe I'm misremembering.
Title: Re: v1.12.0 Bugs Thread
Post by: Eretzu on October 13, 2020, 08:45:24 AM
It seems that I cannot drag and drop in Naval Organization window. Is it a bug or is it just me?

I do not have any mods.

If it is just me, any idea on how to fix?
Title: Re: v1.12.0 Bugs Thread
Post by: Black on October 13, 2020, 10:57:05 AM
It seems that I cannot drag and drop in Naval Organization window. Is it a bug or is it just me?

I do not have any mods.

If it is just me, any idea on how to fix?

Naval organization is working fine for me, tried it just now. I can drag fleet from one admin to another normally.
Title: Re: v1.12.0 Bugs Thread
Post by: Saquenay on October 13, 2020, 12:51:47 PM
Quote from: Llamageddon link=topic=11945. msg141428#msg141428 date=1602435288
It might be a once off, but I just started a new game to regenerate the Sol system and the game just hung (Not responding) when I clicked Create Race.  I waited a while to see if it was just sorting out something complicated in the background.  The New Game options window stayed open and in colour whilst the System Map window went blank.  I just thought I'd mention it in case other people have the same thing happen and it wasn't just my computer glitching.  I didn't do anything unusual, unchecked Known Star Systems, generated Planet X and, set system bodies and jump points to surveyed.

Unconfirmed: works perfectly for me.  -Garfunkel

I just wanted to confirm that I had the same issue the first time I ran 1. 12. 0.   In my case, I had also checked off Known Star Systems.   I did not choose planet X.   I selected all spoilers and 4 NPRs in the default range.   After creating my player race, the game seemed to freeze, as if it was stuck processing something forever.   I forced quit and the next time I ran the game (I recreated the same settings), everything worked perfectly.   So I know this isn't a very useful or reproducible bug report, but just letting you know it isn't completely isolated.

--Saq
Title: Re: v1.12.0 Bugs Thread
Post by: Kylemmie on October 13, 2020, 01:39:42 PM
Quote
I just wanted to confirm that I had the same issue the first time I ran 1.  12.  0.    In my case, I had also checked off Known Star Systems.    I did not choose planet X.    I selected all spoilers and 4 NPRs in the default range.    After creating my player race, the game seemed to freeze, as if it was stuck processing something forever.    I forced quit and the next time I ran the game (I recreated the same settings), everything worked perfectly.    So I know this isn't a very useful or reproducible bug report, but just letting you know it isn't completely isolated.

--Saq

Similar experience last night.  First game after install of 1. 12   Game set up okay.  The 'almost crash' long delay happened for me once I hit the 5 day turn start (on auto).  The first few turns took so long that windows greyed out the program as unresponsive.  It would come back for a second or two and then proceed to grey as the next 5 day turn started.  Finally managed to sneak a click in to stop it, saved, closed and restarted the program.  Worked splendidly after the close/restart.  No prob at all. 

Pretty standard setup.  Known systems, 2 NPR, some spoilers, lowered Research to 20 and Terra to 50.  0% chance for generating new NPR.   
Title: Re: v1.12.0 Bugs Thread
Post by: sodimms on October 13, 2020, 01:42:33 PM
Perhaps not a bug with the game itself -- but Windows 10 default antivirus software flags the 1.   12.   0 update rar and 1.   12.   0 Aurora exe file as being adware.    Has anyone else run into this issue?
edit: multi-source AV scan image
edit2: Sandboxie isn't showing any of the behaviors of the identified virus. . .  wonder why I'm getting a false positive?
Title: Re: v1.12.0 Bugs Thread
Post by: nordakbalrem on October 13, 2020, 05:32:14 PM
Quote from: Llamageddon link=topic=11945. msg141428#msg141428 date=1602435288
It might be a once off, but I just started a new game to regenerate the Sol system and the game just hung (Not responding) when I clicked Create Race.  I waited a while to see if it was just sorting out something complicated in the background.  The New Game options window stayed open and in colour whilst the System Map window went blank.  I just thought I'd mention it in case other people have the same thing happen and it wasn't just my computer glitching.  I didn't do anything unusual, unchecked Known Star Systems, generated Planet X and, set system bodies and jump points to surveyed.

Unconfirmed: works perfectly for me.  -Garfunkel

I had the same thing happen on first game created, unsure how to reproduce.
Title: Re: v1.12.0 Bugs Thread
Post by: Zap0 on October 13, 2020, 11:32:13 PM
I can reconfirm a bug from 1.11 where an error in function 1938 gets thrown when using the group contacts display option and using correct names for alien ships, if those aliens have multiple ships of the same class and one of them has a name of 3 characters or less (or at least your intel name of it is that short).

1.11 bug post:
http://aurora2.pentarch.org/index.php?topic=11565.msg137026#msg137026

Reproduced DB is attached.

Confirmed. Function 1938 error: length cannot be less than zero. Parameter name: length. -Garfunkel

SJW: Fixed for 1.12.1
Title: Re: v1.12.0 Bugs Thread
Post by: Zap0 on October 14, 2020, 12:15:24 AM
I can reconfirm a bug from 1.11 where errors get when trying to use manual mining/mass drivers on a colony where there is both an infrastructure and an orbital habitat pop capacity with 0% manufacturing percentage (Venus).

1.11 bug post:
http://aurora2.pentarch.org/index.php?topic=11565.msg140735#msg140735


The whole thing goes away if you put an automine on Venus, probably because then there's actual production.

Reproduced DB is attached, before adding mass driver.

Confirmed both 2184 and 2092, as well as that they do not happen every 5 day increment. -Garfunkel

SJW: Fixed for 1.12.1
Title: Re: v1.12.0 Bugs Thread
Post by: Zap0 on October 14, 2020, 12:20:35 AM
I can reconfirm an issue from 1.11 where the "show next tech" option in the F10 component design menu does not allow for the next larger size of shield generators to be picked.

Confirmed. Shield type and regeneration rate do work with "Show Next Tech" ticked, it's only Generator Size that does not. -Garfunkel
Title: Re: v1.12.0 Bugs Thread
Post by: Desdinova on October 14, 2020, 01:59:21 AM
I'm getting errors which seem to be when a ship is set to auto-overhaul when it has exceeded deployment.   Right as the auto-order message would normally come up I get these two errors in succession:

1.  12.  0 Function #730: Object reference not set to an instance of an object. 
1.  12.  0 Function #722: Object reference not set to an instance of an object. 

It still sets up the movement orders to the colony (only one with maintenance facilities) and the overhaul order.   Don't see a separate order for refuel/resupply (I forget if it's supposed to be there.  ) The Orders Assigned message is missing though I see the Deployment Time Exceeded message in the previous tick. 

My full orders for these ships:
  • Survey Next Three System Bodies or Locations
  • Move to System Requiring Gravsurvey
  • if Deployment Exceeded, Refueld, Resupply, and Overhaul at Colony
  • if Fuel less than 40%, Refuel from Colony or Hub

These orders seemed to work as I'd expect with no errors at first, but after a few started showing these errors.  Only thing I can think of so far is that they're now 3 jumps out from the colony instead of 1-2.

I'm seeing the same thing crop up from time to time. I managed to save a DB right before it happened - it should happen on the next or phase after next. Hope this helps. Here's a link (https://drive.google.com/file/d/1gNCXMmR5A75iKVvPNGhfNnLErf7OCozw/view?usp=sharing), since apparently the zip is too big for the forum.

Access denied to the file. -Garfunkel
Title: Re: v1.12.0 Bugs Thread
Post by: LoSboccacc on October 14, 2020, 02:09:44 AM
(https://i.imgur.com/LSzsLaD.png)


retrofitted ship removing magazine, copying from a previous class having two magazine.

both the original class ordinance template and the refitted ship remained having the previous loadout

(I updated the class loadout before taking the pic sorry)
Title: Re: v1.12.0 Bugs Thread
Post by: Llamageddon on October 14, 2020, 05:14:23 AM
I was updating one of my move templates, I queued the old template then clicked "Order Templates" again to check what the old name was. I deleted the first few orders and when I clicked on the planet name to add it back in as a destination I got the following error:

Code: [Select]
1.12.0 Function #3210: Unable to cast object of type 'g8' to type 'he'.
I can recreate this by queing any template then selecting "Order Templates" again after it resets to "System Locations" and then deleting one of the orders and trying to make a new one.

Unmodded, real stars not selected.
Title: Re: v1.12.0 Bugs Thread
Post by: IanD on October 14, 2020, 08:25:27 AM
Just started a v1.12 game, selected Refuel, Resupply & Overhaul in Standing Orders for my first survey ships.

Find they overhaul OK but so far do not refuel or resupply before entering overhaul.

Is this unique to my set up?

Edit: A longer observation reveals the error codes:-

1.12.0 Function #730: Object not set to an instance of an object.

Followed by :-

1.12.0 Function #722: Object reference not set to an instance of an object.

These two error messages occur as the ship defaults to its standing order to Refuel, Resupply & Overhaul . But only overhauls.

Edit #2
Started new game and still have this error.

Edit #3: I think its when the trigger for the standing order is Low Fuel.

Incidentally, when I select random warp points for Sol in the past 3-4 games including v1.11 The result is 2, always. Is it just a function of randomness or is the random number generator broken?

Ian
Title: Re: v1.12.0 Bugs Thread
Post by: DFNewb on October 14, 2020, 08:28:44 AM
Just started a v1.12 game, selected Refuel, Resupply & Overhaul in Standing Orders for my first survey ships.

Find they overhaul OK but so far do not refuel or resupply before entering overhaul.

Is this unique to my set up?

Edit: A longer observation reveals the error codes:-

1.12.0 Function #730: Object not set to an instance of an object.

Followed by :-

1.12.0 Function #722: Object reference not set to an instance of an object.

These two error messages occur as the ship defaults to its standing order to Refuel, Resupply & Overhaul . But only overhauls.

Edit #2
Started new game and still have this error.

Incidentally, when I select random warp points for Sol in the past 3-4 games including v1.11 The result is 2, always. Is it just a function of randomness or is the random number generator broken?

Ian

Same thing happened to me. They seem to eventually refuel and resupply tho, but after the overhual.
Title: Re: v1.12.0 Bugs Thread
Post by: Llamageddon on October 14, 2020, 10:43:06 AM
In formation orders if you click on "Set Specific Threat" with nothing selected then you get:

Code: [Select]
1.12.0 Function #3334: Object reference not set to an instance of an object.
Hardly worth mentioning, but I thought you might want to add it to your todo list, even if it is to popup a message rather than and object reference error.

SJW: Fixed
Title: Re: v1.12.0 Bugs Thread
Post by: Zap0 on October 14, 2020, 12:19:40 PM
Somebody deleted a post of mine or the remove option for one's own posts lacks confirmation.

I can reconfirm a bug from 1.11 where 0 habitable planets get shown in the graphics of the star map when the only habitable body in a system is a LG body with the "Habitable-Range Worlds - Include Low Gravity" option is on.

1.11 bug post:
http://aurora2.pentarch.org/index.php?topic=11565.msg141013#msg141013

Reproduced DB is attached.

SJW: Fixed for 1.12.1
Title: Re: v1.12.0 Bugs Thread
Post by: xenoscepter on October 14, 2020, 02:36:32 PM
 - I have had two bugs so far. The first is fighters (again), they will pick up colonists but won't unload them. It should be fairly easy to reproduce, just build a fighter, add an emergency cryo (or two), load it up and try to unload it. They won't. The second is Future Prototypes, again easy to reproduce. They won't be available to research even if you have the tech. I encountered the Future Prototype bug in v1.11 as well. Sorry for the short, lazy report I don't have the databases and I'm using the recommended settings.

 - I.E. decimal separator etc. I haven't run a 75+ year campaign for either of these bugs in v1.12, but I did encounter the Future Prototype bug in a 75+ year game and non-75+ year game in v1.11 fwiw.
Title: Re: v1.12.0 Bugs Thread
Post by: Llamageddon on October 14, 2020, 04:10:05 PM
I couldn't see this already reported in the 1.11 bug thread so it might be new: If you set your Beam Fire Control to "1.25  Size 1.25 Range" it actually calculates it as if you had selected "0.25" and makes it 1/4 as small and 1/4 the range of the fire control.

SJW: Fixed for the next DB release.
Title: Re: v1.12.0 Bugs Thread
Post by: Romalar on October 15, 2020, 03:15:19 AM
I have survey ships set up with these main orders:

This works as expected some of the time.   However, I have a hostile alien-inhabited two jumps from my home system.   I have blocked fleet auto-routing for the system and marked it military-restricted to be sure no civilian ships enter.   I also marked it as controlled by that race and marked them hostile. 

While these ships are not civilian, I would hope the auto-routing restriction would be used.   However, when the ships run out of primary orders (survey) near the home system (such as when they refuel), they generally head directly to the hostile system and are killed. 
Title: Re: v1.12.0 Bugs Thread
Post by: Froggiest1982 on October 15, 2020, 03:23:28 AM
I have survey ships set up with these main orders:
  • Survey Next Three System Bodies or Locations
  • Move to System Requiring Gravsurvey

This works as expected some of the time.   However, I have a hostile alien-inhabited two jumps from my home system.   I have blocked fleet auto-routing for the system and marked it military-restricted to be sure no civilian ships enter.   I also marked it as controlled by that race and marked them hostile. 

While these ships are not civilian, I would hope the auto-routing restriction would be used.   However, when the ships run out of primary orders (survey) near the home system (such as when they refuel), they generally head directly to the hostile system and are killed.

Hi, not a bug. Please use the below:

Movement Orders
Exclude Alien Controlled

The ship will not jump into any System marked as alien controlled.

Auto Route command will come in place only when using auto route commands
Military only will come in place only for civilian ships (non player controlled)

I hope the above helps.
Title: Re: v1.12.0 Bugs Thread
Post by: Romalar on October 15, 2020, 05:15:07 AM
Quote from: froggiest1982 link=topic=11945. msg141655#msg141655 date=1602750208
Hi, not a bug.  Please use the below:

Movement Orders
Exclude Alien Controlled

The ship will not jump into any System marked as alien controlled.
Can confirm that this works for me.  Sorry, I didn't connect that these would work together.
Title: Re: v1.12.0 Bugs Thread
Post by: Llamageddon on October 15, 2020, 11:40:14 AM
Quote from: froggiest1982 link=topic=11945. msg141655#msg141655 date=1602750208
Hi, not a bug.  Please use the below:

Movement Orders
Exclude Alien Controlled

The ship will not jump into any System marked as alien controlled.
Can confirm that this works for me.  Sorry, I didn't connect that these would work together.

I am wondering if I have a bug with this then. I have done all of the above and my survey ships are still jumping into that system to survey. I have double checked, they definitely have "Exclude Alien Controlled" checked and the system is definitely marked as alien controlled. Is this a bug or is it because they are set as neutral in my Diplomacy screen? Should I also mark it as protected in the "Miscellaneous" tab?
Title: Re: v1.12.0 Bugs Thread
Post by: Llamageddon on October 15, 2020, 11:44:34 AM
I have another relatively low-key bug.

II dicovered my first world with less than 2.0 colony cost. I noticed it was very cold, as soon as I hit "Create Colony" the System Generation and Display screen changes the colour and the colony cost to 2.0; I assume this is because at -103 (C) the atmosphere is frozen and therefore unbreathable, so it is WAI for the updated value. If I "Delete Pop" then the value stays at 2.0 afterwards.
Title: Re: v1.12.0 Bugs Thread
Post by: Iceranger on October 15, 2020, 01:05:39 PM
I wasn't sure if this counted as a typo, like the double space on generated engine names, and if those should be reported somewhere other than this thread. I don't want to clutter up the reports with things that aren't really a technical bug, let me know if I should post somewhere else in future.

I hope this hasn't changed without me realising; on the C# changes list it is stated (emphasis mine):
Quote
"Any location that contains a population with maintenance facilities or a ship with maintenance modules is known as a 'Maintenance Location'. This does not need to be in the same location as a population. A Maintenance Location consisting only of ships with maintenance modules could be in deep space."

On the research description for Maintenance Modules it states:
Quote
"A ship component that is added to the total maintenance facilites of a population if the ship is on the same planet or in near orbit"

For ages I wasn't researching maintenance modules because I thought I had misread info about them on the wiki/forums.

- BTW, it sounds like a lot of Steve's time bug fixing is taken up with checking misleading bug reports and focussing on which are a priority. I was wondering if a Glitches/Typos thread might be an good idea. Things like spelling mistakes or UI oddities could be reported there. Just an idea, it might make things more complicated rather than less.

Pretty sure the descriptions of the old techs are just copied from VB6 without much changes.

There is a typo reporting thread, which is probably what you were looking for. http://aurora2.pentarch.org/index.php?topic=10638.0
Title: Re: v1.12.0 Bugs Thread
Post by: Llamageddon on October 15, 2020, 01:12:44 PM
Oh, woops, "Typos" right there on the pinned posts, I feel foolish.  :o I'm going to delete my previous post, so you will look like you are replying to no one.  :D
Title: Re: v1.12.0 Bugs Thread
Post by: Kelewan on October 15, 2020, 01:29:52 PM
Quote from: froggiest1982 link=topic=11945. msg141655#msg141655 date=1602750208
Hi, not a bug.  Please use the below:

Movement Orders
Exclude Alien Controlled

The ship will not jump into any System marked as alien controlled.
Can confirm that this works for me.  Sorry, I didn't connect that these would work together.

I am wondering if I have a bug with this then. I have done all of the above and my survey ships are still jumping into that system to survey. I have double checked, they definitely have "Exclude Alien Controlled" checked and the system is definitely marked as alien controlled. Is this a bug or is it because they are set as neutral in my Diplomacy screen? Should I also mark it as protected in the "Miscellaneous" tab?

If the ships had already queued the move orders at the time you set the "Exclude Alien Controlled" or marked the system as alien controlled the ships will follow the orders
and survey the system till they leave the system (e.g. to refuel or to resupply )
Title: Re: v1.12.0 Bugs Thread
Post by: Llamageddon on October 15, 2020, 01:30:28 PM
I was reloading the game to see what systems might generate when a ship entered an unexplored jump point and on about my 5th try the game has hung (Not Responding). As every time I just clicked on "1 Day" to explore the jump point I assume this is related to system generation. Unfortunately I can't think of any way to recreate the issue other than keep doing this and seeing if it hangs again.

Might be related to my first bug report when the game also went into "(Not Reponding)" when I created a new game.
Title: Re: v1.12.0 Bugs Thread
Post by: Llamageddon on October 15, 2020, 01:32:06 PM
If the ships had already queued the move orders at the time you set the "Exclude Alien Controlled" or marked the system as alien controlled the ships will follow the orders
and survey the system till they leave the system (e.g. to refuel or to resupply )

I thought this wasn't likely, but I will run the game for a while and see if it happens again before confirming as a bug for me.
Title: Re: v1.12.0 Bugs Thread
Post by: Llamageddon on October 15, 2020, 09:08:00 PM
Yep, it just happened again. I have the system set to alien controlled and no auto route, the ship is flagged to ignore alien controlled systems and it definitely had no orders queued. I had sent him back to refuel and on to a system far away from here last time this happened. He has actually passed through another alien controlled, no autoroute system to get where I just found him.
Title: Re: v1.12.0 Bugs Thread
Post by: Malorn on October 15, 2020, 09:44:58 PM
Got a repeating bug

"Object references not set to an instance of an object."

It cycles through quite a few function numbers, including #2608, #222, #224, and #2339.

It seems to cycle infinitely, no matter how many times I push ok.

I was just passing 30 days as normal. The game is 227 years in, random stars, decimal separator is a period, TN start.

I did have the doom option for earth enabled, but it has long singe spiraled into the sun.

PS: I tried to attach the DB file, but for some reason I cannot attach anything, when I do and push post, it refreshes the page to 'create new topic'. Strange, I didn't used to have problems attaching files before...
Title: Re: v1.12.0 Bugs Thread
Post by: Marslettuce on October 16, 2020, 04:32:11 PM
I couldn't see this already reported in the 1.11 bug thread so it might be new: If you set your Beam Fire Control to "1.25  Size 1.25 Range" it actually calculates it as if you had selected "0.25" and makes it 1/4 as small and 1/4 the range of the fire control.

I'd like to confirm this as well. All other multipliers seem to be correct.

TN Start
Real Stars
Period decimal separator
Always occurs
Title: Re: v1.12.0 Bugs Thread
Post by: Droll on October 16, 2020, 05:03:33 PM
I couldn't see this already reported in the 1.11 bug thread so it might be new: If you set your Beam Fire Control to "1.25  Size 1.25 Range" it actually calculates it as if you had selected "0.25" and makes it 1/4 as small and 1/4 the range of the fire control.

I'd like to confirm this as well. All other multipliers seem to be correct.

TN Start
Real Stars
Period decimal separator
Always occurs

+1 this happens to me as well
Title: Re: v1.12.0 Bugs Thread
Post by: Marslettuce on October 16, 2020, 05:52:16 PM
Auto-assigned beam weapons are assigned to multiple beam fire controls simultaneously (See image 1). They do not seem to fire multiple times, as far as I can tell, so this is more of a display bug. I have 9 railguns for a total of 36 shots and this is reflected in combat (See image 2). Attempting to move the railguns to a fire control with a copy of itself results in 2 of the same railgun being assigned to that fire control. Eg. if FC1 has Railgun #1, and FC2 has Railgun #1, then dragging Railgun #1 from FC1 to FC2 will result in 2 copies of Railgun #1 under FC2, and none under FC1.

TN Start
Real Stars
Period decimal separator
Always occurs
18 years in
Title: Re: v1.12.0 Bugs Thread
Post by: Gnaius Pliny on October 17, 2020, 05:52:18 AM
Survey Issue(?)

I have two Geosurvey Vessels with Standing Orders set to 'Survey Nearest Body'.  One doesn't seem to have a problem pathing to the next body but the other returns the 'Unable to carry out standing order: Survey Nearest Body' event log.

This started close to the end of surveying the Sol system but there were still groups of unsurveyed asteroids without a survey order targeting them.  I can manually order the ship to survey them and it will then find other nearby unsurveyed locations but then soon returns the same message.

I checked that the locations hadn't been assigned to the other ship and I couldn't see any orders related to them.  If this continues in other systems, I can see some intense micro might be needed, which is slightly frustrating.

This seems to be related to the distance between the ship and the survey location as the current distance between the ship with the pathing problem and the next survey locations is between 10-35b km but I could be wrong.  (Pre-post update: moved the offending vessel within 10b km and it was able to path to the next location (a comet) with no issues, so I'm more sure that this is a distance issue)

I'm not sure if this is a bug or intended behaviour but it is frustrating to have to manually survey the last locations.
Title: Re: v1.12.0 Bugs Thread
Post by: TheTalkingMeowth on October 17, 2020, 07:56:26 AM
The standing survey next _ orders are range limited. They won't grab targets more than 10bn km away to prevent accidentally losing a survey ship to a distant binary component or long period comet.
Title: Re: v1.12.0 Bugs Thread
Post by: Black on October 17, 2020, 11:29:02 AM
I encountered strange behavior from Precursor missile bases. They are shooting missiles at different direction than the location of my ships.

1.12.0, TN start, decimal separator is dot.

(https://i.ibb.co/TqM5NKP/wild-missiles-01.png) (https://ibb.co/Fq4tds8)

I tried to attach the database, but for some reason it will not upload.
Title: Re: v1.12.0 Bugs Thread
Post by: Marslettuce on October 17, 2020, 12:45:51 PM
Disassembling some components doesn't add any research progress even if it says it does. This issue is intermittent, though. I disassembled some lasers and the stated progress was applied correctly. Disassembling some control systems provided no benefit, though (See attached images).

I tried closing and reopening the research window and checking other planets. I verified that the parts were disassembled on Earth.

TN Start
22 years in
Dot separator
Intermittent
Title: Re: v1.12.0 Bugs Thread
Post by: Droll on October 17, 2020, 01:22:04 PM
I tried to attach the database, but for some reason it will not upload.

Try zipping or otherwise compressing the database file. It might be a file size issue - large files above a certain size wont upload.
Title: Re: v1.12.0 Bugs Thread
Post by: Ekaton on October 17, 2020, 01:25:12 PM
Not sure if sector commanders work - in the officers menu I can see that my administrator is the current governor of Sol, but on colony menus for each colony it says that there isn’t one,

Known issue, already reported. Governors are there and working, they just do not show in Economy screen. -Garfunkel
Title: Re: v1.12.0 Bugs Thread
Post by: Droll on October 17, 2020, 01:26:22 PM
Not sure if sector commanders work - in the officers menu I can see that my administrator is the current governor of Sol, but on colony menus for each colony it says that there isn’t one,

Just to make sure, have you added the sol system to the sector with the sector menu? By default sectors start empty
Title: Re: v1.12.0 Bugs Thread
Post by: JustAnotherDude on October 17, 2020, 02:46:54 PM
I appear to be unable to change game settings after game start. The save settings button does nothing after checking boxes/typing in fields. I have tried changing settings on a save I was currently in and in a different save with identical results. I discovered this while looking into a second thing that I'm not sure is a bug, but I'll bring it up in case it's at all important. Long story short it appears that a spy ship of mine was causing the game to only move forward in the associated sub pulse increments while in enemy systems. I assume that this was related to detection.

Unconfirmed - what Black wrote below is correct. Player has to "save settings" then "play the game" with the right campaign selected to get back to it, then save the game and exit. Coming back to the game, the settings are now properly changed. -Garfunkel
Title: Re: v1.12.0 Bugs Thread
Post by: Black on October 17, 2020, 03:00:51 PM
I appear to be unable to change game settings after game start. The save settings button does nothing after checking boxes/typing in fields. I have tried changing settings on a save I was currently in and in a different save with identical results. I discovered this while looking into a second thing that I'm not sure is a bug, but I'll bring it up in case it's at all important. Long story short it appears that a spy ship of mine was causing the game to only move forward in the associated sub pulse increments while in enemy systems. I assume that this was related to detection.

After you change the setting and click Save Settings, save the game as well and then check the settings again. It should be changed.
Title: Re: v1.12.0 Bugs Thread
Post by: Froggiest1982 on October 17, 2020, 03:04:52 PM
I encountered strange behavior from Precursor missile bases. They are shooting missiles at different direction than the location of my ships.

1.12.0, TN start, decimal separator is dot.

(https://i.ibb.co/TqM5NKP/wild-missiles-01.png) (https://ibb.co/Fq4tds8)

I tried to attach the database, but for some reason it will not upload.

Probably a weird bug, but let's assume it's not.

What are the chances they shooting at something else?

Can you scout towards that direction or there is literally nothing there?
Title: Re: v1.12.0 Bugs Thread
Post by: Black on October 17, 2020, 03:16:06 PM
I encountered strange behavior from Precursor missile bases. They are shooting missiles at different direction than the location of my ships.

1.12.0, TN start, decimal separator is dot.

I tried to attach the database, but for some reason it will not upload.

Probably a weird bug, but let's assume it's not.

What are the chances they shooting at something else?

Can you scout towards that direction or there is literally nothing there?

I destroyed the Precursors and there was nothing else in the system. I have 0 NPRs at the start of the game, so only other possibility would be Star Swarm and I am quite sure I would detect them by now (I am played over a game year after the report). I should have archived the database and tried to upload it again. :(

I think that it may be connected to commands to follow the planet at certain distance. I noticed that my fleets sometimes move in strange direction, most likely in attempt to correct their approach vector in anticipated move of the planet on the orbit. And precursor missiles are anticipating the course change of my ships.
Title: Re: v1.12.0 Bugs Thread
Post by: TheTalkingMeowth on October 17, 2020, 06:34:56 PM
I'm getting errors which seem to be when a ship is set to auto-overhaul when it has exceeded deployment.   Right as the auto-order message would normally come up I get these two errors in succession:

1.  12.  0 Function #730: Object reference not set to an instance of an object. 
1.  12.  0 Function #722: Object reference not set to an instance of an object. 

It still sets up the movement orders to the colony (only one with maintenance facilities) and the overhaul order.   Don't see a separate order for refuel/resupply (I forget if it's supposed to be there.  ) The Orders Assigned message is missing though I see the Deployment Time Exceeded message in the previous tick. 

My full orders for these ships:
  • Survey Next Three System Bodies or Locations
  • Move to System Requiring Gravsurvey
  • if Deployment Exceeded, Refueld, Resupply, and Overhaul at Colony
  • if Fuel less than 40%, Refuel from Colony or Hub

These orders seemed to work as I'd expect with no errors at first, but after a few started showing these errors.  Only thing I can think of so far is that they're now 3 jumps out from the colony instead of 1-2.

Me too post! I'm seeing precisely the same behavior: Deplyment exceeded, then next tick I get two errors in order. No conditional order note in log, but ship is ordered to go to overhaul. But no refuel/resupply order is placed. It happens with "move to system requiring geosurvey" as the second standing order, too.
Title: Re: v1.12.0 Bugs Thread
Post by: Romalar on October 18, 2020, 08:01:36 AM
Auto-assigning governors is not workable if you also have any administrative academy commandants or sector governors.  It will always reassign the latter two to be one of the colony governors and there appears to be no way to mark them as not auto-assigned or to assign a priority for them.

Known issue, already reported. -Garfunkel
Title: Re: v1.12.0 Bugs Thread
Post by: Llamageddon on October 18, 2020, 08:55:08 AM
I seem to have found a bug involving ground units that happens consistently.

So some alien ground units turned up on a planet I was exploring ruins on. They easily destroyed my two 2500 ton xenoarchaelogy expeditions there. I was curious as it was my first GU combat, sent a scout to planet, saw 9200 tons of ground units there. I think the are some kind of spoiler race, but am not experienced enough with Aurora to be sure.

I sent in a nearby transport with another 2500 ton xenoarchaeology team on it, they disembark and game just says alien forces have been defeated, no combat stats. I advance time by a day and I get:
Code: [Select]
1.12.0 Function #2714: Object reference not set to an instance of an object
I press OK and the game continues and announces my new formation being destroyed by overwhelming alien forces, as expexcted. There doesn't seem to be any problems with continuing the game after this point as far as I can tell.

I've repeated it a few times. If I have a scout in orbit, the error message pops up twice, with just the transport in orbit it pops up once. It doesn't make any difference if I have active sensors scanning the ground forces or not.

Have saved the DB file in case you want to look at it.

Unmodded game
Known Star System not selected

Update: I just sent in a more conventional invasion force of medium vehicles. As soon as they had unloaded I got the same report about the alien forces being defeated, without any battle reports in the events log. When I advanced time by 1 day after that I got a normal series of battle reports, I had one damaged formation left. When I advanced by a day for a second time I got the same #2714 error 3 times in immediate succession (again, the same number of ships I had in orbit). After clicking OK on the last error popup the final battle reports came through, showing all my forces wiped out. It appears the object reference error may have been triggered by my last unit's destruction.

Out of curiosity I tried this again but immediately moved my transports out of orbit and I got no errors. The game and events seem to proceed as expected.
Title: Re: v1.12.0 Bugs Thread
Post by: bankshot on October 19, 2020, 11:41:45 AM
Disassembling some components doesn't add any research progress even if it says it does. This issue is intermittent, though. I disassembled some lasers and the stated progress was applied correctly. Disassembling some control systems provided no benefit, though (See attached images).

I tried closing and reopening the research window and checking other planets. I verified that the parts were disassembled on Earth.

TN Start
22 years in
Dot separator
Intermittent

I saw something similar to this in 1.11 - @Marslettuce - were you researching those techs (or prior techs in the same series) when you disassembled the components? 

edit: my prior report:  http://aurora2.pentarch.org/index.php?topic=11565.msg136399#msg136399
Title: Re: v1.12.0 Bugs Thread
Post by: Malorn on October 19, 2020, 01:24:47 PM
I seem to have found a bug involving ground units that happens consistently.

So some alien ground units turned up on a planet I was exploring ruins on. They easily destroyed my two 2500 ton xenoarchaelogy expeditions there. I was curious as it was my first GU combat, sent a scout to planet, saw 9200 tons of ground units there. I think the are some kind of spoiler race, but am not experienced enough with Aurora to be sure.

I sent in a nearby transport with another 2500 ton xenoarchaeology team on it, they disembark and game just says alien forces have been defeated, no combat stats. I advance time by a day and I get:
Code: [Select]
1.12.0 Function #2714: Object reference not set to an instance of an object
I press OK and the game continues and announces my new formation being destroyed by overwhelming alien forces, as expexcted. There doesn't seem to be any problems with continuing the game after this point as far as I can tell.

I've repeated it a few times. If I have a scout in orbit, the error message pops up twice, with just the transport in orbit it pops up once. It doesn't make any difference if I have active sensors scanning the ground forces or not.

Have saved the DB file in case you want to look at it.

Unmodded game
Known Star System not selected

That sounds very similar to what I had, except my game got caught in a loop of errors. I think in my case it was NPR vs NPR, if it was caused by the same thing. There had been nearly two months of shortened increments prior...
Title: Re: v1.12.0 Bugs Thread
Post by: Ekaton on October 19, 2020, 06:03:46 PM
As detailed here: http://aurora2.pentarch.org/index.php?topic=11992.msg141975#msg141975

NPRs jump in and out of a system in a bizarre way.
Title: Re: v1.12.0 Bugs Thread
Post by: BritoO on October 20, 2020, 12:12:54 AM
Just started a v1.12 game, selected Refuel, Resupply & Overhaul in Standing Orders for my first survey ships.

Find they overhaul OK but so far do not refuel or resupply before entering overhaul.

Is this unique to my set up?

Edit: A longer observation reveals the error codes:-

1.12.0 Function #730: Object not set to an instance of an object.

Followed by :-

1.12.0 Function #722: Object reference not set to an instance of an object.

These two error messages occur as the ship defaults to its standing order to Refuel, Resupply & Overhaul . But only overhauls.

Edit #2
Started new game and still have this error.

Edit #3: I think its when the trigger for the standing order is Low Fuel.

Incidentally, when I select random warp points for Sol in the past 3-4 games including v1.11 The result is 2, always. Is it just a function of randomness or is the random number generator broken?

Ian

I'm getting errors which seem to be when a ship is set to auto-overhaul when it has exceeded deployment.   Right as the auto-order message would normally come up I get these two errors in succession:

1.  12.  0 Function #730: Object reference not set to an instance of an object. 
1.  12.  0 Function #722: Object reference not set to an instance of an object. 

It still sets up the movement orders to the colony (only one with maintenance facilities) and the overhaul order.   Don't see a separate order for refuel/resupply (I forget if it's supposed to be there.  ) The Orders Assigned message is missing though I see the Deployment Time Exceeded message in the previous tick. 

My full orders for these ships:
  • Survey Next Three System Bodies or Locations
  • Move to System Requiring Gravsurvey
  • if Deployment Exceeded, Refueld, Resupply, and Overhaul at Colony
  • if Fuel less than 40%, Refuel from Colony or Hub

These orders seemed to work as I'd expect with no errors at first, but after a few started showing these errors.  Only thing I can think of so far is that they're now 3 jumps out from the colony instead of 1-2.

To add some more to these bug reports I ran a series of test cases and seem to have "pinned" it down some.
Feel Free to look inside if you want an idea of the test cases i ran.

Off-Topic: show

Single System Cases - Only Sol System available

Case 1: No standing. Single conditional - exceed time -> refuel, resupply, overhaul.
   Result: No error, proper trigger, REFUELED and OVERHAULED(did not need supply)

Case 2: Survey next 5 bodies standing. Single conditional - exceed time -> refuel, resupply, overhaul.
   Result: No error, proper trigger, REFUELED and OVERHAULED(did not need supply)
   
Case 3: Same as 2, but watch the orders given
   Result: Refuel and Resupply order (no resupply needed). Overhaul order. Orders properly given
   
Case 4: Survey next 5 and Geo Survey other system. Single conditional - exceed time -> refuel, resupply, overhaul.
   Result: Result: No error, proper trigger, REFUELED and OVERHAULED(did not need supply)
   
Case 5: Survey next 5 bodies standing. Two conditionals - exceed time -> refuel, resupply, overhaul; fuel < 30% -> refuel, resupply, overhaul.
   Result: Trigger was exceed time: No error, proper trigger, REFUELED and OVERHAULED(did not need supply)
   Result: Trigger was Fuel Level: No error, proper trigger, REFUELED and OVERHAULED(did not need supply)

Case 6: Survey next 5 and Geo Survey other system. Two conditionals - exceed time -> refuel, resupply, overhaul; fuel < 30% -> refuel, resupply, overhaul.
   Result: Trigger was exceed time: No error, proper trigger, REFUELED and OVERHAULED(did not need supply)
   Result: Trigger was Fuel Level: No error, proper trigger, REFUELED and OVERHAULED(did not need supply)
   
Multi System Cases - Vessels in Non starting system (NOT SOL)

Case 1: Survey next 5 bodies standing. Single conditional - exceed time -> refuel, resupply, overhaul.
   Result: Error #730 Object Reference Not set to and instance of an object -> error #722 Object Reference Not set to and instance of an object
         REFUEL and RESSUPLY order NOT issues, Overhaul was issued properly. (proper navigation back to appropriate overhaul location as well)
         Error occurs when the normal conditional event message would be issued. Conditional Event Message is NOT issued.
         
DB available. Load and run 2 x 1-day increment. Error should appear


Seems like the error is linked with a vessel in one system looking to a Refuel, Resupply and Overhaul Location that is only available in a different system.

Error Messages are #730 followed by a #722. Both have the "Object Reference Not set to and instance of an object" message

DB is Linked (https://www.dropbox.com/s/9022a9km0og7orn/AuroraDB%20-%20Bug%20Report.zip?dl=0). Run 2x1-day Increments and you should see the error.

SJW: Fixed. Thanks for the detailed explanation
Title: Re: v1.12.0 Bugs Thread
Post by: bankshot on October 20, 2020, 12:20:24 PM
System body survey percentage remains at 0% until it is complete. 

First reported in 1.9.5
http://aurora2.pentarch.org/index.php?topic=11298.msg132788#msg132788

SJW: Fixed
Title: Re: v1.12.0 Bugs Thread
Post by: Black on October 20, 2020, 12:23:21 PM
I encountered bug with Unload All installations command. If your freighter fleet carries more than one type of installation and you give it command to unload all, only first type of installation is unloaded.

It can be easily reproduced by loading two installations, for example mine and fuel refinery. Then give command to unload all and only first installation on the list is unloaded. I reproduced it several times.

TN Start
Real Stars
Period decimal separator
Title: Re: v1.12.0 Bugs Thread
Post by: JustAnotherDude on October 20, 2020, 02:33:21 PM
It seems like occupation strength is very broken: I appear to need about 60 billion tons of ground troops to pacify an enemy homeworld, which has an occupation strength of 161,000.

SJW: Fixed
Title: Re: v1.12.0 Bugs Thread
Post by: Demetrious on October 20, 2020, 02:38:36 PM
It seems you can add multiple spinal-mount weapons to a ship, as long as they are of the same type.  If you try to add two different spinal mount weapons to a ship, you get the usual "only a single spinal weapon can be added to a class design" pop-up message. 

SJW: Fixed
Title: Re: v1.12.0 Bugs Thread
Post by: Droll on October 20, 2020, 02:39:17 PM
It seems like occupation strength is very broken: I appear to need about 60 billion tons of ground troops to pacify an enemy homeworld, which has an occupation strength of 161,000.

For completeness what is your decimal separator?
Title: Re: v1.12.0 Bugs Thread
Post by: replicant2699 on October 22, 2020, 01:12:23 AM
I've researched Cloaking Theory, Cloaking Efficiency 3 and Cloak Sensor Reduction 75%, so everything I need to design a cloaking device. Now there is a research called "Minimum Cloak Size 25" but I can already make a 25HS cloaking device. Is this a typo or am I reading something wrong?

SJW: Fixed
Title: Re: v1.12.0 Bugs Thread
Post by: vorpal+5 on October 22, 2020, 02:07:15 AM
There is a bug in which the research points amount, in creation, is often modified to 100.000 automatically (as soon as you want to edit something else). I believe this happens if you try to lower the current value, when you have some decent starting pop (500 M and more). For NPR only ...

Latest version, vanilla, race creation.

This is working as intended - NPR AI code needs them to have at least 100 000 points to work. -Garfunkel
Title: Re: v1.12.0 Bugs Thread
Post by: Neophyte on October 22, 2020, 10:45:56 AM
There is a bug in which the research points amount, in creation, is often modified to 100.000 automatically (as soon as you want to edit something else). I believe this happens if you try to lower the current value, when you have some decent starting pop (500 M and more). For NPR only ...

Latest version, vanilla, race creation.

I believe that's by design, see the Known Issues thread
Title: Re: v1.12.0 Bugs Thread
Post by: Iceranger on October 22, 2020, 04:19:09 PM
I've researched Cloaking Theory, Cloaking Efficiency 3 and Cloak Sensor Reduction 75%, so everything I need to design a cloaking device. Now there is a research called "Minimum Cloak Size 25" but I can already make a 25HS cloaking device. Is this a typo or am I reading something wrong?
Sounds like a bug to me...
Title: Re: v1.12.0 Bugs Thread
Post by: db48x on October 22, 2020, 06:39:26 PM
Version 1.12.0, decimal separator is a period, just a few years into a conventional start.

I designed a size-5 two-stage geosurvey missile and launched one at most of the planets in Sol. The first stage is slow (400km/s) but works fine. The second stage fails, giving me this message:

Code: [Select]
A salvo with 1x Crosswhite Sensor Systems Albatross Geosurvey Bouy has no sensors, no second stage and no method of movement. Therefore it has self-destructed
This was a bit unexpected, so I went hunting for a cause. After some back and forth, I noticed that I still have "No Tech" for geosurvey strength, and that the bouy shows a "-" in the geo column of the tech viewer. The missile designer still shows that I have 1MSP devoted to Geo Sensors, so that's ok.

(http://db48x.net/Aurora/rediscovery:%20conventional%20start%20in%203000%20with%20v1.12/Screenshot%20from%202020-10-22%2016-32-52.png)

It appears to me that it shouldn't allow me to design and research a geosurvey missile before I have the geosurvey tech.

SJW: I've changed it so that the geosurvey line doesn't appear until you have geosurvey tech
Title: Re: v1.12.0 Bugs Thread
Post by: Froggiest1982 on October 22, 2020, 09:22:55 PM
Version 1.12.0, decimal separator is a period, just a few years into a conventional start.

I designed a size-5 two-stage geosurvey missile and launched one at most of the planets in Sol. The first stage is slow (400km/s) but works fine. The second stage fails, giving me this message:

Code: [Select]
A salvo with 1x Crosswhite Sensor Systems Albatross Geosurvey Bouy has no sensors, no second stage and no method of movement. Therefore it has self-destructed
This was a bit unexpected, so I went hunting for a cause. After some back and forth, I noticed that I still have "No Tech" for geosurvey strength, and that the bouy shows a "-" in the geo column of the tech viewer. The missile designer still shows that I have 1MSP devoted to Geo Sensors, so that's ok.

(http://db48x.net/Aurora/rediscovery:%20conventional%20start%20in%203000%20with%20v1.12/Screenshot%20from%202020-10-22%2016-32-52.png)

It appears to me that it shouldn't allow me to design and research a geosurvey missile before I have the geosurvey tech.

Your general explaination it's correct and agree that option should have been greyed out but there is no such function currently so I wouldnt say it's a proper bug but more of a missing feature?

Furthermore, as you can see from your design even if you have 1 point allocated to Geo the general value is zero which is correct.  A sensor in a buoy needs at least 0.25 value to work and you would also see a reactor component being added if all working properly.

However, as said, I agree that should be fixed in some way as I have tried it out and I had the same outcome with all designs. Easy to verify just starting a conventional game and design such buoys or second stage missiles.
Title: Re: v1.12.0 Bugs Thread
Post by: Iceranger on October 23, 2020, 09:25:08 AM
V1.12,
Dot as decimal separator,
test scenario.

When a missile launcher is out of ammo, or the missile in the launcher has 0 hit chance, the launch will not happen, but the weapon breakdown chance still applies:
(https://media.discordapp.net/attachments/619231280713957406/769203067500888124/unknown.png)
(https://media.discordapp.net/attachments/619231280713957406/769204238269022248/unknown.png)

I think in these two cases (and there might be other cases I missed), weapon failure should not roll since the weapon did not fire.

SJW: I've moved the breakdown check after the ammo check.
Title: Re: v1.12.0 Bugs Thread
Post by: Winged on October 23, 2020, 10:02:16 AM
When a game starts with Planet X turned on, if Minerva generates with trojan asteroids, their names look like "Minerva - Moon #1", "Minerva - Moon #2", etc. 
This confused me at first, because all other bodies named this way orbit planets, but these were on the orbit of Sol. 

SJW: Fixed
Title: Re: v1.12.0 Bugs Thread
Post by: db48x on October 23, 2020, 11:57:13 AM
Your general explaination it's correct and agree that option should have been greyed out but there is no such function currently so I wouldnt say it's a proper bug but more of a missing feature?

I suppose it could be considered a missing feature instead :)

Furthermore, as you can see from your design even if you have 1 point allocated to Geo the general value is zero which is correct.  A sensor in a buoy needs at least 0.25 value to work and you would also see a reactor component being added if all working properly.

Yes, ironically at first I noticed the missing reactor, but then I shrugged and finished the design anyway. Alas, researching the tech didn't make my existing stock of missiles suddenly start working.

Also, the sensor value does not need to be greater than any threshold value; once I researched the tech and redesigned the buoy the value was only 0.03 and they worked just fine. They took ages to finish, of course, but the surveys were still finished sooner than I could launch my first 1kt survey ship. Also, after I launched the second batch it occurred to me that I could have rounded them down to slightly below 1 MSP and still had the same strength. Then the first stage could have been a little faster. Or if I had made the buoys slightly larger than 1 MSP they could have had 0.04 strength, meaning that they could finish 33% faster! Oh well.
Title: Re: v1.12.0 Bugs Thread
Post by: TheTalkingMeowth on October 23, 2020, 12:21:15 PM
Also, the sensor value does not need to be greater than any threshold value; once I researched the tech and redesigned the buoy the value was only 0.03 and they worked just fine. They took ages to finish, of course, but the surveys were still finished sooner than I could launch my first 1kt survey ship. Also, after I launched the second batch it occurred to me that I could have rounded them down to slightly below 1 MSP and still had the same strength. Then the first stage could have been a little faster. Or if I had made the buoys slightly larger than 1 MSP they could have had 0.04 strength, meaning that they could finish 33% faster! Oh well.

Missile sensors smaller than 0.25 MSP don't do anything. The actual strength of such a sensor can be anything, but the smallest working sensor is 0.25MSP. That's what froggiest was referring to.
Title: Re: v1.12.0 Bugs Thread
Post by: Froggiest1982 on October 23, 2020, 01:21:28 PM
Also, the sensor value does not need to be greater than any threshold value; once I researched the tech and redesigned the buoy the value was only 0.03 and they worked just fine. They took ages to finish, of course, but the surveys were still finished sooner than I could launch my first 1kt survey ship. Also, after I launched the second batch it occurred to me that I could have rounded them down to slightly below 1 MSP and still had the same strength. Then the first stage could have been a little faster. Or if I had made the buoys slightly larger than 1 MSP they could have had 0.04 strength, meaning that they could finish 33% faster! Oh well.

Missile sensors smaller than 0.25 MSP don't do anything. The actual strength of such a sensor can be anything, but the smallest working sensor is 0.25MSP. That's what froggiest was referring to.

yes thanks, I mixed up sensor value with sensor size  :-\
Title: Re: v1.12.0 Bugs Thread
Post by: Garfunkel on October 23, 2020, 08:29:37 PM
I'm getting errors which seem to be when a ship is set to auto-overhaul when it has exceeded deployment.   Right as the auto-order message would normally come up I get these two errors in succession:

1.  12.  0 Function #730: Object reference not set to an instance of an object. 
1.  12.  0 Function #722: Object reference not set to an instance of an object. 

It still sets up the movement orders to the colony (only one with maintenance facilities) and the overhaul order.   Don't see a separate order for refuel/resupply (I forget if it's supposed to be there.  ) The Orders Assigned message is missing though I see the Deployment Time Exceeded message in the previous tick. 

My full orders for these ships:
  • Survey Next Three System Bodies or Locations
  • Move to System Requiring Gravsurvey
  • if Deployment Exceeded, Refueld, Resupply, and Overhaul at Colony
  • if Fuel less than 40%, Refuel from Colony or Hub

These orders seemed to work as I'd expect with no errors at first, but after a few started showing these errors.  Only thing I can think of so far is that they're now 3 jumps out from the colony instead of 1-2.

Just to double-check, are there stabilized jump points through all 3 jumps?
Title: Re: v1.12.0 Bugs Thread
Post by: TheTalkingMeowth on October 23, 2020, 09:01:31 PM
I'm getting errors which seem to be when a ship is set to auto-overhaul when it has exceeded deployment.   Right as the auto-order message would normally come up I get these two errors in succession:

1.  12.  0 Function #730: Object reference not set to an instance of an object. 
1.  12.  0 Function #722: Object reference not set to an instance of an object. 

It still sets up the movement orders to the colony (only one with maintenance facilities) and the overhaul order.   Don't see a separate order for refuel/resupply (I forget if it's supposed to be there.  ) The Orders Assigned message is missing though I see the Deployment Time Exceeded message in the previous tick. 

My full orders for these ships:
  • Survey Next Three System Bodies or Locations
  • Move to System Requiring Gravsurvey
  • if Deployment Exceeded, Refueld, Resupply, and Overhaul at Colony
  • if Fuel less than 40%, Refuel from Colony or Hub

These orders seemed to work as I'd expect with no errors at first, but after a few started showing these errors.  Only thing I can think of so far is that they're now 3 jumps out from the colony instead of 1-2.

Just to double-check, are there stabilized jump points through all 3 jumps?

In my case, no, I don't think it has happened when there was a stabilized path. But the ships involved are all self jump capable.
Title: Re: v1.12.0 Bugs Thread
Post by: TheTalkingMeowth on October 23, 2020, 09:07:02 PM
v1.12.0
Conventional start with 3 NPRs, all spoilers except invaders on

Ground Forces Screen, Unit Series Tab
Conventional star
I suddenly cannot create new unit series. It WAS working when I first tried to use it (before any civilian mining complexes or alien encounters); I added a bunch of unit series right at the start of the game.

When I went back to add some new vehicle types, I now get a Function #3353: an item with the same key has already been added error when I hit OK in the name popup.

This happens for all names, even "Foo," "Bar," and "Totally not a real unit." So I doubt there is such a series already from some other race.

The issue persists after a save and reload.

SJW: Yes, I encountered this myself. Fixed now.
Title: Re: v1.12.0 Bugs Thread
Post by: Droll on October 23, 2020, 10:00:04 PM
v1.12.0
Conventional start with 3 NPRs, all spoilers except invaders on

Ground Forces Screen, Unit Series Tab
Conventional star
I suddenly cannot create new unit series. It WAS working when I first tried to use it (before any civilian mining complexes or alien encounters); I added a bunch of unit series right at the start of the game.

When I went back to add some new vehicle types, I now get a Function #3353: an item with the same key has already been added error when I hit OK in the name popup.

This happens for all names, even "Foo," "Bar," and "Totally not a real unit." So I doubt there is such a series already from some other race.

The issue persists after a save and reload.

+1. This issue happens once a certain amount of unit series have been created. It seems like some bug is hard capping the number of series you can have.

Adding unit series though DB editing will circumvent this issue but becomes finnicky.
Title: Re: v1.12.0 Bugs Thread
Post by: Arcturius on October 24, 2020, 09:24:28 AM
The occupation strength required to force a surrender of an alien population seems implausibly high.   


The occupation strength required to force a surrender of an alien population is very high.     For example to subdue the Martians (50 mio pop) in my test game required an occupation strength of 3803 - about 650,000 tons of PWL infantry.   

After forcing surrender the required occupation strength drops to a much more reasonable 26.     This is about 1/146 of the occupation strength that is required for surrender.   

Now this might be intended, but it looks like it may as well be an oversight in the formula.     Perhabs this is related to the fix of occupation strength and police modifiers for v1.  12.   


Edit: This seems to be the same issue:
Quote from: JustAnotherDude link=topic=11945. msg142032#msg142032 date=1603222401
It seems like occupation strength is very broken: I appear to need about 60 billion tons of ground troops to pacify an enemy homeworld, which has an occupation strength of 161,000.

SJW: Fixed. The code was in two places and I only fixed one of them in v1.12.
Title: Re: v1.12.0 Bugs Thread
Post by: Romalar on October 24, 2020, 12:42:44 PM
Quote from: Garfunkel
Just to double-check, are there stabilized jump points through all 3 jumps?
In my case, none of the jumps would have been stabilized at first but the ships are jump-capable.     It's possible that when the bug started that it was then a mix of stabilized and non-stabilized on the path back, but I think it's always been non-stabilized at the end of the path that the ship in question is on given its nature as a exploration ship.   
Title: Re: v1.12.0 Bugs Thread
Post by: Demetrious on October 24, 2020, 01:59:39 PM
(Minor) Bug: The new "SM Move Fleet to Rendezvous Waypoint" feature does not properly display the name of the waypoint in the Miscellaneous tab of the Naval Organization window: https://i.  imgur.  com/uZT7JaV.  png

The feature is otherwise working perfectly.  Reproducability steps: Slap down a rendezvous waypoint and simply use SM fleet move to see this.     

For completeness's sake: Decimal separator is a period, TN Start, Real Stars, game is only about 10-15 years in.       

SJW: Appears to be working normally for me.
Title: Re: v1.12.0 Bugs Thread
Post by: Arcturius on October 24, 2020, 03:12:54 PM
Quote from: Droll link=topic=11945. msg142205#msg142205 date=1603508404
Quote from: TheTalkingMeowth link=topic=11945. msg142203#msg142203 date=1603505222
v1. 12. 0
Conventional start with 3 NPRs, all spoilers except invaders on

Ground Forces Screen, Unit Series Tab
Conventional star
I suddenly cannot create new unit series.  It WAS working when I first tried to use it (before any civilian mining complexes or alien encounters); I added a bunch of unit series right at the start of the game.

When I went back to add some new vehicle types, I now get a Function #3353: an item with the same key has already been added error when I hit OK in the name popup.

This happens for all names, even "Foo," "Bar," and "Totally not a real unit. " So I doubt there is such a series already from some other race.

The issue persists after a save and reload.

+1.  This issue happens once a certain amount of unit series have been created.  It seems like some bug is hard capping the number of series you can have.

Adding unit series though DB editing will circumvent this issue but becomes finnicky.

+1.  The following steps reliably reproduce the bug:
Title: Re: v1.12.0 Bugs Thread
Post by: vorpal+5 on October 25, 2020, 02:14:27 AM
NPR ship handle (like RUS, CHI, USA prefixing the NPR ship name on the tactical screen) does not correspond to what you have entered in race creation as the race short name, but always correspond to the three first letters of the race long name.

100% reproducible in all settings

SJW: Not a bug. The 3 letter code is generated using the name of a race but is intended to be manually set in the Intelligence window.
Title: Re: v1.12.0 Bugs Thread
Post by: vorpal+5 on October 25, 2020, 04:23:51 AM
I'm unsure if this is a bug or a 'feature' although I'm not too sure this one would have any positive aspects if a feature. Using (the default) 'real ship / class names', upon detecting my fellow others nations block on Earth, most if not all of their ships are named alphabetically, so they mostly start with a 'A'.

For example the US ships classes are Aberdeen and Abilene (they are the first two entries in their list, which is about US cities and states').
Russia ships classes are ... Aleksandrovsk and Akmolinsk and for the Japanese, this is Abukuma and Agano ...

I would tend to say that's a bug, because it feels rather suboptimal to me. I would have imagined that AI races picked a name at random in the list and not alphabetically.

SJW: It's not a bug as it is working as intended. However, I think changing it to random order is a good idea.
Title: Re: v1.12.0 Bugs Thread
Post by: replicant2699 on October 25, 2020, 07:00:44 AM
Yep, it just happened again. I have the system set to alien controlled and no auto route, the ship is flagged to ignore alien controlled systems and it definitely had no orders queued. I had sent him back to refuel and on to a system far away from here last time this happened. He has actually passed through another alien controlled, no autoroute system to get where I just found him.

I have tested this again today and it seems that if you set that alien race as hostile, your ships will not jump to those systems, though they ignore those orders if it's set to neutral.
Title: Re: v1.12.0 Bugs Thread
Post by: TheTalkingMeowth on October 25, 2020, 11:44:43 AM
NPR ship handle (like RUS, CHI, USA prefixing the NPR ship name on the tactical screen) does not correspond to what you have entered in race creation as the race short name, but always correspond to the three first letters of the race long name.

100% reproducible in all settings

You have to set the "reporting" abbreviation in the Diplomacy window. Otherwise it takes the default as described.
Title: Re: v1.12.0 Bugs Thread
Post by: Demetrious on October 25, 2020, 01:53:24 PM
Two (related?) bugs, one test game - STO surface-to-surface fire throws an error and Ground Support Fighters receive no protection from STO fire while executing ground support orders at a system body. 

1.  STO's throw error "1. 12. 0 Function #311: Object reference not set to an instance of an object" when attempting to fire on civilian populations, shipyards, ground forces and STO ground forces contacts, (located on another system body that is in-range, of course, such as a moon. ) The fire seems to resolve normally, but no combat report is received in the "events" window; only the energy weapon impacts as normal for a third party.  Off-board sensors (such as on a starship) do not affect this in any way. 

2a.  Ground Support Fighters cannot be given a "free-ranging" (e. g.  Search And Destroy) order with just a system body as a target, as documented; a friendly colony must be created. This may only amount to outdated documentation, but it should be confirmed. 

2b.  Ground Support Fighter "protection" is non-functional against STO units in every applicable context. I have tested this on "free-range" missions (Search And Destroy, Flak Suppression, etc. ) with a friendly (empty) colony on the planet, and with friendly ground troops on the planet, with FFD capacity, with the support relationships set up.  In every case the STOs cheerfully engage the ground support fighters with active ground support orders that are on top of the system body.  This is not AA fire as the message is identical to the STO message (someship has been engaged by ground-based energy weapons on Planet,) fire happens every 5 second tick instead of the 8 hour ground combat tick and the fighters themselves never resolve their own ground combat fire. 

For ease of reproducability I have provided a test game with everything already set up. See attached file "AuroraDB_STO_and_fighter_bug_testing. zip. " Game name is "New Game Doot," (as renaming saved games seems nonfunctional at the moment. ) Test subject is NPR Race [AL1] on Alpha Centauri II.  A-II Moon 1 hosts four STO units (TESTING STO 1, 2 3 and 4) pre-set to target shipyards, populations, ground forces and STO ground forces, respectively.  Active sensors are initially off.  ELINT is in the system to keep population contacts live and some missile fighters + sensor ship are in range to verify off-board sensor interaction and/or stimulate defenses to reveal NPR STO units.  The Naval Admin Command "TESTING FLEET" contains prepared assets (clearly named for clarity) for further testing, including Ground Attack Fighters, a loaded troop ship (SM it over A-II and order a drop immediately, it'll resolve that before it gets blown up,) and a conventional particle beam/carrier fleet.  No Rendezvous Waypoints are active so any you create for SM fleet move purposes will be the first in the list. 

Final Note: There are actually two NPR populations on Alpha Centauri A-II; they spawned this way.  Since this itself may be a bug I've included a second save file from immediately after discovering this; before both civs started blowing the hell out of each other.  This may be of interest to Steve, just to compare both files and see how the (unintentional?) NPR multi-race start played out.  Filename is "AuroraDB(early alpha centarui rumble 1. 12). db. zip. "

Technical details: TN start, period decimal separator, easily reproducible (see attached test game) and relatively short games. 

Files: Since I don't have enough posts yet the forum software is treating me with suspicion, so unfortunately you will have to untangle these Mediafire links yourselves:

hxxp: www. mediafire. com/file/zvlit41zaj1fqea/AuroraDB_STO_and_fighter_bug_testing. zip/file

hxxp: www. mediafire. com/file/7g5q8mxclsfzzpn/AuroraDB(early+alpha+centarui+rumble+1. 12). db. zip/file

SJW: 1, 2a and 2b all fixed. Multiple NPRs on same planet is working as intended.
Title: Re: v1.12.0 Bugs Thread
Post by: Droll on October 25, 2020, 02:02:34 PM
2b.  Ground Support Fighter "protection" is non-functional against STO units in every applicable context. I have tested this on "free-range" missions (Search And Destroy, Flak Suppression, etc. ) with a friendly (empty) colony on the planet, and with friendly ground troops on the planet, with FFD capacity, with the support relationships set up.  In every case the STOs cheerfully engage the ground support fighters with active ground support orders that are on top of the system body.  This is not AA fire as the message is identical to the STO message (someship has been engaged by ground-based energy weapons on Planet,) fire happens every 5 second tick instead of the 8 hour ground combat tick and the fighters themselves never resolve their own ground combat fire. 

Yeah this is a problem that renders CAS less than useless. An easy solution would be to make all craft flagged as "fighters" immune to STO targeting and let AA be their exclusive ground-based threat.
On a related note, how does AA damage translate to CAS fighters - damage and armor pen wise?
Title: Re: v1.12.0 Bugs Thread
Post by: Demetrious on October 25, 2020, 02:30:12 PM
Quote from: Droll link=topic=11945. msg142262#msg142262 date=1603652554
Yeah this is a problem that renders CAS less than useless.  An easy solution would be to make all craft flagged as "fighters" immune to STO targeting and let AA be their exclusive ground-based threat.
On a related note, how does AA damage translate to CAS fighters - damage and armor pen wise?

Probably the same scaling rule that Steve uses for translating capital weaponry to ground scale damage for purposes of calculating collateral damage:

"The damage in ground combat for an energy weapon is equal to 20x the square root of its point blank damage in ship-to-ship combat.  Armour penetration is equal to half the damage.  Fractions are retained.  For example, the AP/Damage ratings would be 10/20 for a 10cm railgun round or gauss cannon, 17. 3/34. 6 for a 10cm laser, 40/80 for a 25cm laser.  Weapons roll for failure in the same way as in naval combat. "

I wouldn't know about armor, though, that's a good question. 
Title: Re: v1.12.0 Bugs Thread
Post by: Droll on October 25, 2020, 03:11:59 PM
Quote from: Droll link=topic=11945. msg142262#msg142262 date=1603652554
Yeah this is a problem that renders CAS less than useless.  An easy solution would be to make all craft flagged as "fighters" immune to STO targeting and let AA be their exclusive ground-based threat.
On a related note, how does AA damage translate to CAS fighters - damage and armor pen wise?

Probably the same scaling rule that Steve uses for translating capital weaponry to ground scale damage for purposes of calculating collateral damage:

"The damage in ground combat for an energy weapon is equal to 20x the square root of its point blank damage in ship-to-ship combat.  Armour penetration is equal to half the damage.  Fractions are retained.  For example, the AP/Damage ratings would be 10/20 for a 10cm railgun round or gauss cannon, 17. 3/34. 6 for a 10cm laser, 40/80 for a 25cm laser.  Weapons roll for failure in the same way as in naval combat. "

I wouldn't know about armor, though, that's a good question.

That answers capital to ground but I'm asking the reverse. In my case it seems like precursor AA Decurions can one shot (or two shot) fighters with 4 layers of armor
Title: Re: v1.12.0 Bugs Thread
Post by: Demetrious on October 25, 2020, 03:43:15 PM
Quote from: Droll link=topic=11945.  msg142262#msg142262 date=1603652554
That answers capital to ground but I'm asking the reverse.  In my case it seems like precursor AA Decurions can one shot (or two shot) fighters with 4 layers of armor

I'd assume that you can just invert that equation to translate ground weapons to capital scale.  It'd be nice to have a firmer grasp on it though, because as you note spoilers tend to be very shooty and accounting for tech disparities like that is hard to do without a better idea of how their known capital weaponry translates to ground capability. 
Title: Re: v1.12.0 Bugs Thread
Post by: jtgasv on October 27, 2020, 12:15:17 PM
conventional start, real stars, 200+yrs

orbital habitats allow population to exceed the orbital/planetary population cap
occurring on both luna and mars.

for some reason I was unable to post when attaching the database file.
Title: Re: v1.12.0 Bugs Thread
Post by: bankshot on October 27, 2020, 02:27:42 PM
Civilian Fuel harvesters do not respect planetary bans

TN start, civilian fuel harvesters checked.  My geosurvey found sorium in Jupiter (5M, .6 acc), Saturn (4M, .8 acc), and Minerva (150K, .7 acc).   I banned Saturn to reserve it for my own harvesters, but left Jupiter and Minerva open for civilian harvesting.  I selected "no" to ban the moons, and Saturn is now listed as Saturn(B) confirming the ban was applied. 

The first civilian harvester was created 5 years later, and moved to Saturn.

SJW: Fixed
Title: Re: v1.12.0 Bugs Thread
Post by: Froggiest1982 on October 27, 2020, 05:08:59 PM
I am quite sure ice used to melt at -17 degrees celsius however in this game I am playing now, the ice on Mars melt at -27.9???

Bug?

Any feedback?

EDIT: The wiki mentions -18 Celsius, still far away from -28... http://aurorawiki.pentarch.org/index.php?title=Terraforming

EDIT 2: As a result, even the Water Vapour is different due to different pressure. It used to be 0.0003 but now it's 0.0002.

SJW: It's always been -28C. That is on the low side compared to reality though.
Title: Re: v1.12.0 Bugs Thread
Post by: jtgasv on October 28, 2020, 02:05:58 AM
conventional start, real stars, 200+ yrs.
reproducible in a fresh game with both real and non-real stars.

deep space tracking ranges seem to "wrap around" where the 10,000 range resets to a smaller value,  then the 1,000.  then the 10,000.  etc, as the number of stations, or tech levels grow.  sometimes the 10,000 range disappears entirely. im not sure if its a display issue on the system map or a range limit.

reproduceable by sm mode.  give yourself a high planetary sensor strength tech (2000 was my test). 
turn on passive vs signature 1,000 and 10,000.
then add deep space tracking centers a few at a time.

seems to happen around 11-12m km range

SJW: Fixed
Title: Re: v1.12.0 Bugs Thread
Post by: Ektor on October 28, 2020, 11:56:22 AM
I'm not sure whether this was already posted, but the conditional order "Refuel, Resupply and Overhaul at Colony" gives off errors #722 and #730 "Object reference was not set to instance of an object" when the conditions trigger. This leads the fleet that takes the order to return to a colony and overhaul, however they don't refuel and resupply.

The specific situation if you want to replicate the bug is the following: I had a jump capable survey ship with both geo and grav modules set on the following standing orders: 1. Survey next system body 2. Survey next survey location 3. If fuel less than 40% - Refuel at colony or hub (all) 4. When deployment time exceeded - Refuel, Resupply and Overhaul at Colony.
Title: Re: v1.12.0 Bugs Thread
Post by: TheTalkingMeowth on October 28, 2020, 12:43:45 PM
I'm not sure whether this was already posted, but the conditional order "Refuel, Resupply and Overhaul at Colony" gives off errors #722 and #730 "Object reference was not set to instance of an object" when the conditions trigger. This leads the fleet that takes the order to return to a colony and overhaul, however they don't refuel and resupply.

The specific situation if you want to replicate the bug is the following: I had a jump capable survey ship with both geo and grav modules set on the following standing orders: 1. Survey next system body 2. Survey next survey location 3. If fuel less than 40% - Refuel at colony or hub (all) 4. When deployment time exceeded - Refuel, Resupply and Overhaul at Colony.

It's been posted, but a little extra information would be useful. Can you describe how this interacts with stabilized jump points? We're not sure if it happens if the path back is fully stabilized.
Title: Re: v1.12.0 Bugs Thread
Post by: Ektor on October 28, 2020, 05:14:19 PM
It happens regardless of the points being stabilized or not. I've had it happen with both stabilized and unstabilized points.
Title: Re: v1.12.0 Bugs Thread
Post by: TheTalkingMeowth on October 28, 2020, 05:44:09 PM
It happens regardless of the points being stabilized or not. I've had it happen with both stabilized and unstabilized points.

Has the path back been fully stabilized? I've never seen it happen without at least one unstabilized point in the path.
Title: Re: v1.12.0 Bugs Thread
Post by: Ektor on October 28, 2020, 06:02:15 PM
It was only one JP away from said colony, but yeah, the JP was stabilised.
Title: Re: v1.12.0 Bugs Thread
Post by: jtgasv on October 28, 2020, 11:22:59 PM
conventional start, real stars, 200+ yrs.
reproducible in a fresh game with both real and non-real stars.

deep space tracking ranges seem to "wrap around" where the 10,000 range resets to a smaller value,  then the 1,000.  then the 10,000.  etc, as the number of stations, or tech levels grow.  sometimes the 10,000 range disappears entirely. im not sure if its a display issue on the system map or a range limit.

reproduceable by sm mode.  give yourself a high planetary sensor strength tech (2000 was my test). 
turn on passive vs signature 1,000 and 10,000.
then add deep space tracking centers a few at a time.

seems to happen around 11-12m km range

first occurs at 215,000 tracking station strength ~11.58m range
and again at 644,000
and 1,074,600
and 1,503,000

etc etc at ~430,000x+215,000 tracking strength.  each time the passive vs signature 10,000 range resets.


Title: Re: v1.12.0 Bugs Thread
Post by: db48x on October 29, 2020, 11:41:25 AM
conventional start, real stars, 200+ yrs.
reproducible in a fresh game with both real and non-real stars.

deep space tracking ranges seem to "wrap around" where the 10,000 range resets to a smaller value,  then the 1,000.  then the 10,000.  etc, as the number of stations, or tech levels grow.  sometimes the 10,000 range disappears entirely. im not sure if its a display issue on the system map or a range limit.

reproduceable by sm mode.  give yourself a high planetary sensor strength tech (2000 was my test). 
turn on passive vs signature 1,000 and 10,000.
then add deep space tracking centers a few at a time.

seems to happen around 11-12m km range

first occurs at 215,000 tracking station strength ~11.58m range
and again at 644,000
and 1,074,600
and 1,503,000

etc etc at ~430,000x+215,000 tracking strength.  each time the passive vs signature 10,000 range resets.

That's clearly integer overflow. With the new passive sensor model (http://aurora2.pentarch.org/index.php?topic=8495.msg103085#msg103085), the formula for the range is Detection Range = SQRT(Passive Sensor Strength * Target Signature ) * 250,000 km.

215,000 * 10,000 > 2^31-1, so it doesn't fit into a signed 32-bit integer. Using an unsigned 32-bit integer would delay the overflow until the sensor strength was 430,000. At the highest tech level, the range wraps around after 57 deep space tracking stations. This gives a maximum tracking range of 11.58 bkm, or 77.4 au.

Using an unsigned 64-bit number instead would delay the inevitable until the sensor strength was 1.844×10¹?, which is a pretty big number. At the highest possible tech level that will still be more than 491 billion tracking stations. Even then, I would specifically check for overflow so that I could use the maximum usable tracking strength instead of wrapping around. Looks like that would top out at a maximum detection range of 113 light years, which is silly enough that nobody would be bothered that they can't increase it further.

Note that once that bug is fixed, there will be another overflow bug when multiplying by 250,000 km. Might as well fix both at the same time. I don't know C# or .Net very well, but perhaps there are library functions for checked multiplication, or for saturating multiplication. Using them would do most of the work.

Bonus points for actually allowing detection of units in other star systems if the detection range is big enough…
Title: Re: v1.12.0 Bugs Thread
Post by: Droll on October 29, 2020, 01:20:53 PM
I would specifically check for overflow so that I could use the maximum usable tracking strength instead of wrapping around. Looks like that would top out at a maximum detection range of 113 light years, which is silly enough that nobody would be bothered that they can't increase it further.

Bonus points for actually allowing detection of units in other star systems if the detection range is big enough…

This would be brilliant in the suggestion thread. I think an interesting extension would be to add JP listening which would allow you to use a small % of your sensor sensitivity to "peek" through the other end of a JP.
Title: Re: v1.12.0 Bugs Thread
Post by: db48x on October 29, 2020, 01:39:43 PM
I would specifically check for overflow so that I could use the maximum usable tracking strength instead of wrapping around. Looks like that would top out at a maximum detection range of 113 light years, which is silly enough that nobody would be bothered that they can't increase it further.

Bonus points for actually allowing detection of units in other star systems if the detection range is big enough…

This would be brilliant in the suggestion thread. I think an interesting extension would be to add JP listening which would allow you to use a small % of your sensor sensitivity to "peek" through the other end of a JP.

Heh, I was actually being a little bit facetious. At the maximum of 3750 sensor strength per tracking station, it would take 687,842,178 tracking stations to be able to see into the Proxima Centauri system. Good luck mining the 137.6 billion uridium you'll need.

But letting radar go through stable wormholes would be a welcome addition, I think.
Title: Re: v1.12.0 Bugs Thread
Post by: Ektor on October 29, 2020, 08:51:33 PM
I've just gotten a weird bug. I was fighting some precursors on a planet, when my HQ got overrun. The game throwed a divide by zero error and my units that were within the formation that got its HQ overran disappeared from the ground forces window. The only way I could retrieve them was to load them up on my transports, after a messy loading process where they had to be loaded more than once, all the while the game threw several errors, they reappeared inside the transports.
Title: Re: v1.12.0 Bugs Thread
Post by: db48x on October 30, 2020, 04:00:58 AM
Has anyone else noticed that the mass driver column on the mining tab only ever reports negative numbers? It reports minerals leaving my mining colonies, but not any that arrive at Earth. I know the minerals are arriving, of course. Similarly, the Stockpile Change column on the Empire Mining tab doesn't always report arriving minerals. For example, Earth has run out of Corundium, and I have an empire-wide stockpile of 601 tons. Last week it was 598 tons, so I know that some have arrived somewhere, but the Stockpile Change column reports 0 tons. If three tons were mined at a colony and immediately shipped out via mass driver, but the 3 tons that arrived on Earth that week weren't counted, then that would explain the discrepancy. It would count +3-3+0=0 instead of +3-3+3=3.

v1.12, decimal separator is a period, no error messages, game of any length.

I'm playing with half minerals on Earth. This is turning out to be pretty hard because only four bodies in the whole solar system had any Corundium, and two of them are moons of Minerva…
Title: Re: v1.12.0 Bugs Thread
Post by: Garfunkel on October 30, 2020, 12:22:08 PM
Has anyone else noticed that the mass driver column on the mining tab only ever reports negative numbers? It reports minerals leaving my mining colonies, but not any that arrive at Earth. I know the minerals are arriving, of course. Similarly, the Stockpile Change column on the Empire Mining tab doesn't always report arriving minerals. For example, Earth has run out of Corundium, and I have an empire-wide stockpile of 601 tons. Last week it was 598 tons, so I know that some have arrived somewhere, but the Stockpile Change column reports 0 tons. If three tons were mined at a colony and immediately shipped out via mass driver, but the 3 tons that arrived on Earth that week weren't counted, then that would explain the discrepancy. It would count +3-3+0=0 instead of +3-3+3=3.

v1.12, decimal separator is a period, no error messages, game of any length.

I'm playing with half minerals on Earth. This is turning out to be pretty hard because only four bodies in the whole solar system had any Corundium, and two of them are moons of Minerva…
This is an ongoing thing and it was already in VB6 - the column will only report minerals that arrived during the latest sub-pulse. So most of the time, you will miss seeing it. In any case, it has been this way for a long time so it's safe to assume that it's working as intended.
Title: Re: v1.12.0 Bugs Thread
Post by: QuakeIV on October 30, 2020, 08:57:07 PM
I have a save that is infinite 5 second sub pulses no matter what I do (including diddling with the sub pulse settings), however I used my event interrupt toggler mod, so the game is technically modded.  I'm just pretty sure the bug is unrelated to what my mod did.  Is there any point in posting the DB?
Title: Re: v1.12.0 Bugs Thread
Post by: db48x on October 30, 2020, 10:27:20 PM
I have a save that is infinite 5 second sub pulses no matter what I do (including diddling with the sub pulse settings), however I used my event interrupt toggler mod, so the game is technically modded.  I'm just pretty sure the bug is unrelated to what my mod did.  Is there any point in posting the DB?

That's almost always combat between NPRs. It'll end when the combat ends. How long does it take for your computer to process a 5s turn?
Title: Re: v1.12.0 Bugs Thread
Post by: QuakeIV on October 30, 2020, 10:31:09 PM
About a tenth of a second.  I left it running in the background for two days and it hasn't ended yet.  I'm pretty sure its gotten through multiple (ingame) weeks of 5 seconds.
Title: Re: v1.12.0 Bugs Thread
Post by: db48x on October 31, 2020, 12:36:14 AM
About a tenth of a second.  I left it running in the background for two days and it hasn't ended yet.  I'm pretty sure its gotten through multiple (ingame) weeks of 5 seconds.

And you are absolutely sure that none of your fleets have their fire controls turned on?
Title: Re: v1.12.0 Bugs Thread
Post by: QuakeIV on October 31, 2020, 03:34:15 AM
About a tenth of a second.  I left it running in the background for two days and it hasn't ended yet.  I'm pretty sure its gotten through multiple (ingame) weeks of 5 seconds.

And you are absolutely sure that none of your fleets have their fire controls turned on?

OH MY GOD THAT WAS IT

I could have sworn, for the life of me, that that didn't apply to MFC, and also that there was a special interurpt message if it was your own fire controls holding things up.  Dear lord above, I've even had this exact issue before.

e: so yeah, false alarm, apologies
Title: Re: v1.12.0 Bugs Thread
Post by: db48x on October 31, 2020, 04:10:07 AM
And you are absolutely sure that none of your fleets have their fire controls turned on?

OH MY GOD THAT WAS IT

I could have sworn, for the life of me, that that didn't apply to MFC, and also that there was a special interurpt message if it was your own fire controls holding things up.  Dear lord above, I've even had this exact issue before.

e: so yeah, false alarm, apologies

It's happened to me as well. I think there really ought to be different messages for different causes.
Title: Re: v1.12.0 Bugs Thread
Post by: Droll on October 31, 2020, 04:23:39 PM
So under the misc. tab in the naval fleet menu if you have SM mode you can teleport fleets to either a colony or as of 1.12.0 a rendezvous point.

The problem is when you have a rendezvous point, instead of displaying the name of the waypoint it seems to be displaying the actual C# class name.

In vanilla aurora this seems to be "Je" which I believe is the obfuscated class name for waypoints (or something similar)
Using auroramod 1.12 this appears instead as "GClass190" (I presume this is the deobfuscated equivalent)

Someone should reproduce this and post a reply to confirm this. Just create any rendezvous waypoint with any name and try to use SM to teleport a fleet to it and see if it is called any of these.

I do not regard this as a cosmetic bug because without the player given names its impossible to tell different rendezvous waypoints apart in this menu.

SJW: The bug with weird names was reported before but I couldn't reproduce it. The above explains why. I am using non-obfuscated code. I've excluded waypoint names from obfuscation so should be fixed now.
Title: Re: v1.12.0 Bugs Thread
Post by: vorpal+5 on October 31, 2020, 11:57:17 PM
I can now confirm ... having perused the database a lot, that any NPR creates its ships picking names in alphabetical order, systematically.

This might have been overlooked by Steve because I guess that 95% of the time, you don't keep 'use real ships names' in the Intelligence window, but you name them yourself. But, having checked the 15 (!!) initial NPRs I have created in my game (9 being Earth blocks, 6 being true aliens), then I confirm that every single one, for the 312 ships existing in the universe at Day 0 has been using their list in AB order.

1.12.1, systematical, reproducible.
Title: Ticking "Point Defence Weapon" Doesn't increase tracking rate
Post by: joshuawood on November 01, 2020, 01:00:46 PM
Ticking the box on the ground unit design screen for STO weapons doesn't increase the tracking speed but it does Decrease Range, no idea if visual bug or Functional one as i haven't had my STO's shot at yet but i have confirmed it in 3 games so far.

Here are 2 screenshots for example:
https://i.imgur.com/ZCLvEGq.png
https://i.imgur.com/KTLFi3f.png

SJW: Gauss weapons cannot be in turrets so they are unable to use the tracking speed multiples.
Title: Re: v1.12.0 Bugs Thread
Post by: bankshot on November 01, 2020, 03:41:06 PM
Disassembling alien parts at a second colony does not yield research points

I have found two ruins of the same TL2 civilization.  I unearthed one set of three ECM-1 components from each location.  I waited until I had completed researching EW before disassembly to maximize their effect.  I disassembled one set at Earth then advanced time and confirmed that the tech points shown in the event log were properly subtracted from ECM-1 tech.  However after disassembling the second set at a colony I again advanced time and saw the tech points in the event log but they were not subtracted from the required research total.  Reversing the order of disassembly yielded the same effect - points from the second set were ignored, even if I advanced time for 5 days before the second disassembly.

Further, disassembling one on earth for 200 points then all three on Levinor for 400 points only gave the first 200 point reduction.  I could then disassemble another at earth which was properly reduced.  So it looks like you can only get research credit for disassembly from one colony. 

In case it matters - the components on Earth were dug up on Mars, but the martian ruins were from the same TL-2 civ as Levinor.  When I geo-surveyed the planet the ruins were already translated, they did not require xeno-survey.

to reproduce:  disassemble one or more ECM-1 components on Earth, advance time 5 seconds to see the result.  Then do the same with ECM-1 components on Levinor-A III.  Or do it on Levinor first, then Earth.

TN start, 11 years in, non-real starts, period decimal separator.

edit: I'm unable to save an attachment.  Here's a google drive link to the db:  https://drive.google.com/file/d/1FY0wfYNqwLN48CVTLYEF2o0UXxA1qJRF/view?usp=sharing

Not a bug, this is working as intended. Because a research project can only be worked on at a single colony, research points from disassembling components can also only be gained at a single colony. -Garfunkel
Title: Re: v1.12.0 Bugs Thread
Post by: bankshot on November 01, 2020, 04:09:45 PM
The time to load cargo is dependent upon the remaining cargo capacity of the cargo ship, not on the amount loaded

Previously reported in 1.11 

http://aurora2.pentarch.org/index.php?topic=11565.msg136403#msg136403

This can be confirmed using minerals or ship components using the save I uploaded on my disassembly bug report above. 

SJW: This is working as intended. Its always been this way, because the amount available to load may change after the time to load is calculated (on arrival), so the solution was to have a fixed time equal to full load.
Title: Re: v1.12.0 Bugs Thread
Post by: Froggiest1982 on November 01, 2020, 05:33:58 PM
Survey of 1 Jump Point Location ended up with the discovery of 2 Jump Points

1.12
Native Period

DB attached.

EDIT: It doesn't let me attach the database, here is the link for direct download: https://gofile.io/d/vV8dgR

SJW: That is working as intended. A survey location reveals all jump points within its section of the system.
Title: Re: v1.12.0 Bugs Thread
Post by: bankshot on November 01, 2020, 07:17:51 PM
Load ship components does not respect the maximum # of items.

@Garfunkel:  re: disassembling components.  research progress limited to one colony is how I remembered it from VB6, but not how it has worked for me in C#.  I've tested cancelling a research project at one colony and then starting it at another, and the research point count continues to decrement properly.  You can't have a project running at two colonies at the same time but you can move the project between colonies whenever you wish by cancelling and restarting. 

I did more testing, and disassembly seems to be able to create the project if it does not exist, but does not seem to be able to move an existing project to the colony.  So if I disassembled components on Luna then did a disassembly on Earth I'd lose any points from the Earth disassembly.  However after assigning a research lab on Earth and advancing time 5 days Earth took over the project, and I could then disassemble on Earth but not on Luna.  Assigning a lab and advancing time moved the project to Earth.

Cancelling that project and assigning a lab at Mars then advancing time 5 days allowed me to disassemble at Mars. 

So research gains from disassembly cannot move a project to a new colony the way research gains from a lab can - but I don't know if that limitation is intended.
Title: Re: v1.12.0 Bugs Thread
Post by: Droll on November 02, 2020, 07:09:53 AM
1.12.1, systematical, reproducible.

I am fairly certain that you mean 1.12.0 unless you come from the future.
Title: Re: v1.12.0 Bugs Thread
Post by: Black on November 02, 2020, 03:55:09 PM
I was playing with system generation and I noticed when I change orbit of a planet with trojan asteroids, those asteroids will not adjust their orbit to new position and remain on original orbit.

SJW: Fixed
Title: Re: v1.12.0 Bugs Thread
Post by: Ektor on November 02, 2020, 05:24:59 PM
So I genned a system, made a couple planets, and spawned a player race. Then, I spawned two same race NPRs to act as competitors.

A couple minutes ago, I saved the game and then closed it to go for some coffee. When I returned and opened the game again, it threw the following errors: "1.12.0 Function #1333: The given key was not present in dictionary," "1.12.0 Function #1341: The given key was not present in dictionary" and 1.12.0 Function #1343: The given key was not present in dictionary." The two NPRs I had spawned were completely and entirely vanished. All their ships and pops were gone. This pretty much wrecked my game and I'll have to restart.
Title: Re: v1.12.0 Bugs Thread
Post by: TheTalkingMeowth on November 02, 2020, 06:11:24 PM
Load ship components does not respect the maximum # of items.

@Garfunkel:  re: disassembling components.  research progress limited to one colony is how I remembered it from VB6, but not how it has worked for me in C#.  I've tested cancelling a research project at one colony and then starting it at another, and the research point count continues to decrement properly.  You can't have a project running at two colonies at the same time but you can move the project between colonies whenever you wish by cancelling and restarting. 

I did more testing, and disassembly seems to be able to create the project if it does not exist, but does not seem to be able to move an existing project to the colony.  So if I disassembled components on Luna then did a disassembly on Earth I'd lose any points from the Earth disassembly.  However after assigning a research lab on Earth and advancing time 5 days Earth took over the project, and I could then disassemble on Earth but not on Luna.  Assigning a lab and advancing time moved the project to Earth.

Cancelling that project and assigning a lab at Mars then advancing time 5 days allowed me to disassemble at Mars. 

So research gains from disassembly cannot move a project to a new colony the way research gains from a lab can - but I don't know if that limitation is intended.

This happened in v1.11 too. It's definitely a bug.

Be careful, bankshot. I later SM instanted a project that had both disassembly and lab research, and that somehow deleted every NPR and spoiler. Wrecks, colonies, ships, and contents of the race window.
Title: Re: v1.12.0 Bugs Thread
Post by: Malorn on November 03, 2020, 09:47:20 AM
AI ships seem to have a very strange reaction to superior forces in the latest 1.12 version.

When confronted by superior attackers, the ships head immediately for the nearest Jump Point, even if that jump point leads directly into the 'enemy' home system. This could, in theory, be good tactics, but they jump through, and find themselves confronted by a large blockade force. Again, this could be the fortune of war.

Now, however, comes the buggy part. Before my ships can open fire at pointblank range, they jump BACK through the jump point, and my ships follow them through.

At this point I assumed they would try to run for it...

In reality, they continue to jump back and forth, with none of my ships, even on 5-second increments, ever able to actually fire on them, on either side of the jump point. I finally was forced to split my forces to sit on both sides of the jump point, in the hopes of engaging them. But they still jumped back and forth without me being able to get a shot off on either side of the gate with the waiting ships. This continued until I gave up and allowed them to leave after 18 cycles of jumping.

This... really isn't good for the game, as it makes it possible for any force, no matter how weak, to avoid engagement indefinitely. I thought there was some sort of jump cooldown which would prevent ships from making another jump instantly, as well as not using sensors? My guess is, since this was a stable jump point, that no jump engines were being used, and thus there was no cooldown.  I think there needs to be some sort of basic jump cooldown before another jump is possible, ideally a cooldown which is longer than the jump shock, allowing a chance for ships with superior speed to actually engage their enemies, since they cannot escape.

I know that NPR's don't have the same downsides for jumping as the player, due to weaker decision making, but I cannot think it is intended to be used in this way. In each case here, the ships were jumping back through the point within 5 seconds, with seemingly no end in sight.
Title: Re: v1.12.0 Bugs Thread
Post by: Droll on November 03, 2020, 11:33:31 AM
AI ships seem to have a very strange reaction to superior forces in the latest 1.12 version.

When confronted by superior attackers, the ships head immediately for the nearest Jump Point, even if that jump point leads directly into the 'enemy' home system. This could, in theory, be good tactics, but they jump through, and find themselves confronted by a large blockade force. Again, this could be the fortune of war.

Now, however, comes the buggy part. Before my ships can open fire at pointblank range, they jump BACK through the jump point, and my ships follow them through.

At this point I assumed they would try to run for it...

In reality, they continue to jump back and forth, with none of my ships, even on 5-second increments, ever able to actually fire on them, on either side of the jump point. I finally was forced to split my forces to sit on both sides of the jump point, in the hopes of engaging them. But they still jumped back and forth without me being able to get a shot off on either side of the gate with the waiting ships. This continued until I gave up and allowed them to leave after 18 cycles of jumping.

This... really isn't good for the game, as it makes it possible for any force, no matter how weak, to avoid engagement indefinitely. I thought there was some sort of jump cooldown which would prevent ships from making another jump instantly, as well as not using sensors? My guess is, since this was a stable jump point, that no jump engines were being used, and thus there was no cooldown.  I think there needs to be some sort of basic jump cooldown before another jump is possible, ideally a cooldown which is longer than the jump shock, allowing a chance for ships with superior speed to actually engage their enemies, since they cannot escape.

I know that NPR's don't have the same downsides for jumping as the player, due to weaker decision making, but I cannot think it is intended to be used in this way. In each case here, the ships were jumping back through the point within 5 seconds, with seemingly no end in sight.

This is a problem, Jump shock should also prevent jumping while in effect
Title: Re: v1.12.0 Bugs Thread
Post by: xenoscepter on November 03, 2020, 12:13:41 PM
AI ships seem to have a very strange reaction to superior forces in the latest 1.12 version.

When confronted by superior attackers, the ships head immediately for the nearest Jump Point, even if that jump point leads directly into the 'enemy' home system. This could, in theory, be good tactics, but they jump through, and find themselves confronted by a large blockade force. Again, this could be the fortune of war.

Now, however, comes the buggy part. Before my ships can open fire at pointblank range, they jump BACK through the jump point, and my ships follow them through.

At this point I assumed they would try to run for it...

In reality, they continue to jump back and forth, with none of my ships, even on 5-second increments, ever able to actually fire on them, on either side of the jump point. I finally was forced to split my forces to sit on both sides of the jump point, in the hopes of engaging them. But they still jumped back and forth without me being able to get a shot off on either side of the gate with the waiting ships. This continued until I gave up and allowed them to leave after 18 cycles of jumping.

This... really isn't good for the game, as it makes it possible for any force, no matter how weak, to avoid engagement indefinitely. I thought there was some sort of jump cooldown which would prevent ships from making another jump instantly, as well as not using sensors? My guess is, since this was a stable jump point, that no jump engines were being used, and thus there was no cooldown.  I think there needs to be some sort of basic jump cooldown before another jump is possible, ideally a cooldown which is longer than the jump shock, allowing a chance for ships with superior speed to actually engage their enemies, since they cannot escape.

I know that NPR's don't have the same downsides for jumping as the player, due to weaker decision making, but I cannot think it is intended to be used in this way. In each case here, the ships were jumping back through the point within 5 seconds, with seemingly no end in sight.

 - I'm strongly against a cooldown mechanic, but rather think Jumping should just be either a flat 10 seconds or 15 seconds. The logic for the two increment being that it takes an increment to "jump out" and an increment to "jump in". The logic for the three increment would be either two increments to "plot" the jump and one increment to do the jump itself, or one increment to "plot" the jump, and two increments to complete it.

 - I'm in favor of the three increment system with one increment used for plotting the jump, which can then have the three increment reduced to two with the inclusion of a "Navigation" bridge module. Maybe even have Officers with some sort of Jump bonuses. We could also have it so that the players and NPRs get priority to fire on jumping targets. I'm tempted to dismiss this as "just good use of tactics" since it's technically consistent with Aurora's internal laws, but while the argument for that could be made... the fact remains that it just isn't fun and really only serves to delay the inevitable.
Title: Re: v1.12.0 Bugs Thread
Post by: nuclearslurpee on November 03, 2020, 01:22:37 PM
Quote from: Malorn link=topic=11945. msg142587#msg142587 date=1604418440
AI ships seem to have a very strange reaction to superior forces in the latest 1. 12 version.

When confronted by superior attackers, the ships head immediately for the nearest Jump Point, even if that jump point leads directly into the 'enemy' home system.  This could, in theory, be good tactics, but they jump through, and find themselves confronted by a large blockade force.  Again, this could be the fortune of war.

Now, however, comes the buggy part.  Before my ships can open fire at pointblank range, they jump BACK through the jump point, and my ships follow them through.

At this point I assumed they would try to run for it. . .

In reality, they continue to jump back and forth, with none of my ships, even on 5-second increments, ever able to actually fire on them, on either side of the jump point.  I finally was forced to split my forces to sit on both sides of the jump point, in the hopes of engaging them.  But they still jumped back and forth without me being able to get a shot off on either side of the gate with the waiting ships.  This continued until I gave up and allowed them to leave after 18 cycles of jumping. 

This. . .  really isn't good for the game, as it makes it possible for any force, no matter how weak, to avoid engagement indefinitely.  I thought there was some sort of jump cooldown which would prevent ships from making another jump instantly, as well as not using sensors? My guess is, since this was a stable jump point, that no jump engines were being used, and thus there was no cooldown.   I think there needs to be some sort of basic jump cooldown before another jump is possible, ideally a cooldown which is longer than the jump shock, allowing a chance for ships with superior speed to actually engage their enemies, since they cannot escape. 

I know that NPR's don't have the same downsides for jumping as the player, due to weaker decision making, but I cannot think it is intended to be used in this way.  In each case here, the ships were jumping back through the point within 5 seconds, with seemingly no end in sight.

It seems like the issue is because jumping happens before weapons fire in the turn processing order.  If that's the case, a "simple fix" (disclaimer: I have no idea what this might break in the code by some arcane interaction) would be to move jumping down the turn processing so that ships get a chance to fire on a fleet before it jumps.  That way, we avoid an arbitrary cooldown mechanic and preserve the 5-second jump turnaround if the AI needs it for other reasons.

Either way of course you probably want to tell the AI not to use rapid jumping to escape if it "knows" that the other side of the jump point is also dangerous, but with this mechanics change that becomes a case of telling the AI not to make a suicidal decision, rather than instructing it to avoid a cheesy exploit.
Title: Re: v1.12.0 Bugs Thread
Post by: Froggiest1982 on November 03, 2020, 02:49:29 PM
AI ships seem to have a very strange reaction to superior forces in the latest 1.12 version.

When confronted by superior attackers, the ships head immediately for the nearest Jump Point, even if that jump point leads directly into the 'enemy' home system. This could, in theory, be good tactics, but they jump through, and find themselves confronted by a large blockade force. Again, this could be the fortune of war.

Now, however, comes the buggy part. Before my ships can open fire at pointblank range, they jump BACK through the jump point, and my ships follow them through.

At this point I assumed they would try to run for it...

In reality, they continue to jump back and forth, with none of my ships, even on 5-second increments, ever able to actually fire on them, on either side of the jump point. I finally was forced to split my forces to sit on both sides of the jump point, in the hopes of engaging them. But they still jumped back and forth without me being able to get a shot off on either side of the gate with the waiting ships. This continued until I gave up and allowed them to leave after 18 cycles of jumping.

This... really isn't good for the game, as it makes it possible for any force, no matter how weak, to avoid engagement indefinitely. I thought there was some sort of jump cooldown which would prevent ships from making another jump instantly, as well as not using sensors? My guess is, since this was a stable jump point, that no jump engines were being used, and thus there was no cooldown.  I think there needs to be some sort of basic jump cooldown before another jump is possible, ideally a cooldown which is longer than the jump shock, allowing a chance for ships with superior speed to actually engage their enemies, since they cannot escape.

I know that NPR's don't have the same downsides for jumping as the player, due to weaker decision making, but I cannot think it is intended to be used in this way. In each case here, the ships were jumping back through the point within 5 seconds, with seemingly no end in sight.

 - I'm strongly against a cooldown mechanic, but rather think Jumping should just be either a flat 10 seconds or 15 seconds. The logic for the two increment being that it takes an increment to "jump out" and an increment to "jump in". The logic for the three increment would be either two increments to "plot" the jump and one increment to do the jump itself, or one increment to "plot" the jump, and two increments to complete it.

 - I'm in favor of the three increment system with one increment used for plotting the jump, which can then have the three increment reduced to two with the inclusion of a "Navigation" bridge module. Maybe even have Officers with some sort of Jump bonuses. We could also have it so that the players and NPRs get priority to fire on jumping targets. I'm tempted to dismiss this as "just good use of tactics" since it's technically consistent with Aurora's internal laws, but while the argument for that could be made... the fact remains that it just isn't fun and really only serves to delay the inevitable.

I think that cooldown is the most realistic way to handle jump shock. All sci-fi fictions and games rely on jump shock theory as you cannot just jump from system to system.

I think jump shock should be more related to the actual capability of the engines to cool down and recharge.

The mechanic could be related to a specific tech Jump cooldown in seconds and you could start from 60 down to a minimum of 5 or 10 sec.

Being a tech, it will also level the game with NPRs which will be allowed to jump only according to their tech.

I recognize the above could be hard to implement but the current mechanic it's too unpredictable at the point which is totally unrealistic and unbalanced.
Title: Re: v1.12.0 Bugs Thread
Post by: Ostar on November 04, 2020, 02:14:02 PM
Minor issue with using Rank Theme Barsoom (E.   R.   B.    was a childhood favorite).   
In the Events Window, the ranks are referred to as R5, R7, etc, instead of the actual rank name shown in the Commander Window.   This seems to be only for the Commander Experience Event, Promotion Event shows Rank name.   
Ranks display fine in the Commander Window when examining the individual.   
Using 1.   12.   0, normal start, no mods.   
It's possible other rarely used Rank Themes have the same issue, but I haven't checked.   

Addendum:  The same R5/R6/etc shows up here and there throughout other windows when the Name Rank should show.

SJW: The experience event (and some other areas) uses the abbreviation for the rank name instead of the full rank. When no abbreviation exists for a rank, Aurora uses R1, R2, etc.. You can set the abbreviation by renaming each rank. Keep the name and enter your preferred abbreviation.
Title: Re: v1.12.0 Bugs Thread
Post by: TheTalkingMeowth on November 04, 2020, 07:57:49 PM
Tried to post this with DB and the forum ate it.

Anyway, the move to system requiring geosurvey standing order can get stuck in an infinite loop of bouncing back and forth across a jump point. I cought one of my survey ships doing this and when I checked the history it had been doing so for several years.
Title: Re: v1.12.0 Bugs Thread
Post by: db48x on November 04, 2020, 09:52:14 PM
Tried to post this with DB and the forum ate it.

Anyway, the move to system requiring geosurvey standing order can get stuck in an infinite loop of bouncing back and forth across a jump point. I cought one of my survey ships doing this and when I checked the history it had been doing so for several years.

Did you have that selected as the primary or the secondary standing order? The standing orders system is stateless; it doesn't take into account which orders have recently been executed. The primary order is considered any time the ship has no orders in its queue, and the secondary order is only considered if the primary order cannot be executed.

Thus, you should set the primary order to survey the next 5 system bodies (or one of the similar orders), and the set  the secondary order to move to a system requiring geosurvey. That way the ship will only change systems if there are no bodies in the current system that need surveying.
Title: Re: v1.12.0 Bugs Thread
Post by: TheTalkingMeowth on November 05, 2020, 09:07:45 AM
Yeah, survey next 3 system bodies or locations primary, move to system secondary.

As far as I could tell, the move to system requiring gravsurvey order didn't do this. I'm also pretty sure the systems being bounced between were BOTH fully geosurveyed (one possible explanation would be moving between two systems with unsurveyed distant bodies, so it goes to the system, then can't find anything within 10 billion klicks, so the move to system order fires again and we loop. That is NOT what happened).
Title: Re: v1.12.0 Bugs Thread
Post by: Ektor on November 06, 2020, 04:44:46 PM
I'm not sure whether this is an actual "bug," but I had a fleet with four ships: A frigate, a commercial jump tender, a military jump tender, and a tanker for fuel. All but the frigate had commercial engines. When the fleet is together, it can't jump because the military ship keeps trying to use the commercial jump drive. In fact, the only way I could get it to detach the military ship, jump the commercial ships, then detach and send the commercial ship away, and only then the military ship managed to jump. There's nothing wrong with the JDs as evidenced by the fact that I jumped three systems with them, but it's very awkward.

Edit: This was what finally worked, I actually tried a bunch of stuff, I just want to make clear that this is not an issue of trying to jump a commercial ship with a military JD, because even when I had all four ships in different fleets, the military ship only jumped once the commercial jump tender was physically removed from the jump point.

I'm really trying to upload my DB but it's not working. Every time I try to upload it sends my browser into the "start new topic" window.

I tried uploading it to google drive. Not sure whether it works or not.

https://drive.google.com/file/d/1X-iqQN7nOo8CKhf-61MFGLIo3NKUnKCQ/view?usp=sharing
Title: Re: v1.12.0 Bugs Thread
Post by: TheTalkingMeowth on November 06, 2020, 06:05:35 PM
I'm really trying to upload my DB but it's not working. Every time I try to upload it sends my browser into the "start new topic" window.
If the file is too big it just eats the post and fails silently. I had this happen several times before I realized my database was 37MB (because of all the ship history entries caused by the cycling standing order issue).
Title: Re: v1.12.0 Bugs Thread
Post by: nuclearslurpee on November 07, 2020, 07:28:35 PM
Bug:
In the Ground Forces window, Unit Series tab, the "Delete Series" button does not delete the series. It will remove units from the series but the series itself remains in the list. I assume this is not the intended behavior since the button is not labeled "Clear Series" and because frankly it makes sense to delete a series rather than leaving an empty one cluttering up the list.

Info:
No error messages
Encountered while starting new game with techs and some ships already added using starting RP/BP
TN start
Real stars
Decimal separator is a period
Reproducible immediately in a new game start

SJW: Fixed
Title: Re: v1.12.0 Bugs Thread
Post by: nuclearslurpee on November 07, 2020, 07:42:24 PM
v1.12.0
Conventional start with 3 NPRs, all spoilers except invaders on

Ground Forces Screen, Unit Series Tab
Conventional star
I suddenly cannot create new unit series. It WAS working when I first tried to use it (before any civilian mining complexes or alien encounters); I added a bunch of unit series right at the start of the game.

When I went back to add some new vehicle types, I now get a Function #3353: an item with the same key has already been added error when I hit OK in the name popup.

This happens for all names, even "Foo," "Bar," and "Totally not a real unit." So I doubt there is such a series already from some other race.

The issue persists after a save and reload.

I can also confirm this same bug as well as the DB workaround proposed elsewhere in the thread.
Title: Re: v1.12.0 Bugs Thread
Post by: Black on November 08, 2020, 07:55:12 AM
version 1.12.0, decimal separator is dot.

I encountered issue with ground force formations. In Ground Force tab. Complete Organization Unit List shows wrong numbers of unit for formation.

I have infantry regiment (1st Devil's Fusiliers) with 3 infantry battalions, each having 600 Riflemen. But when I select regimental formation, it shows total number of Riflemen as 2400, same issue with other elements. It shows numbers as if there are 4 battalions attached to regimental formation.

I have another identical regiment (2nd Devil's Fusiliers) that shows correct numbers in Complete Organization Unit List. Both formation have same size. Formation and Direct Attachments part shoes correct number of Units for both regiments, so it seems that the issue is only in Complete Organization Unit List.

Formations are on Earth and part of 1st Infantry Division. DB is too big for attachment so bellow is link to it, if anyone wants to check.

http://www.mediafire.com/file/twooxoisgymy8tz/AuroraDB.db/file
Title: Re: v1.12.0 Bugs Thread
Post by: Jeltz on November 08, 2020, 08:58:01 AM
A minor issue, I hope:

Version 1.12.0, decimal separator dot, conventional start.

- from main form open Economic, then the GU Training tab (I have only one training facility)
- Well, I can select the first empty row!
- now if I click the Create Task button the first error message occur:

"1.12.0 Function #2187: Object reference not set to an instance of an object"

followed by a similar second:

"1.12.0 Function #569: Object reference not set to an instance of an object"

the game continues 


The error occur after 10 year, but I think that is a problem in the embedded table in GU Tarining tab that has an empty row at game start: in fact I have start a new test game, and the problem occur at turn 0.

J.


Title: Re: v1.12.0 Bugs Thread
Post by: Bremen on November 08, 2020, 11:17:16 AM
1.12, decimal separator is dot, as I had a scout discover a new system I was spammed with dozens of "Object reference not set to an instance of an object" errors, all with different functions (or at least I noticed the number changing). Given the context and previous problems, I believe it was probably related to discovering a system with an NPR on one of the planets and the game trying to generate everything necessary. The game continued, but I haven't yet played on enough to see if the errors cause any permanent issues.

It was not my first system explored, so at least somewhat intermittent.

Edit: Indeed, exploring the system revealed an alien race, except they had absolutely nothing in orbit and a very small thermal signature (30,709 EM and 3,103 thermal). This leads me to believe something went wrong in the code to generate them and left them crippled. IIRC my first game in C# had the same thing happen, making me wonder if it may be something local to my machine that doesn't work with the code - I've never had a spontaneously generated NPR start with stuff (that does not apply for ones generated at game start), yet it always happening for me doesn't seem to mesh with other players apparently not having problems.

SJW: I think there is a rare bug that causes what you describe above but I have never been able to pin it down. I hope it will eventually happen in one of my own games so I can see what is happening.
Title: Re: v1.12.0 Bugs Thread
Post by: Kristover on November 08, 2020, 12:15:54 PM
Interesting bug that might be somewhat related to the report immediately above this one.  I captured two enemy troop transports in my home world system and brought them back to my capital.  I was in the middle of a pretty hot war and all of my shipyards were pumping out warships and support vessels so I didn't have any space left for scrapping.  They were inferior in design to my troop ships and doctrine so I deleted them and two things happened:

1.  On the next turn, a new NPR was formed on my home world named 'civilian'.  It didn't have any population, EM/TH signature, or ships and started with +10,000 relations.

2.  The next turn, I started getting 1.12.0 Function #11: Object reference not set to an instance of an object" errors on every turn.  Everything else appeared to be in order but just another error popup every turn - couldn't utilize continuous time because of the interrupts.

I don't know if the deleting the troopships was the cause but that was the only I took prior to the error messages.  I went back to an earlier DB (about 4 months earlier) and ended up encountering the same troopships and this time I destroyed them rather than capturing them and everything proceeded as normal.
Title: Re: v1.12.0 Bugs Thread
Post by: xenoscepter on November 08, 2020, 12:56:46 PM
As per the "Bug Reporting Guidelines"
Quote
- The function number
 --- N/A

 - The complete error text
 --- N/A

 - The window affected
 --- Component Design Window, AKA Create Research Project; specifically the Beam Fire Control bit.

 - What you were doing at the time?
 --- Just playing as per the usual.

 - Conventional or TN start
 --- TN Start

 - Random or Real Stars
 --- Random

 - Is your decimal separator a comma?
 --- Decimal

 - Is the bug is easy to reproduce, intermittent or a one-off?
 --- Both very easy and quite simple to reproduce.

 - If this is a long campaign - say 75 years or longer - let me know the length of the campaign as well
 --- 76 Years in as of this typing.

The Bug in question occurs when you attempt to create a Beam FCS with a 1.25x Range, more specifically the game instead makes the Beam FCS in question to have a 0.25x Range. Easy enough to do.

SJW: Fixed
Title: Re: v1.12.0 Bugs Thread
Post by: Ogamaga on November 09, 2020, 01:00:52 PM
Function number
     N/A
Error text
     N/A
window affected
     Economics most directly
Circumstances
     Normal play, and a dedicated test
Conventional or TN start
     TN in both cases
Random or Real Stars
     Random in normal play, real in test
Decimal separator
     Period
Easy to reproduce
     Yes
Long campaign
     No, under 10 years for normal, under 1 month for test

Sector governors have no impact on population growth. The dedicated test process was;
create a fresh install
create fresh game (I gave humanity a 5x growth multiplier to make differences more obvious and construction cycle to 431999 for easy time consistency)
note names of 2 admins of sufficient rank
hit save
close
set pop growth bonus for said admins to 50% in database with no other changes made (same reason as 5x growth)
SM Add 1 sector command
assign one admin to Earth Governor position
save
advance time 5 days (432000 seconds)
note new pop total for earth
close without saving
assign other admin as sector governor to Sol Sector
ensure Sol Sector includes Sol
advance time 5 days
note new pop total for earth.

Noted totals were the same, 501.29 million.

Database used for test available if needed or wanted

SJW: Fixed. The sector was applying a bonus to growth. However, it was the terraforming bonus :)
Title: Re: v1.12.0 Bugs Thread
Post by: ExChairman on November 10, 2020, 01:31:57 AM
Not entirely sure its a bug but when advancing time by 20 minutes my ship dont fire defensive at enemy missiles, eccept CIWS, but all the Gauss turrets, railguns and lasers are silent...



Not a bug. The missiles cross the entire firing envelope during the increment. You should use smaller increments when combat is imminent. -Garfunkel
Title: Re: v1.12.0 Bugs Thread
Post by: Ogamaga on November 10, 2020, 05:11:34 PM
further testing, this time without touching the DB. 10x pop growth for humanity, growth time 5 days, starting pop 500m
no admins results in 501.73m
planetary governor bonus 25 results in 502.16m
sector governor bonus 20 results in 501.73m
both together result in 502.16m
DB available on request, just specify which one or both
Title: Re: v1.12.0 Bugs Thread
Post by: jtgasv on November 10, 2020, 05:42:55 PM
affects the galactic map, with sectors check box enabled
occurs on both tn and conventional start, real and random systems.
Decimal separator - Period
400+ year campaign but reproduceable in fresh game with sm mode

sm mode
give improved command and control
build a sector command

on the galactic map...
assign sol to the sol sector.
switch sol back to "no sector"

the red ring around sol turns black instead of dissapearing
when clicking on sol system the drop down menu still lists it as being in the sol sector even though sector management still lists it.

SJW: Fixed. Sol was being assigned to a 'zero sector' instead of no sector.
Title: Re: v1.12.0 Bugs Thread
Post by: Froggiest1982 on November 11, 2020, 07:55:43 PM
When changing Jump Squadron size on Jump Drive Design Tech, if a Self-Jump is selected it's still changing the tonnage of the design.

The above behavior makes no sense as being a Sel-Jump Engine it shouldn't matter.

SJW: Fixed
Title: Re: v1.12.0 Bugs Thread
Post by: db48x on November 11, 2020, 07:57:56 PM
the red ring around sol turns black instead of dissapearing
when clicking on sol system the drop down menu still lists it as being in the sol sector even though sector management still lists it.

I've seen those black rings but I couldn't figure out how I caused them!
Title: Re: v1.12.0 Bugs Thread
Post by: SerBeardian on November 13, 2020, 04:51:21 PM
1.12.0
No mods


Scrapping a ship that is being tugged does not break the tug link.
It's possible to release tractored ships to break the link (which creates an empty fleet for the scrapped ship), however scrapping should break the link on it's own.

Confirmed. -Garfunkel

SJW: Fixed
Title: Re: v1.12.0 Bugs Thread
Post by: TheTalkingMeowth on November 16, 2020, 10:10:54 PM
Orbital Bombardment Accuracy does not behave as described in the changes thread.

Orbital weapon accuracy is supposed to be target fortification times a to-hit modifier based on the planetary terrain. Thus, a forested mountain planet should see a too hit chance of, at worst, 100/6 (max fortification)/2.5 (planetary fortification mod)/4 (planetary accuracy mod)=1.667%.

And the worst possible scenario, a jungle mountain world, has a to hit chance of no worse than 0.694%.

However, the event log reports anywhere from 0.1% to 0.3% chance to hit when firing on ground contacts on this forested mountain body. I can't post the DB (too big because of all the ground combat events), but I am looking at the event log right now.

The planet has significant radiation and dust, if that is relevant.

SJW: The base chance to hit isn't 100%. As per the link below "Orbital bombardment ships have the same chance to hit as ground units".
http://aurora2.pentarch.org/index.php?topic=8495.msg110310;topicseen#msg110310
Title: Re: v1.12.0 Bugs Thread
Post by: unkfester on November 18, 2020, 07:13:28 AM
Designing rail guns
When I design rail guns there does not seem to be any differents between standard mounts, or spinal mounts, on drop down window in design thing. plus when I research said items, the research points are identical.

SJW: Having the spinal option visible was an error. Fixed now.
Title: Re: v1.12.0 Bugs Thread
Post by: Droll on November 18, 2020, 07:14:35 AM
Designing rail guns
When I design rail guns there does not seem to be any differents between standard mounts, or spinal mounts, on drop down window in design thing. plus when I research said items, the research points are identical.

This is a UI mistake, you aren't supposed to be able to make spinal railguns yet but IIRC Steve was doing some testing and forgot to remove the option.
Title: Re: v1.12.0 Bugs Thread
Post by: unkfester on November 18, 2020, 07:15:40 AM
Okay thanks
Title: Re: v1.12.0 Bugs Thread
Post by: db48x on November 18, 2020, 09:10:11 AM
The function number: n/a
The complete error text: n/a
The window affected: class design
What you were doing at the time: trying to design an FAC
Conventional or TN start: conventional, but I have TN tech
Random or Real Stars: real stars
Is your decimal separator a comma?: no
Is the bug is easy to reproduce, intermittent or a one-off?: easy
If this is a long campaign - say 75 years or longer - let me know the length of the campaign as well: ~70 years, but I doubt that it matters

If you attempt to remove the bridge from a ship that is large enough to require a bridge, it is added back immediately. The bug is that the total mass of the ship is reduced by a few tons, likely because it doesn't recalculate the ship's armor after adding it back. However, I haven't seen the armor size change. Perhaps the change is smaller than the level of precision shown.

I'll give a concrete answer. I have an ordinary standard freighter with a size of 767.6398, 25.3 Duranium armor, and a mass of 38,382t. After I try to remove the bridge the size is 767.4353, with 25.3 armor and a mass of 38,372t. You can see that the mass went down by 10t, and the size by 0.2045.
Title: Re: v1.12.0 Bugs Thread
Post by: db48x on November 19, 2020, 10:23:44 AM
This is a pretty minor issue, but the discovery date for Sol is being displayed with a different date format than the discovery date of the other systems on the galaxy map. It doesn't change format if I change any of the display options, or if I select a different system. On the other hand, I cannot reproduce in new game.

(http://db48x.net/Aurora/rediscovery:%20conventional%20start%20in%203000%20with%20v1.12/seriously%3f.png)

The function number: n/a
The complete error text: n/a
The window affected: galaxy map
What you were doing at the time: looking at the galaxy map
Conventional or TN start: conventional, but I have TN tech
Random or Real Stars: real stars
Is your decimal separator a comma?: no
Is the bug is easy to reproduce, intermittent or a one-off?: unknown
If this is a long campaign - say 75 years or longer - let me know the length of the campaign as well: ~70 years, but I doubt that it matters
Title: Re: v1.12.0 Bugs Thread
Post by: Froggiest1982 on November 19, 2020, 02:52:37 PM
This is a pretty minor issue, but the discovery date for Sol is being displayed with a different date format than the discovery date of the other systems on the galaxy map. It doesn't change format if I change any of the display options, or if I select a different system. On the other hand, I cannot reproduce in new game.

(http://db48x.net/Aurora/rediscovery:%20conventional%20start%20in%203000%20with%20v1.12/seriously%3f.png)

The function number: n/a
The complete error text: n/a
The window affected: galaxy map
What you were doing at the time: looking at the galaxy map
Conventional or TN start: conventional, but I have TN tech
Random or Real Stars: real stars
Is your decimal separator a comma?: no
Is the bug is easy to reproduce, intermittent or a one-off?: unknown
If this is a long campaign - say 75 years or longer - let me know the length of the campaign as well: ~70 years, but I doubt that it matters

I can confirm this one. My game have the same issue.
Title: Re: v1.12.0 Bugs Thread
Post by: chokuto on November 19, 2020, 04:16:34 PM
This is a pretty minor issue, but the discovery date for Sol is being displayed with a different date format than the discovery date of the other systems on the galaxy map. It doesn't change format if I change any of the display options, or if I select a different system. On the other hand, I cannot reproduce in new game.

(http://db48x.net/Aurora/rediscovery:%20conventional%20start%20in%203000%20with%20v1.12/seriously%3f.png)

The function number: n/a
The complete error text: n/a
The window affected: galaxy map
What you were doing at the time: looking at the galaxy map
Conventional or TN start: conventional, but I have TN tech
Random or Real Stars: real stars
Is your decimal separator a comma?: no
Is the bug is easy to reproduce, intermittent or a one-off?: unknown
If this is a long campaign - say 75 years or longer - let me know the length of the campaign as well: ~70 years, but I doubt that it matters

I can confirm this one. My game have the same issue.

I had that too on my first game. I'm guessing it happens if you change date format. I'm pretty sure I changed my date format from including the weekday before I discovered any systems.
Title: Re: v1.12.0 Bugs Thread
Post by: db48x on November 19, 2020, 04:50:43 PM
I had that too on my first game. I'm guessing it happens if you change date format. I'm pretty sure I changed my date format from including the weekday before I discovered any systems.

That's certainly a possibility, but in my case the date format was changed long before I began this game.
Title: Re: v1.12.0 Bugs Thread
Post by: Froggiest1982 on November 19, 2020, 11:48:10 PM
I had that too on my first game. I'm guessing it happens if you change date format. I'm pretty sure I changed my date format from including the weekday before I discovered any systems.

That's certainly a possibility, but in my case the date format was changed long before I began this game.

Same here.
Title: Re: v1.12.0 Bugs Thread
Post by: Tyrannus Rex on November 21, 2020, 03:27:34 AM
Function number
     N/A
Error text
     N/A
window affected
     Economics most directly
Circumstances
     Normal play, pressed the wrong button and acknowledged without reading. With 1% death spiral selected
Conventional or TN start
    Conventional
Random or Real Stars
     Random
Decimal separator
     Period
Easy to reproduce
    Unknown
Long campaign
    35 years+

Accidentally pressed the Set Capital button(was distracted as was assisting kids with school). When I realized what was done I selected Mars as the new capital, then proceeded to select Earth as capital once again. Currently Mars no longer has an unrest/protection required/actual number. Earth is currently the capital and has no required protection as it normally does. All other major colonies have required/actual number.
Have swapped back between the two and allowed time to move in one, five and thirty day increments. It currently appears that I have two capitals, with no errors. Making a backup and will see if anything changes when Earth explodes if it still remains as the capital. 
Title: Re: v1.12.0 Bugs Thread
Post by: Red Dusk on November 21, 2020, 06:06:54 PM
What you were doing at the time - Building vessels with pre-fabbed components
Conventional or TN start - Conventional, with 20k starting RP used to unlock TN tech and a handful of other technologies.
Random or Real Stars - Random
Is the bug is easy to reproduce, intermittent or a one-off? - Should be relatively easy to reproduce.
If this is a long campaign - say 75 years or longer - let me know the length of the campaign as well - Done with a brand-new start that hadn't incremented yet.
Construction Cycle is 86000s

I've discovered that if you construct a vessel with pre-fabricated components, the setting appears to cause a sort of phantom effect in certain circumstances that allows you to build vessels with significantly reduced mineral costs (including entirely omitting them for some minerals)

The test I performed was to design an engine, any engine (In this instance I used Nuclear Thermal engine tech, 100% power). I then designed a ship that used that engine, slapping 20 engines on. Removing any other items that consumed gallicite, I then had a cost of exactly 2000 gallicite. Earth already had 2000 gallicite on it, so I quickly SM'd away all conventional factories, added 1000 construction factories and edited the pop to be 5b so I had people to man the facilities. Adding a new naval shipyard and quickly modifying it to be 50kt (about 7k more than I needed, but quicker to type for me), I assigned the ship class to it, then went to industry and built the components over the course of a few 30 day increments. Quickly checking and confirming that I had 0 gallicite on Earth, I then queued the shipyard to build a ship of that class using components. A few 30d increments later it was finished, no issues.
Here's where it gets funny.
I then re-opened the shipyards page, and noticed that the gallicite cost for the ship class was now just...missing. It no longer listed the cost as being there at all, and to test if it was just a visual glitch I queued up another ship to be built without ticking the Use Components box. A few 30d increments later and the ship, while taking much longer than before, was built. And I had no issues with gallicite usage, even though I very clearly had 0 in my stockpile, and I had also double checked to make sure I didn't have stockpiled engines for some reason. I conducted a further test, adding 2000 more gallicite to Earth via SM and closing/reopening the shipyard window. It now correctly displayed the gallicite need, and when I built this ship, while taking the same time as the previous "free" one, it did use the gallicite and what's more, gave an message in the event log upon completion that there were not enough minerals. Trying to build a new ship then gave the correct behavior, throwing the same message into the event log about missing the required minerals.

tl:dr is that it seems to be possible to trigger the game into thinking there are components available when there aren't, and this removes the mineral usage of a ship class

SJW: Fixed
Title: Re: v1.12.0 Bugs Thread
Post by: TheTalkingMeowth on November 21, 2020, 08:33:20 PM
Conventional Start, Real Stars, 30 years in, decimal native

Disassembling components on a planet when for a technology that you have partially researched via labs doesn't work right. Instead of adding to your progress, research from disassembly accumulates on its own. If the total exceeds the progress from actual research, then the total progress switches. The bug seems to particularly affect auxiliary control, but I am leery of further testing since this bug occurred in 1.11 and ended up breaking the save (all alien races got deleted).

DB way too big to post because of ground combat events.

EDIT: Opened the database and figured out what is happening. There are TWO projects associated with Auxiliary control in my save file.
1 project has the RP from doing research like normal. The other has the RP from disassembly. One appears in FCT_ResearchProject, the other appears in FCT_PausedResearch. If I cancel the active project, they effectively swap places.

Deleting the extra project seems to fix the issue, BUT the first time I open the economics window for the race the extra project belonged to, I get a function #2169, key not in dictionary error.

SJW: The problem is caused by command and control components. Should be fixed for v1.13.
Title: Re: v1.12.0 Bugs Thread
Post by: Lord Solar on November 21, 2020, 08:37:24 PM
What you were doing at the time - Building vessels with pre-fabbed components
Conventional or TN start - Conventional, with 20k starting RP used to unlock TN tech and a handful of other technologies.
Random or Real Stars - Random
Is the bug is easy to reproduce, intermittent or a one-off? - Should be relatively easy to reproduce.
If this is a long campaign - say 75 years or longer - let me know the length of the campaign as well - Done with a brand-new start that hadn't incremented yet.
Construction Cycle is 86000s

I've discovered that if you construct a vessel with pre-fabricated components, the setting appears to cause a sort of phantom effect in certain circumstances that allows you to build vessels with significantly reduced mineral costs (including entirely omitting them for some minerals)

The test I performed was to design an engine, any engine (In this instance I used Nuclear Thermal engine tech, 100% power). I then designed a ship that used that engine, slapping 20 engines on. Removing any other items that consumed gallicite, I then had a cost of exactly 2000 gallicite. Earth already had 2000 gallicite on it, so I quickly SM'd away all conventional factories, added 1000 construction factories and edited the pop to be 5b so I had people to man the facilities. Adding a new naval shipyard and quickly modifying it to be 50kt (about 7k more than I needed, but quicker to type for me), I assigned the ship class to it, then went to industry and built the components over the course of a few 30 day increments. Quickly checking and confirming that I had 0 gallicite on Earth, I then queued the shipyard to build a ship of that class using components. A few 30d increments later it was finished, no issues.
Here's where it gets funny.
I then re-opened the shipyards page, and noticed that the gallicite cost for the ship class was now just...missing. It no longer listed the cost as being there at all, and to test if it was just a visual glitch I queued up another ship to be built without ticking the Use Components box. A few 30d increments later and the ship, while taking much longer than before, was built. And I had no issues with gallicite usage, even though I very clearly had 0 in my stockpile, and I had also double checked to make sure I didn't have stockpiled engines for some reason. I conducted a further test, adding 2000 more gallicite to Earth via SM and closing/reopening the shipyard window. It now correctly displayed the gallicite need, and when I built this ship, while taking the same time as the previous "free" one, it did use the gallicite and what's more, gave an message in the event log upon completion that there were not enough minerals. Trying to build a new ship then gave the correct behavior, throwing the same message into the event log about missing the required minerals.

tl:dr is that it seems to be possible to trigger the game into thinking there are components available when there aren't, and this removes the mineral usage of a ship class

I confirmed this result and have an addition; this work to reduce mineral costs even if the ship uses the same mineral in other components; in my test I got the game to give me "free" plasma carronades but still had to pay for other components that costed Duranium. Building the class at another shipyard lists the reduced cost, but it consumes the expected amount of minerals and removes other shipyards for paying reduced cost.
Title: Re: v1.12.0 Bugs Thread
Post by: db48x on November 22, 2020, 12:29:28 AM
The function number
    3239
The complete error text
    1.12.0 Function #3239: Object reference not set to an instance of an object.
The window affected
    n/a
What you were doing at the time
    saving the game
Conventional or TN start
    conventional
Random or Real Stars
    real stars
Is your decimal separator a comma?
    no
Is the bug is easy to reproduce, intermittent or a one-off?
    intermittent, but once it happens it won't go away
If this is a long campaign - say 75 years or longer - let me know the length of the campaign as well
    ~79 years

I saved my game this afternoon and got this message. I kept playing, but eventually I started getting interrupts every two hours. This game has had a lot of interrupts from NPR activity, so I let it run for a while. When I came back and found that it still hadn't been resolved, I peeked into the database. These are the 100 most recent messages in the game log:

Code: [Select]
66731|38|217|0|2500994915.0|83|FT Bosmans Small F3 004 was unable to load Ground Force Construction Complex from Blücher-A I|3078|-7027655.47182478|18904480.5779801|10|0
66731|38|217|0|2500994915.0|83|FT Bosmans Small F3 010 was unable to load Ground Force Construction Complex from Blücher-A I|3078|-7027655.47182478|18904480.5779801|10|0
66731|38|217|0|2500994915.0|83|FT Bosmans Small F3 016 was unable to load Ground Force Construction Complex from Blücher-A I|3078|-7027655.47182478|18904480.5779801|10|0
66731|38|218|0|2500994915.0|83|FT Nasser Small F3 010 was unable to load Mine from Ehecatotontli-A II|3132|-24155266.66499|14274525.0701791|10|0
66731|38|219|0|2500994915.0|83|FT de Klerk Small F3 007 was unable to load Mine from Hamadan-B III - Moon 10|3182|2349028888.18414|433089884.305349|10|0
66731|38|219|0|2500994915.0|83|FT de Klerk Small F3 019 was unable to load Mine from Hamadan-B III - Moon 10|3182|2349028888.18414|433089884.305349|10|0
66731|38|217|0|2500994915.0|83|FT Bosmans Large F3 020 was unable to load Ground Force Construction Complex from Blücher-A I|3078|-7027655.47182478|18904480.5779801|10|0
66731|38|217|0|2500994915.0|83|FT Timmermans Small F3 005 was unable to load Ground Force Construction Complex from Blücher-A I|3078|-7027655.47182478|18904480.5779801|10|0
66731|38|217|0|2500994915.0|83|FT Goethals Small F3 005 was unable to load Ground Force Construction Complex from Blücher-A I|3078|-7027655.47182478|18904480.5779801|10|0
66731|38|217|0|2500994915.0|83|FT Goethals Small F4 007 was unable to load Ground Force Construction Complex from Blücher-A I|3078|-7027655.47182478|18904480.5779801|10|0
66731|38|217|0|2500994915.0|83|FT Verhaeghe Small F4 006 was unable to load Ground Force Construction Complex from Blücher-A I|3078|-7027655.47182478|18904480.5779801|10|0
66731|38|218|0|2500994915.0|83|FT Nasser Large F3 023 was unable to load Mine from Ehecatotontli-A II|3132|-24155266.66499|14274525.0701791|10|0
66731|38|218|0|2500994915.0|83|FT Essa Small F3 003 was unable to load Mine from Ehecatotontli-A II|3132|-24155266.66499|14274525.0701791|10|0
66731|38|217|0|2500994915.0|83|FT Timmermans Small F4 007 was unable to load Ground Force Construction Complex from Blücher-A I|3078|-7027655.47182478|18904480.5779801|10|0
66731|38|223|0|2500994915.0|45|Salvage Squadron - Beam Escort 001 cannot salvage the target wreck as no ships within the fleet have salvage capability|3158|163854029.259284|571728110.333741|10|0
66731|38|223|0|2500994915.0|83|FT Stanojkovi? Small F7 005 was unable to load Automated Mine from Le Blanc Prime|3158|114903086.163866|121872511.393931|10|0
66731|38|227|0|2500994915.0|45|Salvage Squadron - Beam Escort 002 cannot salvage the target wreck as no ships within the fleet have salvage capability|3170|-3564738232.24972|1975966668.19576|10|0
66731|38|227|0|2500994915.0|83|FT Hanson Small F8 043 was unable to load Deep Space Tracking Station from Airone-A III - Moon 4|3215|182460736.165574|195528871.667756|10|0
66731|38|228|0|2500994915.0|83|FT Chatapara Small F8 001 was unable to load Automated Mine from Masterson Prime|3249|-13322068.2631936|45906218.014858|10|0
66731|38|228|0|2500994915.0|83|FT Chatapara Small F8 016 was unable to load Automated Mine from Masterson Prime|3249|-13322068.2631936|45906218.014858|10|0
66731|38|228|0|2500994915.0|83|FT Chatapara Small F8 031 was unable to load Automated Mine from Masterson Prime|3249|-13322068.2631936|45906218.014858|10|0
66731|38|228|0|2500994915.0|83|FT Chatapara Small F8 049 was unable to load Automated Mine from Masterson Prime|3249|-13322068.2631936|45906218.014858|10|0
66731|38|227|0|2500994915.0|83|FT Hanson Large F8 098 was unable to load Automated Mine from Alabarda-A II|3170|32233834.7214426|16275783.7686958|10|0
66731|38|226|0|2500994915.0|45|Salvage Squadron 001 cannot salvage the target wreck as no ships within the fleet have salvage capability|3192|540753133.678104|-2781933705.51223|10|0
66731|38|219|0|2500994915.0|42|SS Akkrum 003 is unable to carry out its primary standing order: Refuel from Colony or Hub (All)|3274|-3485685011.58667|-2012461179.74981|10|0
66731|38|228|0|2500994915.0|42|DDG Angels Numinous 020 is unable to carry out its primary standing order: Join Operational Group|3249|-13322068.2631936|45906218.014858|10|0
66731|38|217|0|2500994915.0|42|JD Aranda II 001 is unable to carry out its primary standing order: Join Operational Group|2997|595198394.472728|-36195057.6874419|10|0
66731|38|217|0|2500994915.0|42|JD Aranda II 002 is unable to carry out its primary standing order: Join Operational Group|2997|595198394.472728|-36195057.6874419|10|0
66731|38|217|0|2500994915.0|42|JD Aranda II 003 is unable to carry out its primary standing order: Join Operational Group|2997|595198394.472728|-36195057.6874419|10|0
66731|38|217|0|2500994915.0|42|JD Aranda II 004 is unable to carry out its primary standing order: Join Operational Group|3079|775805332.059489|484776975.051813|10|0
66731|38|223|0|2500994915.0|42|Stabilisation Squadron - Beam Escort 006 is unable to carry out its primary standing order: Build Jump Gate at Nearest Jump Point|3226|-1377537464.58247|315447077.054361|10|0
66731|38|223|0|2500994915.0|42|JD Kiputytto 008 is unable to carry out its primary standing order: Join Operational Group|3166|5130498672.00933|721040210.148912|10|0
66731|38|226|0|2500994915.0|42|Stabilisation Squadron 003 is unable to carry out its primary standing order: Build Jump Gate at Nearest Jump Point|3192|-38730803.2553723|-119788650.555606|10|0
66731|38|226|0|2500994915.0|42|Stabilisation Squadron 004 is unable to carry out its primary standing order: Build Jump Gate at Nearest Jump Point|3192|-38730803.2553723|-119788650.555606|10|0
66731|38|227|0|2500994915.0|42|Stabilisation Squadron - Beam Escort 002 is unable to carry out its primary standing order: Build Jump Gate at Nearest Jump Point|3210|-3226303.4647296|-19287738.0161702|10|0
66731|38|223|0|2500994915.0|42|CJ Meilikki 013 is unable to carry out its primary standing order: Join Operational Group|3158|114903086.163866|121872511.393931|10|0
66731|38|223|0|2500994915.0|42|CJ Meilikki 014 is unable to carry out its primary standing order: Join Operational Group|3158|114903086.163866|121872511.393931|10|0
66731|38|228|0|2500994915.0|42|GE Adulators 001 is unable to carry out its primary standing order: Refuel from Colony or Hub (All)|3194|776885135.489099|-1149124440.67871|10|0
66731|38|228|0|2500994915.0|42|GE Adulators 003 is unable to carry out its primary standing order: Refuel from Colony or Hub (All)|3194|154259744.101406|-122035590.417525|10|0
66731|38|228|0|2500994915.0|42|Stabilisation Squadron 003 is unable to carry out its primary standing order: Build Jump Gate at Nearest Jump Point|3249|-13322068.2631936|45906218.014858|10|0
66731|38|228|0|2500994915.0|42|Stabilisation Squadron 004 is unable to carry out its primary standing order: Build Jump Gate at Nearest Jump Point|3284|1655743577.19062|0.0|10|0
66731|38|228|0|2500994915.0|42|DDG Angels of Damnation 005 is unable to carry out its primary standing order: Join Operational Group|3249|-13322068.2631936|45906218.014858|10|0
66731|38|228|0|2500994915.0|42|DDG Angels of Damnation 006 is unable to carry out its primary standing order: Join Operational Group|3249|-13322068.2631936|45906218.014858|10|0
66731|38|228|0|2500994915.0|42|Stabilisation Squadron 005 is unable to carry out its primary standing order: Build Jump Gate at Nearest Jump Point|3270|991048189.060855|-572181938.734176|10|0
66731|38|228|0|2500994915.0|42|Stabilisation Squadron 006 is unable to carry out its primary standing order: Build Jump Gate at Nearest Jump Point|3249|-13322068.2631936|45906218.014858|10|0
66731|38|228|0|2500994915.0|42|DDG Angels of Damnation 007 is unable to carry out its primary standing order: Join Operational Group|3249|-13322068.2631936|45906218.014858|10|0
66731|38|228|0|2500994915.0|42|DDG Angels of Damnation 008 is unable to carry out its primary standing order: Join Operational Group|3249|-13322068.2631936|45906218.014858|10|0
66731|38|228|0|2500994915.0|42|DDG Angels Numinous 015 is unable to carry out its primary standing order: Join Operational Group|3249|-13322068.2631936|45906218.014858|10|0
66731|38|228|0|2500994915.0|42|DDG Angels of Damnation 009 is unable to carry out its primary standing order: Join Operational Group|3249|-13322068.2631936|45906218.014858|10|0
66731|38|228|0|2500994915.0|42|DDG Angels Numinous 016 is unable to carry out its primary standing order: Join Operational Group|3249|-13322068.2631936|45906218.014858|10|0
66731|38|228|0|2500994915.0|42|DDG Angels Numinous 017 is unable to carry out its primary standing order: Join Operational Group|3249|-13322068.2631936|45906218.014858|10|0
66731|38|228|0|2500994915.0|42|DDG Angels Numinous 018 is unable to carry out its primary standing order: Join Operational Group|3249|-13322068.2631936|45906218.014858|10|0
66731|38|228|0|2500994915.0|42|DDG Angels Numinous 019 is unable to carry out its primary standing order: Join Operational Group|3249|-13322068.2631936|45906218.014858|10|0
66730|38|217|0|2500987715.0|83|FT Bosmans Small F3 001 was unable to load Ground Force Construction Complex from Blücher-A I|3078|-7027655.47182478|18904480.5779801|10|0
66730|38|217|0|2500987715.0|83|FT Bosmans Small F3 007 was unable to load Ground Force Construction Complex from Blücher-A I|3078|-7027655.47182478|18904480.5779801|10|0
66730|38|217|0|2500987715.0|83|FT Bosmans Small F3 013 was unable to load Ground Force Construction Complex from Blücher-A I|3078|-7027655.47182478|18904480.5779801|10|0
66730|38|218|0|2500987715.0|83|FT Nasser Small F3 004 was unable to load Mine from Ehecatotontli-A II|3132|-24155266.66499|14274525.0701791|10|0
66730|38|218|0|2500987715.0|83|FT Nasser Small F3 013 was unable to load Mine from Ehecatotontli-A II|3132|-24155266.66499|14274525.0701791|10|0
66730|38|219|0|2500987715.0|83|FT de Klerk Small F3 004 was unable to load Mine from Hamadan-B III - Moon 10|3182|2349028888.18414|433089884.305349|10|0
66730|38|219|0|2500987715.0|83|FT de Klerk Small F3 010 was unable to load Mine from Hamadan-B III - Moon 10|3182|2349028888.18414|433089884.305349|10|0
66730|38|217|0|2500987715.0|83|FT Verhaeghe Small F3 001 was unable to load Ground Force Construction Complex from Blücher-A I|3078|-7027655.47182478|18904480.5779801|10|0
66730|38|219|0|2500987715.0|83|FT van Heerden Small F3 001 was unable to load Mine from Hamadan-B III - Moon 10|3182|2349028888.18414|433089884.305349|10|0
66730|38|217|0|2500987715.0|83|FT Timmermans Small F3 004 was unable to load Ground Force Construction Complex from Blücher-A I|3078|-7027655.47182478|18904480.5779801|10|0
66730|38|217|0|2500987715.0|83|FT Goethals Small F3 002 was unable to load Ground Force Construction Complex from Blücher-A I|3078|-7027655.47182478|18904480.5779801|10|0
66730|38|217|0|2500987715.0|83|FT Goethals Small F4 006 was unable to load Ground Force Construction Complex from Blücher-A I|3078|-7027655.47182478|18904480.5779801|10|0
66730|38|217|0|2500987715.0|83|FT Bosmans Large F4 023 was unable to load Ground Force Construction Complex from Blücher-A I|3078|-7027655.47182478|18904480.5779801|10|0
66730|38|217|0|2500987715.0|83|FT Bosmans Large F4 024 was unable to load Ground Force Construction Complex from Blücher-A I|3078|-7027655.47182478|18904480.5779801|10|0
66730|38|218|0|2500987715.0|83|FT Nasser Large F3 024 was unable to load Mine from Ehecatotontli-A II|3132|-24155266.66499|14274525.0701791|10|0
66730|38|218|0|2500987715.0|83|FT Essa Small F3 004 was unable to load Mine from Ehecatotontli-A II|3132|-24155266.66499|14274525.0701791|10|0
66730|38|217|0|2500987715.0|83|FT Parmentier Small F4 001 was unable to load Ground Force Construction Complex from Blücher-A I|3078|-7027655.47182478|18904480.5779801|10|0
66730|38|217|0|2500987715.0|83|FT Lefebvre Small F4 002 was unable to load Ground Force Construction Complex from Blücher-A I|3078|-7027655.47182478|18904480.5779801|10|0
66730|38|217|0|2500987715.0|83|FT Parmentier Small F4 002 was unable to load Ground Force Construction Complex from Blücher-A I|3078|-7027655.47182478|18904480.5779801|10|0
66730|38|217|0|2500987715.0|83|FT Lefebvre Small F4 005 was unable to load Ground Force Construction Complex from Blücher-A I|3078|-7027655.47182478|18904480.5779801|10|0
66730|38|217|0|2500987715.0|83|FT Bosmans Small F4 027 was unable to load Ground Force Construction Complex from Blücher-A I|3078|-7027655.47182478|18904480.5779801|10|0
66730|38|217|0|2500987715.0|83|FT Lefebvre Small F4 006 was unable to load Ground Force Construction Complex from Blücher-A I|3078|-7027655.47182478|18904480.5779801|10|0
66730|38|217|0|2500987715.0|83|FT Robert Small F4 002 was unable to load Ground Force Construction Complex from Blücher-A I|3078|-7027655.47182478|18904480.5779801|10|0
66730|38|217|0|2500987715.0|83|FT Robert Small F4 004 was unable to load Ground Force Construction Complex from Blücher-A I|3078|-7027655.47182478|18904480.5779801|10|0
66730|38|217|0|2500987715.0|83|FT Poncelet Small F4 001 was unable to load Ground Force Construction Complex from Blücher-A I|3078|-7027655.47182478|18904480.5779801|10|0
66730|38|217|0|2500987715.0|83|FT Lefebvre Small F4 007 was unable to load Ground Force Construction Complex from Blücher-A I|3078|-7027655.47182478|18904480.5779801|10|0
66730|38|217|0|2500987715.0|83|FT Robert Small F4 007 was unable to load Ground Force Construction Complex from Blücher-A I|3078|-7027655.47182478|18904480.5779801|10|0
66730|38|217|0|2500987715.0|83|FT Robert Small F5 008 was unable to load Ground Force Construction Complex from Blücher-A I|3078|-7027655.47182478|18904480.5779801|10|0
66730|38|217|0|2500987715.0|83|FT Poncelet Small F5 007 was unable to load Ground Force Construction Complex from Blücher-A I|3078|-7027655.47182478|18904480.5779801|10|0
66730|38|218|0|2500987715.0|83|FT Omar Small F4 002 was unable to load Mine from Ehecatotontli-A II|3132|-24155266.66499|14274525.0701791|10|0
66730|38|217|0|2500987715.0|83|FT Verstraete Small F5 003 was unable to load Ground Force Construction Complex from Blücher-A I|3078|-7027655.47182478|18904480.5779801|10|0
66730|38|217|0|2500987715.0|83|FT Lefebvre Small F5 009 was unable to load Ground Force Construction Complex from Blücher-A I|3078|-7027655.47182478|18904480.5779801|10|0
66730|38|217|0|2500987715.0|83|FT Robert Small F5 010 was unable to load Ground Force Construction Complex from Blücher-A I|3078|-7027655.47182478|18904480.5779801|10|0
66730|38|217|0|2500987715.0|83|FT Renard Small F5 003 was unable to load Ground Force Construction Complex from Blücher-A I|3078|-7027655.47182478|18904480.5779801|10|0
66730|38|217|0|2500987715.0|83|FT Renard Small F5 006 was unable to load Ground Force Construction Complex from Blücher-A I|3078|-7027655.47182478|18904480.5779801|10|0
66730|38|217|0|2500987715.0|83|FT Vandenberghe Small F5 001 was unable to load Ground Force Construction Complex from Blücher-A I|3078|-7027655.47182478|18904480.5779801|10|0
66730|38|217|0|2500987715.0|83|FT Renard Small F5 007 was unable to load Ground Force Construction Complex from Blücher-A I|3078|-7027655.47182478|18904480.5779801|10|0
66730|38|217|0|2500987715.0|83|FT Renard Small F5 008 was unable to load Ground Force Construction Complex from Blücher-A I|3078|-7027655.47182478|18904480.5779801|10|0
66730|38|217|0|2500987715.0|83|FT Verstraete Small F5 009 was unable to load Ground Force Construction Complex from Blücher-A I|3078|-7027655.47182478|18904480.5779801|10|0
66730|38|217|0|2500987715.0|83|FT Vermeulen Small F5 002 was unable to load Ground Force Construction Complex from Blücher-A I|3078|-7027655.47182478|18904480.5779801|10|0
66730|38|217|0|2500987715.0|83|FT Vermeulen Small F5 004 was unable to load Ground Force Construction Complex from Blücher-A I|3078|-7027655.47182478|18904480.5779801|10|0
66730|38|218|0|2500987715.0|83|FT Shahriar Small F4 007 was unable to load Mine from Ehecatotontli-A II|3132|-24155266.66499|14274525.0701791|10|0
66730|38|217|0|2500987715.0|83|FT Vermeulen Small F5 006 was unable to load Ground Force Construction Complex from Blücher-A I|3078|-7027655.47182478|18904480.5779801|10|0
66730|38|217|0|2500987715.0|83|FT Verhaeghe Small F5 001 was unable to load Ground Force Construction Complex from Blücher-A I|3078|-7027655.47182478|18904480.5779801|10|0
66730|38|217|0|2500987715.0|83|FT Verstraete Small F5 010 was unable to load Ground Force Construction Complex from Blücher-A I|3078|-7027655.47182478|18904480.5779801|10|0
66730|38|217|0|2500987715.0|83|FT Bosmans Large F5 041 was unable to load Ground Force Construction Complex from Blücher-A I|3078|-7027655.47182478|18904480.5779801|10|0
66730|38|217|0|2500987715.0|83|FT Verhaeghe Large F5 012 was unable to load Ground Force Construction Complex from Blücher-A I|3078|-7027655.47182478|18904480.5779801|10|0

To get an idea of the scale of the problem, I dumped out all the messages for race 217 in game 38, and counted up all the occurences of each message. Here are the 100 most commonly repeated messages:

Code: [Select]
    306 38|217|65|Angledool III 054 has run out of fuel
    306 38|217|65|Angledool III 055 has run out of fuel
    306 38|217|65|Angledool III 056 has run out of fuel
    306 38|217|65|Angledool III 057 has run out of fuel
    306 38|217|65|Angledool III 064 has run out of fuel
    306 38|217|65|Angledool III 065 has run out of fuel
    306 38|217|65|Angledool III 066 has run out of fuel
    306 38|217|65|Angledool III 067 has run out of fuel
    306 38|217|65|J. Douglas Blackwood 004 has run out of fuel
    308 38|217|83|FT Poncelet Small F4 002 was unable to load Ground Force Construction Complex from Blücher-A I
    308 38|217|83|FT Poncelet Small F4 006 was unable to load Ground Force Construction Complex from Blücher-A I
    308 38|217|83|FT Poncelet Small F5 011 was unable to load Ground Force Construction Complex from Blücher-A I
    308 38|217|83|FT Timmermans Large F5 010 was unable to load Ground Force Construction Complex from Blücher-A I
    309 38|217|83|FT Parmentier Small F5 008 was unable to load Ground Force Construction Complex from Blücher-A I
    309 38|217|83|FT Poncelet Small F5 009 was unable to load Ground Force Construction Complex from Blücher-A I
    310 38|217|83|FT Parmentier Small F4 006 was unable to load Ground Force Construction Complex from Blücher-A I
    310 38|217|83|FT Parmentier Small F5 010 was unable to load Ground Force Construction Complex from Blücher-A I
    310 38|217|83|FT Vandenberghe Small F5 002 was unable to load Ground Force Construction Complex from Blücher-A I
    310 38|217|83|FT Vandenberghe Small F5 006 was unable to load Ground Force Construction Complex from Blücher-A I
    310 38|217|83|FT Vandenberghe Small F5 007 was unable to load Ground Force Construction Complex from Blücher-A I
    310 38|217|83|FT Vermeulen Small F5 001 was unable to load Ground Force Construction Complex from Blücher-A I
    311 38|217|83|FT Bosmans Large F5 049 was unable to load Ground Force Construction Complex from Blücher-A I
    311 38|217|83|FT Renard Small F5 010 was unable to load Ground Force Construction Complex from Blücher-A I
    311 38|217|83|FT Robert Small F5 014 was unable to load Ground Force Construction Complex from Blücher-A I
    311 38|217|83|FT Vandenberghe Small F5 009 was unable to load Ground Force Construction Complex from Blücher-A I
    312 38|217|83|FT Renard Small F5 005 was unable to load Ground Force Construction Complex from Blücher-A I
    312 38|217|83|FT Verstraete Small F5 005 was unable to load Ground Force Construction Complex from Blücher-A I
    312 38|217|83|FT Verstraete Small F5 006 was unable to load Ground Force Construction Complex from Blücher-A I
    313 38|217|83|FT Bosmans Large F5 048 was unable to load Ground Force Construction Complex from Blücher-A I
    313 38|217|83|FT Lefebvre Small F5 011 was unable to load Ground Force Construction Complex from Blücher-A I
    314 38|217|83|FT Vandenberghe Small F5 011 was unable to load Ground Force Construction Complex from Blücher-A I
    314 38|217|83|FT Verhaeghe Large F5 013 was unable to load Ground Force Construction Complex from Blücher-A I
    315 38|217|83|FT Verhaeghe Small F5 011 was unable to load Ground Force Construction Complex from Blücher-A I
    316 38|217|83|FT van Damme Small F5 002 was unable to load Ground Force Construction Complex from Blücher-A I
    318 38|217|83|FT Bosmans Large F5 046 was unable to load Ground Force Construction Complex from Blücher-A I
    318 38|217|83|FT Goethals Large F5 016 was unable to load Ground Force Construction Complex from Blücher-A I
    318 38|217|83|FT Verhaeghe Large F5 012 was unable to load Ground Force Construction Complex from Blücher-A I
    319 38|217|83|FT Parmentier Small F5 012 was unable to load Ground Force Construction Complex from Blücher-A I
    320 38|217|83|FT Vandenberghe Small F5 013 was unable to load Ground Force Construction Complex from Blücher-A I
    320 38|217|83|FT Vermeulen Small F5 010 was unable to load Ground Force Construction Complex from Blücher-A I
    321 38|217|83|FT Verhaeghe Small F5 009 was unable to load Ground Force Construction Complex from Blücher-A I
    322 38|217|83|FT Bosmans Large F5 041 was unable to load Ground Force Construction Complex from Blücher-A I
    322 38|217|83|FT Bosmans Small F4 027 was unable to load Ground Force Construction Complex from Blücher-A I
    322 38|217|83|FT Verhaeghe Small F5 008 was unable to load Ground Force Construction Complex from Blücher-A I
    323 38|217|83|FT Robert Large F5 012 was unable to load Ground Force Construction Complex from Blücher-A I
    323 38|217|83|FT Robert Small F5 008 was unable to load Ground Force Construction Complex from Blücher-A I
    323 38|217|83|FT Robert Small F5 010 was unable to load Ground Force Construction Complex from Blücher-A I
    324 38|217|83|FT Robert Small F4 002 was unable to load Ground Force Construction Complex from Blücher-A I
    324 38|217|83|FT Robert Small F4 004 was unable to load Ground Force Construction Complex from Blücher-A I
    324 38|217|83|FT Robert Small F4 007 was unable to load Ground Force Construction Complex from Blücher-A I
    324 38|217|83|FT van Damme Small F5 006 was unable to load Ground Force Construction Complex from Blücher-A I
    325 38|217|83|FT de Winter Small F5 006 was unable to load Ground Force Construction Complex from Blücher-A I
    328 38|217|83|FT van Damme Small F5 001 was unable to load Ground Force Construction Complex from Blücher-A I
    329 38|217|83|FT Lefebvre Small F4 002 was unable to load Ground Force Construction Complex from Blücher-A I
    329 38|217|83|FT Lefebvre Small F4 006 was unable to load Ground Force Construction Complex from Blücher-A I
    329 38|217|83|FT Parmentier Small F4 002 was unable to load Ground Force Construction Complex from Blücher-A I
    329 38|217|83|FT Vermeulen Small F5 004 was unable to load Ground Force Construction Complex from Blücher-A I
    330 38|217|83|FT Lefebvre Small F5 009 was unable to load Ground Force Construction Complex from Blücher-A I
    330 38|217|83|FT Poncelet Small F5 007 was unable to load Ground Force Construction Complex from Blücher-A I
    330 38|217|83|FT Vandenberghe Small F5 001 was unable to load Ground Force Construction Complex from Blücher-A I
    330 38|217|83|FT Vermeulen Small F5 002 was unable to load Ground Force Construction Complex from Blücher-A I
    330 38|217|83|FT Vermeulen Small F5 006 was unable to load Ground Force Construction Complex from Blücher-A I
    331 38|217|83|FT Lefebvre Small F4 005 was unable to load Ground Force Construction Complex from Blücher-A I
    331 38|217|83|FT Lefebvre Small F4 007 was unable to load Ground Force Construction Complex from Blücher-A I
    331 38|217|83|FT Poncelet Small F4 001 was unable to load Ground Force Construction Complex from Blücher-A I
    331 38|217|83|FT Verhaeghe Small F5 013 was unable to load Ground Force Construction Complex from Blücher-A I
    332 38|217|83|FT Renard Small F5 006 was unable to load Ground Force Construction Complex from Blücher-A I
    332 38|217|83|FT Renard Small F5 007 was unable to load Ground Force Construction Complex from Blücher-A I
    332 38|217|83|FT Verhaeghe Small F5 001 was unable to load Ground Force Construction Complex from Blücher-A I
    332 38|217|83|FT Verstraete Small F5 009 was unable to load Ground Force Construction Complex from Blücher-A I
    332 38|217|83|FT Verstraete Small F5 010 was unable to load Ground Force Construction Complex from Blücher-A I
    333 38|217|83|FT Renard Small F5 003 was unable to load Ground Force Construction Complex from Blücher-A I
    333 38|217|83|FT Renard Small F5 008 was unable to load Ground Force Construction Complex from Blücher-A I
    333 38|217|83|FT Verstraete Small F5 003 was unable to load Ground Force Construction Complex from Blücher-A I
    334 38|217|83|FT Verhaeghe Small F5 005 was unable to load Ground Force Construction Complex from Blücher-A I
    345 38|217|83|FT Timmermans Small F3 004 was unable to load Ground Force Construction Complex from Blücher-A I
    345 38|217|83|FT Verhaeghe Small F3 001 was unable to load Ground Force Construction Complex from Blücher-A I
    349 38|217|83|FT Bosmans Large F4 024 was unable to load Ground Force Construction Complex from Blücher-A I
    351 38|217|83|FT Bosmans Large F4 023 was unable to load Ground Force Construction Complex from Blücher-A I
    351 38|217|83|FT Bosmans Small F3 001 was unable to load Ground Force Construction Complex from Blücher-A I
    351 38|217|83|FT Bosmans Small F3 007 was unable to load Ground Force Construction Complex from Blücher-A I
    351 38|217|83|FT Bosmans Small F3 013 was unable to load Ground Force Construction Complex from Blücher-A I
    351 38|217|83|FT Goethals Small F3 002 was unable to load Ground Force Construction Complex from Blücher-A I
    351 38|217|83|FT Goethals Small F4 006 was unable to load Ground Force Construction Complex from Blücher-A I
    354 38|217|83|FT Timmermans Small F3 005 was unable to load Ground Force Construction Complex from Blücher-A I
    354 38|217|83|FT Verhaeghe Small F4 006 was unable to load Ground Force Construction Complex from Blücher-A I
    356 38|217|83|FT Timmermans Small F4 007 was unable to load Ground Force Construction Complex from Blücher-A I
    357 38|217|83|FT Parmentier Small F4 001 was unable to load Ground Force Construction Complex from Blücher-A I
    360 38|217|83|FT Bosmans Large F3 020 was unable to load Ground Force Construction Complex from Blücher-A I
    360 38|217|83|FT Goethals Small F3 005 was unable to load Ground Force Construction Complex from Blücher-A I
    360 38|217|83|FT Goethals Small F4 007 was unable to load Ground Force Construction Complex from Blücher-A I
    361 38|217|83|FT Bosmans Small F3 004 was unable to load Ground Force Construction Complex from Blücher-A I
    361 38|217|83|FT Bosmans Small F3 010 was unable to load Ground Force Construction Complex from Blücher-A I
    361 38|217|83|FT Bosmans Small F3 016 was unable to load Ground Force Construction Complex from Blücher-A I
    494 38|217|64|Shortage of Gallicite in shipyard task: Build TT Amelup III at Hwaseong Prime
    768 38|217|42|JD Aranda II 001 is unable to carry out its primary standing order: Join Operational Group
    770 38|217|42|JD Aranda II 002 is unable to carry out its primary standing order: Join Operational Group
    770 38|217|42|JD Aranda II 003 is unable to carry out its primary standing order: Join Operational Group
    770 38|217|42|JD Aranda II 004 is unable to carry out its primary standing order: Join Operational Group
   1011 38|217|64|Shortage of Neutronium in shipyard task: Build TT Amelup III at Hwaseong Prime

You can see that the civilian freighters are getting orders that they cannot complete. I've previously reported a similar bug (http://aurora2.pentarch.org/index.php?topic=11565.msg140503#msg140503) where my civilian ships got orders to load cargo while they were already full. This seems to be the same bug, except that it is affecting the NPR's civilian ships rather than my own.

Edit: it wouldn't let me upload the save, so I uploaded it here: http://db48x.net/Aurora/rediscovery:%20conventional%20start%20in%203000%20with%20v1.12/AuroraDB.2_hour_intervals.zip
Title: Re: v1.12.0 Bugs Thread
Post by: SteelChicken on November 22, 2020, 05:51:53 PM
V1.12.0

Disabling fuel refineries and maintenance facilities don't free up the workers for other activities. 

Is it by design you cannot disable other industries (like ordnance factories, etc) like you could in VB6?

Thanks ;)

SJW: Working as Intended
Title: Re: v1.12.0 Bugs Thread
Post by: db48x on November 22, 2020, 08:15:12 PM
I set up a supply order at Earth for 9 mass drivers, then added a request for 1 mass driver at mars and 1 at the comet Wolf. I expected a civilian freighter to move one (1) mass driver to Mars, and another to move one (1) mass driver to the comet Wolf. The actual result was that two (2) freighters moved mass drivers to Mars, and two (2) moved mass drivers to Wolf.

My game has two civilian shipping lines, but I see from the ship history that one line delivered one mass driver, and the other line delivered three using two ships. This excerpt from the FCT_FleetHistory table shows that three mass drivers were loaded at Earth before any of them arrived, and that the final mass driver was loaded after a previous one had already arrived at the same destination.

Code: [Select]
sqlite> select * from fct_fleethistory where description like '%Mass Driver' order by gametime desc;
38|18632|Wolf: Unload Installation - Mass Driver|1366154010.0
38|18632|Earth: Load Installation - Mass Driver|1364908410.0
38|18641|Wolf: Unload Installation - Mass Driver|1364879610.0
38|18809|Mars: Unload Installation - Mass Driver|1364555610.0
38|18632|Mars: Unload Installation - Mass Driver|1364224410.0
38|18809|Earth: Load Installation - Mass Driver|1363878810.0
38|18632|Earth: Load Installation - Mass Driver|1363590810.0
38|18641|Earth: Load Installation - Mass Driver|1363590810.0

The function number
    n/a
The complete error text
    n/a
The window affected
    n/a
What you were doing at the time
    moving mass drivers to Mars and Wolf
Conventional or TN start
    conventional
Random or Real Stars
    real stars
Is your decimal separator a comma?
    no
Is the bug is easy to reproduce, intermittent or a one-off?
    easy
If this is a long campaign - say 75 years or longer - let me know the length of the campaign as well
    short
Title: Re: v1.12.0 Bugs Thread
Post by: TheTalkingMeowth on November 22, 2020, 08:50:45 PM
1.12, decimal native. ~30 years in. Conventional start.

NPRs seem to have stopped doing research. Note that this is a 1/4 research speed game.

I have a share research deal with two of the starting NPRs in my game. There is a 3rd starting NPR, as well as 3 additional NPRs spawned since game start.

I have not received ANY research results from the deal, and so I got curious. The database shows precisely 0 paused or active research projects that don't belong to me. Furthermore, the GameLog table contains no research complete events that are not from my race id. However, there are ALSO no "inactive research facility" events for the NPRs in the log, either. Maybe they just don't get those? Intel indicates that all the NPRs HAVE labs. They just are not using them.

The weirdest part is that, at one point, they WERE using them. I have encountered ships from the starting NPRs with different levels of engine tech. So at least for a while they were researching new tech.

I had to go into the database to fix the screw up with multiple projects for auxiliary control, so it's at least POSSIBLE I broke something. But I'm pretty sure this issue predates any database edits, though I've only just now noticed it. In particular, the paused research table (the one I needed to edit to fix the doubled projects) only had stuff from my race even before I made any changes. Still, it would be nice if someone could confirm this!

SJW: The NPRs don't do research projects in the same way as players. Instead, they research groups of projects linked to their design theme. The cost and results of the research is the same and they still use the output from research facilities to generate research points, but it is handled in the background rather than via the UI, which means you won't see any NPR research in the DB. It also takes a while to research a project group, after which they get all the new techs at the same time.
Title: Re: v1.12.0 Bugs Thread
Post by: db48x on November 23, 2020, 03:46:34 AM
I have an update to my previous but report about extra deliveries. I added a supply order on Wolf for one mass driver, and a demand for one mass driver on Hyperion. Three freighters belonging Horsey Logistics (yes, that's what they named it) have picked up mass drivers from Earth and are taking them to Hyperion. One is unloading and two are on the way.

Here are the relevant entries from FCT_PopInstallationDemand:

Code: [Select]
sqlite> select * from fct_popinstallationdemand where populationid = 5573;
  PopulationID = 5573
InstallationID = 24
        Amount = 2.0
        Export = 1
        GameID = 38
  NonEssential = 0
sqlite> select * from fct_popinstallationdemand where populationid = 5955;
  PopulationID = 5955
InstallationID = 24
        Amount = 1.0
        Export = 0
        GameID = 38
  NonEssential = 0

You can see that there are still two mass drivers available at Earth (out of the five that were there), and Hyperion is still wanting to import one (presumably because the first freighter hasn't finished unloading yet). I don't see any table in the database that records whether ships have been assigned to this task or not, so I'm not really sure how that's supposed to work. Possibly it's supposed to search the relevant civilian ships to see if any have orders to drop off that installationid at that populationid?

I've uploaded my database here: http://db48x.net/Aurora/rediscovery%202:%20conventional%20start%20in%204000%20with%20v1.12/AuroraDB.2_extra_deliveries_in_progress.zip (http://db48x.net/Aurora/rediscovery%202:%20conventional%20start%20in%204000%20with%20v1.12/AuroraDB.2_extra_deliveries_in_progress.zip)
Title: Re: v1.12.0 Bugs Thread
Post by: Garfunkel on November 23, 2020, 11:51:16 AM
1.12, decimal native. ~30 years in. Conventional start.

NPRs seem to have stopped doing research. Note that this is a 1/4 research speed game.

I have a share research deal with two of the starting NPRs in my game. There is a 3rd starting NPR, as well as 3 additional NPRs spawned since game start.

I have not received ANY research results from the deal, and so I got curious. The database shows precisely 0 paused or active research projects that don't belong to me. Furthermore, the GameLog table contains no research complete events that are not from my race id. However, there are ALSO no "inactive research facility" events for the NPRs in the log, either. Maybe they just don't get those? Intel indicates that all the NPRs HAVE labs. They just are not using them.

The weirdest part is that, at one point, they WERE using them. I have encountered ships from the starting NPRs with different levels of engine tech. So at least for a while they were researching new tech.

I had to go into the database to fix the screw up with multiple projects for auxiliary control, so it's at least POSSIBLE I broke something. But I'm pretty sure this issue predates any database edits, though I've only just know noticed it. In particular, the paused research table (the one I needed to edit to fix the doubled projects) only had stuff from my race even before I made any changes. Still, it would be nice if someone could confirm this!
Yes, absolutely. I'm not too keen on going DB diving myself but it would be hugely useful if other people could confirm this as it is possibly a major issue for the AI.
Title: Re: v1.12.0 Bugs Thread
Post by: nuclearslurpee on November 23, 2020, 01:22:05 PM
1.12, decimal native. ~30 years in. Conventional start.

NPRs seem to have stopped doing research. Note that this is a 1/4 research speed game.

I have a share research deal with two of the starting NPRs in my game. There is a 3rd starting NPR, as well as 3 additional NPRs spawned since game start.

I have not received ANY research results from the deal, and so I got curious. The database shows precisely 0 paused or active research projects that don't belong to me. Furthermore, the GameLog table contains no research complete events that are not from my race id. However, there are ALSO no "inactive research facility" events for the NPRs in the log, either. Maybe they just don't get those? Intel indicates that all the NPRs HAVE labs. They just are not using them.

The weirdest part is that, at one point, they WERE using them. I have encountered ships from the starting NPRs with different levels of engine tech. So at least for a while they were researching new tech.

I had to go into the database to fix the screw up with multiple projects for auxiliary control, so it's at least POSSIBLE I broke something. But I'm pretty sure this issue predates any database edits, though I've only just know noticed it. In particular, the paused research table (the one I needed to edit to fix the doubled projects) only had stuff from my race even before I made any changes. Still, it would be nice if someone could confirm this!
Yes, absolutely. I'm not too keen on going DB diving myself but it would be hugely useful if other people could confirm this as it is possibly a major issue for the AI.

I don't have a DB that can confirm this, but from what I remember reading about AI problems anyone who does should also check the AI wealth situation, it may be that they are running out of money and shutting down labs to break even (the C# AI does use money, yes?).
Title: Re: v1.12.0 Bugs Thread
Post by: TheTalkingMeowth on November 23, 2020, 05:15:19 PM
I don't have a DB that can confirm this, but from what I remember reading about AI problems anyone who does should also check the AI wealth situation, it may be that they are running out of money and shutting down labs to break even (the C# AI does use money, yes?).

Yeah, I wondered about this so I tried to find the wealth in the DB. Couldn't locate it. However, the AIs are building other stuff (they have active stuff in the Industrial Projects table).
Title: Re: v1.12.0 Bugs Thread
Post by: nuclearslurpee on November 23, 2020, 08:01:39 PM
It's in the FCT_Race table, literally the next column over from the race title so it's easy to find.
Title: Re: v1.12.0 Bugs Thread
Post by: db48x on November 26, 2020, 06:29:59 PM
Got a repeating bug

"Object references not set to an instance of an object."

It cycles through quite a few function numbers, including #2608, #222, #224, and #2339.

It seems to cycle infinitely, no matter how many times I push ok.

I was just passing 30 days as normal. The game is 227 years in, random stars, decimal separator is a period, TN start.

I did have the doom option for earth enabled, but it has long singe spiraled into the sun.

PS: I tried to attach the DB file, but for some reason I cannot attach anything, when I do and push post, it refreshes the page to 'create new topic'. Strange, I didn't used to have problems attaching files before...

I've just had the same problem in my game, but it's a conventional start, 7 years into the game, I just moved some infrastructure to Mars. This must be a problem with the AI; my own civilians haven't even launched a ship yet. Although I suppose the civilians could be trying and failing to launch a ship.

I haven't even saved it yet…

I guess I'll start over. Again.

Edit: I decided to click it a few times to see if it is infinite or if it's just looping over some reasonable list of things. After a few dozen clicks it went away, so apparently the list isn't too long. Or at least it isn't long at this stage of the game; there's no telling how long it could be in principle.
Title: Re: v1.12.0 Bugs Thread
Post by: TheTalkingMeowth on November 26, 2020, 09:09:05 PM
It's in the FCT_Race table, literally the next column over from the race title so it's easy to find.
You know, I didn't even think to look in that table. Derp. Thanks!
Title: Re: v1.12.0 Bugs Thread
Post by: Second Foundationer on November 27, 2020, 12:04:52 AM
v1.12.0
Conventional start with 3 NPRs, all spoilers except invaders on

Ground Forces Screen, Unit Series Tab
Conventional star
I suddenly cannot create new unit series. It WAS working when I first tried to use it (before any civilian mining complexes or alien encounters); I added a bunch of unit series right at the start of the game.

When I went back to add some new vehicle types, I now get a Function #3353: an item with the same key has already been added error when I hit OK in the name popup.

This happens for all names, even "Foo," "Bar," and "Totally not a real unit." So I doubt there is such a series already from some other race.

The issue persists after a save and reload.

+1. This issue happens once a certain amount of unit series have been created. It seems like some bug is hard capping the number of series you can have.

Adding unit series though DB editing will circumvent this issue but becomes finnicky.

I encountered the same problem. By chance, I have noticed that it suddenly starts to work again after doing stuff in the OOB tab and then go back to the Unit Series tab. I'm not yet absolutely sure what does it (or if it is reliably reproducible at all or semi-random); but this time the last thing I had done was hit the 'Clear Support' button for an HQ formation. Now, I can create new unit series again, no db editing required. Odd.
Title: Re: v1.12.0 Bugs Thread
Post by: nuclearslurpee on November 27, 2020, 12:38:17 AM
I encountered the same problem. By chance, I have noticed that it suddenly starts to work again after doing stuff in the OOB tab and then go back to the Unit Series tab. I'm not yet absolutely sure what does it (or if it is reliably reproducible at all or semi-random); but this time the last thing I had done was hit the 'Clear Support' button for an HQ formation. Now, I can create new unit series again, no db editing required. Odd.

I can confirm at least one precise workaround:The name of the series does not seem to matter, i.e. it does not matter if you create a series with the same or a different name.

EDIT: I had previously mis-identified effects in the ground forces window as being the source of the problem, this was incorrect and I've deleted that from my post.
Title: Re: v1.12.0 Bugs Thread
Post by: Second Foundationer on November 27, 2020, 01:06:07 AM
I can confirm at least one precise workaround:
  • On opening the Ground Forces window for the first time after loading the game, creating a series will fail twice.
  • It will succeed on the third try.
  • Creating another series will fail, then succeed.
  • Once again, creating another series will fail, then succeed.
  • Creating additional series will succeed, even after closing and re-opening the Ground Forces window.
The name of the series does not seem to matter, i.e. it does not matter if you create a series with the same or a different name.

EDIT: I had previously mis-identified effects in the ground forces window as being the source of the problem, this was incorrect and I've deleted that from my post.

You seem to have pinned the problem down. I just probed the matter very quickly once more and had to go through about two dozen failed attempts. After my previous post, I had many unit series, several of them empty. Did you have two pre-existing unit series? If so, the number of failures seems to depend on the number of unit series you already have. Presumably some incrementing index that starts over (after every restart of Aurora?) when it shouldn't.
Title: Re: v1.12.0 Bugs Thread
Post by: mostly_harmless on November 27, 2020, 05:51:09 AM
Commercial vessels as part of a military fleet going into overhaul, do not receive overhaul (which is correct).
However, they still suffer overhaul sluggishness when pulled out of the overhauled fleet.

v1.12 no mods

Thomas

SJW: Fixed
Title: Re: v1.12.0 Bugs Thread
Post by: nuclearslurpee on November 27, 2020, 11:20:22 AM
I can confirm at least one precise workaround:
  • On opening the Ground Forces window for the first time after loading the game, creating a series will fail twice.
  • It will succeed on the third try.
  • Creating another series will fail, then succeed.
  • Once again, creating another series will fail, then succeed.
  • Creating additional series will succeed, even after closing and re-opening the Ground Forces window.
The name of the series does not seem to matter, i.e. it does not matter if you create a series with the same or a different name.

EDIT: I had previously mis-identified effects in the ground forces window as being the source of the problem, this was incorrect and I've deleted that from my post.

You seem to have pinned the problem down. I just probed the matter very quickly once more and had to go through about two dozen failed attempts. After my previous post, I had many unit series, several of them empty. Did you have two pre-existing unit series? If so, the number of failures seems to depend on the number of unit series you already have. Presumably some incrementing index that starts over (after every restart of Aurora?) when it shouldn't.

I did this testing on an existing "real" save where I had around 15-20 series already. However, I do recall that some people have had bigger problems.

However, you've given me an idea...

...okay, I checked in my database and I found the following:
Quote
1   Series L Light Rifle   40   224
2   Series M Infantry Rifle   40   224
4   Series 1 Heavy Machine Gun   40   224
6   Series 3 Anti-Tank Rocket Launcher   40   224
40   Series SM-10 Marine Rifle   40   224
42   Series SM-11 Marine Heavy Machine Gun   40   224
48   Series SM-17S Marine Munitions   40   224
50   Series SM-19A Marine Company Command   40   224
58   Series 21 Armored Personnel Carrier   40   224
63   Series 23M SP Anti-Tank Gun   40   224
65   Series 24M SP Artillery Gun   40   224
67   Series 25M SP Anti-Air Gun   40   224
69   Series 27 Munitions Transport Vehicle   40   224
70   Series 29A Company Command Vehicle   40   224
71   Series 29B Battalion Command Vehicle   40   224
84   Series 33M Medium Tank   40   224
188   Series 71 Machine Gun Pillbox   40   224
191   Series 73M Anti-Tank Bunker   40   224
194   Series 74M Fortress Artillery   40   224
198   Series 75M Anti-Air Gun Emplacement   40   224
201   Series 79-B Fortified Command Post   40   224

Notice that the series ID numbers which are here match the numbers of the tries which failed to create new series in my tests - Try #1 failed, try #2 failed, try #3 (not listed) succeeded...and so on. So the hypothesis here would be that the series ID is not checked on loading a new game, and is incremented with each series one creates or attempts to create and only succeeds if the series ID is not used. This would explain why other people have many more repeated failures until they can create a new series - in my case the gaps between series IDs are due to my poking around in the DB to implement the previously-mentioned workaround (and also a couple of other points I'll note below).

To test this I booted up the same game and created 40+ series to reach the next used ID# after 6. Someone owes me a beer for this... Anyways, it pans out; I was able to create every series from #7 through #39, failed on #40, created #41, failed on #42, succeeded on #43.

So the behavior is definitely that game does not check the most recent or highest series ID on game load, starts incrementing series IDs from 1, and increments every time regardless of success or failure, only succeeding if a vacant series ID# exists.

I don't presume to know anything about Steve's code, but my suggestion for a hotfix would be to have the code for failing to create a series (which currently throws the Function #3353 error) increment the series ID repeatedly if series creation fails until an empty ID is found. Obviously this is a cheap hotfix but if the actual problem is subtle and difficult this would hopefully restore functionality in the meantime.

----

Notes:

The reason for my rather...sparse series ID spread in the DB is because I developed an ID numbering system to try and keep series ordered when I add new ones via the DB (referencing the earlier workaround posted in this thread). However, this did not work as the game does not sort the series list by ID#, the order is simply the order they are listed in the DB which is simply the chronological order of record creation. To get these sorted I this had to cut, create, and paste back my series to get the ID# order to match the chronological order. I'm not sure if this is intentional.

Additionally, I reiterate an earlier comment - there is currently no way in-game to remove a series, as the "Delete Series" button only clears the list of elements from a series. The only workaround for this is a DB edit, again.

To sum up, the series system in general needs some TLC to touch up the functionality so it all actually works as intended.
Title: Re: v1.12.0 Bugs Thread
Post by: db48x on November 27, 2020, 06:54:53 PM
So the behavior is definitely that game does not check the most recent or highest series ID on game load, starts incrementing series IDs from 1, and increments every time regardless of success or failure, only succeeding if a vacant series ID# exists.

That's some good bug-hunting. Obviously a slightly nicer fix would be to first query for the highest ID already used when loading the game, then start adding new rows with the next ID.
Title: Re: v1.12.0 Bugs Thread
Post by: Steve Walmsley on November 28, 2020, 12:30:23 PM
I've been fixing some bugs today. Rather than reply to each, I've noted any fixes or other comments in green text on the original posts.
Title: Re: v1.12.0 Bugs Thread
Post by: John Schilling on November 28, 2020, 01:27:18 PM
TL,DR: New installations sometimes don't appear when their production is complete.

Playing a v1. 12. 0 conventional start, but have researched TN tech.   The first time I tried to convert conventional industry to a construction factory, the project ran to completion, events window told me the project had completed, but there was no construction factory in the colony (Earth) summary window, and construction capacity had not changed.   Built a construction factory from scratch, same result - factory doesn't appear, no change in construction capacity.   Tried converting conventional industry to a mine, and that worked normally.   From that point forward, could convert to or build construction factories normally.

And just now, completed my first new shipyard complex (commercial), and no new shipyard appeared in the shipyards window.

In all cases, verified that I had sufficient wealth, minerals, and excess population at the start of the project, just before completion of the project, and just after completion of the project.   And the missing items aren't showing up on other colonies, in freighter cargo holds, or anywhere else I can find.
Title: Re: v1.12.0 Bugs Thread
Post by: db48x on November 28, 2020, 03:31:10 PM
I've been fixing some bugs today. Rather than reply to each, I've noted any fixes or other comments in green text on the original posts.

Thank you for the bug fixes, Steve!

However, it's a bit harder to find them when you edit an old post than when you write a new one. I went back through this thread to find out what you'd fixed, and I kept list of them to save others the work:

Title: Re: v1.12.0 Bugs Thread
Post by: Demetrious on November 29, 2020, 05:05:36 AM
Quote from: Steve Walmsley link=topic=11945. msg143650#msg143650 date=1606588223
I've been fixing some bugs today.  Rather than reply to each, I've noted any fixes or other comments in green text on the original posts.

Really happy to know that multiple NPRs on a single planet are a feature.  Certainly made for a very interesting game when I found that!
Title: Re: v1.12.0 Bugs Thread
Post by: Steve Walmsley on November 29, 2020, 05:24:09 AM
I've been fixing some bugs today. Rather than reply to each, I've noted any fixes or other comments in green text on the original posts.

Thank you for the bug fixes, Steve!

However, it's a bit harder to find them when you edit an old post than when you write a new one. I went back through this thread to find out what you'd fixed, and I kept list of them to save others the work:

Thanks for creating the list. I also make a note in the changes list of the new version as I fix each bug.

http://aurora2.pentarch.org/index.php?topic=12035.msg142470#msg142470

I started editing the original posts so the thread doesn't end up twice as long :)
Title: Re: v1.12.0 Bugs Thread
Post by: Steve Walmsley on November 29, 2020, 07:00:10 AM
conventional start, real stars, 200+ yrs.
reproducible in a fresh game with both real and non-real stars.

deep space tracking ranges seem to "wrap around" where the 10,000 range resets to a smaller value,  then the 1,000.  then the 10,000.  etc, as the number of stations, or tech levels grow.  sometimes the 10,000 range disappears entirely. im not sure if its a display issue on the system map or a range limit.

reproduceable by sm mode.  give yourself a high planetary sensor strength tech (2000 was my test). 
turn on passive vs signature 1,000 and 10,000.
then add deep space tracking centers a few at a time.

seems to happen around 11-12m km range

first occurs at 215,000 tracking station strength ~11.58m range
and again at 644,000
and 1,074,600
and 1,503,000

etc etc at ~430,000x+215,000 tracking strength.  each time the passive vs signature 10,000 range resets.

That's clearly integer overflow. With the new passive sensor model (http://aurora2.pentarch.org/index.php?topic=8495.msg103085#msg103085), the formula for the range is Detection Range = SQRT(Passive Sensor Strength * Target Signature ) * 250,000 km.

215,000 * 10,000 > 2^31-1, so it doesn't fit into a signed 32-bit integer. Using an unsigned 32-bit integer would delay the overflow until the sensor strength was 430,000. At the highest tech level, the range wraps around after 57 deep space tracking stations. This gives a maximum tracking range of 11.58 bkm, or 77.4 au.

Using an unsigned 64-bit number instead would delay the inevitable until the sensor strength was 1.844×10¹?, which is a pretty big number. At the highest possible tech level that will still be more than 491 billion tracking stations. Even then, I would specifically check for overflow so that I could use the maximum usable tracking strength instead of wrapping around. Looks like that would top out at a maximum detection range of 113 light years, which is silly enough that nobody would be bothered that they can't increase it further.

Note that once that bug is fixed, there will be another overflow bug when multiplying by 250,000 km. Might as well fix both at the same time. I don't know C# or .Net very well, but perhaps there are library functions for checked multiplication, or for saturating multiplication. Using them would do most of the work.

Bonus points for actually allowing detection of units in other star systems if the detection range is big enough…

I was storing the range in an 8 byte double, but calculating that as double = int * int. C# won't multiply 2 ints if the result is greater than a max int value, even if the output is to a double. I changed one of the ints to a double and now it works fine.
Title: Re: v1.12.0 Bugs Thread
Post by: Steve Walmsley on November 29, 2020, 07:33:29 AM
AI ships seem to have a very strange reaction to superior forces in the latest 1.12 version.

When confronted by superior attackers, the ships head immediately for the nearest Jump Point, even if that jump point leads directly into the 'enemy' home system. This could, in theory, be good tactics, but they jump through, and find themselves confronted by a large blockade force. Again, this could be the fortune of war.

Now, however, comes the buggy part. Before my ships can open fire at pointblank range, they jump BACK through the jump point, and my ships follow them through.

At this point I assumed they would try to run for it...

In reality, they continue to jump back and forth, with none of my ships, even on 5-second increments, ever able to actually fire on them, on either side of the jump point. I finally was forced to split my forces to sit on both sides of the jump point, in the hopes of engaging them. But they still jumped back and forth without me being able to get a shot off on either side of the gate with the waiting ships. This continued until I gave up and allowed them to leave after 18 cycles of jumping.

This... really isn't good for the game, as it makes it possible for any force, no matter how weak, to avoid engagement indefinitely. I thought there was some sort of jump cooldown which would prevent ships from making another jump instantly, as well as not using sensors? My guess is, since this was a stable jump point, that no jump engines were being used, and thus there was no cooldown.  I think there needs to be some sort of basic jump cooldown before another jump is possible, ideally a cooldown which is longer than the jump shock, allowing a chance for ships with superior speed to actually engage their enemies, since they cannot escape.

I know that NPR's don't have the same downsides for jumping as the player, due to weaker decision making, but I cannot think it is intended to be used in this way. In each case here, the ships were jumping back through the point within 5 seconds, with seemingly no end in sight.

 - I'm strongly against a cooldown mechanic, but rather think Jumping should just be either a flat 10 seconds or 15 seconds. The logic for the two increment being that it takes an increment to "jump out" and an increment to "jump in". The logic for the three increment would be either two increments to "plot" the jump and one increment to do the jump itself, or one increment to "plot" the jump, and two increments to complete it.

 - I'm in favor of the three increment system with one increment used for plotting the jump, which can then have the three increment reduced to two with the inclusion of a "Navigation" bridge module. Maybe even have Officers with some sort of Jump bonuses. We could also have it so that the players and NPRs get priority to fire on jumping targets. I'm tempted to dismiss this as "just good use of tactics" since it's technically consistent with Aurora's internal laws, but while the argument for that could be made... the fact remains that it just isn't fun and really only serves to delay the inevitable.

I think that cooldown is the most realistic way to handle jump shock. All sci-fi fictions and games rely on jump shock theory as you cannot just jump from system to system.

I think jump shock should be more related to the actual capability of the engines to cool down and recharge.

The mechanic could be related to a specific tech Jump cooldown in seconds and you could start from 60 down to a minimum of 5 or 10 sec.

Being a tech, it will also level the game with NPRs which will be allowed to jump only according to their tech.

I recognize the above could be hard to implement but the current mechanic it's too unpredictable at the point which is totally unrealistic and unbalanced.

The AI should suffer jump shock equal to half the amount for players, so not sure why the above is happening. I'll look into it.
Title: Re: v1.12.0 Bugs Thread
Post by: Steve Walmsley on November 29, 2020, 07:43:40 AM
Minor issue with using Rank Theme Barsoom (E.   R.   B.    was a childhood favorite).   
In the Events Window, the ranks are referred to as R5, R7, etc, instead of the actual rank name shown in the Commander Window.   This seems to be only for the Commander Experience Event, Promotion Event shows Rank name.   
Ranks display fine in the Commander Window when examining the individual.   
Using 1.   12.   0, normal start, no mods.   
It's possible other rarely used Rank Themes have the same issue, but I haven't checked.   

Addendum:  The same R5/R6/etc shows up here and there throughout other windows when the Name Rank should show.

The experience event (and some other areas) uses the abbreviation for the rank name instead of the full rank. When no abbreviation exists for a rank, Aurora uses R1, R2, etc.. You can set the abbreviation by renaming each rank. Keep the name and enter your preferred abbreviation.
Title: Re: v1.12.0 Bugs Thread
Post by: Steve Walmsley on November 29, 2020, 09:50:08 AM
I had that too on my first game. I'm guessing it happens if you change date format. I'm pretty sure I changed my date format from including the weekday before I discovered any systems.

That's certainly a possibility, but in my case the date format was changed long before I began this game.

I can't reproduce. The date is recorded as a text field at the time of discovery, so if the date format was changed after game start you would see a difference on the discovery dates on the Galactic Map.
Title: Re: v1.12.0 Bugs Thread
Post by: TheTalkingMeowth on November 29, 2020, 10:10:45 AM
AI ships seem to have a very strange reaction to superior forces in the latest 1.12 version.

When confronted by superior attackers, the ships head immediately for the nearest Jump Point, even if that jump point leads directly into the 'enemy' home system. This could, in theory, be good tactics, but they jump through, and find themselves confronted by a large blockade force. Again, this could be the fortune of war.

Now, however, comes the buggy part. Before my ships can open fire at pointblank range, they jump BACK through the jump point, and my ships follow them through.

At this point I assumed they would try to run for it...

In reality, they continue to jump back and forth, with none of my ships, even on 5-second increments, ever able to actually fire on them, on either side of the jump point. I finally was forced to split my forces to sit on both sides of the jump point, in the hopes of engaging them. But they still jumped back and forth without me being able to get a shot off on either side of the gate with the waiting ships. This continued until I gave up and allowed them to leave after 18 cycles of jumping.

This... really isn't good for the game, as it makes it possible for any force, no matter how weak, to avoid engagement indefinitely. I thought there was some sort of jump cooldown which would prevent ships from making another jump instantly, as well as not using sensors? My guess is, since this was a stable jump point, that no jump engines were being used, and thus there was no cooldown.  I think there needs to be some sort of basic jump cooldown before another jump is possible, ideally a cooldown which is longer than the jump shock, allowing a chance for ships with superior speed to actually engage their enemies, since they cannot escape.

I know that NPR's don't have the same downsides for jumping as the player, due to weaker decision making, but I cannot think it is intended to be used in this way. In each case here, the ships were jumping back through the point within 5 seconds, with seemingly no end in sight.

 - I'm strongly against a cooldown mechanic, but rather think Jumping should just be either a flat 10 seconds or 15 seconds. The logic for the two increment being that it takes an increment to "jump out" and an increment to "jump in". The logic for the three increment would be either two increments to "plot" the jump and one increment to do the jump itself, or one increment to "plot" the jump, and two increments to complete it.

 - I'm in favor of the three increment system with one increment used for plotting the jump, which can then have the three increment reduced to two with the inclusion of a "Navigation" bridge module. Maybe even have Officers with some sort of Jump bonuses. We could also have it so that the players and NPRs get priority to fire on jumping targets. I'm tempted to dismiss this as "just good use of tactics" since it's technically consistent with Aurora's internal laws, but while the argument for that could be made... the fact remains that it just isn't fun and really only serves to delay the inevitable.

I think that cooldown is the most realistic way to handle jump shock. All sci-fi fictions and games rely on jump shock theory as you cannot just jump from system to system.

I think jump shock should be more related to the actual capability of the engines to cool down and recharge.

The mechanic could be related to a specific tech Jump cooldown in seconds and you could start from 60 down to a minimum of 5 or 10 sec.

Being a tech, it will also level the game with NPRs which will be allowed to jump only according to their tech.

I recognize the above could be hard to implement but the current mechanic it's too unpredictable at the point which is totally unrealistic and unbalanced.

The AI should suffer jump shock equal to half the amount for players, so not sure why the above is happening. I'll look into it.

This is happening on stabilized jump points. A standard transit through a stable jump point does suffer the combat related jump shock, but there is nothing stopping you from transiting back out via the stabilized point. Humans can do this too.
Title: Re: v1.12.0 Bugs Thread
Post by: ndkid on November 29, 2020, 02:11:37 PM
FWIW, it's an order of operations thing. It calculates the result of multiplying two integers using integer math, _then_ casts (the now overflown value) to a double. By turning one of the values to double ahead of time, it can no longer do integer multiplication, so it does double multiplication, avoiding the overflow.
Title: Re: v1.12.0 Bugs Thread
Post by: Potat999 on November 29, 2020, 07:02:00 PM
Through a strange turn of events, I finished my first Sorium harvester before I had completed my system survey.   

I set a standing order to move to gas giant with Sorium, although I had not yet surveyed any such bodies, figuring the harvester would move after I found sorium.

On the next tick, I find my harvester is already on course for planet II - which I have not yet surveyed.

It seems the standing order does not take survey status into account.   I assume this is not intended

SJW: Fixed
Title: Re: v1.12.0 Bugs Thread
Post by: Steve Walmsley on November 30, 2020, 11:52:37 AM
What you were doing at the time - Building vessels with pre-fabbed components
Conventional or TN start - Conventional, with 20k starting RP used to unlock TN tech and a handful of other technologies.
Random or Real Stars - Random
Is the bug is easy to reproduce, intermittent or a one-off? - Should be relatively easy to reproduce.
If this is a long campaign - say 75 years or longer - let me know the length of the campaign as well - Done with a brand-new start that hadn't incremented yet.
Construction Cycle is 86000s

I've discovered that if you construct a vessel with pre-fabricated components, the setting appears to cause a sort of phantom effect in certain circumstances that allows you to build vessels with significantly reduced mineral costs (including entirely omitting them for some minerals)

The test I performed was to design an engine, any engine (In this instance I used Nuclear Thermal engine tech, 100% power). I then designed a ship that used that engine, slapping 20 engines on. Removing any other items that consumed gallicite, I then had a cost of exactly 2000 gallicite. Earth already had 2000 gallicite on it, so I quickly SM'd away all conventional factories, added 1000 construction factories and edited the pop to be 5b so I had people to man the facilities. Adding a new naval shipyard and quickly modifying it to be 50kt (about 7k more than I needed, but quicker to type for me), I assigned the ship class to it, then went to industry and built the components over the course of a few 30 day increments. Quickly checking and confirming that I had 0 gallicite on Earth, I then queued the shipyard to build a ship of that class using components. A few 30d increments later it was finished, no issues.
Here's where it gets funny.
I then re-opened the shipyards page, and noticed that the gallicite cost for the ship class was now just...missing. It no longer listed the cost as being there at all, and to test if it was just a visual glitch I queued up another ship to be built without ticking the Use Components box. A few 30d increments later and the ship, while taking much longer than before, was built. And I had no issues with gallicite usage, even though I very clearly had 0 in my stockpile, and I had also double checked to make sure I didn't have stockpiled engines for some reason. I conducted a further test, adding 2000 more gallicite to Earth via SM and closing/reopening the shipyard window. It now correctly displayed the gallicite need, and when I built this ship, while taking the same time as the previous "free" one, it did use the gallicite and what's more, gave an message in the event log upon completion that there were not enough minerals. Trying to build a new ship then gave the correct behavior, throwing the same message into the event log about missing the required minerals.

tl:dr is that it seems to be possible to trigger the game into thinking there are components available when there aren't, and this removes the mineral usage of a ship class

I have a Materials object that includes a value for each mineral. This is used by a variety of other objects such as populations, ship designs, etc. to track their minerals. Each shipyard task has its own Materials object. The bug was caused by me assigning the Materials object of the shipyard task to the Materials object of the class it was building, which meant they were both the same object. When the Materials object of the shipyard task was modified to reduce the required minerals, that modification also applied to the class. I've fixed it by creating a copy of the object, rather than (mistakenly) using a reference.
Title: Re: v1.12.0 Bugs Thread
Post by: Steve Walmsley on November 30, 2020, 12:10:27 PM
Conventional Start, Real Stars, 30 years in, decimal native

Disassembling components on a planet when for a technology that you have partially researched via labs doesn't work right. Instead of adding to your progress, research from disassembly accumulates on its own. If the total exceeds the progress from actual research, then the total progress switches. The bug seems to particularly affect auxiliary control, but I am leery of further testing since this bug occurred in 1.11 and ended up breaking the save (all alien races got deleted).

I'll reply separately on the bug. However, are you aware that Aurora creates backups for your previous two saves, so if you encounter something like the above, you can reload the previous save.
Title: Re: v1.12.0 Bugs Thread
Post by: Steve Walmsley on November 30, 2020, 01:09:44 PM
I saved my game this afternoon and got this message. I kept playing, but eventually I started getting interrupts every two hours. This game has had a lot of interrupts from NPR activity, so I let it run for a while. When I came back and found that it still hadn't been resolved, I peeked into the database. These are the 100 most recent messages in the game log:

You can see that the civilian freighters are getting orders that they cannot complete. I've previously reported a similar bug (http://aurora2.pentarch.org/index.php?topic=11565.msg140503#msg140503) where my civilian ships got orders to load cargo while they were already full. This seems to be the same bug, except that it is affecting the NPR's civilian ships rather than my own.

I don't know what is causing the bug. It most be relatively rare, so its probably some unusual combination of events. However, I can treat the symptoms even if I don't know the cause. I've added some code that deletes any existing NPR or civilian freighter cargo just before they load their new cargo. I've added a breakpoint to that code so if its triggers I can look into more detail and perhaps fix the underlying problem.
Title: Re: v1.12.0 Bugs Thread
Post by: Steve Walmsley on November 30, 2020, 01:10:33 PM
V1.12.0

Disabling fuel refineries and maintenance facilities don't free up the workers for other activities. 

Is it by design you cannot disable other industries (like ordnance factories, etc) like you could in VB6?

Thanks ;)

Yes it is by design. You can't shut down industry sectors in C#.
Title: Re: v1.12.0 Bugs Thread
Post by: Steve Walmsley on November 30, 2020, 01:15:59 PM
1.12, decimal native. ~30 years in. Conventional start.

NPRs seem to have stopped doing research. Note that this is a 1/4 research speed game.

I have a share research deal with two of the starting NPRs in my game. There is a 3rd starting NPR, as well as 3 additional NPRs spawned since game start.

I have not received ANY research results from the deal, and so I got curious. The database shows precisely 0 paused or active research projects that don't belong to me. Furthermore, the GameLog table contains no research complete events that are not from my race id. However, there are ALSO no "inactive research facility" events for the NPRs in the log, either. Maybe they just don't get those? Intel indicates that all the NPRs HAVE labs. They just are not using them.

The weirdest part is that, at one point, they WERE using them. I have encountered ships from the starting NPRs with different levels of engine tech. So at least for a while they were researching new tech.

I had to go into the database to fix the screw up with multiple projects for auxiliary control, so it's at least POSSIBLE I broke something. But I'm pretty sure this issue predates any database edits, though I've only just now noticed it. In particular, the paused research table (the one I needed to edit to fix the doubled projects) only had stuff from my race even before I made any changes. Still, it would be nice if someone could confirm this!

The NPRs don't do research projects in the same way as players. Instead, they research groups of projects linked to their design theme. The cost and results of the research is the same and they still use the output from research facilities to generate research points, but it is handled in the background rather than via the UI, which means you won't see any NPR research in the DB. It also takes a while to research a project group, after which they get all the new techs at the same time.
Title: Re: v1.12.0 Bugs Thread
Post by: Droll on November 30, 2020, 01:34:06 PM
I saved my game this afternoon and got this message. I kept playing, but eventually I started getting interrupts every two hours. This game has had a lot of interrupts from NPR activity, so I let it run for a while. When I came back and found that it still hadn't been resolved, I peeked into the database. These are the 100 most recent messages in the game log:

You can see that the civilian freighters are getting orders that they cannot complete. I've previously reported a similar bug (http://aurora2.pentarch.org/index.php?topic=11565.msg140503#msg140503) where my civilian ships got orders to load cargo while they were already full. This seems to be the same bug, except that it is affecting the NPR's civilian ships rather than my own.

I don't know what is causing the bug. It most be relatively rare, so its probably some unusual combination of events. However, I can treat the symptoms even if I don't know the cause. I've added some code that deletes any existing NPR or civilian freighter cargo just before they load their new cargo. I've added a breakpoint to that code so if its triggers I can look into more detail and perhaps fix the underlying problem.

If it helps I encountered this issue with colony ships. I had conquered an alien NPR but forgot to immediately set the colony to not a source of colonists so the civilian colony ships got their order to load up alien colonists. The problem occurred because there was no other eligible colony in my race that would accept those alien colonists so the civilians just sat in orbit of the alien homeworld with bays full of aliens.

My fix was through DB editing, I found the colony ships and set their cargo status so that they have 0 alien colonists which worked - essentially mimicking your workaround.

My worry with the way this fix has been done is that in my initial attempt instead of deleting the cargo entry in the DB I had just set its value to 0 - this caused a problem during unloading in that the colony ships were not allowed to unload "0" alien colonists onto a planet. This issue might be because of my initial shoddy DB work and might not arise naturally during a normal game but maybe you should make it so that ship cargo entries that have 0 of an item are automatically deleted as they aren't right now.

If you are just going to delete the cargo inside the ship when this happens this could result in scenarios where colony ships just start to repeatedly space their colonists, depopulating worlds.
Title: Re: v1.12.0 Bugs Thread
Post by: db48x on November 30, 2020, 04:55:13 PM
Minor issue with using Rank Theme Barsoom (E.   R.   B.    was a childhood favorite).   
In the Events Window, the ranks are referred to as R5, R7, etc, instead of the actual rank name shown in the Commander Window.   This seems to be only for the Commander Experience Event, Promotion Event shows Rank name.   
Ranks display fine in the Commander Window when examining the individual.   
Using 1.   12.   0, normal start, no mods.   
It's possible other rarely used Rank Themes have the same issue, but I haven't checked.   

Addendum:  The same R5/R6/etc shows up here and there throughout other windows when the Name Rank should show.

SJW: The experience event (and some other areas) uses the abbreviation for the rank name instead of the full rank. When no abbreviation exists for a rank, Aurora uses R1, R2, etc.. You can set the abbreviation by renaming each rank. Keep the name and enter your preferred abbreviation.

Steve, this confusion would crop up less often if the rank abbreviation was included next to the rank in the tree. It would be nice if it were in the minimum/maximum rank fields as well.

SJW: Added for v1.13
Title: Re: v1.12.0 Bugs Thread
Post by: xenoscepter on November 30, 2020, 05:43:36 PM
- The function number
 --- N/A

 - The complete error text
 --- N/A

 - The window affected
 --- No window per se, but rather a mechanical bug.

 - What you were doing at the time?
 --- Testing this bug specifically.

 - Conventional or TN start
 --- TN Start

 - Random or Real Stars
 --- Random

 - Is your decimal separator a comma?
 --- Decimal

 - Is the bug is easy to reproduce, intermittent or a one-off?
 --- Both very easy and quite simple to reproduce.

 - If this is a long campaign - say 75 years or longer - let me know the length of the campaign as well
 --- Fresh Game, default settings, whatever race settings it generated from the start, only the bare minimum SM needed to set up.

- I have had two bugs so far. The first is fighters (again), they will pick up colonists but won't unload them. It should be fairly easy to reproduce, just build a fighter, add an emergency cryo (or two), load it up and try to unload it. They won't. The second is Future Prototypes, again easy to reproduce. They won't be available to research even if you have the tech. I encountered the Future Prototype bug in v1.11 as well. Sorry for the short, lazy report I don't have the databases and I'm using the recommended settings.

 - I.E. decimal separator etc. I haven't run a 75+ year campaign for either of these bugs in v1.12, but I did encounter the Future Prototype bug in a 75+ year game and non-75+ year game in v1.11 fwiw.

 --- This bug is the fighter bug. I have gone through the checklist for bug submissions and will have an attached DB too. After some testing, this bug prevents fighters from unloading colonists at colonies without Cargo Shuttle Stations, as well as prevents the 'Load Colonist Order' from appearing on any that lack them. The file included is what I tested it with, there are colonies on Luna, Mars, Venus and Mercury. All have sufficient infrastructure. Two have populations, two do not. One without population has a Cargo Shuttle Station, one with population also has a Cargo Shuttle Station, the others do not. When SM removing the Cargo Shuttle Station AND the Spaceport from Earth, the option to 'Load Colonists' disappears...

SJW: Fixed
Title: Re: v1.12.0 Bugs Thread
Post by: Potat999 on November 30, 2020, 07:51:06 PM
Quote from: Potat999 link=topic=11945. msg143726#msg143726 date=1606698120
Through a strange turn of events, I finished my first Sorium harvester before I had completed my system survey.   

I set a standing order to move to gas giant with Sorium, although I had not yet surveyed any such bodies, figuring the harvester would move after I found sorium. 

On the next tick, I find my harvester is already on course for planet II - which I have not yet surveyed. 

It seems the standing order does not take survey status into account.    I assume this is not intended

SJW: Fixed


Thanks for the quick fix on the standing orders issue.   Thinking back, I forgot to mention a second related issue (?) - not only did the harvesters move to an unsurvey body, they also harvested successfully.   

I just tested by manually sending a harvester to various un-surveyed gas giants and advancing time, and found that harvesters will harvest from un-surveyed bodies.

I'm not 100% sure this is a bug per-se.   I guess if you had a sorium scoop and were in orbit on an un-surveyed gas giant an industrious captain might just try to scoop and see what happens? 

If this was already fixed at the same time you bopped the standing order bug or is intended, sorry :) 
Title: Re: v1.12.0 Bugs Thread
Post by: db48x on November 30, 2020, 08:23:24 PM
I just tested by manually sending a harvester to various un-surveyed gas giants and advancing time, and found that harvesters will harvest from un-surveyed bodies.

I'm not 100% sure this is a bug per-se.   I guess if you had a sorium scoop and were in orbit on an un-surveyed gas giant an industrious captain might just try to scoop and see what happens? 

If this was already fixed at the same time you bopped the standing order bug or is intended, sorry :)

This is some great QA work, deliberately going out of your way to find cool bugs. I like the industrious captain idea, it would make for an obscure but rewarding message in the game log. Get enough of those written and the game could get a reputation similar to Nethack, where "the DevTeam thinks of everything".
Title: Re: v1.12.0 Bugs Thread
Post by: Kalkkis on December 01, 2020, 03:30:30 AM
Affects Create Research Project window.   Decimal separator is comma. 

When you check 'Show Next Tech' checkbox to create a future prototype, min and max engine power for engines and max size shields don't use next tech, only current tech. 

Also, "Point Defence Weapon" checkbox when designing STO units is only active for weapons that can be on a turret, it should really only be active for weapons that ARE on a turret.  Also, checking the database, Rakha seem to have a design for STO Point Defence Plasma Carronade.  They shouldn't really bother since it's not on a turret.
Title: Re: v1.12.0 Bugs Thread
Post by: Zap0 on December 01, 2020, 08:07:12 AM
In 1.12, when making a new game with two player races and giving one of the empires a proper name of two characters or less results in a few errors when you first progress time and they encounter each other on Earth.

Errors are in sequence:
1957
1953
1948
1957
1948
460
Title: Re: v1.12.0 Bugs Thread
Post by: Zap0 on December 01, 2020, 08:16:54 AM
In 1.12, when invading another empire you end up with two populations on the same body. If there are any orbital habitats present when you have two colonies on the same body, each one gets the population cap increase from the habitat, making the habitat essentially provide twice it's capacity.

In this case I invaded a pop with an orbital habitat over it, which surrendered to the invading empire that then ended up with it and the two colonies.

Replicated DB attached.

SJW: Fixed
Title: Re: v1.12.0 Bugs Thread
Post by: Droll on December 01, 2020, 09:29:11 AM
In 1.12, when invading another empire you end up with two populations on the same body. If there are any orbital habitats present when you have two colonies on the same body, each one gets the population cap increase from the habitat, making the habitat essentially provide twice it's capacity.

In this case I invaded a pop with an orbital habitat over it, which surrendered to the invading empire that then ended up with it and the two colonies.

Replicated DB attached.

I was wondering if this was the case since I have some similar situations in my game, there might be a need to have a special command for fleets with orbital stations called "orbital colony" which explicitly assigns the habitats to a specific population to avoid this.
Title: Re: v1.12.0 Bugs Thread
Post by: db48x on December 02, 2020, 02:52:52 AM
Assign New Labs

An 'Assign New' button has been added to the Research tab of the Economics window. This is used to toggle an 'Assign New' status to one or more research projects, indicated by (N) after the project name.

When new research facilities are constructed, or become available through completion of other projects that do not have associated queued projects, those facilities will automatically be assigned to projects flagged as 'Assign New' in descending order of existing facilities. Each project in the list will be assigned available facilities until it reaches maximum, then any remaining available facilities will go to the next project in the list, etc.

I have some feedback on this one. While it usually works great, there is one scenario where it can be annoying. When your Power & Propulsion scientist is working on the next engine upgrade (which I think we can all agree is the most vital tech to research) and then decides to retire, all of their labs get silently reassigned to whatever project happened to be marked (N) at the time. That's certainly a boon for the scientist running that project, but a few years go by and you discover that the vital engine upgrade still isn't available…

I think that a nice refinement would be for the game to track the reason why the lab is unassigned. It could be a new lab, or it could be that the queue it was assigned to has been completed (both are mentioned in the post). However, it could also be due to retirement or untimely demise of the scientist. In that case, I think it would be better to either not reassign the labs or to automatically assign the next scientist of the appropriate speciality to the same project using the same number of labs.

This would not need to be state that is saved to the database, or even persisted from one increment to the next.
Title: Re: v1.12.0 Bugs Thread
Post by: Drakale on December 03, 2020, 08:49:10 AM
1.12 , Decimal separator is comma.

One of my NPR sent a pair of scout ships in my territories and started to send me the usual get out of here message. I eventually got annoyed and sent a boarding party to seize one of the offending scout, but I never officially declared war.  The boarding party managed to land with heavy losses and captured their ship(military scout). The funny thing is that they did not react and did not turn hostile, the relation status in the NPR window show 0. A few days later I fire a few missiles at another scout and then as expected they properly turned hostile and started to shoot my buoy I had around their planets.

TLDR, I do not think boarding ships is properly registered as an hostile act. I will test further if I find another NPR as I unfortunately saved after I went hostile. 

SJW: Fixed
Title: Re: v1.12.0 Bugs Thread
Post by: Norm49 on December 03, 2020, 02:52:15 PM
When creating a swarm in SM it doesn't take in consideration the planet you selected and all ways put it on the same planet.
Title: Re: v1.12.0 Bugs Thread
Post by: db48x on December 05, 2020, 12:30:20 AM
Steve, I don't know if you will count this as a bug, but measuring distances is a little bit annoying at present. The distance is easily obscured by other information on the map, and it's often hidden by the mouse cursor as well.

Could you move the label a bit further away from the cursor, and give it a different color scheme? If it were placed north of the cursor position, then it would be unlikely to ever be hidden by it. And if it were dark text on a light background, which was drawn to the screen last, then it would never be obscured by other text.

Thanks!
Title: Re: v1.12.0 Bugs Thread
Post by: Froggiest1982 on December 05, 2020, 01:58:18 AM
Steve, I don't know if you will count this as a bug, but measuring distances is a little bit annoying at present. The distance is easily obscured by other information on the map, and it's often hidden by the mouse cursor as well.

Could you move the label a bit further away from the cursor, and give it a different color scheme? If it were placed north of the cursor position, then it would be unlikely to ever be hidden by it. And if it were dark text on a light background, which was drawn to the screen last, then it would never be obscured by other text.

Thanks!

On this topic I am not sure if it was a bug which was fixed, me remembering wrong or even me not remembering at all.

However, there was a way for you to leave the measurements on the map till clicking again with the mouse, I have tried everything but seems like gone as an option.

Was I dreaming?
Title: Re: v1.12.0 Bugs Thread
Post by: Froggiest1982 on December 07, 2020, 05:43:17 PM
Not sure if WAI but in 1.12 shipyards are currently able to Repair ships of higher displacementent.

Refit and Scrap working as it should with only eligible classes able to be modified.

SJW: Fixed
Title: Re: v1.12.0 Bugs Thread
Post by: Froggiest1982 on December 07, 2020, 05:50:36 PM
This is a rare one.

1.12
native period

When a ship (usually in auto grav or geo) needs to transit on a Jump Point and face a Transit Failure due to cooldown the Orders Not Possible for no suitable destination triggers cancelling all standing orders.

Funny fact is that you first receive the Orders Not Possible and then the Transit Failure so that's why was hard to spot.

I think there should be a mechanism where before the Order is Cancelled due to this event the ship should try another time at least the transit.

No biggie, just a bit unpleasant as it can happen often when you have multiple ships moving in and out of the same system.
Title: Re: v1.12.0 Bugs Thread
Post by: nuclearslurpee on December 07, 2020, 06:46:19 PM
This is a rare one.

1.12
native period

When a ship (usually in auto grav or geo) needs to transit on a Jump Point and face a Transit Failure due to cooldown the Orders Not Possible for no suitable destination triggers cancelling all standing orders.

Funny fact is that you first receive the Orders Not Possible and then the Transit Failure so that's why was hard to spot.

I think there should be a mechanism where before the Order is Cancelled due to this event the ship should try another time at least the transit.

No biggie, just a bit unpleasant as it can happen often when you have multiple ships moving in and out of the same system.

Seconded. I usually see this happen when a ship jumps into a system without follow-up orders and I order it to jump back. If the jump cooldown is not finished it will have this error and forget its orders. The desired behavior would be for the ship to wait until it is able to execute the order and then try.
Title: Re: v1.12.0 Bugs Thread
Post by: nuclearslurpee on December 08, 2020, 01:05:48 AM
Actually less of a bug and more of an unexpected behavior that I strongly doubt is working as intended: After further testing, this is in fact a bug.

As part of my campaign setup I have six survey ships requiring rank 3 to command (rank 1 being the lowest). In the Commanders window, I have run an auto-assign by clicking the "Reassign Naval" button. Only four of my six survey ships receive a commander, despite the fact that my two rank-3 commanders with the highest Survey stats are not assigned to any ship at all.

I notice several things:

Thus, my conjecture is that the auto-assign is treating my survey ships as warships due to the missile launchers (or perhaps the boat bays?). This strikes me as undesired if not unintended behavior since the auto-assign considers survey ships a higher priority, thus it makes no sense that the algorithm to determine ship type ranks weapons/PPV higher than survey sensors. Certainly, I would think a player is more likely to design a survey ship with weapons than a warship with survey sensors, and the game should account for this!

I have previously noted a similar behavior with orbital mining platforms with an included cargo bay (for a mass driver), which is treated as a freighter and assigned a Logistics commander instead of a Mining commander, even though mining ships are supposed to be a higher priority than freighters. I wonder if the algorithm which determines the ship type for officer assignment is getting its assignments backwards?

----

ADDENDUM: I did a little bit of testing. I designed and built the following ship:
Quote
Galorfing C class Deep Space Survey Ship      27,881 tons       57 Crew       503.9 BP       TCS 558    TH 400    EM 0
717 km/s      Armour 1-81       Shields 0-0       HTK 13      Sensors 0/0/1/1      DCR 1      PPV 0
Maint Life 0.00 Years     MSP 11    AFR 6218%    IFR 86.4%    1YR 3,223    5YR 48,349    Max Repair 100.0000 MSP
Cargo 25,000    Cargo Shuttle Multiplier 5   
Captain of the List    Control Rating 1   BRG   
Intended Deployment Time: 3 months    Morale Check Required   

Commercial Inertial Fusion Drive  EP400.00 (1)    Power 400.0    Fuel Use 2.80%    Signature 400.00    Explosion 5%
Fuel Capacity 250,000 Litres    Range 57.7 billion km (931 days at full power)

Geological Survey Sensors (1)   1 Survey Points Per Hour
Gravitational Survey Sensors (1)   1 Survey Points Per Hour

This design is classed as a Military Vessel for maintenance purposes
The auto-assignment via "Reassign Naval" button gave this ship a commander with Crew Training 50 and Reaction 20 - not a Survey specialist.

However, I built the following ship:
Quote
Galorfing C-2 class Deep Space Survey Ship      2,201 tons       42 Crew       363.1 BP       TCS 44    TH 400    EM 0
9087 km/s      Armour 1-15       Shields 0-0       HTK 11      Sensors 0/0/1/1      DCR 1      PPV 0
Maint Life 2.12 Years     MSP 103    AFR 39%    IFR 0.5%    1YR 31    5YR 461    Max Repair 100.0000 MSP
Captain of the List    Control Rating 1   BRG   
Intended Deployment Time: 3 months    Morale Check Required   

Commercial Inertial Fusion Drive  EP400.00 (1)    Power 400.0    Fuel Use 2.80%    Signature 400.00    Explosion 5%
Fuel Capacity 250,000 Litres    Range 731.5 billion km (931 days at full power)

Geological Survey Sensors (1)   1 Survey Points Per Hour
Gravitational Survey Sensors (1)   1 Survey Points Per Hour

This design is classed as a Military Vessel for maintenance purposes
This ship class receives Survey-spec commanders as expected. The only difference in the designs was the cargo hold and shuttles in the former. There is no logical reason that a cargo hold would cause a survey ship to be reclassified as a warship (perhaps as a freighter though that would still be non-ideal). Thus, I now consider this a proper bug and not merely an undesired behavior.

SJW: The game assigns a main function to a ship class for auto-assignment. The code checked for weapons before checking for survey sensors. I've now changed it so a ship will be classed as a survey ship if the size of survey sensors exceeds the size of weapons. I've also added a line to the class summary so you can see the class function for assignment purposes.
Title: Re: v1.12.0 Bugs Thread
Post by: chokuto on December 08, 2020, 04:06:47 AM
Very minor issue that surprised me.
When loading a game with a Sol disaster (tested with cooling) the temperature of Earth is displayed without change of temperature. It fixes itself after a construction cycle.

To reproduce.
Create a new game with a Sol disaster of cooling
Process several construction cycles for the temperature of Earth to go down
Save the game and close Aurora. The temperature is correct in the database.
Open Aurora and load the game
Check the temperature of Earth and it displays the original temperature
Process a construction cycle and the temperature fixes itself
Title: Re: v1.12.0 Bugs Thread
Post by: Cosinus on December 08, 2020, 04:32:21 PM
I have noticed a bit of a UI bug in the "create research project" window:
To reproduce:
Expected behaviour: When selecting "Jump Drive" in the dropdown menu as long as not all required technologies are available, the "project name" field should be empty (or show something Jump Drive related, but not active sensors...) and the "Create" button should be greyed out.

Other Info: Version 1.12, dot separator, unmodded, no error message, etc.
Title: Re: v1.12.0 Bugs Thread
Post by: Cosinus on December 08, 2020, 04:36:58 PM
A small bug regarding medals:

When completing a research project, you only get awarded the "completed 1 research project" medal if it was the scientist's first research project. To reproduce this, start a new game, let a scientist research something. Then make medals for "complete 1 research project" and "complete 5 research projects". Then let the scientist complete 4 more projects. the scientist will get the "complete 5" projects medal, but not the "complete 1" medal.
Expected Behaviour: With every completed project, the game should check if the scientist is eligible for the "complete 1" or "complete 5" medal, not just after the first or fifth project. This probably also happens for other medals.

Other Info: Version 1.12, dot separator, unmodded, no error message, etc.
I initially noticed this after I imported medals from a medal collection from the forums here after the first research project was already completed.

PS: I'm sorry if these 2 bugs were reported before, but I did not read through all 16 pages in this bug thread. I've checked the resolved issues in the mechanics section though and did not find them there.
Title: Re: v1.12.0 Bugs Thread
Post by: Froggiest1982 on December 08, 2020, 05:01:07 PM
A small bug regarding medals:

When completing a research project, you only get awarded the "completed 1 research project" medal if it was the scientist's first research project. To reproduce this, start a new game, let a scientist research something. Then make medals for "complete 1 research project" and "complete 5 research projects". Then let the scientist complete 4 more projects. the scientist will get the "complete 5" projects medal, but not the "complete 1" medal.
Expected Behaviour: With every completed project, the game should check if the scientist is eligible for the "complete 1" or "complete 5" medal, not just after the first or fifth project. This probably also happens for other medals.

Other Info: Version 1.12, dot separator, unmodded, no error message, etc.
I initially noticed this after I imported medals from a medal collection from the forums here after the first research project was already completed.

PS: I'm sorry if these 2 bugs were reported before, but I did not read through all 16 pages in this bug thread. I've checked the resolved issues in the mechanics section though and did not find them there.

DISCLAIMER: I am not an expert and I am not a bug moderator, so please wait for an official answer from those who know better how the game is structured. My answers are based on my personal experience and a few peeks at the DB.

As you know the issue is that you create the medals afterward.

Probably the logic behind that is that when the new entry is created the game recognizes the first project when the count is at 1 (otherwise the line will simply be 0 or any other number but 1). When a new project is completed counter goes to 2 not triggering the condition set to 1. Obviously, once the count reaches 5 then it assigns the respective medal. I think if you let the scientist research 6 projects you will have the same issue with the 5 projects medal if created afterward. I am also sure your assumption is correct, this behavior is carried on all other medals.

Probably a way for you to fix this would be to allow Multiple so that the function code switches to COUNT from VALUE (not sure these are the real codes I just use excel mostly).

Also, if you do not want the medal then to be assigned all the times you can rever value back just unflagging the Multiple, or I am afraid you have to manually assign the first medal.

As much as I agree with you, I think this is more code related than an effective bug and I assume it could be quite hard to code it in a different way as the system should assign a date for medal creation and start counting values only from that point.

Probably you could make a request on the Suggestion section to change the behavior of medals conditions.
Title: Re: v1.12.0 Bugs Thread
Post by: Cosinus on December 08, 2020, 05:49:50 PM
Probably the logic behind that is that when the new entry is created the game recognizes the first project when the count is at 1 (otherwise the line will simply be 0 or any other number but 1)

[...]

I assume it could be quite hard to code it in a different way as the system should assign a date for medal creation and start counting values only from that point.

As I mentioned in the report, the fix is to change the condition to >=1 instead of ==1 on completion. There is no performance overhead and researchers should get the correct medals eventually.
What you are suggesting (separate counter after medal creation) would be a change from the current expected behaviour, that you could probably post in the suggestion forums. I am against it though. The current behaviour is fine, because I would expect a scientist who already completed 2 projects and then completes 3 more to get a medal for 5 completed projects.
Title: Re: v1.12.0 Bugs Thread
Post by: xenoscepter on December 08, 2020, 08:40:38 PM
Quote
- The function number
 --- N/A

 - The complete error text
 --- N/A

 - The window affected
 --- Commander Window

 - What you were doing at the time?
 --- Assigning Officers.

 - Conventional or TN start
 --- TN Start

 - Random or Real Stars
 --- Random

 - Is your decimal separator a comma?
 --- Decimal

 - Is the bug is easy to reproduce, intermittent or a one-off?
 --- Both very easy and quite simple to reproduce.

 - If this is a long campaign - say 75 years or longer - let me know the length of the campaign as well
 --- About 5 Years, not a long campaign at all.

  -  This bug affects commander assignment, specifically with regards to Commercial Ships. More specifically so, the assignment of commanders to say, Main Engineering, on those ships. I understand that Main Engineering has no effect on such a vessel, but regardless the module can be added and yet a commander cannot be assigned to it. I was planning to train up some officers on these ships. Database Attached.

EDIT: Seems I wasn't clear enough: You cannot assign Officers to a Main Engineering if that Main Engineering is on a Commercial Ship. I don't know if other commands are affected or not. I was using the LCDR, and it worked just fine for my other ships.
Title: Re: v1.12.0 Bugs Thread
Post by: db48x on December 09, 2020, 01:13:06 AM
  -  This bug affects commander assignment, specifically with regards to Commercial Ships. More specifically so, the assignment of commanders to say, Main Engineering, on those ships. I understand that Main Engineering has no effect on such a vessel, but regardless the module can be added and yet a commander cannot be assigned to it. I was planning to train up some officers on these ships. Database Attached.

I think you forgot to actually describe the bug.
Title: Re: v1.12.0 Bugs Thread
Post by: shock on December 09, 2020, 03:40:57 AM
I seem to be generating a crazy amount of resources by building a ships with the use components option (pre-built a bunch of engines in factories).  At first i thought it was just a display bug, but i am sure i haven't mined anywhere close to 7m gallicite.

https://imgur.com/AQEHHOF

Edit/Update: After the ships where complete ~2months, it was over 9m gallicite stockpiled



Conventional or TN start: TN start
Is the bug is easy to reproduce, intermittent or a one-off? Adding more ships to the queue increase the negative gallicite value displayed
If this is a long campaign - say 75 years or longer - let me know the length of the campaign as well - Currently 71 years in
Title: Re: v1.12.0 Bugs Thread
Post by: TheTalkingMeowth on December 09, 2020, 10:04:30 AM
I seem to be generating a crazy amount of resources by building a ships with the use components option (pre-built a bunch of engines in factories).  At first i thought it was just a display bug, but i am sure i haven't mined anywhere close to 7m gallicite.

https://imgur.com/AQEHHOF

Edit/Update: After the ships where complete ~2months, it was over 9m gallicite stockpiled



Conventional or TN start: TN start
Is the bug is easy to reproduce, intermittent or a one-off? Adding more ships to the queue increase the negative gallicite value displayed
If this is a long campaign - say 75 years or longer - let me know the length of the campaign as well - Currently 71 years in
Is your decimal separator a period or a comma? I can't tell from the screenshot (guess I need glasses).
Title: Re: v1.12.0 Bugs Thread
Post by: shock on December 09, 2020, 10:36:09 AM
Period, at least i think that's what it is when the text is so small you can't really tell them apart.  The OS is set for all US settings so i would assume it should be using a period.  I half didn't understand the whole decimal thing when making the first bug report, i assume its a European formatting style?
Title: Re: v1.12.0 Bugs Thread
Post by: shock on December 09, 2020, 11:19:20 AM
It might be the amount of resources magically produces is connected to how many components are stockpiled.  Its only at -300k now instead of over -1m.  Before i had hundreds of engines stockpiled, now im down to 75
Title: Re: v1.12.0 Bugs Thread
Post by: Potat999 on December 09, 2020, 11:20:38 PM
I designed long range jump survey vessel with a military jump drive.   

Since it is intended to be long range, I tossed on civilian grade engines for fuel economy.

I discovered that this vessel cannot jump itself, despite the military grade jump drive having sufficient mass.   It throws a transit failure interrupt stating that there are no jump drives capable of transferring the civilian engine vessels.   OK, perhaps I was mislead by the Wiki to believe that this would work when it is not intended to?

However - the plot thickens.

I discovered that although this vessel could not do a standard transit, it CAN do a squadron transit when joined by one of my other survey vessels which has military grade engines (and no jump drive of it's own).

I assume one of these behaviors is not intended - either it should be able to standard transit by itself, or it should not be able to squadron transit with another ship?

The ship in question:
Quote
Cypelus G class Long Range Survey Ship      9 992 tons       192 Crew       936. 1 BP       TCS 200    TH 500    EM 0
2502 km/s    JR 3-50      Armour 1-41       Shields 0-0       HTK 47      Sensors 24/18/2/0      DCR 1      PPV 0
Maint Life 4. 36 Years     MSP 10 058    AFR 799%    IFR 11. 1%    1YR 851    5YR 12 767    Max Repair 285. 8 MSP
Adept    Control Rating 1   BRG   
Intended Deployment Time: 36 months    Morale Check Required   

J10000(3-50) Military Jump Drive     Max Ship Size 10000 tons    Distance 50k km     Squadron Size 3

Knossos Aircraft Engine Co Commercial Ion Drive  EP250. 00 (2)    Power 500    Fuel Use 7. 07%    Signature 250    Explosion 5%
Fuel Capacity 500 000 Litres    Range 127. 4 billion km (589 days at full power)

EM Sensor EM3-18 (1)     Sensitivity 18     Detect Sig Strength 1000:  33. 5m km
Thermal Sensor TH3. 00-24. 00 (1)     Sensitivity 24     Detect Sig Strength 1000:  38. 7m km
Gravitational Survey Sensors (2)   2 Survey Points Per Hour

This design is classed as a Military Vessel for maintenance purposes
Title: Re: v1.12.0 Bugs Thread
Post by: Froggiest1982 on December 10, 2020, 12:34:01 AM
I designed long range jump survey vessel with a military jump drive.   

Since it is intended to be long range, I tossed on civilian grade engines for fuel economy.

I discovered that this vessel cannot jump itself, despite the military grade jump drive having sufficient mass.   It throws a transit failure interrupt stating that there are no jump drives capable of transferring the civilian engine vessels.   OK, perhaps I was mislead by the Wiki to believe that this would work when it is not intended to?

However - the plot thickens.

I discovered that although this vessel could not do a standard transit, it CAN do a squadron transit when joined by one of my other survey vessels which has military grade engines (and no jump drive of it's own).

I assume one of these behaviors is not intended - either it should be able to standard transit by itself, or it should not be able to squadron transit with another ship?

The ship in question:
Quote
Cypelus G class Long Range Survey Ship      9 992 tons       192 Crew       936. 1 BP       TCS 200    TH 500    EM 0
2502 km/s    JR 3-50      Armour 1-41       Shields 0-0       HTK 47      Sensors 24/18/2/0      DCR 1      PPV 0
Maint Life 4. 36 Years     MSP 10 058    AFR 799%    IFR 11. 1%    1YR 851    5YR 12 767    Max Repair 285. 8 MSP
Adept    Control Rating 1   BRG   
Intended Deployment Time: 36 months    Morale Check Required   

J10000(3-50) Military Jump Drive     Max Ship Size 10000 tons    Distance 50k km     Squadron Size 3

Knossos Aircraft Engine Co Commercial Ion Drive  EP250. 00 (2)    Power 500    Fuel Use 7. 07%    Signature 250    Explosion 5%
Fuel Capacity 500 000 Litres    Range 127. 4 billion km (589 days at full power)

EM Sensor EM3-18 (1)     Sensitivity 18     Detect Sig Strength 1000:  33. 5m km
Thermal Sensor TH3. 00-24. 00 (1)     Sensitivity 24     Detect Sig Strength 1000:  38. 7m km
Gravitational Survey Sensors (2)   2 Survey Points Per Hour

This design is classed as a Military Vessel for maintenance purposes

100% bug, well done in spotting it.
Title: Re: v1.12.0 Bugs Thread
Post by: QuakeIV on December 10, 2020, 01:06:08 AM
Oh, is the military jump drive not being able to transit civilian engines really a bug?  Thank god, I was really hating that.
Title: Re: v1.12.0 Bugs Thread
Post by: Kylemmie on December 10, 2020, 09:36:17 AM
Oh, is the military jump drive not being able to transit civilian engines really a bug?  Thank god, I was really hating that.

Double check that - I think the Bug is the multiple transit part. If I recall correctly, C# has a change where Jump Drives can only jump ships with similar drives. A Mil JD should not be able to jump a ship with Civ Engine I believe?
Title: Re: v1.12.0 Bugs Thread
Post by: Froggiest1982 on December 10, 2020, 12:18:54 PM
Oh, is the military jump drive not being able to transit civilian engines really a bug?  Thank god, I was really hating that.

Double check that - I think the Bug is the multiple transit part. If I recall correctly, C# has a change where Jump Drives can only jump ships with similar drives. A Mil JD should not be able to jump a ship with Civ Engine I believe?

Correct.
Title: Re: v1.12.0 Bugs Thread
Post by: Garfunkel on December 10, 2020, 12:21:07 PM
Yes, that's a change from VB6 to C# - military JD only jumps military engines and commercial JD only jumps commercial engines.
Title: Re: v1.12.0 Bugs Thread
Post by: Cosinus on December 10, 2020, 02:47:15 PM
The function number: 730, 722
The complete error text: 1.12. Object reference not set to an object (both)
The window affected: Tactical view
What you were doing at the time: These messages popped up seemingly randomly directly one after the other while advancing time. I did not notice anything different after the bug happened and nothing noteworthy happened before and after. The bug did not happen again so far for at least 1 in-game year.
Conventional or TN start: TN
Random or Real Stars: Random
Is your decimal separator a comma?: no
Is the bug is easy to reproduce, intermittent or a one-off?: one off, was not able to reproduce.
If this is a long campaign - say 75 years or longer - let me know the length of the campaign as well: ~24 years. This game has 4 NPRs.

I will attach a DB from the moment a few in-game days after the bug, because even though the bug did not have any noticeable consequences (so far) and is not reproducible by me, maybe other people have encountered the same bug and Steve can figure out what it is from the DB. Also Steve knows what 730 actually means.
Title: Re: v1.12.0 Bugs Thread
Post by: Froggiest1982 on December 10, 2020, 03:56:23 PM
The function number: 730, 722
The complete error text: 1.12. Object reference not set to an object (both)
The window affected: Tactical view
What you were doing at the time: These messages popped up seemingly randomly directly one after the other while advancing time. I did not notice anything different after the bug happened and nothing noteworthy happened before and after. The bug did not happen again so far for at least 1 in-game year.
Conventional or TN start: TN
Random or Real Stars: Random
Is your decimal separator a comma?: no
Is the bug is easy to reproduce, intermittent or a one-off?: one off, was not able to reproduce.
If this is a long campaign - say 75 years or longer - let me know the length of the campaign as well: ~24 years. This game has 4 NPRs.

I will attach a DB from the moment a few in-game days after the bug, because even though the bug did not have any noticeable consequences (so far) and is not reproducible by me, maybe other people have encountered the same bug and Steve can figure out what it is from the DB. Also Steve knows what 730 actually means.

Do you have any fleet set in auto explore?

If so it may be that.

It has been fixed for 1.13 release
Title: Re: v1.12.0 Bugs Thread
Post by: db48x on December 10, 2020, 04:09:53 PM
I recently encountered two bugs at once:
(http://db48x.net/Aurora/two%20bugs.png)

The first is most obvious: the MessageBox that has popped up with the name of a ship (or fleet) in it. I don't know the exact trigger for this; it certainly does not happen every time a ship goes through a jump point, or even every time a new system is discovered. However, it did happen while the named ship (or fleet) was discovering a new system, so it does seem related to that event, or to generating the new system.

The second bug is more subtle. Behind the MessageBox, the tactical map is drawn incorrectly. In fact, it appears that the MessageBox is interrupting a process that redraws the tactical map multiple times with different data.

First, the system that the ship is leaving is being drawn, rather than the system that the ship is discovering. Second, the position of the ship is incorrect; it should be on top of the jump point. Perhaps this position is stale, and comes from the previous sub-pulse. This ship just launched those two missiles, then outraced them to the jump point (they're obsolete first-generation missiles; I must have made too many), so the ship's position has definitely been updated at least once since the start of the turn. Lastly, the lines that indicate motion are drawn incorrectly. The ship and missiles are actually moving SSW, not NNE. It looks like this is happening because the start of the line is drawn in the coordinate system of the destination star system; the jump point in the destination star system is due south of the star, and the start of that line is due south of the star in this system (it's behind the MessageBox, of course). Likewise, the missiles moved from a point to the NNE of the star in this system, and the start of their line is to the NNE of this star but at the wrong distance from the center because the scale is different.

It looks like some of the flickering during window updates is happening because the window is drawn and cleared multiple times. I don't know the Windows API very well, but I believe that you should be inhibiting paint events while updating the window. Even better I think you should use double-buffering, at least for the graphical elements if not the UI widgets.
Title: Re: v1.12.0 Bugs Thread
Post by: Cosinus on December 11, 2020, 03:08:11 AM
The function number: 730, 722
The complete error text: 1.12. Object reference not set to an object (both)
The window affected: Tactical view
What you were doing at the time: These messages popped up seemingly randomly directly one after the other while advancing time. I did not notice anything different after the bug happened and nothing noteworthy happened before and after. The bug did not happen again so far for at least 1 in-game year.
Conventional or TN start: TN
Random or Real Stars: Random
Is your decimal separator a comma?: no
Is the bug is easy to reproduce, intermittent or a one-off?: one off, was not able to reproduce.
If this is a long campaign - say 75 years or longer - let me know the length of the campaign as well: ~24 years. This game has 4 NPRs.

I will attach a DB from the moment a few in-game days after the bug, because even though the bug did not have any noticeable consequences (so far) and is not reproducible by me, maybe other people have encountered the same bug and Steve can figure out what it is from the DB. Also Steve knows what 730 actually means.

Do you have any fleet set in auto explore?

If so it may be that.

It has been fixed for 1.13 release

No, I don't have fleets set to Autoexplore, only to auto geosurvey and gravsurvey. The AI might have, though.
Title: Re: v1.12.0 Bugs Thread
Post by: db48x on December 11, 2020, 04:18:18 AM
The function number: 730, 722

Do you have any fleet set in auto explore?

If so it may be that.

It has been fixed for 1.13 release

No, I don't have fleets set to Autoexplore, only to auto geosurvey and gravsurvey. The AI might have, though.

That error is caused by the new Refuel, Resupply, and Overhaul at Colony conditional order. It causes the ship to fail to refuel and resupply unless it's already in a system with fuel and supplies, but it still manages to go and get overhauled.
Title: Re: v1.12.0 Bugs Thread
Post by: Froggiest1982 on December 11, 2020, 04:18:33 AM
The function number: 730, 722
The complete error text: 1.12. Object reference not set to an object (both)
The window affected: Tactical view
What you were doing at the time: These messages popped up seemingly randomly directly one after the other while advancing time. I did not notice anything different after the bug happened and nothing noteworthy happened before and after. The bug did not happen again so far for at least 1 in-game year.
Conventional or TN start: TN
Random or Real Stars: Random
Is your decimal separator a comma?: no
Is the bug is easy to reproduce, intermittent or a one-off?: one off, was not able to reproduce.
If this is a long campaign - say 75 years or longer - let me know the length of the campaign as well: ~24 years. This game has 4 NPRs.

I will attach a DB from the moment a few in-game days after the bug, because even though the bug did not have any noticeable consequences (so far) and is not reproducible by me, maybe other people have encountered the same bug and Steve can figure out what it is from the DB. Also Steve knows what 730 actually means.

Do you have any fleet set in auto explore?

If so it may be that.

It has been fixed for 1.13 release

No, I don't have fleets set to Autoexplore, only to auto geosurvey and gravsurvey. The AI might have, though.

Sorry my bad, I meant grav and geo. Yes it is a known bug and it has been fixed fir 1.13, you can read it on the changelog.

No worries the game will function perfectly despite the errors that will pop up when a ship triggers the extended deployment condition and needs to move into another system to overhaul.
Title: Re: v1.12.0 Bugs Thread
Post by: Cosinus on December 11, 2020, 08:16:59 AM
Bug: Refuelling tankers with tankers is nonfunctional. This makes e.g. hybrid tankers/freighters very hard to manage.

Steps to reproduce: Make 2 ship classes with lets say 1Ml fuel capacity and minimum fuel 50%. Flag both as tankers and equip both with refuelling systems. Have a fleet consisting of class A ships and have them run low on fuel, e.g. 10%. Have a class B fleet with almost full fuel, e.g. 95%. This means, the A fleet has less than minimum fuel while B has more than the minimum.
Set the B fleet to join and refuel A. -> They successfully join, but fuel levels do not change, even after waiting (as refuelling takes time).
Alternatively, set A to "refuel from stationary tankers" from B. This also does not change fuel levels even though the order is completed successfully.

Expected behaviour. In both cases the B Fleet should give fuel to A until B is at their minimum fuel or until A is full, whichever comes first.

For everyone experiencing this bug: There is a workaround. If you join A and B, then create a new Waypoint right next to them and set them to fly to the waypoint and "refuel from own tankers" this works. However it does not distribute the fuel equally among A ships and also does not work if A ran out of fuel. In this case the fleet is stuck until you tow it back.
Title: Re: v1.12.0 Bugs Thread
Post by: vorpal+5 on December 12, 2020, 02:32:16 AM
In my experience (because I refilled tankers with other tankers), it works if you use 'refuel own fleet tankers'. Is that your issue?

I have a bug to report for tankers though ...

An immobile tanker but with an order with delay (like move in 2 days) is not consider immobile and won't refill anything. It means you can't automate picking up stranded ships, wait one day but with an order, then move them back.

SJW: Working as intended. If a fleet has orders, it isn't 'stationary'. I don't want to write the large amount of code required to check if a ship is actually stationary throughout the increment.
Title: Re: v1.12.0 Bugs Thread
Post by: pwhk on December 12, 2020, 04:06:19 AM
I encountered bug with Unload All installations command. If your freighter fleet carries more than one type of installation and you give it command to unload all, only first type of installation is unloaded.

It can be easily reproduced by loading two installations, for example mine and fuel refinery. Then give command to unload all and only first installation on the list is unloaded. I reproduced it several times.

TN Start
Real Stars
Period decimal separator

I am pretty sure I have also encountered this issue on v1.12.0. (Conventional start, Real stars, period decimal separator)
Title: Re: v1.12.0 Bugs Thread
Post by: pwhk on December 12, 2020, 04:21:13 AM
v1.12.0, conventional start, real stars, period decimal separator.

1. Create two classes where class A is compatible to class B
2. Refit a shipyard to class A
3. Build class B at the shipyard
4. Design of Class B is not locked properly and can be changed (without spacemaster mode)

p.s. I remembered that this issue happened before and fixed before, and it returns in v1.12.0. Software are hard  ;D

SJW: Fixed
Title: Re: v1.12.0 Bugs Thread
Post by: Cosinus on December 12, 2020, 07:58:28 AM
In my experience (because I refilled tankers with other tankers), it works if you use 'refuel own fleet tankers'. Is that your issue?

No, the issue is that the other 2 orders provided in my report are not working. As I said, "refuel own fleet tankers" works for me.
Title: Re: v1.12.0 Bugs Thread
Post by: pwhk on December 12, 2020, 08:50:45 AM
Not sure if intended. If using "Automated assignment for colony" for assigning governors, those assignments never appear in Event logs, unlike ship commander assignments.

SJW: Fixed
Title: Re: v1.12.0 Bugs Thread
Post by: hammer58 on December 13, 2020, 09:55:03 AM
V1. 12

Using an AWACS ship design to provide targeting info to missile ships without any active sensors on the missile ships, will not allow the missile ships to target any enemy fleets or incoming missiles. 

None of my missile ships will fire on or lock a target into the fire control system. 

I have tried to use the AWACS inside the same fleet as the missile ships and also in a separate fleet in a stand off position.  In both cases I was not able to get a target lock on any target.  The anti missiles did not fire in PD mode either. 

This used to work in the VB version.
Title: Re: v1.12.0 Bugs Thread
Post by: Kristover on December 13, 2020, 10:20:51 AM
That’s weird - I totally just fought an engagement that other day where an AWACS with active sensors totally lit up a target for an alpha strike from a couple of squadrons of missile boats.  Frankly my whole fleet doctrine is set up around AWACs and Fleet Sensor Ships painting targets for shooters.  The only capital ships I have that have large active sensors - all my warships have the 50 ton active/thermal/EM sensors I put on all vessels - are my carriers.
Title: Re: v1.12.0 Bugs Thread
Post by: hammer58 on December 13, 2020, 10:52:12 AM
How? I can not get any target lock. My Beam fire control will lock onto enemy ships. But the missile fire control will not. At any range. I am factoring in ecm.
The enemy ships have a 40% degrade in ecm range. My Missile fire control range is 109m/km. I should be able to target the enemy ships at a range of about 60m/km. But even at 20m/km I still can not get a target lock. And the enemy missiles I can track out to 5m/km. My anti missile fire control range is 110m/km. At 5m/km range my pd should be targeting and firing. But they do not. I have tried both auto target and manual targeting. Neither work.
Title: Re: v1.12.0 Bugs Thread
Post by: Droll on December 13, 2020, 12:00:22 PM
How? I can not get any target lock. My Beam fire control will lock onto enemy ships. But the missile fire control will not. At any range. I am factoring in ecm.
The enemy ships have a 40% degrade in ecm range. My Missile fire control range is 109m/km. I should be able to target the enemy ships at a range of about 60m/km. But even at 20m/km I still can not get a target lock. And the enemy missiles I can track out to 5m/km. My anti missile fire control range is 110m/km. At 5m/km range my pd should be targeting and firing. But they do not. I have tried both auto target and manual targeting. Neither work.

Do you happen to have your DB? Any save state during the relevant combat would be good.

Just zip up your AuroraDB.db file so that someone can take a look at what the situation looks like.
Title: Re: v1.12.0 Bugs Thread
Post by: hammer58 on December 13, 2020, 12:05:01 PM
How? I can not get any target lock. My Beam fire control will lock onto enemy ships. But the missile fire control will not. At any range. I am factoring in ecm.
The enemy ships have a 40% degrade in ecm range. My Missile fire control range is 109m/km. I should be able to target the enemy ships at a range of about 60m/km. But even at 20m/km I still can not get a target lock. And the enemy missiles I can track out to 5m/km. My anti missile fire control range is 110m/km. At 5m/km range my pd should be targeting and firing. But they do not. I have tried both auto target and manual targeting. Neither work.

Do you happen to have your DB? Any save state during the relevant combat would be good.

Well you have to tell me how to do this. I assume you want me to upload my save game file? I do have a save exactly at this point.
So how exactly do I upload the file and where do I find it?
Just zip up your AuroraDB.db file so that someone can take a look at what the situation looks like.
Title: Re: v1.12.0 Bugs Thread
Post by: hammer58 on December 13, 2020, 12:50:45 PM
Never mind I got it to work. I did not know I had to click and drag the target to the fire control.
Title: Re: v1.12.0 Bugs Thread
Post by: TheBawkHawk on December 15, 2020, 03:02:57 PM
I've been stuck in 2 hour turns for a while now, while trying to do 5 day increments. This is on random stars, period decimal separator, TN start, about 65 years into game. I thought it was just the NPRs playing nuclear rocket tag across the galaxy, until it continued for over 5 ingame days. I tried a 30 day increment, and time advanced for six hours. It seems that something is causing an interrupt every sub-pulse, and when I checked in the database log to see what was happening, I found a few NPR ships trying and failing to complete standing orders, as well as a few ship detections every increment. I turned off detection, but that didn't solve the increments.

I saw a post earlier on similar to this one where it was NPR civilians trying to load cargo, but these are military vessels and what seem to be construction ships.

Off-Topic: show
GE Ajonpaa 002 is unable to carry out its primary standing order: Refuel from Colony or Hub (All)
Stabilisation Squadron 001 is unable to carry out its primary standing order: Build Jump Gate at Nearest Jump Point
Stabilisation Squadron 003 is unable to carry out its primary standing order: Build Jump Gate at Nearest Jump Point
CLE Aura II 025 is unable to carry out its primary standing order: Join Operational Group
CLE Aura II 026 is unable to carry out its primary standing order: Join Operational Group
CLE Aura II 027 is unable to carry out its primary standing order: Join Operational Group
CLE Aura II 028 is unable to carry out its primary standing order: Join Operational Group
CLE Aura II 029 is unable to carry out its primary standing order: Join Operational Group
CLE Aura II 030 is unable to carry out its primary standing order: Join Operational Group
CLE Aura II 031 is unable to carry out its primary standing order: Join Operational Group
CLE Aura II 032 is unable to carry out its primary standing order: Join Operational Group
CJ Harjus III 001 is unable to carry out its primary standing order: Join Operational Group
CJ Harjus III 002 is unable to carry out its primary standing order: Join Operational Group
CJ Harjus III 003 is unable to carry out its primary standing order: Join Operational Group
CJ Harjus III 004 is unable to carry out its primary standing order: Join Operational Group
CJ Harjus III 005 is unable to carry out its primary standing order: Join Operational Group
CJ Harjus III 006 is unable to carry out its primary standing order: Join Operational Group
CJ Harjus III 007 is unable to carry out its primary standing order: Join Operational Group
CJ Harjus III 008 is unable to carry out its primary standing order: Join Operational Group
GE Alfheim 001 is unable to carry out its primary standing order: Refuel from Colony or Hub (All)
GE Alfheim 002 is unable to carry out its primary standing order: Refuel from Colony or Hub (All)
SS Alfhild 001 is unable to carry out its primary standing order: Survey Next Three System Locations
Stabilisation Squadron - Beam Escort 001 is unable to carry out its primary standing order: Build Jump Gate at Nearest Jump Point
Stabilisation Squadron - Beam Escort 002 is unable to carry out its primary standing order: Build Jump Gate at Nearest Jump Point
SS Binjai 001 is unable to carry out its primary standing order: Refuel from Colony or Hub (All)


I can attach the database if that helps.
Title: Re: v1.12.0 Bugs Thread
Post by: Froggiest1982 on December 15, 2020, 03:08:02 PM
I've been stuck in 2 hour turns for a while now, while trying to do 5 day increments. This is on random stars, period decimal separator, TN start, about 65 years into game. I thought it was just the NPRs playing nuclear rocket tag across the galaxy, until it continued for over 5 ingame days. I tried a 30 day increment, and time advanced for six hours. It seems that something is causing an interrupt every sub-pulse, and when I checked in the database log to see what was happening, I found a few NPR ships trying and failing to complete standing orders, as well as a few ship detections every increment. I turned off detection, but that didn't solve the increments.

I saw a post earlier on similar to this one where it was NPR civilians trying to load cargo, but these are military vessels and what seem to be construction ships.

Off-Topic: show
GE Ajonpaa 002 is unable to carry out its primary standing order: Refuel from Colony or Hub (All)
Stabilisation Squadron 001 is unable to carry out its primary standing order: Build Jump Gate at Nearest Jump Point
Stabilisation Squadron 003 is unable to carry out its primary standing order: Build Jump Gate at Nearest Jump Point
CLE Aura II 025 is unable to carry out its primary standing order: Join Operational Group
CLE Aura II 026 is unable to carry out its primary standing order: Join Operational Group
CLE Aura II 027 is unable to carry out its primary standing order: Join Operational Group
CLE Aura II 028 is unable to carry out its primary standing order: Join Operational Group
CLE Aura II 029 is unable to carry out its primary standing order: Join Operational Group
CLE Aura II 030 is unable to carry out its primary standing order: Join Operational Group
CLE Aura II 031 is unable to carry out its primary standing order: Join Operational Group
CLE Aura II 032 is unable to carry out its primary standing order: Join Operational Group
CJ Harjus III 001 is unable to carry out its primary standing order: Join Operational Group
CJ Harjus III 002 is unable to carry out its primary standing order: Join Operational Group
CJ Harjus III 003 is unable to carry out its primary standing order: Join Operational Group
CJ Harjus III 004 is unable to carry out its primary standing order: Join Operational Group
CJ Harjus III 005 is unable to carry out its primary standing order: Join Operational Group
CJ Harjus III 006 is unable to carry out its primary standing order: Join Operational Group
CJ Harjus III 007 is unable to carry out its primary standing order: Join Operational Group
CJ Harjus III 008 is unable to carry out its primary standing order: Join Operational Group
GE Alfheim 001 is unable to carry out its primary standing order: Refuel from Colony or Hub (All)
GE Alfheim 002 is unable to carry out its primary standing order: Refuel from Colony or Hub (All)
SS Alfhild 001 is unable to carry out its primary standing order: Survey Next Three System Locations
Stabilisation Squadron - Beam Escort 001 is unable to carry out its primary standing order: Build Jump Gate at Nearest Jump Point
Stabilisation Squadron - Beam Escort 002 is unable to carry out its primary standing order: Build Jump Gate at Nearest Jump Point
SS Binjai 001 is unable to carry out its primary standing order: Refuel from Colony or Hub (All)


I can attach the database if that helps.

Do NPR failed orders contribute to interrupts? Sorry but I still don't know after 10 years! :D

Have you checked if you have any MFCs on by mistake?

That was the cause of many issues of the same kind

SJW: No, they don't cause interrupts. There are very few AI interrupts and they are related to combat, the detection of hostile contacts and the detection of new jump points.
Title: Re: v1.12.0 Bugs Thread
Post by: TheBawkHawk on December 15, 2020, 03:53:51 PM
Do NPR failed orders contribute to interrupts? Sorry but I still don't know after 10 years! :D

Have you checked if you have any MFCs on by mistake?

That was the cause of many issues of the same kind
There are no MFC's enabled, none of mine at least. I went through and set all of them to off just to make sure, but that didn't fix it
Title: Re: v1.12.0 Bugs Thread
Post by: Alno on December 16, 2020, 06:34:25 AM
Hey Everyone,

I'm not sure if this is a bug or intended, so i wanted to make sure.       
I just installed Aurora C# for the first time and my research rate seems extremely high compared to what i remember from the VB version.  Just a single research lab with 0% bonus produces 20k RP per year.  I can complete the most expensive research available to me in 6 months with a single lab without any bonuses.       

I installed 1. 5. 1 Full version, followed by the 1. 12. 0 patch.  The only mod i use is the interface colour mod and i get the same result without it.       
To me it seems like the number in the research speed option is not a percentage, which is how i interpreted the tooltip, but a straight multiplier to the research speed.  Now I'm wondering if the same is true for the other speed options or not and my game just runs on x100 speed in general.   
I also only got 80 instant research points, which seems weird.  But I can still instant a 10k research with them.   

BTW, i love the spell check function of this forum.  I do not love that it adds spaces after every period every time i edit.   

Edit: Ok, i reinstalled the game and just running the mod at all seems to have broken something.  Research rates are back to normal.  In that case my "bug" is that the game seems to import the time and date formating of the system it's run on.  And on my german Windows 8. 1, that is to long to fit into its column in the research window.  I know exactly on what day of the week my research finishes but not what year.  The only reason i ran the mod was to fix this. 

Edit2: After some more research, the problem with the date format was that the game imports the long date format and not the short one.  I changed it to use a format without the day of the week and it fits now.  Also, thank you to Cosinus for the hint about the decimal separator.
Title: Re: v1.12.0 Bugs Thread
Post by: Cosinus on December 16, 2020, 06:45:19 AM
Hey Everyone,
[...]

You should set your decimal separator to a dot ('.') in your OS settings. Otherwise Aurora does not work properly. You will need to start a new save game as well unfortunately.
Title: Re: v1.12.0 Bugs Thread
Post by: Alno on December 16, 2020, 07:38:55 AM
Ok, in conclusion:
Changing the "long date" format of my OS fixed the research finish dates not fitting.     
And the OS decimal separator must be a dot when creating a new game, or things break.  It was not the mod that broke things afterall.  Also, don't forget to reboot after changing the decimal separator, or you will sit there like a moron and wonder why your research rates are still nuts.  Not gonna name anyone here.  *sideeyes mirror*
Title: Re: v1.12.0 Bugs Thread
Post by: pwhk on December 16, 2020, 07:41:14 AM
I've been stuck in 2 hour turns for a while now, while trying to do 5 day increments. This is on random stars, period decimal separator, TN start, about 65 years into game. I thought it was just the NPRs playing nuclear rocket tag across the galaxy, until it continued for over 5 ingame days. I tried a 30 day increment, and time advanced for six hours. It seems that something is causing an interrupt every sub-pulse, and when I checked in the database log to see what was happening, I found a few NPR ships trying and failing to complete standing orders, as well as a few ship detections every increment. I turned off detection, but that didn't solve the increments.

(snip)

I can confirm I am also getting a similar issue, on a conventional start with real stars, 70 years in, continued for multiple in-game years. One save file also getting a lot of "Out of fuel" messages from NPR ships. Also have database handy.
Title: Re: v1.12.0 Bugs Thread
Post by: Potat999 on December 16, 2020, 09:56:11 PM
I'm playing a game with two player races, which have neutral but overall positive relations (~500) and a trade agreement.

I just finished researching Microwave Focusing 5 with Race #1. 
Race#2 received Microwave Focusing Technology 1 from Race #1.

These two races do not have a research data agreement.  It shows as "Not Available" on both races. 

Is this an intended feature - ideas slowly spreading between friendly races via trade?  Or just a bug that should not have happened without research data sharing?

SJW: That is working as intended. Trade relations will result in the transfer of tech systems that are very low level compared to your current tech.
Title: Re: v1.12.0 Bugs Thread
Post by: nuclearslurpee on December 17, 2020, 12:35:12 AM
I'm playing a game with two player races, which have neutral but overall positive relations (~500) and a trade agreement.

I just finished researching Microwave Focusing 5 with Race #1. 
Race#2 received Microwave Focusing Technology 1 from Race #1.

These two races do not have a research data agreement.  It shows as "Not Available" on both races. 

Is this an intended feature - ideas slowly spreading between friendly races via trade?  Or just a bug that should not have happened without research data sharing?

Someone else who knows better can chime in, but I remember as far back as VB6 there was a mechanic for which races that were far behind in the tech tree could passively receive outdated techs from other races just by being generally aware of each other. The case I remember is a player-created race spawned in the middle of the game received low-tier armor tech from another player race that had a higher level of armor tech. I don't know the detailed mechanics but it sounds like this is what happened.
Title: Re: v1.12.0 Bugs Thread
Post by: pwhk on December 17, 2020, 08:54:41 AM
I've been stuck in 2 hour turns for a while now, while trying to do 5 day increments. This is on random stars, period decimal separator, TN start, about 65 years into game. I thought it was just the NPRs playing nuclear rocket tag across the galaxy, until it continued for over 5 ingame days. I tried a 30 day increment, and time advanced for six hours. It seems that something is causing an interrupt every sub-pulse, and when I checked in the database log to see what was happening, I found a few NPR ships trying and failing to complete standing orders, as well as a few ship detections every increment. I turned off detection, but that didn't solve the increments.

(snip)

I can confirm I am also getting a similar issue, on a conventional start with real stars, 70 years in, continued for multiple in-game years. One save file also getting a lot of "Out of fuel" messages from NPR ships. Also have database handy.

Fed up with this, I decided to try investigate myself ;)

Looks like some NPR fleets (which is construction fleet) keep jumping back and forth at a jump point, keep triggering hostile contacts for another NPR. The other NPR, not to be outdone by hostilities, also have another fleet jumping back and forth at the same jump point.
 
I edited the DB to take control, SM delete the offending ships, and put control back (edit DB again). This appears to fix the issue.
Title: Re: v1.12.0 Bugs Thread
Post by: Froggiest1982 on December 17, 2020, 01:46:41 PM
I've been stuck in 2 hour turns for a while now, while trying to do 5 day increments. This is on random stars, period decimal separator, TN start, about 65 years into game. I thought it was just the NPRs playing nuclear rocket tag across the galaxy, until it continued for over 5 ingame days. I tried a 30 day increment, and time advanced for six hours. It seems that something is causing an interrupt every sub-pulse, and when I checked in the database log to see what was happening, I found a few NPR ships trying and failing to complete standing orders, as well as a few ship detections every increment. I turned off detection, but that didn't solve the increments.

(snip)

I can confirm I am also getting a similar issue, on a conventional start with real stars, 70 years in, continued for multiple in-game years. One save file also getting a lot of "Out of fuel" messages from NPR ships. Also have database handy.

Fed up with this, I decided to try investigate myself ;)

Looks like some NPR fleets (which is construction fleet) keep jumping back and forth at a jump point, keep triggering hostile contacts for another NPR. The other NPR, not to be outdone by hostilities, also have another fleet jumping back and forth at the same jump point.
 
I edited the DB to take control, SM delete the offending ships, and put control back (edit DB again). This appears to fix the issue.

The peeking NPR affects players as well. Not sure if Steve was doing something about it as I remember sever posts talking about the event.

Next time you may download this tool: http://aurora2.pentarch.org/index.php?topic=11780.0 and deactivate the issue. Just remember to keep an eye on your event log!
Title: Re: v1.12.0 Bugs Thread
Post by: TheBawkHawk on December 17, 2020, 05:46:23 PM
I did a bit further digging inspired by your post, and I examined the last several increments. Turns out not only were these military ships unable to complete their orders, there were also some survey ships bouncing back and forth at a jump point like you had suggested. In addition, there were also at least 4 NPR civilian ships unable to load cargo, because they were already full. How all of this happened at the same time I have no idea, but the issue has been solved. I had to take manual control of the NPR's like you said, and delete the civilians and the survey ships.

So the issue I had posted earlier is solved, and I believe that Steve said he has already found a workaround for the civilian one, I'm not sure about the ships bouncing back and forth at jump points though. Although, the NPR ships unable to complete their orders haven't done anything for a while, so it would appear that something might be up with the NPR order assignments.
Title: Re: v1.12.0 Bugs Thread
Post by: Cosinus on December 18, 2020, 04:17:31 PM
The function number: #787
The complete error text:  The sequence contains no elements (roughly translated)
The window affected: tactical view.
What you were doing at the time: Advancing time in 2h increments, which seems to be a common problem among several posters above (see e.g. reply #271 here)
Conventional or TN start: TN
Random or Real Stars: random
Is your decimal separator a comma?: dot
Is the bug is easy to reproduce, intermittent or a one-off?: reproducible with the attached DB
If this is a long campaign - say 75 years or longer - let me know the length of the campaign as well: roughly 50 years

More info: This is a game with several nearby NPRs which had a large fight just 1 year before this DB date (see "Yalta" system). After that the game only incremented in 2h increments and ran REALLY slow, to the point where it was basically impossible to play (several minutes for 1 in-game day) and I just let it run in the background while playing Slay the Spire. After roughly 1 in-game year of these 2h increments the game showed me this error and incredibly after that, the game started to run a lot faster and use 5 day increments again. I'm curious for the reason. Fortunately I had a savefile from just before the bug occurred (thanks autobackup feature).
To reproduce: Load the attached DB, select autoturns and 5 day increments and let it run for a while. After a few days (in game date 25.10.2052) the error should happen. I reproduced this once (from 1 attempt) and interestingly the error occurred on the 26th

EDIT: After writing all of this I can't seem to post it. I get redirected either to "create new post" or to "500 internal server error". I try to post it without the DB now, to see if that works.
EDIT2: The attachments seems to be the issue. Maybe the forum is broken or something. Anyway here is the DB: https://drive.google.com/file/d/1n5YjyD1R0cOWSVG6vEaAYQ5r5WH21Ush/view?usp=sharing
Title: Re: v1.12.0 Bugs Thread
Post by: Droll on December 18, 2020, 04:24:44 PM
The function number: #787
The complete error text:  The sequence contains no elements (roughly translated)
The window affected: tactical view.
What you were doing at the time: Advancing time in 2h increments, which seems to be a common problem among several posters above (see e.g. reply #271 here)
Conventional or TN start: TN
Random or Real Stars: random
Is your decimal separator a comma?: dot
Is the bug is easy to reproduce, intermittent or a one-off?: reproducible with the attached DB
If this is a long campaign - say 75 years or longer - let me know the length of the campaign as well: roughly 50 years

More info: This is a game with several nearby NPRs which had a large fight just 1 year before this DB date (see "Yalta" system). After that the game only incremented in 2h increments and ran REALLY slow, to the point where it was basically impossible to play (several minutes for 1 in-game day) and I just let it run in the background while playing Slay the Spire. After roughly 1 in-game year of these 2h increments the game showed me this error and incredibly after that, the game started to run a lot faster and use 5 day increments again. I'm curious for the reason. Fortunately I had a savefile from just before the bug occurred (thanks autobackup feature).
To reproduce: Load the attached DB, select autoturns and 5 day increments and let it run for a while. After a few days (in game date 25.10.2052) the error should happen. I reproduced this once (from 1 attempt) and interestingly the error occurred on the 26th

EDIT: After writing all of this I can't seem to post it. I get redirected either to "create new post" or to "500 internal server error". I try to post it without the DB now, to see if that works.
EDIT2: The attachments seems to be the issue. Maybe the forum is broken or something. Anyway here is the DB: https://drive.google.com/file/d/1n5YjyD1R0cOWSVG6vEaAYQ5r5WH21Ush/view?usp=sharing

Did you try to compress your DB into a zip file? I've found that with large files the forum likes to error out.
Title: Re: v1.12.0 Bugs Thread
Post by: Cosinus on December 18, 2020, 04:45:23 PM
Did you try to compress your DB into a zip file? I've found that with large files the forum likes to error out.

It's already 7z compressed. It's 20MB so way below the file size limit.
Title: Re: v1.12.0 Bugs Thread
Post by: Garfunkel on December 18, 2020, 07:25:11 PM
I'm playing a game with two player races, which have neutral but overall positive relations (~500) and a trade agreement.

I just finished researching Microwave Focusing 5 with Race #1. 
Race#2 received Microwave Focusing Technology 1 from Race #1.

These two races do not have a research data agreement.  It shows as "Not Available" on both races. 

Is this an intended feature - ideas slowly spreading between friendly races via trade?  Or just a bug that should not have happened without research data sharing?

Someone else who knows better can chime in, but I remember as far back as VB6 there was a mechanic for which races that were far behind in the tech tree could passively receive outdated techs from other races just by being generally aware of each other. The case I remember is a player-created race spawned in the middle of the game received low-tier armor tech from another player race that had a higher level of armor tech. I don't know the detailed mechanics but it sounds like this is what happened.
Races/factions that share a planet will "bleed" non-cutting edge tech to each other.
Title: Re: v1.12.0 Bugs Thread
Post by: Cosinus on December 19, 2020, 04:53:23 PM
(Not using the normal format since there is no error code, but yes I use 1.12 unmodded with dot separator.)

3 maybe related bugs with displaying alien ship contacts:

First issue: There are some glitches in the "contacts list". In my game, there is an Alien NPR known as the Saratov Aliens. However since communication was established, they are known as the Saad Alliance. This leads to some issues, as the game rapidly glitches between those two names. To replicate: Go to the attached DB, tactical window, "contacts" tab and select the "saratov aliens 224" in the drop down menu for "display single race contacts only". The name will flicker between saratov aliens and saad alliance. Expected behaviour: Just use Saad alliance everywhere after communications is established.

This leads right to the second issue. As you can see, if you disable "lost contacts" there are no contacts displayed for any race in Saratov, even though there are 4 ships right next to my Survey ship at Saratov B1. Expected behaviour: Unless I severely misunderstand the purpose of this list, the list of contacts should show all current contacts so you can easily find them.

Third Issue: This has to do with drawing contacts on the tactical map. As you can see in the DB, I have several Deep space tracking stations on Saratov B1 and passive sensors in orbit on the CVS Athena. The alien ships are in orbit as well and thus have a distance of zero to my passive sensors. However, the passive sensors can't detect them, even though they have a thermal signature. When you turn active sensors off, the ships just vanish, even though they are right next to my ship. Expected behaviour: Passive thermal sensors and deep space tracking stations should always detect a nonzero thermal emission at zero range. Same for other sensors.

The DB is here (7z format, 22MB), as I couldn't upload before: https://drive.google.com/file/d/1kYL4ssDl2xuqpz3JhQfWCdQDZO8McBUt/view?usp=sharing
Title: Re: v1.12.0 Bugs Thread
Post by: Cosinus on December 20, 2020, 09:45:31 AM
Bug: Fighters ignore naming themes.
To reproduce: Design a fighter (<500 tons), select a naming theme in the "miscellaneous" tab and select "pick random name from theme".
Build a few fighters. They will be named A 001, A 002, etc where A is your class name and will not follow your chosen naming theme.
To double check, go to the "ships in class" tab in the class design window and select "rename all". All fighters of that class will be renamed according to your selected naming theme.

Expected behaviour: Fighters should behave just like ships and be named according to the naming theme selected from the start.

You can see this problem in the DB posted in my previous report with the "Eye" class.
Title: Re: v1.12.0 Bugs Thread
Post by: Cosinus on December 20, 2020, 10:32:14 AM
(Sorry to report a lot of bugs lately, but I keep finding more ::))

There seems to be an issue with the pathfinding algorithm. I have not tracked down where it comes from exactly, but I just noticed this behaviour in one location in a big multi star system.
I noticed that in this specific location, when setting 2 fleets to go to the location of the other, the pathfinding algorithm lets them end up in the middle of nowhere.

(https://i.imgur.com/SrVxapZ.png)

As you can see, the ships do not go towards each other in a straight line, but rather go in a completely different direction.
DB is here: https://drive.google.com/file/d/16U8NyUzBkcZ9gkN58JsPP6CGa4nXBDb7/view?usp=sharing
To reproduce, set the Pacifica to go to the location of the Triton, and vice versa. Then advance time.

SJW: Working as intended. When you give a fleet orders to move to another fleet, it sets an intercept course to move to where the target fleet will be in the future, rather than where it is now.
Title: Re: v1.12.0 Bugs Thread
Post by: nuclearslurpee on December 20, 2020, 11:08:42 AM
Bug: Fighters ignore naming themes.
To reproduce: Design a fighter (<500 tons), select a naming theme in the "miscellaneous" tab and select "pick random name from theme".
Build a few fighters. They will be named A 001, A 002, etc where A is your class name and will not follow your chosen naming theme.
To double check, go to the "ships in class" tab in the class design window and select "rename all". All fighters of that class will be renamed according to your selected naming theme.

Expected behaviour: Fighters should behave just like ships and be named according to the naming theme selected from the start.

You can see this problem in the DB posted in my previous report with the "Eye" class.

This one is technically WAD but perhaps not WAI. If you build fighters or stations from the Construction tab they will not use the naming scheme, as there is nowhere in that interface to actually name the thing you're building. The names only work if you build them from a shipyard which does have a space on the interface for naming things.
Title: Re: v1.12.0 Bugs Thread
Post by: ivangorin21 on December 20, 2020, 02:03:00 PM
I'm not sure if this is the right place to post this, because I don't know if this is a bug or a feature.   I think my ship disappeared without any messages about it in the event log. 

As you can see in the image, I had GSV Astrakhan 001 go through a jump point and discover a new system, then ordered it to go to Proxima Centauri-A I.   After that I saved and closed the game.   A couple days later I open the game and see that the ship is gone, you can see that its fleet is empty.   Also, the design for the ship has disappeared from class design.   The later orders you see in the event log is me trying to order the empty fleet.   Maybe it got destroyed by an unknown enemy ship? Would I get any message then?

(http://hxxp: hxxp: aurora_bug.  png)

Edit: actually I remembered that I have a save before the jump, so I opened it and the ship is gone there too, so I guess the problem is that the ship did not save in the . db?
Title: Re: v1.12.0 Bugs Thread
Post by: TheTalkingMeowth on December 20, 2020, 02:15:31 PM
I'm not sure if this is the right place to post this, because I don't know if this is a bug or a feature.   I think my ship disappeared without any messages about it in the event log. 

As you can see in the image, I had GSV Astrakhan 001 go through a jump point and discover a new system, then ordered it to go to Proxima Centauri-A I.   After that I saved and closed the game.   A couple days later I open the game and see that the ship is gone, you can see that its fleet is empty.   Also, the design for the ship has disappeared from class design.   The later orders you see in the event log is me trying to order the empty fleet.   Maybe it got destroyed by an unknown enemy ship? Would I get any message then?

(http://hxxp: hxxp: aurora_bug.  png)

Edit: actually I remembered that I have a save before the jump, so I opened it and the ship is gone there too, so I guess the problem is that the ship did not save in the . db?

Ship destruction by enemy action would definitely show in the log. There would also be a wreck displayed on the tactical map.

Did you accidentally click the delete button with the class design selected? That would delete the ship as well.
Title: Re: v1.12.0 Bugs Thread
Post by: ivangorin21 on December 20, 2020, 02:21:12 PM
Quote from: TheTalkingMeowth link=topic=11945. msg144873#msg144873 date=1608495331
Quote from: ivangorin21 link=topic=11945. msg144872#msg144872 date=1608494580
I'm not sure if this is the right place to post this, because I don't know if this is a bug or a feature.    I think my ship disappeared without any messages about it in the event log.   

As you can see in the image, I had GSV Astrakhan 001 go through a jump point and discover a new system, then ordered it to go to Proxima Centauri-A I.    After that I saved and closed the game.    A couple days later I open the game and see that the ship is gone, you can see that its fleet is empty.    Also, the design for the ship has disappeared from class design.    The later orders you see in the event log is me trying to order the empty fleet.    Maybe it got destroyed by an unknown enemy ship? Would I get any message then?

(http://hxxp: hxxp: hxxp: aurora_bug.   png)

Edit: actually I remembered that I have a save before the jump, so I opened it and the ship is gone there too, so I guess the problem is that the ship did not save in the .  db?

Ship destruction by enemy action would definitely show in the log.  There would also be a wreck displayed on the tactical map.

Did you accidentally click the delete button with the class design selected? That would delete the ship as well.

In the save before the jump the ship is missing too, so even if I deleted the ship from class design in the latest save, it should still appear in the previous save? Or does the ship disappear when deleted from class design only after a save and restart of the game?
Title: Re: v1.12.0 Bugs Thread
Post by: ivangorin21 on December 20, 2020, 02:25:57 PM
Also, I noticed that there is a bunch of empty subfleets in civilian shipping lines.  Is this normal? Maybe they just scrapped the ships and didn't delete the subfleets.
(http://hxxp: aurora_bug2)
Title: Re: v1.12.0 Bugs Thread
Post by: TheTalkingMeowth on December 20, 2020, 02:51:03 PM
Quote from: TheTalkingMeowth link=topic=11945. msg144873#msg144873 date=1608495331
Quote from: ivangorin21 link=topic=11945. msg144872#msg144872 date=1608494580
I'm not sure if this is the right place to post this, because I don't know if this is a bug or a feature.    I think my ship disappeared without any messages about it in the event log.   

As you can see in the image, I had GSV Astrakhan 001 go through a jump point and discover a new system, then ordered it to go to Proxima Centauri-A I.    After that I saved and closed the game.    A couple days later I open the game and see that the ship is gone, you can see that its fleet is empty.    Also, the design for the ship has disappeared from class design.    The later orders you see in the event log is me trying to order the empty fleet.    Maybe it got destroyed by an unknown enemy ship? Would I get any message then?

(http://hxxp: hxxp: hxxp: aurora_bug.   png)

Edit: actually I remembered that I have a save before the jump, so I opened it and the ship is gone there too, so I guess the problem is that the ship did not save in the .  db?

Ship destruction by enemy action would definitely show in the log.  There would also be a wreck displayed on the tactical map.

Did you accidentally click the delete button with the class design selected? That would delete the ship as well.

In the save before the jump the ship is missing too, so even if I deleted the ship from class design in the latest save, it should still appear in the previous save? Or does the ship disappear when deleted from class design only after a save and restart of the game?

Ship disappearing because the class design got deleted would likely cause errors (I've never done it), but the disappearing after a reload would not be a surprising effect.

Can you open up the database and look for the ship, class design, etc?
Title: Re: v1.12.0 Bugs Thread
Post by: ivangorin21 on December 20, 2020, 02:55:06 PM
Quote from: TheTalkingMeowth link=topic=11945. msg144879#msg144879 date=1608497463
Quote from: ivangorin21 link=topic=11945. msg144874#msg144874 date=1608495672
Quote from: TheTalkingMeowth link=topic=11945.  msg144873#msg144873 date=1608495331
Quote from: ivangorin21 link=topic=11945.  msg144872#msg144872 date=1608494580
I'm not sure if this is the right place to post this, because I don't know if this is a bug or a feature.     I think my ship disappeared without any messages about it in the event log.   

As you can see in the image, I had GSV Astrakhan 001 go through a jump point and discover a new system, then ordered it to go to Proxima Centauri-A I.     After that I saved and closed the game.     A couple days later I open the game and see that the ship is gone, you can see that its fleet is empty.     Also, the design for the ship has disappeared from class design.     The later orders you see in the event log is me trying to order the empty fleet.     Maybe it got destroyed by an unknown enemy ship? Would I get any message then?

(http://hxxp: hxxp: hxxp: hxxp: aurora_bug.    png)

Edit: actually I remembered that I have a save before the jump, so I opened it and the ship is gone there too, so I guess the problem is that the ship did not save in the .   db?

Ship destruction by enemy action would definitely show in the log.   There would also be a wreck displayed on the tactical map. 

Did you accidentally click the delete button with the class design selected? That would delete the ship as well. 

In the save before the jump the ship is missing too, so even if I deleted the ship from class design in the latest save, it should still appear in the previous save? Or does the ship disappear when deleted from class design only after a save and restart of the game?

Ship disappearing because the class design got deleted would likely cause errors (I've never done it), but the disappearing after a reload would not be a surprising effect.

Can you open up the database and look for the ship, class design, etc?

Sure, can you explain how to open it? I thought there was some secret key that only a few of the moderators knew.
Title: Re: v1.12.0 Bugs Thread
Post by: ivangorin21 on December 20, 2020, 02:57:36 PM
Nevermind, I think I figured it out using DB browser
Title: Re: v1.12.0 Bugs Thread
Post by: ivangorin21 on December 20, 2020, 03:35:11 PM
Quote from: TheTalkingMeowth link=topic=11945.  msg144879#msg144879 date=1608497463
Quote from: ivangorin21 link=topic=11945.  msg144874#msg144874 date=1608495672
Quote from: TheTalkingMeowth link=topic=11945.   msg144873#msg144873 date=1608495331
Quote from: ivangorin21 link=topic=11945.   msg144872#msg144872 date=1608494580
I'm not sure if this is the right place to post this, because I don't know if this is a bug or a feature.      I think my ship disappeared without any messages about it in the event log.     

As you can see in the image, I had GSV Astrakhan 001 go through a jump point and discover a new system, then ordered it to go to Proxima Centauri-A I.      After that I saved and closed the game.      A couple days later I open the game and see that the ship is gone, you can see that its fleet is empty.      Also, the design for the ship has disappeared from class design.      The later orders you see in the event log is me trying to order the empty fleet.      Maybe it got destroyed by an unknown enemy ship? Would I get any message then?

(http://hxxp: hxxp: hxxp: hxxp: hxxp: aurora_bug.     png)

Edit: actually I remembered that I have a save before the jump, so I opened it and the ship is gone there too, so I guess the problem is that the ship did not save in the .    db?

Ship destruction by enemy action would definitely show in the log.    There would also be a wreck displayed on the tactical map.   

Did you accidentally click the delete button with the class design selected? That would delete the ship as well.   

In the save before the jump the ship is missing too, so even if I deleted the ship from class design in the latest save, it should still appear in the previous save? Or does the ship disappear when deleted from class design only after a save and restart of the game?

Ship disappearing because the class design got deleted would likely cause errors (I've never done it), but the disappearing after a reload would not be a surprising effect. 

Can you open up the database and look for the ship, class design, etc?

I looked into the database, the ship is there with ShipID 13462, ShipClassID 10412.   But the ship class with that ID is missing.   I also checked for one of the empty civilian subfleets (Ectelion Small F7 001).   The ship is there, but its ship design is missing.  Do you know if there is a way to see deleted classes or events like "class deleted"? Also, since almost all of the civilian classes are missing too, I don't think I could accidentally delete them all.
Title: Re: v1.12.0 Bugs Thread
Post by: Potat999 on December 20, 2020, 03:44:19 PM
I'm playing a game with two player races, which have neutral but overall positive relations (~500) and a trade agreement.

I just finished researching Microwave Focusing 5 with Race #1. 
Race#2 received Microwave Focusing Technology 1 from Race #1.

These two races do not have a research data agreement.  It shows as "Not Available" on both races. 

Is this an intended feature - ideas slowly spreading between friendly races via trade?  Or just a bug that should not have happened without research data sharing?

Someone else who knows better can chime in, but I remember as far back as VB6 there was a mechanic for which races that were far behind in the tech tree could passively receive outdated techs from other races just by being generally aware of each other. The case I remember is a player-created race spawned in the middle of the game received low-tier armor tech from another player race that had a higher level of armor tech. I don't know the detailed mechanics but it sounds like this is what happened.
Races/factions that share a planet will "bleed" non-cutting edge tech to each other.

I guess that's probably it, thanks. In retrospect I think this started occurring after one dropped some AMs on an asteroid where the other had a CMC. 

I was thrown off by the message stating "xyz tech was provided to us by Faction" which didn't sound like passive bleed.




Title: Re: v1.12.0 Bugs Thread
Post by: TheTalkingMeowth on December 20, 2020, 09:28:03 PM
Quote from: TheTalkingMeowth link=topic=11945.  msg144879#msg144879 date=1608497463
Quote from: ivangorin21 link=topic=11945.  msg144874#msg144874 date=1608495672
Quote from: TheTalkingMeowth link=topic=11945.   msg144873#msg144873 date=1608495331
Quote from: ivangorin21 link=topic=11945.   msg144872#msg144872 date=1608494580
I'm not sure if this is the right place to post this, because I don't know if this is a bug or a feature.      I think my ship disappeared without any messages about it in the event log.     

As you can see in the image, I had GSV Astrakhan 001 go through a jump point and discover a new system, then ordered it to go to Proxima Centauri-A I.      After that I saved and closed the game.      A couple days later I open the game and see that the ship is gone, you can see that its fleet is empty.      Also, the design for the ship has disappeared from class design.      The later orders you see in the event log is me trying to order the empty fleet.      Maybe it got destroyed by an unknown enemy ship? Would I get any message then?

(http://hxxp: hxxp: hxxp: hxxp: hxxp: aurora_bug.     png)

Edit: actually I remembered that I have a save before the jump, so I opened it and the ship is gone there too, so I guess the problem is that the ship did not save in the .    db?

Ship destruction by enemy action would definitely show in the log.    There would also be a wreck displayed on the tactical map.   

Did you accidentally click the delete button with the class design selected? That would delete the ship as well.   

In the save before the jump the ship is missing too, so even if I deleted the ship from class design in the latest save, it should still appear in the previous save? Or does the ship disappear when deleted from class design only after a save and restart of the game?

Ship disappearing because the class design got deleted would likely cause errors (I've never done it), but the disappearing after a reload would not be a surprising effect. 

Can you open up the database and look for the ship, class design, etc?

I looked into the database, the ship is there with ShipID 13462, ShipClassID 10412.   But the ship class with that ID is missing.   I also checked for one of the empty civilian subfleets (Ectelion Small F7 001).   The ship is there, but its ship design is missing.  Do you know if there is a way to see deleted classes or events like "class deleted"? Also, since almost all of the civilian classes are missing too, I don't think I could accidentally delete them all.

I don't think that is logged. But you can see the entire event log in the GameLog table.

This is very strange.Have you had any error messages during the game, either before or after this happened?
Title: Re: v1.12.0 Bugs Thread
Post by: ivangorin21 on December 21, 2020, 01:22:49 PM
Quote from: TheTalkingMeowth link=topic=11945. msg144893#msg144893 date=1608521283
Quote from: ivangorin21 link=topic=11945. msg144883#msg144883 date=1608500111
Quote from: TheTalkingMeowth link=topic=11945.   msg144879#msg144879 date=1608497463
Quote from: ivangorin21 link=topic=11945.   msg144874#msg144874 date=1608495672
Quote from: TheTalkingMeowth link=topic=11945.    msg144873#msg144873 date=1608495331
Quote from: ivangorin21 link=topic=11945.    msg144872#msg144872 date=1608494580
I'm not sure if this is the right place to post this, because I don't know if this is a bug or a feature.       I think my ship disappeared without any messages about it in the event log.     

As you can see in the image, I had GSV Astrakhan 001 go through a jump point and discover a new system, then ordered it to go to Proxima Centauri-A I.       After that I saved and closed the game.       A couple days later I open the game and see that the ship is gone, you can see that its fleet is empty.       Also, the design for the ship has disappeared from class design.       The later orders you see in the event log is me trying to order the empty fleet.       Maybe it got destroyed by an unknown enemy ship? Would I get any message then?

(http://hxxp: hxxp: hxxp: hxxp: hxxp: hxxp: aurora_bug.      png)

Edit: actually I remembered that I have a save before the jump, so I opened it and the ship is gone there too, so I guess the problem is that the ship did not save in the .     db?

Ship destruction by enemy action would definitely show in the log.     There would also be a wreck displayed on the tactical map.   

Did you accidentally click the delete button with the class design selected? That would delete the ship as well.   

In the save before the jump the ship is missing too, so even if I deleted the ship from class design in the latest save, it should still appear in the previous save? Or does the ship disappear when deleted from class design only after a save and restart of the game?

Ship disappearing because the class design got deleted would likely cause errors (I've never done it), but the disappearing after a reload would not be a surprising effect.   

Can you open up the database and look for the ship, class design, etc?

I looked into the database, the ship is there with ShipID 13462, ShipClassID 10412.    But the ship class with that ID is missing.    I also checked for one of the empty civilian subfleets (Ectelion Small F7 001).    The ship is there, but its ship design is missing.   Do you know if there is a way to see deleted classes or events like "class deleted"? Also, since almost all of the civilian classes are missing too, I don't think I could accidentally delete them all.

I don't think that is logged.  But you can see the entire event log in the GameLog table.

This is very strange. Have you had any error messages during the game, either before or after this happened?

I think there was a warning when I was saving, but it saved successfully.  I don’t remember what it was exactly, is there a log or warnings/errors?
Title: Re: v1.12.0 Bugs Thread
Post by: TheTalkingMeowth on December 21, 2020, 01:29:55 PM
I think there was a warning when I was saving, but it saved successfully.  I don’t remember what it was exactly, is there a log or warnings/errors?

I don't think errors are logged anywhere.

If there was an error message while saving, that was probably related to whatever weirdness deleted all these ship classes.

Does the game give an error if you try to save again?
Title: Re: v1.12.0 Bugs Thread
Post by: n01487477 on December 21, 2020, 08:04:19 PM
Quote from: Kev link=topic=11945. msg141517#msg141517 date=1602565883
Hi, everybody! New adept here. 
Decided to finally try Aurora after 1.  12 came out. 

But I've stumbled on some issues almost immediately.   I use system-wide font scaling because i can't see anything on 4k screen otherwise.   For Aurora I've set system scaling override so it looks sharp.   But some windows (Class Design and Game Information) don't scale properly - some controls go out of "client" area of form.   I've attached two screenshots. 
It should be an easy fix (I'm c# dev myself).   So i hope it will be fixed.   I really like the idea of this game. 

Thanks.   Apologies for bad English. 

Working as intended, not a bug.  -Garfunkel
Hi - I'm having the same problem and no matter what I do to the font scaling I can't get the information within these 2 windows.   Win10 OS with 2 monitor setup (2560x1440 & 1920x1080) & scaling set to the lowest 100%.  Custom scaling didn't seem to anything.  Nor did changing DPI settings in a shortcut to the EXE. 

If it is WAI - then can someone please point me in the general direction of a fix.
Title: Re: v1.12.0 Bugs Thread
Post by: nuclearslurpee on December 21, 2020, 08:10:42 PM
Quote from: Kev link=topic=11945. msg141517#msg141517 date=1602565883
Hi, everybody! New adept here. 
Decided to finally try Aurora after 1.  12 came out. 

But I've stumbled on some issues almost immediately.   I use system-wide font scaling because i can't see anything on 4k screen otherwise.   For Aurora I've set system scaling override so it looks sharp.   But some windows (Class Design and Game Information) don't scale properly - some controls go out of "client" area of form.   I've attached two screenshots. 
It should be an easy fix (I'm c# dev myself).   So i hope it will be fixed.   I really like the idea of this game. 

Thanks.   Apologies for bad English. 

Working as intended, not a bug.  -Garfunkel
Hi - I'm having the same problem and no matter what I do to the font scaling I can't get the information within these 2 windows.   Win10 OS with 2 monitor setup (2560x1440 & 1920x1080) & scaling set to the lowest 100%.  Custom scaling didn't seem to anything.  Nor did changing DPI settings in a shortcut to the EXE. 

If it is WAI - then can someone please point me in the general direction of a fix.

As stated in the quoted post it is WAI. A possible fix would be to use AuroraMod which may or may not be able to address this.
Title: Re: v1.12.0 Bugs Thread
Post by: ivangorin21 on December 22, 2020, 12:48:14 AM
Quote from: TheTalkingMeowth link=topic=11945. msg144947#msg144947 date=1608578995
Quote from: ivangorin21 link=topic=11945. msg144945#msg144945 date=1608578569
I think there was a warning when I was saving, but it saved successfully.   I don’t remember what it was exactly, is there a log or warnings/errors?

I don't think errors are logged anywhere.

If there was an error message while saving, that was probably related to whatever weirdness deleted all these ship classes.

Does the game give an error if you try to save again?

No, saves without warnings/errors now
Title: Re: v1.12.0 Bugs Thread
Post by: ChubbyPitbull on December 22, 2020, 07:29:14 AM
EDIT: Not actually a bug! As was helpfully pointed out to me the bases are just producing MSP.


Game Year: 2050
Start: Trans-Newtonian
Stars: Random
Decimal Separator: Period

I recently moved several Maintenance Facilities to a LG research colony with an 80% P&P Ancient Construct. In orbit of the colony are 10 Orbital Habitats, all of the same model:

Code: [Select]
Sitting Bull class Orbital Habitat      2,504,443 tons       160 Crew       1,159.1 BP       TCS 50,089    TH 0    EM 0
1 km/s      No Armour       Shields 0-0     HTK 131      Sensors 0/0/0/0      DCR 1      PPV 0
MSP 0    Max Repair 200 MSP
Habitation Capacity 1,000,000   
Dictator    Control Rating 1   BRG   
Intended Deployment Time: 3 months   


This design is classed as a Commercial Vessel for maintenance purposes
This design is classed as a Space Station for construction purposes

There are no other ships in orbit at this time, however, the "Mining" tab for the colony now shows that Duranium/Uridium/Gallicite are starting to be consumed for "Maintenance." I would have expected that Commercial Vessels would not consume any minerals for maintenance as they don't have a Maintenance Clock. Is that not correct?
Title: Re: v1.12.0 Bugs Thread
Post by: Zap0 on December 22, 2020, 10:20:00 AM
Maintenance consumption is the minerals used for producing MSP, which is done passively in maintenance facilities unless explicitly turned off in the industry tab.

Not a bug :-)
Title: Re: v1.12.0 Bugs Thread
Post by: Kylemmie on December 22, 2020, 10:24:48 AM
The Maintenance Facilities have two functions.

1) Regular Maintenance on ships in orbit to stop the 'clock' or overhaul and reset it
2) Produce MSP.  I believe this is the mineral usage you are seeing. On the main colony summary tab there is a spot on the right for Fuel and MSP stockpile amounts if on a planet. You should see MSP rise on that planet when not short of minerals.

If you just want the Maintenance for ships in orbit and don't want MSP production (or the out of mineral alerts), shut them down on the colony industrial tab.  They should still provide orbital maintenance but stop trying to produce MSP.

Also, this is one of the main differences between Maintenance Facilities and Maintenance Modules (for orbital bases). I don't believe Modules can produce MSP - just provide maintenance. Still convenient for FOB's, just big sloppy pie in the face the one time I got the bright idea of creating a MSP producing base in an empty important crossroads system. Built and moved over 100M tons of bases 5 systems over and when it was all set and I flipped the switch.....nada....no MSP production...
Title: Re: v1.12.0 Bugs Thread
Post by: ivangorin21 on December 22, 2020, 04:22:32 PM
Quote from: TheTalkingMeowth link=topic=11945.  msg144947#msg144947 date=1608578995
Quote from: ivangorin21 link=topic=11945.  msg144945#msg144945 date=1608578569
I think there was a warning when I was saving, but it saved successfully.    I don’t remember what it was exactly, is there a log or warnings/errors?

I don't think errors are logged anywhere. 

If there was an error message while saving, that was probably related to whatever weirdness deleted all these ship classes. 

Does the game give an error if you try to save again?

I have started a new game, and this error appeared after a few 30 day skips.   Do you think it could be related to the previous game bug? I think it is similar to the message I got when saving before
Title: Re: v1.12.0 Bugs Thread
Post by: TheTalkingMeowth on December 22, 2020, 04:48:57 PM
Quote from: TheTalkingMeowth link=topic=11945.  msg144947#msg144947 date=1608578995
Quote from: ivangorin21 link=topic=11945.  msg144945#msg144945 date=1608578569
I think there was a warning when I was saving, but it saved successfully.    I don’t remember what it was exactly, is there a log or warnings/errors?

I don't think errors are logged anywhere. 

If there was an error message while saving, that was probably related to whatever weirdness deleted all these ship classes. 

Does the game give an error if you try to save again?

I have started a new game, and this error appeared after a few 30 day skips.   Do you think it could be related to the previous game bug? I think it is similar to the message I got when saving before
I don't recognize the function number. Can you make a full report with the info on what you were doing when the error message popped?
Title: Re: v1.12.0 Bugs Thread
Post by: ivangorin21 on December 22, 2020, 05:52:33 PM
Quote from: TheTalkingMeowth link=topic=11945. msg145039#msg145039 date=1608677337
I don't recognize the function number.  Can you make a full report with the info on what you were doing when the error message popped?

Function number: 2939
Error text: 1. 12. 0 Function #2939: Object reference not set to an instance of an object.
Window affected: Main window
Start: TN
Stars: Random
Decimal separator: period
Reproducible: No, tried a couple of times with a backup, could not reproduce the bug


Just started a new game, assigned the governor and research and was on 30 day autoturn, then the error appeared.  After I clicked OK the game froze, I closed it with task manager.  I had a backup of the database saved before any turns made (January 1 2025), tried using it to recreate the bug but it didn't happen. 

I also have a backup of the database from my previous game, where several ships disappeared in game without any messages (the discussion of this bug is in my previous messages).  I got a similar error to this one (I think the same number, but not sure) when saving the previous game, so it may be related.  In this database I found that the ships that disappeared (my ship Astrakhan 001 and a few civilian ships, for example Ectelion Small F7 001) are still in FCT_Ship, but their classes are missing in FCT_ShipClass.  Also, in the gamelog there are many messages about NPR ships running out of fuel, not sure if it is relevant. 

I couldn't attach the db to the post for some reason.

Edit: here is the .db: http://s000.tinyupload.com/?file_id=20412646311680459930
Title: Re: v1.12.0 Bugs Thread
Post by: Froggiest1982 on December 23, 2020, 02:42:57 AM
Ships with destroyed components such as box launchers and magazines are able to load the respective ammo resulting in a percentage of ordnance higher than 100%.

The correct behaviour should be that such ships shouldn't be able to load any ordnance for destroyed components (>100% damage on damage control screen)

It is okay for damaged ones (<100% damage on damage control screen)
Title: Re: v1.12.0 Bugs Thread
Post by: Droll on December 24, 2020, 06:49:26 AM
1.12 unmodded
Was doing some troubleshooting for someone on the EnterElysium discord

When a ship that has both gauss and CIWS pd and is targeted by missiles, the PD weapons of the ship itself fires as usual. However, gauss weapons located on other ships in the fleet do not help the affected ship.

Probably the CIWS FDF Self-only step is skipping the rest of the fleets turn to fire or something
Title: Re: v1.12.0 Bugs Thread
Post by: Silvarelion on December 24, 2020, 06:55:48 AM
Seems like the exploding carrier/tanker bug is back again, from 1.11.0

Version: 1.12.0
Dec Sep: .
Any game length.

Add mostly hangers to a ship with plenty of MSP.  Start fleet training.  Extreme designs can blow up in the first 5 day increment.  Saner designs blow up within 6 months when deployment and maintenance are both measured in years, with no record of low MSP, and indeed, many years worth still in storage.
Title: Re: v1.12.0 Bugs Thread
Post by: slevir on December 24, 2020, 04:04:11 PM
Not sure if this is a bug, but orbital-only colonies, when reaching maximum population, do not stop growing, and the population "overflowing" to surface starts building infrastructure there. 

How to reproduce with SM:
- start new game with default settings, make a colony on Venus, make an orbital habitat for 1m people, move it to Venus.   Designate it as military only for good measure. 
- give the habitat exactly 1m people using SM.   Note that "Annual growth rate (Orbital Habitat)" is 10%. 
- go 5 days forward (screenshot 1).   It still shows "population 1.  00m", but "Annual growth rate (Surface)" becomes negative, which tells us there's actually a bit more than 1m people in the colony.   The homeless were sent to the surface apparently. 
- go another 5 days forward (screenshot 2).   Some infrastructure appears on the surface.   The colony is military only, and the game is only 10 days in so there's no civilian shipping yet.   It appears that colonists have built infrastructure themselves. 

This is certainly useful in some cases, but in cases like Venus (or any other high colony cost rock) this makes maintaining orbital-only habitation impossible without constantly moving people off the colony. 
Title: Re: v1.12.0 Bugs Thread
Post by: Cosinus on December 24, 2020, 05:47:35 PM
Fun little UI bug I found by accident:

The function number: #3210
The complete error text: Object of type 'g8' can't be converted to 'i4' (roughly translated)
The window affected: Naval Organization, movement orders tab.
What you were doing at the time: See steps to reproduce
Conventional or TN start: doesn't matter
Random or Real Stars: doesn't matter
Is your decimal separator a comma?: dot
Is the bug is easy to reproduce, intermittent or a one-off?: always reproducible
If this is a long campaign - say 75 years or longer - let me know the length of the campaign as well: doesn't matter

Steps to reproduce:
 
Expected behaviour: In step 3, either the destination list should still show the systems list (preferred), or the selector and list should go back to showing in-system locations like planets, wrecks etc.
Title: Re: v1.12.0 Bugs Thread
Post by: Froggiest1982 on December 24, 2020, 08:01:26 PM
Not sure if this is a bug, but orbital-only colonies, when reaching maximum population, do not stop growing, and the population "overflowing" to surface starts building infrastructure there. 

How to reproduce with SM:
- start new game with default settings, make a colony on Venus, make an orbital habitat for 1m people, move it to Venus.   Designate it as military only for good measure. 
- give the habitat exactly 1m people using SM.   Note that "Annual growth rate (Orbital Habitat)" is 10%. 
- go 5 days forward (screenshot 1).   It still shows "population 1.  00m", but "Annual growth rate (Surface)" becomes negative, which tells us there's actually a bit more than 1m people in the colony.   The homeless were sent to the surface apparently. 
- go another 5 days forward (screenshot 2).   Some infrastructure appears on the surface.   The colony is military only, and the game is only 10 days in so there's no civilian shipping yet.   It appears that colonists have built infrastructure themselves. 

This is certainly useful in some cases, but in cases like Venus (or any other high colony cost rock) this makes maintaining orbital-only habitation impossible without constantly moving people off the colony.

Unfortunately not a bug WAI. It was discussed on other posts to change it but so far no words from Steve.

Also not all players agreed, maybe 7 out of 10.
Title: Re: v1.12.0 Bugs Thread
Post by: Droll on December 24, 2020, 08:28:28 PM
I don't follow how that makes it impossible. The infrastructure comes free doesn't it?
Title: Re: v1.12.0 Bugs Thread
Post by: Froggiest1982 on December 24, 2020, 08:44:26 PM
I don't follow how that makes it impossible. The infrastructure comes free doesn't it?

I think he means Orbital Habitat Only = Impossible, which is true.

Title: Re: v1.12.0 Bugs Thread
Post by: Desdinova on December 24, 2020, 08:48:04 PM
I'm not sure if this is a known issue, but if a fire control is destroyed while set to open fire, it can't be told to cease fire, leading to endless 5 second increments forcing you to SM repair it and turn it off again.
Title: Re: v1.12.0 Bugs Thread
Post by: Droll on December 25, 2020, 11:23:09 AM
I don't follow how that makes it impossible. The infrastructure comes free doesn't it?
I think he means Orbital Habitat Only = Impossible, which is true.

Oh I thought he meant it as in the colony is unviable, that makes more sense.
Title: Re: v1.12.0 Bugs Thread
Post by: ivangorin21 on December 25, 2020, 11:50:31 AM
In a game with Rakhas disabled they still generate for a period of time, long enough to destroy a ship.

My exploration ship got destroyed by ground based defences and I decided to check the database. There is a Rakha race generated with a population on that planet and ground units stationed there. Rakhas were turned off from the very creation of the game.
GameID: 38
RaceID: 220
PopulationID: 5602
Ground Formation IDs: 5313 - 5321

After a 5 second skip and save the population is removed and the formations remain with no PopulationID assigned. I don't think they can be detected on the planet after that. The race is not removed, but I guess its dead without any populations.

Here is the link to the db right after ship destruction, when the population is still there: https://gofile.io/d/BOxJOQ

Edit: I continued exploring and noticed another 2 Rakha races generating in two new systems.
Title: Re: v1.12.0 Bugs Thread
Post by: Tikhun on December 25, 2020, 01:20:28 PM
I have found two bugs related to the new Death Spiral cataclysm.   Both happen once Earth is destroyed by tidal stress.   

1) Luna stays in orbit around empty space where Earth used to be, gets very low temperature (-269C) even though it is very close to the sun, and doesn't seem to move on the orbit.   I removed it in SM mode soon after that, so there might be other consequences for the game flow.   

2) All comanders who were graduated from Earth academy, are unavailable in Commanders tab and throw an error "1.  12 Function #384 Object reference not set to an instance of an object" when attempting to choose them in Commanders tab; they are impossible to assign to any position, and left-most part of their dossier is not shown.   

Start is conventional
Known stars
Dot decimal separator
The campaign is 100 years in.   

SJW: Both fixed.
Title: Re: v1.12.0 Bugs Thread
Post by: Zap0 on December 25, 2020, 01:56:00 PM
2) All comanders who were graduated from Earth academy, are unavailable in Commanders tab and throw an error "1.  12 Function #384 Object reference not set to an instance of an object" when attempting to choose them in Commanders tab; they are impossible to assign to any position, and left-most part of their dossier is not shown.

I get that too whenever I delete the Earth colony of an empire, for any commander that has Earth as it's homeworld or academy.

SJW: Fixed.
Title: Re: v1.12.0 Bugs Thread
Post by: papent on December 25, 2020, 02:10:17 PM

Previously reported on versions 1.9.4 & 1.9.3
http://aurora2.pentarch.org/index.php?topic=11231.msg130424#msg130424

The function number: N/A
The complete error text: N/A
The window affected: Naval Org. Ship overview on Supply ship
What you were doing at the time: Setting ships to Auto Resupply closing windows moving forward time or saving, exit, and then reload game. it reverts.
Conventional or TN start: TN
Random or Real Stars: Real
Is your decimal separator a comma? decimal
Is the bug is easy to reproduce, intermittent or a one-off? easy

Supply ship "resupply own fleet" setting reverting to "no auto resupply".

Possible solution: have supply ships, Tankers, And Coilers work like carriers where it defaults to automatic supply, refuel, and replace armaments.
Title: Re: v1.12.0 Bugs Thread
Post by: Droll on December 26, 2020, 04:27:10 PM
Version 1.12 - Vanilla tech only

This might not be the correct thread but are there plans to fix naval mines / blind fired active missiles for 1.13?

What is the problem with them? I haven't used them in any of my C# campaigns.

I just did my own test, I threw together a test with active sensor missiles.

The missile ship was to attack a group of freighters without using its own active sensor. Since I cannot target the thermal contacts directly I elected to use a named waypoint and fired the missiles at with that waypoint as the target. The missiles can see 2m km with RES 100. The freighters were HS 500.

The missiles reached the waypoint ahead of time and waited there for a while. Two things happened which I think are suspect:
1 - Despite standing still at the waypoint, the missiles expire after a while - seems like they still consume fuel when stationary (might be WAI for missiles but is a problem for naval mines)
2 - When the freighters entered the sensor range of the missiles, the contact information was updated confirming that the missiles detected their targets. However they did not attempt to intercept. (again might be WAI for guided missiles but massive issue for any naval mine that will almost certainly be dropped at some sort of waypoint)

Ill continue testing with the ships actives and try to make the missiles "lose" their target mid flight and see what happens

UPDATE: I can confirm that in this second test everything went fine missiles lost contact but kept flying to last known location. Not only did they successfully reacquire their target, once it was destroyed they moved on to the next until there were no salvos left. Some missiles stopped after the first target went down but immediately fired back up when the freighters entered active range.
Note: Its worth noting that the salvos did not all arrive at the same time. Ill test this next.

I just confirmed that active missiles DO NOT prevent overkill like they used to if all the salvos arrive at the same time. Although the combat summary only reported 8 hits I had 40 nuclear impacts register. 4 out of 5 salvos were wasted despite them having active sensors to seek something else. (maybe this is WAI?)

However there were 2 salvos trailing behind the target - These salvos DID re-target something else. So the corollary is that when using active sensor missiles - stagger your launches.
IMO this makes active sensor missiles useless against anything that has a modicum of gauss PD.

Naval mines seem to stay put if you use "launch ready ordnance" and don't target a waypoint with them. The problem I have found regarding naval mines is that when an enemy fleet enters their sensor range they seek like they are supposed to. But the fact that all "salvos" of mines arrive at the same time means that they can at most destroy one ship as they tend to target the same vessel. This is the same problem that active missiles have.

The above post details my experimentation with naval mines/missiles and I've concluded that they are unuseable in their current state.

Even if they have re-targeting capability missiles/naval mines do not avoid overkill situations IF the salvos all arrive during the same time increment. This means that active missiles can only be used if their launches are staggered - making them useless/incredibly weak against PD. Naval mines also suffer from this problem, allowing a single enemy ship to soak the entire minefield regardless of how much overkill there is.

Attached is my DB file - you want to look at the game called "test" and not the one with the hegemony. Its a basic test rig, use SM to design your own naval mines but the active missiles I used are there already. Action happens at mars where the "Americas" have some missile ships with "Asia" having a bunch of blind freighters on their way to mars.
Title: Re: v1.12.0 Bugs Thread
Post by: kilo on December 27, 2020, 11:12:47 AM
Bug in 1.12.0

When designing a BFC and you pick the 1.25x range & 1.25x size option you end up with a .25x range and .25x size BFC. 
Title: Re: v1.12.0 Bugs Thread
Post by: Droll on December 27, 2020, 11:15:06 AM
Bug in 1.12.0

When designing a BFC and you pick the 1.25x range & 1.25x size option you end up with a .25x range and .25x size BFC.

This has been fixed for 1.13
Title: Re: v1.12.0 Bugs Thread
Post by: ChubbyPitbull on December 28, 2020, 10:58:50 AM
The "Range Bands" field on the class design display accepts the return key/new line characters as input. If you accidentally enter one and then try to modify the design or open a different class design, you'll now constantly get the error "1.12.0 Function #237: Input string was not in a correct format."

Depending on where it's put, the user may not know that this is the problem. The range band by default has a value of "10000" I had clicked into the range band field and entered 40000, but thinking I needed to confirm it I hit return with the cursor just after the 4, which changed the displayed value in the field to "0000." I entered 4 again and clicked out, with range bands now showing "40000," but constantly getting the above error no matter where I tried to navigate. I had to go back into the Range Bands field, and delete back to the beginning to clear the newline character out; the field accepts multi-line inputs but only ever displays a single line, so the user can't tell by looking that the new line is the problem if they hit enter a few times.
Title: Re: v1.12.0 Bugs Thread
Post by: Cosinus on January 02, 2021, 04:07:04 PM
Some more bugs...:

The function number: #2123
The complete error text: The sequence contains no elements (roughly translated)
The window affected: Ground forces window, order of battle tab.
What you were doing at the time: I conquered a planet of an NPR (Sjofn A2). They had a garrison on the planet, but nothing else. I had dumped 200 Infrastructure on the planet years earlier, but those were conquered by the aliens and were still there. Otherwise the alien colony is completely empty. On all relevant windows, I have 2 colonies on Sjofn A2 (both named Sjofn A2), 1 colony where I dropped my invasion troops and one that was conquered by the aliens. My colony is also empty, except for invasion troops. Other weird things that are going on are, that unrest is rising in the alien colony, even though no one lives there.
Conventional or TN start: TN
Random or Real Stars: random
Is your decimal separator a comma?: dot
Is the bug is easy to reproduce, intermittent or a one-off?: always reproducible
If this is a long campaign - say 75 years or longer - let me know the length of the campaign as well: nope

Steps to reproduce:
DB: https://drive.google.com/file/d/1naOBYHPgHU0-NeiUnGL5AtjrI_tA55Va/view?usp=sharing
Title: Re: v1.12.0 Bugs Thread
Post by: Cosinus on January 02, 2021, 04:10:18 PM
Scrapped carriers destroy their parasites:
(https://i.imgur.com/vR4BwJ8.png)

The function number: N/A
The complete error text: N/A
The window affected: Economics window/Shipyards tab
What you were doing at the time: See steps to reproduce
Conventional or TN start: doesn't matter
Random or Real Stars: doesn't matter
Is your decimal separator a comma?: dot
Is the bug is easy to reproduce, intermittent or a one-off?: always reproducible
If this is a long campaign - say 75 years or longer - let me know the length of the campaign as well: doesn't matter

Steps to reproduce:
Expected behaviour: Fuel, Ordnance and crew are recovered when a ship is scrapped. It seems unreasonable that the shipyard workers would just kill any fighter crews in the carrier. Parasites should be ejected into their own fleet just before the ship is finally scrapped.

SJW: Fixed.
Title: Re: v1.12.0 Bugs Thread
Post by: Cosinus on January 02, 2021, 04:17:04 PM
You can obsolete basic components like Engineering spaces, Crew quarters and the Bridge. Engineering spaces, bridges, crew quarters, Hangar bays, etc. are never replaced by newer tech and thus should never be obsolete. This also leads to a lot of confusion among newer players, who accidentally do this and don't find a way to switch it back (see reddit.com/kn6wff/ which caused this investigation).

The function number: N/A
The complete error text: N/A
The window affected: Class design
What you were doing at the time: See steps to reproduce
Conventional or TN start: doesn't matter
Random or Real Stars: doesn't matter
Is your decimal separator a comma?: dot
Is the bug is easy to reproduce, intermittent or a one-off?: always reproducible
If this is a long campaign - say 75 years or longer - let me know the length of the campaign as well: doesn't matter

Steps to reproduce:
Expected behaviour: When designing ships, clicking the "Obso comp" while an evergreen component is selected should either:

SJW: The Obso Comp button is now only displayed for race tech, not for basic components
Title: Re: v1.12.0 Bugs Thread
Post by: Lord Solar on January 02, 2021, 10:41:11 PM
Minor bug/ gripe.

When you capture a NPR ship or a ship from another empire the design is unlocked. This means you can add whatever you want to it without SM. Captured designs should be locked.

SJW: Fixed
Title: Re: v1.12.0 Bugs Thread
Post by: kilo on January 03, 2021, 03:23:11 AM
Possible deployment time bug and survivors.

I have a  build a cruiser fleet with two cruisers, which carry one rescue craft with 2000 cryo crew berth each. They rescued 138 and 233 survivors respectively and landed back on their assigned ships. Now one of the Cls appears to have insufficient crew accommodation.

SJW: When parasites land on a carrier, any survivors are transferred to the mothership.
Title: Re: v1.12.0 Bugs Thread
Post by: tobijon on January 05, 2021, 03:24:22 AM
When trying to change the order in which components are repaired after combat I got an error message: 1.12.0 Function #991: unable to cast object of type 'fr' to type 'ay'.
Title: Re: v1.12.0 Bugs Thread
Post by: Droll on January 05, 2021, 10:01:41 AM
When trying to change the order in which components are repaired after combat I got an error message: 1.12.0 Function #991: unable to cast object of type 'fr' to type 'ay'.

What type of components specifically were you trying to reorder?
Title: Re: v1.12.0 Bugs Thread
Post by: tobijon on January 05, 2021, 11:00:04 AM
I was trying to prioritize the engine over the fire control
Title: Re: v1.12.0 Bugs Thread
Post by: brevduva on January 05, 2021, 01:59:13 PM
The function number: #1170 at startup, then #1168 before game loads.  Same error message on both.
The complete error text: "The given key was not present in the dictionary"
The window affected: Game startup
What you were doing at the time: Starting the game
Conventional or TN start: TN
Random or Real Stars: Random
Is your decimal separator a comma?: No
Is the bug is easy to reproduce, intermittent or a one-off: No idea, tried to recreate from a backup but no success
Campaign length: 5 december 0065 Years


Notes on attempted normal play:
2 november - added Fuel production 80. 000 liters to research queue
10 november - removed orders from Freighter "Loki UPS 003", changed to autoroute to . Sol and send message when arrived
- removed last order from "Loki UPS 004" ("JP1: Rome (JG): Standard Transit", last order after change is now "Scania: Refuel at colony")
- added orders to "Loki UPS 005": load mines on mercury, autoroute to Londinium, unload all installations on London, autoroute to . Sol, Scania: refeul from colony.  Repeat orders 1 time
20 november - 4 Heimdal refitted to Heimdal MkII.  Started refitting another 4 Heimdal
25 november - Gas removed from Athens, changed to add Water vapour (0. 2)
5 december - Removed all old unit templates from an existing Formation template, made new unit templates with updated tech, added the new ones to old Formation template
- renamed 8 old existing Formations (not templates)
Processed two 5-day increments to allow for the construction cycle to properly progress.
12 december - Saved the game, exited, restarted game, no issues encountered.

I don't remember if there was anything different I did or if maybe there was an event that fired.  If it did I don't know how to recreate it.  I have the different save files if necessary (save with error, backup save from a couple of months earlier, save with time progressed without interference, save with attempted normal play according to above notes)

Sidenote: I encoutered a similar error messages (#1170 and #3056) in this same game yesterday, further along in time (67 years).  Back then I also, upon loading the game, found 15+ systems without system bodies.  Having no idea what caused it, I reverted back to an earlier save, this one 3 years earlier ;_;, and was hoping that it wouldn't happen again.  But here I am. . .
Title: Re: v1.12.0 Bugs Thread
Post by: Alno on January 06, 2021, 05:34:37 AM
Hey,

is it intentional that gravitational/geological sensors come with so many MSP included, that they increase a ships maintainance life instead of reducing it? The effect increases with the sensor's tech level.   Might not be a bug, but more of a balancing thing? Not quite sure where the right place to post this is. 

Edit: I just read the maintainance post and now i THINK i just have a good failure modifier?
Title: Re: v1.12.0 Bugs Thread
Post by: Froggiest1982 on January 06, 2021, 02:44:23 PM
Hey,

is it intentional that gravitational/geological sensors come with so many MSP included, that they increase a ships maintainance life instead of reducing it? The effect increases with the sensor's tech level.   Might not be a bug, but more of a balancing thing? Not quite sure where the right place to post this is. 

Edit: I just read the maintainance post and now i THINK i just have a good failure modifier?

I am not really sure I understood, however, currently your MSP amount are due to the engineering (you something like 27 of them). There are 2 ways to increase your MSP: add engineering which will also reduce your AFR and IFR or, if you are satisfied with the current AFR and IFR rate and you wish to add MSP only, you have Maintenance Storages.

Off-Topic: show
Also, if you are really trying to keep that ship around for 10 years you may need a bit more MSP as the ones you have are based on a fixed value as the Maint calculator on the ship view is not really super reliable. You AFR increase the double every year so for instance, the second year your ship will have an AFR of 62%, the third 93% and so on. Your 3700 MSP are then just above the bare minimum assuming a linear failure rate, which we can assume you won't get after the 5th year in space. I would consider keeping it around the 4,000 even 5,000 MSP mark, just to be sure.
Title: Re: v1.12.0 Bugs Thread
Post by: Bremen on January 06, 2021, 10:23:54 PM
When firing at STO units with ships, the accuracy appears to be the same regardless of range. It's still fairly low, I assume because of fortification and terrain bonuses, but it appears to remain the same regardless of how close you get. This is a significant penalty to STO units.
Title: Re: v1.12.0 Bugs Thread
Post by: nuclearslurpee on January 06, 2021, 11:02:47 PM
When firing at STO units with ships, the accuracy appears to be the same regardless of range. It's still fairly low, I assume because of fortification and terrain bonuses, but it appears to remain the same regardless of how close you get. This is a significant penalty to STO units.

Someone else can confirm but I believe this is intentional as a stationary target on a planet is very easy to hit compared to a ship moving at 1000s of km/s. Fortification and terrain serve as the difficulty in this case rather than speed and erratic motion.
Title: Re: v1.12.0 Bugs Thread
Post by: Bremen on January 07, 2021, 12:07:55 AM
When firing at STO units with ships, the accuracy appears to be the same regardless of range. It's still fairly low, I assume because of fortification and terrain bonuses, but it appears to remain the same regardless of how close you get. This is a significant penalty to STO units.

Someone else can confirm but I believe this is intentional as a stationary target on a planet is very easy to hit compared to a ship moving at 1000s of km/s. Fortification and terrain serve as the difficulty in this case rather than speed and erratic motion.

If so I'd hope it could be adjusted into just some kind of accuracy bonus, because flat out eliminating the range penalty is effectively a massive range bonus against STO units, and makes it easy to pick them off from a range where they're either unable or very unlikely to hit you. It's true they get a 25% range bonus, but that means if you're even 1 tech level above them you can sit at max range where they have 1% chance to hit and bombard them with essential invulnerability.
Title: Re: v1.12.0 Bugs Thread
Post by: nuclearslurpee on January 07, 2021, 01:08:28 AM
If so I'd hope it could be adjusted into just some kind of accuracy bonus, because flat out eliminating the range penalty is effectively a massive range bonus against STO units, and makes it easy to pick them off from a range where they're either unable or very unlikely to hit you. It's true they get a 25% range bonus, but that means if you're even 1 tech level above them you can sit at max range where they have 1% chance to hit and bombard them with essential invulnerability.

In terms of realism, that sounds quite fair to me. It's much harder for a stationary target to hit an erratically-moving target at range than vice versa, after all.

In terms of balance, I'm not sure. This may simply balance STOs versus other defensive options or it may make them virtually worthless, I'm not sure. They seem to work fine currently. On the other hand, it does seem silly that space stations with 0 (1) km/s speed do benefit from BFC accuracy drop-off but STOs do not, although stations do lack terrain bonuses and cost valuable MSP to maintain, so it seems alright from a balance perspective.
Title: Re: v1.12.0 Bugs Thread
Post by: punchkid on January 07, 2021, 08:49:34 AM
Adding a report for this for completeness sake.

If you start building a ship in your shipyard at earth, then pause said ship, tow the shipyard somewhere else (Luna in my case)
You can then resume building paused ships and even though the shipyard was moved to a different body the ship that was paused will continue building on the body where you started the job, and will use resources from that body as well.
This was done with a comercial shipyard btw, if that matters. Have not tested with a military one.

Not really a big deal imo. But a bit odd in any event. Maybe at least worth a mention in known issues.
Title: Re: v1.12.0 Bugs Thread
Post by: xenoscepter on January 07, 2021, 06:36:09 PM
The function number
 - N/A
The complete error text
 - N/A
The window affected
 - Intelligence & Foreign Relations / Main Game Window (System View???)
What you were doing at the time
 - Exploring the cosmos, lookin' for dem aliums. :)
Conventional or TN start
 - TN Start
Random or Real Stars
 - Random
Is your decimal separator a comma?
 - Negative.
Is the bug is easy to reproduce, intermittent or a one-off?
 - Unknown.
If this is a long campaign - say 75 years or longer - let me know the length of the campaign as well
 - 62 Years

 - I believe this bug is related to the generation of Rakhas, but am unsure and as such am posting this bug here for completeness. One of my NPRs blew up a Diplo Ship when I went to establish contact, and I decided to re-load from the point beforehand to try tailing the planet instead. Long-short, they dun disappeared, the whole population is just... gone. No idea what they had or anything, so yeah... I'm going to attempt to attach my .db, but the forum has been weird about file sizes AFAIK.

 - ADDENDUM: One thing I forgot to add, upon re-loading old .db files, AKA the save backups, the were nowhere to be found. As annoying as this is, I petition to add a Roanoke Colony style event, at like 0.001% or some stupidly low chance, where a whole colony just... vanishes without a trace. That'd be spoopy.

 - UPDATE: It seems my Standing Orders have stopped working too... weird...
Title: Re: v1.12.0 Bugs Thread
Post by: ZimRathbone on January 08, 2021, 07:26:38 AM

 - I believe this bug is related to the generation of Rakhas, but am unsure and as such am posting this bug here for completeness. One of my NPRs blew up a Diplo Ship when I went to establish contact, and I decided to re-load from the point beforehand to try tailing the planet instead. Long-short, they dun disappeared, the whole population is just... gone. No idea what they had or anything, so yeah... I'm going to attempt to attach my .db, but the forum has been weird about file sizes AFAIK.

 - ADDENDUM: One thing I forgot to add, upon re-loading old .db files, AKA the save backups, the were nowhere to be found. As annoying as this is, I petition to add a Roanoke Colony style event, at like 0.001% or some stupidly low chance, where a whole colony just... vanishes without a trace. That'd be spoopy.

 - UPDATE: It seems my Standing Orders have stopped working too... weird...

in my latest 1.12 campaign I had a similar event, geosurvey ship goes to investigate near habitable planet in the system next door to the homeworld, arrives over planet, detects alien race and is promptly blown to bits by aliens (by STO's I think - there were no reports of alien ships).

When I return with ships loaded for bear (this was the only exit JP from my home system at the time) there is no sign of the culprits.

Checking the Database there is a record for the alien race but nothing attached as far as I have seen, there was nothing else unique about that planet, no resources were found (a neighboring planet did have a Ancient Artifact for Energy Weapons which I have had limited ability to exploit properly to date)

I didn't notice anything to do with standing orders.  This was about 6 years into the campaign, random stars and UK number formats.
Title: Re: v1.12.0 Bugs Thread
Post by: TheTalkingMeowth on January 08, 2021, 11:15:49 AM

 - I believe this bug is related to the generation of Rakhas, but am unsure and as such am posting this bug here for completeness. One of my NPRs blew up a Diplo Ship when I went to establish contact, and I decided to re-load from the point beforehand to try tailing the planet instead. Long-short, they dun disappeared, the whole population is just... gone. No idea what they had or anything, so yeah... I'm going to attempt to attach my .db, but the forum has been weird about file sizes AFAIK.

 - ADDENDUM: One thing I forgot to add, upon re-loading old .db files, AKA the save backups, the were nowhere to be found. As annoying as this is, I petition to add a Roanoke Colony style event, at like 0.001% or some stupidly low chance, where a whole colony just... vanishes without a trace. That'd be spoopy.

 - UPDATE: It seems my Standing Orders have stopped working too... weird...

in my latest 1.12 campaign I had a similar event, geosurvey ship goes to investigate near habitable planet in the system next door to the homeworld, arrives over planet, detects alien race and is promptly blown to bits by aliens (by STO's I think - there were no reports of alien ships).

When I return with ships loaded for bear (this was the only exit JP from my home system at the time) there is no sign of the culprits.

Checking the Database there is a record for the alien race but nothing attached as far as I have seen, there was nothing else unique about that planet, no resources were found (a neighboring planet did have a Ancient Artifact for Energy Weapons which I have had limited ability to exploit properly to date)

I didn't notice anything to do with standing orders.  This was about 6 years into the campaign, random stars and UK number formats.

This is a known bug; Rakhas don't properly persist across save and reload.
Title: Re: v1.12.0 Bugs Thread
Post by: Steve Walmsley on January 09, 2021, 10:07:41 AM
Actually less of a bug and more of an unexpected behavior that I strongly doubt is working as intended: After further testing, this is in fact a bug.

As part of my campaign setup I have six survey ships requiring rank 3 to command (rank 1 being the lowest). In the Commanders window, I have run an auto-assign by clicking the "Reassign Naval" button. Only four of my six survey ships receive a commander, despite the fact that my two rank-3 commanders with the highest Survey stats are not assigned to any ship at all.

I notice several things:
  • My survey ships have missile launchers attached for the purpose of dropping buoys, with MFC, magazine, and an ordnance load.
  • Each survey ship also has 2x Boat Bay for the purpose of carrying a single fighter-size survey craft.
  • The unemployed commanders in question do not have any skill in Crew Training, Reaction, Engineering, or Tactical.
  • Each commander assigned to the survey ship possesses one of these four skills. In fact, one of the commanders assigned lacks any survey skill.

Thus, my conjecture is that the auto-assign is treating my survey ships as warships due to the missile launchers (or perhaps the boat bays?). This strikes me as undesired if not unintended behavior since the auto-assign considers survey ships a higher priority, thus it makes no sense that the algorithm to determine ship type ranks weapons/PPV higher than survey sensors. Certainly, I would think a player is more likely to design a survey ship with weapons than a warship with survey sensors, and the game should account for this!

I have previously noted a similar behavior with orbital mining platforms with an included cargo bay (for a mass driver), which is treated as a freighter and assigned a Logistics commander instead of a Mining commander, even though mining ships are supposed to be a higher priority than freighters. I wonder if the algorithm which determines the ship type for officer assignment is getting its assignments backwards?

----

ADDENDUM: I did a little bit of testing. I designed and built the following ship:
Quote
Galorfing C class Deep Space Survey Ship      27,881 tons       57 Crew       503.9 BP       TCS 558    TH 400    EM 0
717 km/s      Armour 1-81       Shields 0-0       HTK 13      Sensors 0/0/1/1      DCR 1      PPV 0
Maint Life 0.00 Years     MSP 11    AFR 6218%    IFR 86.4%    1YR 3,223    5YR 48,349    Max Repair 100.0000 MSP
Cargo 25,000    Cargo Shuttle Multiplier 5   
Captain of the List    Control Rating 1   BRG   
Intended Deployment Time: 3 months    Morale Check Required   

Commercial Inertial Fusion Drive  EP400.00 (1)    Power 400.0    Fuel Use 2.80%    Signature 400.00    Explosion 5%
Fuel Capacity 250,000 Litres    Range 57.7 billion km (931 days at full power)

Geological Survey Sensors (1)   1 Survey Points Per Hour
Gravitational Survey Sensors (1)   1 Survey Points Per Hour

This design is classed as a Military Vessel for maintenance purposes
The auto-assignment via "Reassign Naval" button gave this ship a commander with Crew Training 50 and Reaction 20 - not a Survey specialist.

However, I built the following ship:
Quote
Galorfing C-2 class Deep Space Survey Ship      2,201 tons       42 Crew       363.1 BP       TCS 44    TH 400    EM 0
9087 km/s      Armour 1-15       Shields 0-0       HTK 11      Sensors 0/0/1/1      DCR 1      PPV 0
Maint Life 2.12 Years     MSP 103    AFR 39%    IFR 0.5%    1YR 31    5YR 461    Max Repair 100.0000 MSP
Captain of the List    Control Rating 1   BRG   
Intended Deployment Time: 3 months    Morale Check Required   

Commercial Inertial Fusion Drive  EP400.00 (1)    Power 400.0    Fuel Use 2.80%    Signature 400.00    Explosion 5%
Fuel Capacity 250,000 Litres    Range 731.5 billion km (931 days at full power)

Geological Survey Sensors (1)   1 Survey Points Per Hour
Gravitational Survey Sensors (1)   1 Survey Points Per Hour

This design is classed as a Military Vessel for maintenance purposes
This ship class receives Survey-spec commanders as expected. The only difference in the designs was the cargo hold and shuttles in the former. There is no logical reason that a cargo hold would cause a survey ship to be reclassified as a warship (perhaps as a freighter though that would still be non-ideal). Thus, I now consider this a proper bug and not merely an undesired behavior.

The game assigns a main function to a ship class for auto-assignment. The code checked for weapons before checking for survey sensors. I've now changed it so a ship will be classed as a survey ship if the size of survey sensors exceeds the size of weapons. I've also added a line to the class summary so you can see the class function for assignment purposes.
Title: Re: v1.12.0 Bugs Thread
Post by: Steve Walmsley on January 09, 2021, 10:29:53 AM
I've been stuck in 2 hour turns for a while now, while trying to do 5 day increments. This is on random stars, period decimal separator, TN start, about 65 years into game. I thought it was just the NPRs playing nuclear rocket tag across the galaxy, until it continued for over 5 ingame days. I tried a 30 day increment, and time advanced for six hours. It seems that something is causing an interrupt every sub-pulse, and when I checked in the database log to see what was happening, I found a few NPR ships trying and failing to complete standing orders, as well as a few ship detections every increment. I turned off detection, but that didn't solve the increments.

I saw a post earlier on similar to this one where it was NPR civilians trying to load cargo, but these are military vessels and what seem to be construction ships.

Off-Topic: show
GE Ajonpaa 002 is unable to carry out its primary standing order: Refuel from Colony or Hub (All)
Stabilisation Squadron 001 is unable to carry out its primary standing order: Build Jump Gate at Nearest Jump Point
Stabilisation Squadron 003 is unable to carry out its primary standing order: Build Jump Gate at Nearest Jump Point
CLE Aura II 025 is unable to carry out its primary standing order: Join Operational Group
CLE Aura II 026 is unable to carry out its primary standing order: Join Operational Group
CLE Aura II 027 is unable to carry out its primary standing order: Join Operational Group
CLE Aura II 028 is unable to carry out its primary standing order: Join Operational Group
CLE Aura II 029 is unable to carry out its primary standing order: Join Operational Group
CLE Aura II 030 is unable to carry out its primary standing order: Join Operational Group
CLE Aura II 031 is unable to carry out its primary standing order: Join Operational Group
CLE Aura II 032 is unable to carry out its primary standing order: Join Operational Group
CJ Harjus III 001 is unable to carry out its primary standing order: Join Operational Group
CJ Harjus III 002 is unable to carry out its primary standing order: Join Operational Group
CJ Harjus III 003 is unable to carry out its primary standing order: Join Operational Group
CJ Harjus III 004 is unable to carry out its primary standing order: Join Operational Group
CJ Harjus III 005 is unable to carry out its primary standing order: Join Operational Group
CJ Harjus III 006 is unable to carry out its primary standing order: Join Operational Group
CJ Harjus III 007 is unable to carry out its primary standing order: Join Operational Group
CJ Harjus III 008 is unable to carry out its primary standing order: Join Operational Group
GE Alfheim 001 is unable to carry out its primary standing order: Refuel from Colony or Hub (All)
GE Alfheim 002 is unable to carry out its primary standing order: Refuel from Colony or Hub (All)
SS Alfhild 001 is unable to carry out its primary standing order: Survey Next Three System Locations
Stabilisation Squadron - Beam Escort 001 is unable to carry out its primary standing order: Build Jump Gate at Nearest Jump Point
Stabilisation Squadron - Beam Escort 002 is unable to carry out its primary standing order: Build Jump Gate at Nearest Jump Point
SS Binjai 001 is unable to carry out its primary standing order: Refuel from Colony or Hub (All)


I can attach the database if that helps.

Do NPR failed orders contribute to interrupts? Sorry but I still don't know after 10 years! :D

No, they don't cause interrupts. There are very few AI interrupts and they are related to combat, the detection of hostile contacts and the detection of new jump points.
Title: Re: v1.12.0 Bugs Thread
Post by: Steve Walmsley on January 09, 2021, 10:41:46 AM
Quote from: TheTalkingMeowth link=topic=11945.  msg144947#msg144947 date=1608578995
Quote from: ivangorin21 link=topic=11945.  msg144945#msg144945 date=1608578569
I think there was a warning when I was saving, but it saved successfully.    I don’t remember what it was exactly, is there a log or warnings/errors?

I don't think errors are logged anywhere. 

If there was an error message while saving, that was probably related to whatever weirdness deleted all these ship classes. 

Does the game give an error if you try to save again?

I have started a new game, and this error appeared after a few 30 day skips.   Do you think it could be related to the previous game bug? I think it is similar to the message I got when saving before

That function number is for calculation of orbit. I could only see that error appearing if the parent star had somehow been deleted.
Title: Re: v1.12.0 Bugs Thread
Post by: Steve Walmsley on January 09, 2021, 11:45:47 AM
Ships with destroyed components such as box launchers and magazines are able to load the respective ammo resulting in a percentage of ordnance higher than 100%.

The correct behaviour should be that such ships shouldn't be able to load any ordnance for destroyed components (>100% damage on damage control screen)

It is okay for damaged ones (<100% damage on damage control screen)

How did you load the ordnance. From a colony or a collier?
Title: Re: v1.12.0 Bugs Thread
Post by: Steve Walmsley on January 09, 2021, 11:59:33 AM
I'm not sure if this is a known issue, but if a fire control is destroyed while set to open fire, it can't be told to cease fire, leading to endless 5 second increments forcing you to SM repair it and turn it off again.

I can't reproduce this one - anyone else having similar problems?

There is existing code to set any destroyed fire to cease fire.
Title: Re: v1.12.0 Bugs Thread
Post by: xenoscepter on January 09, 2021, 02:15:50 PM
I'm not sure if this is a known issue, but if a fire control is destroyed while set to open fire, it can't be told to cease fire, leading to endless 5 second increments forcing you to SM repair it and turn it off again.

I can't reproduce this one - anyone else having similar problems?

There is existing code to set any destroyed fire to cease fire.

 - Is it Beam FCS or Missile FCS?
Title: Re: v1.12.0 Bugs Thread
Post by: yourITguy on January 09, 2021, 02:33:38 PM
Quote from: TheTalkingMeowth link=topic=11945. msg142375#msg142375 date=1603907025
Quote from: Ektor link=topic=11945. msg142372#msg142372 date=1603904182
I'm not sure whether this was already posted, but the conditional order "Refuel, Resupply and Overhaul at Colony" gives off errors #722 and #730 "Object reference was not set to instance of an object" when the conditions trigger.  This leads the fleet that takes the order to return to a colony and overhaul, however they don't refuel and resupply.

The specific situation if you want to replicate the bug is the following: I had a jump capable survey ship with both geo and grav modules set on the following standing orders: 1.  Survey next system body 2.  Survey next survey location 3.  If fuel less than 40% - Refuel at colony or hub (all) 4.  When deployment time exceeded - Refuel, Resupply and Overhaul at Colony.

It's been posted, but a little extra information would be useful.  Can you describe how this interacts with stabilized jump points? We're not sure if it happens if the path back is fully stabilized.

I've experienced this bug as well.  In my case, I had jump capable survey ships in other systems with no JP stabilization yet (early game).  I lost two of the initial three due to lack of MSP before I noticed that the refuel and resupply order wasn't being added to the orders list when the error happens.

Edit: The order works fine as long as the colony it is going to overhaul from is in the same system.
Title: Re: v1.12.0 Bugs Thread
Post by: nuclearslurpee on January 09, 2021, 03:21:46 PM
The game assigns a main function to a ship class for auto-assignment. The code checked for weapons before checking for survey sensors. I've now changed it so a ship will be classed as a survey ship if the size of survey sensors exceeds the size of weapons. I've also added a line to the class summary so you can see the class function for assignment purposes.

This instantly becomes my favorite change of 1.13 and all my future admirals in charge of BuPers thank you from the bottom of their warmongering peaceful scientific and exploration-loving little hearts.

However I do want to note that the actual bug I was noting was that placing a Cargo Hold on a survey ship, with no other changes, caused the ship to be recognized as a warship despite lacking any weapons, rather than either a survey ship (preferred behavior) or a freighter requiring a Logistics commander (not preferred but makes sense).

I suspect the listed fix here probably resolves that as well but I wanted to clarify just in case.

(Also on a side note if you'd like to adjust the priorities while you're in that bit of the code so that my OMPs with a cargo hold to tote a mass driver around are recognized as miners rather than freighters I would not be unappreciative...  ;) )
Title: Re: v1.12.0 Bugs Thread
Post by: Steve Walmsley on January 09, 2021, 05:09:47 PM
The game assigns a main function to a ship class for auto-assignment. The code checked for weapons before checking for survey sensors. I've now changed it so a ship will be classed as a survey ship if the size of survey sensors exceeds the size of weapons. I've also added a line to the class summary so you can see the class function for assignment purposes.

This instantly becomes my favorite change of 1.13 and all my future admirals in charge of BuPers thank you from the bottom of their warmongering peaceful scientific and exploration-loving little hearts.

However I do want to note that the actual bug I was noting was that placing a Cargo Hold on a survey ship, with no other changes, caused the ship to be recognized as a warship despite lacking any weapons, rather than either a survey ship (preferred behavior) or a freighter requiring a Logistics commander (not preferred but makes sense).

I suspect the listed fix here probably resolves that as well but I wanted to clarify just in case.

(Also on a side note if you'd like to adjust the priorities while you're in that bit of the code so that my OMPs with a cargo hold to tote a mass driver around are recognized as miners rather than freighters I would not be unappreciative...  ;) )

It can't be recognised as a warship without weapons. I suspect it was recognised as a freighter and just happened to gain a commander with bonuses that could be used for warships. When all commanders with the right bonuses have been assigned, the automated assignment does three more runs through all military ships without commanders, using reaction, engineering and tactical bonuses. So the ship would have been classed as a freighter but no commanders with logistics were available, but then it would also have been treated as a military ship without a commander and assigned one of the remaining available commanders.
Title: Re: v1.12.0 Bugs Thread
Post by: Cosinus on January 10, 2021, 09:54:23 AM
[...] There seems to be an issue with the pathfinding algorithm. I have not tracked down where it comes from exactly, but I just noticed this behaviour in one location in a big multi star system.
I noticed that in this specific location, when setting 2 fleets to go to the location of the other, the pathfinding algorithm lets them end up in the middle of nowhere.

(https://i.imgur.com/SrVxapZ.png)

As you can see, the ships do not go towards each other in a straight line, but rather go in a completely different direction.
DB is here: https://drive.google.com/file/d/16U8NyUzBkcZ9gkN58JsPP6CGa4nXBDb7/view?usp=sharing
To reproduce, set the Pacifica to go to the location of the Triton, and vice versa. Then advance time.

SJW: Working as intended. When you give a fleet orders to move to another fleet, it sets an intercept course to move to where the target fleet will be in the future, rather than where it is now.

I disagree that this is working as intended. When you intercept a single fleet, the algorithm works, because the target of the intercept has an unchanging course.
In this situation, both fleets are trying to intercept each other with no initial velocity and are thus changing their course to meet the other fleet, which causes the other fleet to change course and so on. There should be a special case in the pathfinding algorithm for this, that prevents this loop and just sets the ships on a straight course towards each other. As you can see in my example, currently they take massive detours.
Title: Re: v1.12.0 Bugs Thread
Post by: nuclearslurpee on January 10, 2021, 12:32:02 PM
I disagree that this is working as intended. When you intercept a single fleet, the algorithm works, because the target of the intercept has an unchanging course.
In this situation, both fleets are trying to intercept each other with no initial velocity and are thus changing their course to meet the other fleet, which causes the other fleet to change course and so on. There should be a special case in the pathfinding algorithm for this, that prevents this loop and just sets the ships on a straight course towards each other. As you can see in my example, currently they take massive detours.

I have to agree. If both fleets start at rest (or 1 km/s) they should start off in a straight line toward each other. This shouldn't even be a special case: fleet A should see that fleet B is not moving and set a direct course, then fleet B should plot the intercept and set...a direct course.

When both fleets start from zero and go off at an odd angle it makes no sense and requires ticky-tacky micromanagement to solve, i.e. set one fleet to intercept, advance 5s, then give the other fleet its orders. Easy by itself, but also very easily lost in the shuffle of a dozen other events on that turn.
Title: Re: v1.12.0 Bugs Thread
Post by: Squigles on January 10, 2021, 02:08:13 PM
1.12, no mods, conventional start.

Not actually sure if this is a bug.

Was playing a reduced tech conventional start. By the time I researched Trans-Newtonian technology and Nuclear Thermal Engines, I had established thriving colonies on Luna and Mars with "Luxury Passenger Accomodation" (incidentally, it's spelled Accommodation, but that's not the bug) equipped ships.

The civilian sector promptly kicked into gear and began building civilian ships. The "bug" is that those civilian ships included cryogenics equipped colony ships despite the technology for that not yet existing.
Title: Re: v1.12.0 Bugs Thread
Post by: Droll on January 10, 2021, 03:46:39 PM
1.12

Fleets created under an admin command that is not on earth will spawn on the correct body with the HQ, however they will not remain in orbit unless you use SM teleport to teleport them to the orbit - kind of defeating the point.

SJW: Fixed
Title: Re: v1.12.0 Bugs Thread
Post by: StarshipCactus on January 11, 2021, 06:39:46 AM
I have a strange bug, not game breaking, nor does it create an error. It is just mildly annoying.

The function number: No error message.
The complete error text : see above.
The window affected: As far as I can tell, only the system display window.

What you were doing at the time: I was trying to set up a multi faction alien game. I used SM to edit the system and some of the minerals. To edit the minerals, I clicked the button that gives one faction a full geo survey for that system. When I was done for the day, I clicked the button to forget the Geo survey, clicked the button to survey one body (The homeworld of course.) While I was making these edits, I was viewing the system from the perspective of just one nation. (Faction_1 for now.) When I came back the next day to keep editing, I noticed that the whole system was surveyed. I though I had forgotten to forget the geo survey, so I ignored it. It kept happening though, every time I close the game, the entire system is surveyed for Faction_1 and only Faction_1. The other factions are fine. Could it be that forgetting the geo survey button does not make the correct DB edit?

Conventional or TN start: Conventional.
Random or Real Stars: Random
Is your decimal separator a comma?: My decimal separator is correct.
Is the bug is easy to reproduce, intermittent or a one-off?: I have not tried to reproduce it.
If this is a long campaign - say 75 years or longer - let me know the length of the campaign as well: It happened before I had progressed any time. I have progressed a few years and it still happens.

Edited to make it easier to read.
Title: Re: v1.12.0 Bugs Thread
Post by: Jorgen_CAB on January 13, 2021, 04:16:08 AM
Not sure if anyone mentioned this but Sub-fleets don't seem to remember being attached to sub-fleets after you close and restart the game. All the sub-fleets are directly attached to the fleet and not whichever sub-fleet it was attached to once you save and restart.

Or I'm doing something wrong in my game,  but I usually have deep sub-fleet systems just don't close Aurora down all that often so I never bothered reporting it before.
Title: Re: v1.12.0 Bugs Thread
Post by: Droll on January 13, 2021, 04:19:49 AM
Not sure if anyone mentioned this but Sub-fleets don't seem to remember being attached to sub-fleets after you close and restart the game. All the sub-fleets are directly attached to the fleet and not whichever sub-fleet it was attached to once you save and restart.

Or I'm doing something wrong in my game,  but I usually have deep sub-fleet systems just don't close Aurora down all that often so I never bothered reporting it before.

I can at least second this but just know that in general aurora is bad at handling multi-layer sub-fleet hierarchies. That's why I try to avoid such OOBs.
Title: Re: v1.12.0 Bugs Thread
Post by: Black on January 13, 2021, 05:17:11 AM
Not sure if anyone mentioned this but Sub-fleets don't seem to remember being attached to sub-fleets after you close and restart the game. All the sub-fleets are directly attached to the fleet and not whichever sub-fleet it was attached to once you save and restart.

Or I'm doing something wrong in my game,  but I usually have deep sub-fleet systems just don't close Aurora down all that often so I never bothered reporting it before.

This is unfortunately bugged from beginning, I reported it in previous versions, but it either got lost between other bugs, or Steve never got to implementing fix for this.
Title: Re: v1.12.0 Bugs Thread
Post by: Droll on January 13, 2021, 06:00:41 AM
1.12

Ship history display for fighter strike groups is completely borked.

Normal history approximately looks something like this:
Code: [Select]
Ships destroyed 3
Military tonnage destroyed 16372
Commercial tonnage destroyed 43021

What I expect an armed carriers history to look like:
Code: [Select]
Ships destroyed 3
Military tonnage destroyed 16372
Commercial tonnage destroyed 43021

Ships destroyed (SG) 7
Military tonnage destroyed (SG) 78134

What an armed carriers history actually looks like:
Code: [Select]
Ships destroyed 3
Military tonnage destroyed 16372
Commercial tonnage destroyed 43021

Ships destroyed 1
Ships destroyed 1
Ships destroyed 1
Ships destroyed 1
Ships destroyed 1
Ships destroyed 1
Ships destroyed 1
Military tonnage destroyed 6271
Military tonnage destroyed 12632
Military tonnage destroyed 16822
Military tonnage destroyed 24823
Military tonnage destroyed 11234
Military tonnage destroyed 6271
Military tonnage destroyed 6271

Furthermore, the history for fighters themselves is also borked

What I expect:
Code: [Select]
Ships destroyed 3
Military tonnage destroyed 16372

What I see instead:
Code: [Select]
Ships destroyed (SG) 1
Ships destroyed (SG) 1
Ships destroyed (SG) 1
Military tonnage destroyed (SG) 16372
Military tonnage destroyed (SG) 16372
Military tonnage destroyed (SG) 16372
Title: Re: v1.12.0 Bugs Thread
Post by: Steve Walmsley on January 13, 2021, 10:29:23 AM
1.12

Ship history display for fighter strike groups is completely borked.


This one was already fixed

From changes log: "Fixed a bug in Ship Measurement for parasites that resulted in many records of the same type, instead of one."
Title: Re: v1.12.0 Bugs Thread
Post by: Droll on January 13, 2021, 11:33:15 AM
1.12

Ship history display for fighter strike groups is completely borked.


This one was already fixed

From changes log: "Fixed a bug in Ship Measurement for parasites that resulted in many records of the same type, instead of one."

D'oh
Title: Re: v1.12.0 Bugs Thread
Post by: Froggiest1982 on January 13, 2021, 12:28:51 PM
Ships with destroyed components such as box launchers and magazines are able to load the respective ammo resulting in a percentage of ordnance higher than 100%.

The correct behaviour should be that such ships shouldn't be able to load any ordnance for destroyed components (>100% damage on damage control screen)

It is okay for damaged ones (<100% damage on damage control screen)

How did you load the ordnance. From a colony or a collier?

Hi Steve, a colony. Thanks.
Title: Re: v1.12.0 Bugs Thread
Post by: xenoscepter on January 14, 2021, 12:19:05 PM
 - These bugs are more quibbles than bugs, but they are still technically bugs ASFAIK so I'll put 'em here. I didn't bother with the whole spiel of stuff as these are super straightforward and have been around since 1.0

 - A: Adding a Missile FCS throws a "Ship has Missile FCS, but no Missile Weapons" when you have Fighter Pods installed. Annoying, but not game breaking.

 - B: Research Window has an extra clickable field above where the first research project would show up, this field has no function and seems like it was not intended to be clickable.

Cheers! ;D
Title: Re: v1.12.0 Bugs Thread
Post by: ohrodr on January 14, 2021, 05:02:41 PM
I hate to say something about this, but it does trip me up everytime i read it.

"The ruined city on $planet has been fully surveyed. . .  their language and symboloy. . . "

I think symbology was the intended word.
Title: Re: v1.12.0 Bugs Thread
Post by: Droll on January 14, 2021, 05:03:59 PM
I hate to say something about this, but it does trip me up everytime i read it.

"The ruined city on $planet has been fully surveyed. . .  their language and symboloy. . . "

I think symbology was the intended word.

There should be a dedicated typo thread where you can post this instead, in fact, its one of the pinned threads in the bug report sub-forum
Title: Re: v1.12.0 Bugs Thread
Post by: kuhaica on January 14, 2021, 06:16:38 PM
I have 5 total empires on earth at the very start of the game, they range from pops of 300m to 1500m. Each population has a PPV value equal to it's population, I at first figured this was working as intended but was told to make a report.

Additional Information:
Conventional Start, Real Stars, Human. I made 7 races total all with the Homeworld of Earth. I move 2 of the populations off-world and change those Human populations to another body setting it as a new capital. I have yet to make any turns and have not edited anything in the game files or relating to earth other than changing pop numbers.

I attempted to recreate the bug and was unable to. 2 Examples
(https://i.imgur.com/RZClXCz.png)

(https://i.imgur.com/ub8gBXJ.png)

So no idea what's going on here.
Title: Re: v1.12.0 Bugs Thread
Post by: TheTalkingMeowth on January 14, 2021, 07:24:43 PM
kuhaica, did you try the "Set capital" button?
Title: Re: v1.12.0 Bugs Thread
Post by: kuhaica on January 14, 2021, 07:40:57 PM
kuhaica, did you try the "Set capital" button?
It only works for 1 race at a time. All the others retain the PPV, then when I change it for another, it results in the previous losing it's capital status
Title: Re: v1.12.0 Bugs Thread
Post by: kuhaica on January 14, 2021, 07:45:26 PM
kuhaica, did you try the "Set capital" button?
It only works for 1 race at a time. All the others retain the PPV, then when I change it for another, it results in the previous losing it's capital status
Update... Afters messing around with it and going in order from the bottom of the list to the top of the list. It worked. I am confused. But sometimes I had to do them 1-2 times before it stayed
Title: Re: v1.12.0 Bugs Thread
Post by: papent on January 14, 2021, 10:39:21 PM
i'm not sure if this is a bug, haven't checked in VB6.

Reduced sized option for lasers ( Reduced-size Laser 0.75 Size / 4x Recharge & Reduced-size Laser 0.5 Size / 20x Recharge )
doesn't decrease size by  0.75 or 0.5 for 10cm lasers. It does however still increase the recharge time.

again not sure if this is actually a bug.

[The math as I see it 10cm lazer 3 HS or 150 tons reduced by 0.75 is 3 * 0.75 = 2.25 or reduced by 0.5 is 3 * 0.5 = 1.5]
Title: Re: v1.12.0 Bugs Thread
Post by: nuclearslurpee on January 14, 2021, 10:58:43 PM
i'm not sure if this is a bug, haven't checked in VB6.

Reduced sized option for lasers ( Reduced-size Laser 0.75 Size / 4x Recharge & Reduced-size Laser 0.5 Size / 20x Recharge )
doesn't decrease size by  0.75 or 0.5 for 10cm lasers. It does however still increase the recharge time.

again not sure if this is actually a bug.

[The math as I see it 10cm lazer 3 HS or 150 tons reduced by 0.75 is 3 * 0.75 = 2.25 or reduced by 0.5 is 3 * 0.5 = 1.5]

This was previously posted and attributed to a rounding behavior. I don't remember a response from Steve about this.
Title: Re: v1.12.0 Bugs Thread
Post by: TMaekler on January 16, 2021, 03:15:28 AM
Started a new campaign from a clean install but all race values for the starting race are set to zero. What did I wrong?

Edit:
Ok, found it. I had no race pictures in the race-folder. And that leads to the starting values for the race are all set to 0.
Title: Re: v1.12.0 Bugs Thread
Post by: brevduva on January 17, 2021, 09:07:44 AM
I'm experiencing a slowdown of the game.  For the last 2 months+ my game has been refusing too run increments above 6hrs.  30 days->6hrs, 5 days->2hrs, 1 day->30min, and so on.

People have on reddit have suggested that it's NPRs chasing each other over JPs and the only thing I can do is let the game run until it disappears.  Is there a garantie that it disappears? I've had it running on automated turns now for 2+ months, switching between 5sec and 5 day increments with no change.
Title: Re: v1.12.0 Bugs Thread
Post by: TheTalkingMeowth on January 17, 2021, 09:14:19 AM
I'm experiencing a slowdown of the game.  For the last 2 months+ my game has been refusing too run increments above 6hrs.  30 days->6hrs, 5 days->2hrs, 1 day->30min, and so on.

People have on reddit have suggested that it's NPRs chasing each other over JPs and the only thing I can do is let the game run until it disappears.  Is there a garantie that it disappears? I've had it running on automated turns now for 2+ months, switching between 5sec and 5 day increments with no change.
There is no guarantee. However, you can double check that this is happening and (possibly) do something about it.

Get a SQL database browser and open the .db file. Check out the FCT_GameLog table (filter for the GameID of the game you are currently playing; it's usually fairly easy to figure that out by looking at the names of the races involved). This is the regular old event logs you get in game, but it ALSO includes NPR events. Should help you discern the cause.

If it really is NPRs chasing each other through a JP, you need to get rid of one of the fleets. You can do it via DB editing, but I prefer to do it by creating a race and using spacemaster to explore to the relevant system. Then I spawn in a giant pile of lasers and blow up the offender. This avoids any weirdness from editing the DB.
Title: Re: v1.12.0 Bugs Thread
Post by: nuclearslurpee on January 17, 2021, 11:56:16 AM
I'm experiencing a slowdown of the game.  For the last 2 months+ my game has been refusing too run increments above 6hrs.  30 days->6hrs, 5 days->2hrs, 1 day->30min, and so on.

People have on reddit have suggested that it's NPRs chasing each other over JPs and the only thing I can do is let the game run until it disappears.  Is there a garantie that it disappears? I've had it running on automated turns now for 2+ months, switching between 5sec and 5 day increments with no change.
There is no guarantee. However, you can double check that this is happening and (possibly) do something about it.

Get a SQL database browser and open the .db file. Check out the FCT_GameLog table (filter for the GameID of the game you are currently playing; it's usually fairly easy to figure that out by looking at the names of the races involved). This is the regular old event logs you get in game, but it ALSO includes NPR events. Should help you discern the cause.

If it really is NPRs chasing each other through a JP, you need to get rid of one of the fleets. You can do it via DB editing, but I prefer to do it by creating a race and using spacemaster to explore to the relevant system. Then I spawn in a giant pile of lasers and blow up the offender. This avoids any weirdness from editing the DB.

I usually just take the offending fleet and change its XY position in space. It's possible that this does something to mess up the AI, but I don't think it should (and now I've jinxed it...), and it's an easy quick fix from the DB without appreciably unsettling the NPR vs NPR balance.
Title: Re: v1.12.0 Bugs Thread
Post by: RaDeus on January 17, 2021, 12:33:42 PM
Well I'd like to report my very first bug: Cargo Shuttle Bay disappeared from my list of components and as expected I was quite baffled by this.

After some troubleshooting (restarting the game, deleting the tech and insta-ing it back) I found out the reason: I had apparently marked the tech as obsolete so it didn't show up unless I ticked the show obsolete box.

This is clearly (my) user-error, but some techs just shouldn't be possible to mark as obsolete because they don't really change (I know it gets upgraded, but that doesn't change its name, its all in the background), like bridge and cargo shuttle bay.
Title: Re: v1.12.0 Bugs Thread
Post by: nuclearslurpee on January 17, 2021, 12:35:22 PM
Well I'd like to report my very first bug: Cargo Shuttle Bay disappeared from my list of components and as expected I was quite baffled by this.

After some troubleshooting (restarting the game, deleting the tech and insta-ing it back) I found out the reason: I had apparently marked the tech as obsolete so it didn't show up unless I ticked the show obsolete box.

This is clearly (my) user-error, but some techs just shouldn't be possible to mark as obsolete because they don't really change (I know it gets upgraded, but that doesn't change its name, its all in the background), like bridge and cargo shuttle bay.

This is fixed in 1.13.
Title: Re: v1.12.0 Bugs Thread
Post by: Zap0 on January 18, 2021, 12:56:05 PM
Haven't found anything about this already being fixed:

In the F3 commander window, you can't filter ground commanders for their tactical bonus.
Title: Re: v1.12.0 Bugs Thread
Post by: Droll on January 18, 2021, 01:27:22 PM
Haven't found anything about this already being fixed:

In the F3 commander window, you can't filter ground commanders for their tactical bonus.

I think you found a bug but not the bug you think you found.
I'm pretty certain ground commanders should not be getting tactical skills - it's not useful for them
Title: Re: v1.12.0 Bugs Thread
Post by: Lord Solar on January 18, 2021, 01:28:07 PM
Haven't found anything about this already being fixed:

In the F3 commander window, you can't filter ground commanders for their tactical bonus.

I think you found a bug but not the bug you think you found.
I'm pretty certain ground commanders should not be getting tactical skills - it's not useful for them
Tactical bonus is for STO units.
Title: Re: v1.12.0 Bugs Thread
Post by: TMaekler on January 18, 2021, 02:55:55 PM
When building a ship with only box launchers of let's say size 10 and equip them with missiles size 8 you can load more missiles than the number of box launchers because the magazine is calculated from the size of the box launchers. Maybe adding a check if no additional magazine is included in a ship with only box launchers the number of box launchers limits the number of missiles that can be loaded... .
Title: Re: v1.12.0 Bugs Thread
Post by: Zap0 on January 18, 2021, 03:48:32 PM
Serious bug when shooting at tugged ships:

Tugged ships always count as moving at light speed, making them very hard to hit. Tugged ships show as having an engine status of 300 000% (or more) in their ship view. They probably should be using their task group speed to determine hit chances. Shooting the tugging ship seems to work as expected.

Reproduced DB attached, I only tested using beam weapons, not missiles.
Title: Re: v1.12.0 Bugs Thread
Post by: alex_g on January 20, 2021, 02:00:00 AM
The game seems to get stuck in an infinite loop if I try to Replace at Ordnance Transfer Hub with a certain fleet. I have allowed the game to go on for 2 real-time hours to process and the game is still stuck and I can't seem to find a way to make it respond.

If I instead issue Unload to Ordnance Transfer Hub + Load from Ordnance Transfer Hub everything is fine and it works. It's not a problem for me now that I've realized the issue, but I thought I should still report it.

It's weird because in the past I've definitely used the Replace command without any problems in this game.

    The function number N/A
    The complete error text N/A
    The window affected N/A
    What you were doing at the time Replace at Ordnance Transfer Hub
    Conventional or TN start: Conventional
    Random or Real Stars: Real Stars
    Is your decimal separator a comma? No, it's a period
    Is the bug is easy to reproduce, intermittent or a one-off? It happens 100% with the current DB
    If this is a long campaign - say 75 years or longer - let me know the length of the campaign as well - 177 years in
Title: Re: v1.12.0 Bugs Thread
Post by: Cosinus on January 20, 2021, 08:27:13 AM
Unload all Ship components has a redundant "maximum amount" field.

The function number: N/A
The complete error text: N/A
The window affected: Naval window/Movement Orders
What you were doing at the time: See steps to reproduce
Conventional or TN start: doesn't matter
Random or Real Stars: doesn't matter
Is your decimal separator a comma?: dot
Is the bug is easy to reproduce, intermittent or a one-off?: always reproducible
If this is a long campaign - say 75 years or longer - let me know the length of the campaign as well: doesn't matter

Steps to reproduce:
Expected behaviour:  Unload all ship components should behave in the same way as "Unload all installations" and "Unload all Minerals". With these orders, the textbox is hidden.
Title: Rahkas Appear and Disappear a magic bug.
Post by: SpaceMarine on January 21, 2021, 11:07:13 PM
The function number: N/A
The complete error text: N/A
The window affected: Tactical Map/Ground Force window
What you were doing at the time: Landing Troops on an enemy world
Conventional or TN start: Conventional
Random or Real Stars: Real Stars
Is your decimal separator a comma?: dot
Is the bug is easy to reproduce, intermittent or a one-off?: Able to be reproduced with a save that still showed the ground forces appear
If this is a long campaign - say 75 years or longer - Somewhat long around 90 years in.

Steps to reproduce:
Load up the Database, go to the system NN 3193, on the second planet of the system there are ground force signatures these are rahkas, my fleet is overhead and if you check the ground forces window you can see a regiment of marines deployed, all you have to do is increment and the ground force signatures disappear. and this isnt a display  bug the rahkas are just gone completely.

Notes: I did manage to actually fight the rahkas one time and got decimated but when i reloaded to check if i could do anything wrong they had this behaviour which i explain above.

Database is having issues being uploaded will be found below when the forums work with it.
Title: Re: v1.12.0 Bugs Thread
Post by: nuklearwanze on January 23, 2021, 03:21:10 AM
since i conquered a world with aliens on them it seems i can no longer create new colonies.  when i click the create colony button a "select colony species" window opens and no matter what i click it wont create a new colony.  seems to me like a bug.

the whole "select colony species" window seems broken anyway.  there is a checkbox on there, that does nothing (or does it?).
Title: Re: v1.12.0 Bugs Thread
Post by: Black on January 23, 2021, 03:29:39 AM
since i conquered a world with aliens on them it seems i can no longer create new colonies.  when i click the create colony button a "select colony species" window opens and no matter what i click it wont create a new colony.  seems to me like a bug.

the whole "select colony species" window seems broken anyway.  there is a checkbox on there, that does nothing (or does it?).

This bug is unfortunately with us for quite some time. You can still create colonies from System Generation and Display window. There is species selection in upper right corner of the window to select what species you want to colony to be and then just use Create Colony button.
Title: Re: v1.12.0 Bugs Thread
Post by: Black on January 23, 2021, 06:34:56 AM
I am getting hit by repeated error message:

The function number: #346
The complete error text: For the Decimal type, the value was either too large or too small (translated from my language)
The window affected: shown on main screen
What you were doing at the time: I click on turn length button, doesn't matter if it is 5 Seconds or 1 Day. The error always shows up.
Conventional or TN start: TN start
Random or Real Stars: Real Stars
Is your decimal separator a comma? Decimal separator is dot.
Is the bug is easy to reproduce, intermittent or a one-off? Happens every time with my database
If this is a long campaign - say 75 years or longer - let me know the length of the campaign as well: arround 20 years

Edit: Commanders window is also affected, when I click between naval commanders error message also shows up. Ground commanders, scientists and administrators are not affected.

Edit 2: I loaded older database and found what caused the error. One of my ship finished repair and grade points got changed from 1605 to -369, It seems that ship have lost more crew that is the maximum and when it takes replacements, it will cause the issue, but deleting the ship removes the error. Also when I select the bugged ship on Naval Organization, in Ship Design Display is only one word: error.
Title: Re: v1.12.0 Bugs Thread
Post by: paco149 on January 23, 2021, 06:59:33 AM
Is there any way I can play with a 1360x768 monitor?
Title: Re: v1.12.0 Bugs Thread
Post by: TheBawkHawk on January 23, 2021, 01:33:59 PM
Unsure if this has already been reported, but it's an interesting one. In my most recent game, an NPR I discovered and established communications with was named the Tokyo Khanate, with a human race picture and a Soviet flag. I had Human NPRs turned off, and I checked in the DB and they are indeed a separate race known as Tokyo. I wanted them to be a little more alien sounding so I changed their name to Tokarian Khanate (or something along those lines), and changed the picture and flag using the spacemaster buttons on the intelligence window.

I loaded the save again today and started receiving unintelligible communications from them for about a month in game, until they translated my language again, and the Tokarian Khanate declared that they were the Tokyo Khanate. The race flag and picture stayed the same, but it treated the renamed NPR as an unknown race until communications were reestablished with the original name.
Title: Re: v1.12.0 Bugs Thread
Post by: Droll on January 23, 2021, 07:33:39 PM
1.12

The ancient constructs tab is always empty despite there being active constructs in the empire (with a colony >10m pop). Bonuses seem to be working so its just the UI.
To reproduce just have any empire that has an ancient construct under its control.
Title: Re: v1.12.0 Bugs Thread
Post by: captainwolfer on January 23, 2021, 09:41:26 PM
I found what I assume is an NPR, except the NPR has literally zero building on its homeworld. It has 1070 million people on the planet, but no buildings. I used an Elint ship in orbit to find that they had 1070 million population but no facilities, and then invaded the population, and they had no ground units, so I used SM to spawn in a giant (7 million PWL infantry) formation to force the population to surrender despite the 100x strength needed to surrender bug. At which point, I confirmed that there was literally zero facilities on the planet, not even conventional factories.

Possibly relevant information:
I had a elint/diplomatic ship in orbit for a while, but eventually left only an Elint ship in orbit.
I never received any messages from them despite having ships in orbit of their homeworld. Turning on the Transponders on my ships did not do anything.
I started the game with 2 billion population on my capital instead of 500 million
There was a precursor ground army on the 4th planet of the system the NPR was in. The precursor army did have STO weapons, but I destroyed them.

Database file is attached, the aliens are in the system of Seabring, on the second planet.
Title: Re: v1.12.0 Bugs Thread
Post by: SpaceMarine on January 23, 2021, 09:53:44 PM
I found what I assume is an NPR, except the NPR has literally zero building on its homeworld. It has 1070 million people on the planet, but no buildings. I used an Elint ship in orbit to find that they had 1070 million population but no facilities, and then invaded the population, and they had no ground units, so I used SM to spawn in a giant (7 million PWL infantry) formation to force the population to surrender despite the 100x strength needed to surrender bug. At which point, I confirmed that there was literally zero facilities on the planet, not even conventional factories.

Possibly relevant information:
I had a elint/diplomatic ship in orbit for a while, but eventually left only an Elint ship in orbit.
I never received any messages from them despite having ships in orbit of their homeworld. Turning on the Transponders on my ships did not do anything.
I started the game with 2 billion population on my capital instead of 500 million
There was a precursor ground army on the 4th planet of the system the NPR was in. The precursor army did have STO weapons, but I destroyed them.

Database file is attached, the aliens are in the system of Seabring, on the second planet.

This is likely not a bug, as this is from what I can tell looking in the DB a non TN NPR which are broken NPRs and can never get out of TN tech and have 0 installations as you describe. . - Spacemarine
Title: Re: v1.12.0 Bugs Thread
Post by: captainwolfer on January 24, 2021, 12:05:50 AM
This is likely not a bug, as this is from what I can tell looking in the DB a non TN NPR which are broken NPRs and can never get out of TN tech and have 0 installations as you describe. . - Spacemarine
If the NPR is broken then isn't it a bug? shouldn't pre-TN NPRs at least have conventional factories?
Title: Re: v1.12.0 Bugs Thread
Post by: SpaceMarine on January 24, 2021, 12:29:53 AM
This is likely not a bug, as this is from what I can tell looking in the DB a non TN NPR which are broken NPRs and can never get out of TN tech and have 0 installations as you describe. . - Spacemarine
If the NPR is broken then isn't it a bug? shouldn't pre-TN NPRs at least have conventional factories?

Negative. This is not a bug because nprs simply have not been coded to work when they are non tn but will still appear on occasion so for now this is intended behaviour
Title: Re: v1.12.0 Bugs Thread
Post by: captainwolfer on January 24, 2021, 12:32:28 AM
Negative. This is not a bug because nprs simply have not been coded to work when they are non tn but will still appear on occasion so for now this is intended behaviour
Ok, I thought it was a bug because it wasn't listed on the Known issues thread.
Title: Re: v1.12.0 Bugs Thread
Post by: Steve Walmsley on January 24, 2021, 07:29:33 AM
Ok, I thought it was a bug because it wasn't listed on the Known issues thread.

It's not a bug. Some NPRs are pre-industrial and don't have installations or (effective) defence forces. There wasn't much point in coding archers to fight your powered infantry.
Title: Re: v1.12.0 Bugs Thread
Post by: captainwolfer on January 24, 2021, 09:07:19 AM
Ok, I thought it was a bug because it wasn't listed on the Known issues thread.

It's not a bug. Some NPRs are pre-industrial and don't have installations or (effective) defence forces. There wasn't much point in coding archers to fight your powered infantry.
Can you add something that says a NPR is pre-industrial? It would be pretty obvious to any ship in orbit, but isn't as obvious in-game due to the population still having an EM signature.
Title: Re: v1.12.0 Bugs Thread
Post by: majorT on January 24, 2021, 12:47:07 PM
howdy all, after playing a campaign in v1. 12. 0 for about 25 in game years, I've started to get a text box appearing anytime I advance in time.  "Function #1414: The Given Key was not present in the dictionary" is what I'm getting.  Any solutions? Thanks in advance
Title: Re: v1.12.0 Bugs Thread
Post by: Zap0 on January 24, 2021, 01:03:00 PM
howdy all, after playing a campaign in v1. 12. 0 for about 25 in game years, I've started to get a text box appearing anytime I advance in time.  "Function #1414: The Given Key was not present in the dictionary" is what I'm getting.  Any solutions? Thanks in advance

Random bugs? Welcome to Aurora :-)

Try clearing your ship orders, especially if you have something arcane in there. If you're unlucky an NPR or civilian ship might have something borked.
Title: Re: v1.12.0 Bugs Thread
Post by: Froggiest1982 on January 24, 2021, 04:05:52 PM
Not really a bug

1.12

Gauss Turrets should appear under Kinetic Weapons for research but they are currently being displayed under Energy Weapons.
Title: Re: v1.12.0 Bugs Thread
Post by: majorT on January 25, 2021, 01:21:13 AM
If I uploaded my DB of my current save, would it be possible for anyone on the forums or Steve himself if he had some downtime to help identify the bug or problem itself? Or would I be better off starting a new campaign haha.  Its a shame to lose one that I played for quite a while lol
Title: Re: v1.12.0 Bugs Thread
Post by: Steve Walmsley on January 25, 2021, 05:08:07 AM
1.12

The ancient constructs tab is always empty despite there being active constructs in the empire (with a colony >10m pop). Bonuses seem to be working so its just the UI.
To reproduce just have any empire that has an ancient construct under its control.

I added the tab but never got around to coding it :)
Title: Re: v1.12.0 Bugs Thread
Post by: Steve Walmsley on January 25, 2021, 05:09:38 AM
howdy all, after playing a campaign in v1. 12. 0 for about 25 in game years, I've started to get a text box appearing anytime I advance in time.  "Function #1414: The Given Key was not present in the dictionary" is what I'm getting.  Any solutions? Thanks in advance

#1414 is unfortunately the largest function in the code - ExecuteOrders - so there is no easy way to identify the problem beyond that a fleet somewhere is trying to interact with something that no longer exists. Have you recently deleted something that was the target of a fleet order?
Title: Re: v1.12.0 Bugs Thread
Post by: Steve Walmsley on January 25, 2021, 05:10:57 AM
Can you add something that says a NPR is pre-industrial? It would be pretty obvious to any ship in orbit, but isn't as obvious in-game due to the population still having an EM signature.

An ELINT Module will tell you how many installations are at a population.
Title: Re: v1.12.0 Bugs Thread
Post by: Droll on January 25, 2021, 05:11:17 AM
1.12

The ancient constructs tab is always empty despite there being active constructs in the empire (with a colony >10m pop). Bonuses seem to be working so its just the UI.
To reproduce just have any empire that has an ancient construct under its control.

I added the tab but never got around to coding it :)

Why must you hurt me in this way
Title: Re: v1.12.0 Bugs Thread
Post by: nuclearslurpee on January 25, 2021, 07:07:31 AM
Why must you hurt me in this way

It provides a fun diversion from hurting you in all the other ways this game does!  ;D
Title: Re: v1.12.0 Bugs Thread
Post by: majorT on January 25, 2021, 02:39:41 PM
Quote from: Steve Walmsley link=topic=11945. msg147513#msg147513 date=1611572978
Quote from: majorT link=topic=11945. msg147409#msg147409 date=1611514027
howdy all, after playing a campaign in v1.  12.  0 for about 25 in game years, I've started to get a text box appearing anytime I advance in time.   "Function #1414: The Given Key was not present in the dictionary" is what I'm getting.   Any solutions? Thanks in advance

#1414 is unfortunately the largest function in the code - ExecuteOrders - so there is no easy way to identify the problem beyond that a fleet somewhere is trying to interact with something that no longer exists.  Have you recently deleted something that was the target of a fleet order?

This could be the cause yes, recently I had some issues with colonists being loaded/unloaded so I had done some reorganization.  Either way I think it might be some civ ships with these order problems R I P.  Oddly enough I receive the error only after using a time advancement larger than I believe 5 minutes.  Anything from 5 seconds to that limit works without giving a pop up message
Title: Re: v1.12.0 Bugs Thread
Post by: xenoscepter on January 26, 2021, 07:32:55 AM
 - A super-minor annoyance that might be a bug, might be WAI, or might simply be an oversight, but if you re-name a component after you have researched it, the name does not change if you go to remove it on the Research Screen. So a "10cm Laser, IR" renamed to "10cm Laser, IR Mark One" would still be "10cm Laser, IR" if I go to the Research Screen and try to remove it from the "Completed Research" Projects. I have confirmed this to be the case in 1.12, but I ran into it as early as the introduction of Prototype parts. Mainly because I make typos or decide to use a different or refined naming convention, or just change my mind on what I want something to be called; and then it makes it a pain to go and delete those Prototypes to declutter the Ship Design window. :)

 - That all said, I can confirm that it does change the name in the Technology Screen. :)
Title: Re: v1.12.0 Bugs Thread
Post by: TMaekler on January 26, 2021, 07:57:42 AM
When refitting a ship into a new class, you can change the name of the ship in the task list, but once the refit is done, the name of the ship isn't changed.
Title: Re: v1.12.0 Bugs Thread
Post by: Droll on January 26, 2021, 05:47:53 PM
1.12

A fleet with too many reaction bonuses stacked is completely unable to move and is even unable to perform tasks such as activating shields at their current location (when given as a move command and not though the combat menu)

In the DB attached the affected fleet was the "Carrier Group - 13th Star Lords". Their fleet commander is "Thierry Arene" (ID 111292) who had a reaction bonus of 35%. Reducing this bonus to 10% through DB magic made the fleet start moving again. So if you want to reproduce revert my workaround.

Also useful to note is my admin command structure that this fleet falls under:
GEN - 35% Reaction bonus
   GEN - 35% Reaction bonus
      NAV - 25% Reaction bonus
         NAV - 50% Reaction bonus
            NAV - 35% Reaction bonus
               Affected fleet - 35% Reaction bonus (fleet CO)
                  DD HNS Porpoise - 50% Reaction bonus (Captain, highest in the fleet, haven't checked the fighters though)
Title: Re: v1.12.0 Bugs Thread
Post by: Erik L on January 26, 2021, 06:01:04 PM
1.12

When dragging a unit/formation out of their command structure to the planetary level, it moves but does not stay there. There currently does not seem to be a way to move a unit out of a command structure without moving it to another one.
Title: Re: v1.12.0 Bugs Thread
Post by: nuclearslurpee on January 26, 2021, 06:18:46 PM
1.12

When dragging a unit/formation out of their command structure to the planetary level, it moves but does not stay there. There currently does not seem to be a way to move a unit out of a command structure without moving it to another one.

The visual behavior is a glitch, but you can move a unit out of its command hierarchy with the "Clear Hierarchy" button.
Title: Re: v1.12.0 Bugs Thread
Post by: Celarious on January 26, 2021, 10:20:15 PM
v1. 12
Game length: 27 years
Real Stars
TN start
Reproducible easily
Function #730, #722

If a fleet is set to have a primary conditional order of "Refuel, Resupply and Overhaul at Colony" when the Deployment Exceeded condition is met, the next 8+ hour time increment will throw the following two errors:

1.  12.  0 Function #730: Object reference not set to an instance of an object. 
1.  12.  0 Function #722: Object reference not set to an instance of an object. 

This is reproducible 100% of the time.   The actual order then seems to change to just overhauling.   The fleet has a commercial and military ship.   No other errors are thrown after this, unless I select another conditional order and change it back to the one mentioned above. 

Title: Re: v1.12.0 Bugs Thread
Post by: captainwolfer on January 29, 2021, 07:21:36 PM
1.12

Had an Elint ship gathering intel on an NPR homeworld. I managed to steal the technical details of a component called a Swarm Extraction Module

Given the name and that this is flat out better in every way than the normal orbital mining module, I assume the NPR (Which was a normal NPR called the Korsk Republic) should not have had this tech.

The database is attached, the save used is Star League, note that I let a lot of in-game time pass before I realized I should file a bug report.

Title: Re: v1.12.0 Bugs Thread
Post by: Steve Walmsley on January 30, 2021, 05:52:35 AM
Had an Elint ship gathering intel on an NPR homeworld. I managed to steal the technical details of a component called a Swarm Extraction Module

Yes, it shouldn't have had access to the tech. Fixed now.
Title: Re: v1.12.0 Bugs Thread
Post by: ExChairman on January 30, 2021, 03:13:30 PM
Auto-asssign Tech points seems to be broken... Tested several lvls up to 8 000 000 all starts with basic techs, seems to be using 2-300 000 tech points at most...
Title: Re: v1.12.0 Bugs Thread
Post by: nuclearslurpee on January 30, 2021, 03:16:35 PM
Auto-asssign Tech points seems to be broken... Tested several lvls up to 8 000 000 all starts with basic techs, seems to be using 2-300 000 tech points at most...

Is it using the correct amount of tech points for the default starting conditions(ranging from 80k RP at 500m pop to 200k RP at 1250m+ pop)? If so, it is probably WAI, the game is not configured to deal with e.g. 8 million RPs as the auto-assignment of tech points will use an NPR design script which is very much hard-coded and not adaptable to extreme starting conditions.
Title: Re: v1.12.0 Bugs Thread
Post by: Jorgen_CAB on January 30, 2021, 04:30:47 PM
Not entirely sure this is a bug but Troop Transport bays don't require Cargo Shuttle Bays to either load or unload troops.

I thought they should require this. I get that drop capable troops bays don't need it to drop the troop but they should need it retrieve the troops once on the ground. Ships can't land on planets so I suppose they should need to use Cargo Shuttle bays.
Title: Re: v1.12.0 Bugs Thread
Post by: xenoscepter on January 30, 2021, 06:22:21 PM
Not entirely sure this is a bug but Troop Transport bays don't require Cargo Shuttle Bays to either load or unload troops.

I thought they should require this. I get that drop capable troops bays don't need it to drop the troop but they need it retrieve the troops once on the ground. Ships can't land on planets so I suppose they should need to use Cargo Shuttle bays.

 - Cargo Shuttle Stations work too, so double check that the population your loading from / to doesn't have one.
Title: Re: v1.12.0 Bugs Thread
Post by: Jorgen_CAB on January 30, 2021, 07:18:39 PM
Not entirely sure this is a bug but Troop Transport bays don't require Cargo Shuttle Bays to either load or unload troops.

I thought they should require this. I get that drop capable troops bays don't need it to drop the troop but they need it retrieve the troops once on the ground. Ships can't land on planets so I suppose they should need to use Cargo Shuttle bays.

 - Cargo Shuttle Stations work too, so double check that the population your loading from / to doesn't have one.

No I have tested this.. ship with no "Cargo Shuttle Bay" both unloading and loading troops from a world that have nothing but a colony on it.
Title: Re: v1.12.0 Bugs Thread
Post by: Rince Wind on January 31, 2021, 05:40:18 AM
You can load partial ship components.

That in itself might be intended, but you can still disassemble the partial components. It will say you have 0 in storage and when you disassemble them it will go negative. You still get the RP though.

I'll get the rest of the module to see if I'll have -1 in stockpile then.
Title: Re: v1.12.0 Bugs Thread
Post by: ExChairman on January 31, 2021, 05:49:56 AM
Auto-asssign Tech points seems to be broken... Tested several lvls up to 8 000 000 all starts with basic techs, seems to be using 2-300 000 tech points at most...

Is it using the correct amount of tech points for the default starting conditions(ranging from 80k RP at 500m pop to 200k RP at 1250m+ pop)? If so, it is probably WAI, the game is not configured to deal with e.g. 8 million RPs as the assignment of tech points will use an NPR design script which is very much hard-coded and not adaptable to extreme starting conditions.

Did not know that, it seems to bee locked at most 400 000 RPs. So its probably works as intended.
Tried to make a Solar Union some 500 years into the future and wanted 1.5 million in RPs.
Title: Re: v1.12.0 Bugs Thread
Post by: Second Foundationer on January 31, 2021, 07:16:12 AM
1.12

A fleet with too many reaction bonuses stacked is completely unable to move and is even unable to perform tasks such as activating shields at their current location (when given as a move command and not though the combat menu)

In the DB attached the affected fleet was the "Carrier Group - 13th Star Lords". Their fleet commander is "Thierry Arene" (ID 111292) who had a reaction bonus of 35%. Reducing this bonus to 10% through DB magic made the fleet start moving again. So if you want to reproduce revert my workaround.

Also useful to note is my admin command structure that this fleet falls under:
GEN - 35% Reaction bonus
   GEN - 35% Reaction bonus
      NAV - 25% Reaction bonus
         NAV - 50% Reaction bonus
            NAV - 35% Reaction bonus
               Affected fleet - 35% Reaction bonus (fleet CO)
                  DD HNS Porpoise - 50% Reaction bonus (Captain, highest in the fleet, haven't checked the fighters though)

(Through a facepalm) I encountered this a while ago, and couldn't figure it out. I didn't think of the stacked bonuses and continued to suspect it was something about the about the command ship design, so, on top of our two command cruisers, we developed several variants of "Funny Customer" class command ships which all showed the same behaviour. Except when they didn't ???. Eventually, I gave up looking for any reasonable reportable pattern and simply fired all fleet commanders permanently.

Thanks for enlightening me at last.

(I could provide another db if needed. But it seems to me Droll's already has the bug in the crosshairs. And I don't want to risk breaking this thread with another misfiring attachment.)
Title: Re: v1.12.0 Bugs Thread
Post by: TheTalkingMeowth on January 31, 2021, 08:22:16 AM
1.12

A fleet with too many reaction bonuses stacked is completely unable to move and is even unable to perform tasks such as activating shields at their current location (when given as a move command and not though the combat menu)

In the DB attached the affected fleet was the "Carrier Group - 13th Star Lords". Their fleet commander is "Thierry Arene" (ID 111292) who had a reaction bonus of 35%. Reducing this bonus to 10% through DB magic made the fleet start moving again. So if you want to reproduce revert my workaround.

Also useful to note is my admin command structure that this fleet falls under:
GEN - 35% Reaction bonus
   GEN - 35% Reaction bonus
      NAV - 25% Reaction bonus
         NAV - 50% Reaction bonus
            NAV - 35% Reaction bonus
               Affected fleet - 35% Reaction bonus (fleet CO)
                  DD HNS Porpoise - 50% Reaction bonus (Captain, highest in the fleet, haven't checked the fighters though)

(Through a facepalm) I encountered this a while ago, and couldn't figure it out. I didn't think of the stacked bonuses and continued to suspect it was something about the about the command ship design, so, on top of our two command cruisers, we developed several variants of "Funny Customer" class command ships which all showed the same behaviour. Except when they didn't ???. Eventually, I gave up looking for any reasonable reportable pattern and simply fired all fleet commanders permanently.

Thanks for enlightening me at last.

(I could provide another db if needed. But it seems to me Droll's already has the bug in the crosshairs. And I don't want to risk breaking this thread with another misfiring attachment.)

Yeah, I can confirm this was a thing in 1.11. It's definitely reaction related.
Title: Re: v1.12.0 Bugs Thread
Post by: Rince Wind on January 31, 2021, 04:04:16 PM
You can load partial ship components.

That in itself might be intended, but you can still disassemble the partial components. It will say you have 0 in storage and when you disassemble them it will go negative. You still get the RP though.

I'll get the rest of the module to see if I'll have -1 in stockpile then.

I had indeed -1 jump stabilizations modules after completing the module. Scrapping it gave me negative 420 wealth/minerals.
Title: Re: v1.12.0 Bugs Thread
Post by: wqcoleman on February 01, 2021, 12:37:39 AM
Game reverts to 6 hour or 2 hour increments for play on 5 and 30 day respectively.   There is nothing in the DB that suggests NPC warfare is happening nor any activities that would warrant the slow down in pulse length.   I've attached the db to this thread, as it will show what I'm experiencing.   I saw other forum posts that were experiencing similar problems, one appeared to resolve itself and the other went on for a year with no resolution.   It's unclear how to fix this outside of just iterating time and hoping it resolves itself, but I didn't see anything in the db that would warrant this change in pulse.
Title: Re: v1.12.0 Bugs Thread
Post by: TheBawkHawk on February 01, 2021, 09:48:31 AM
Game reverts to 6 hour or 2 hour increments for play on 5 and 30 day respectively.   There is nothing in the DB that suggests NPC warfare is happening nor any activities that would warrant the slow down in pulse length.   I've attached the db to this thread, as it will show what I'm experiencing.   I saw other forum posts that were experiencing similar problems, one appeared to resolve itself and the other went on for a year with no resolution.   It's unclear how to fix this outside of just iterating time and hoping it resolves itself, but I didn't see anything in the db that would warrant this change in pulse.

The only thing that might be the cause is the fleets trying and failing to refuel from a colony/hub. Other than that, I can't see anything else that would cause the turn interrupts.
Title: Re: v1.12.0 Bugs Thread
Post by: nuclearslurpee on February 01, 2021, 10:30:29 AM
Game reverts to 6 hour or 2 hour increments for play on 5 and 30 day respectively.   There is nothing in the DB that suggests NPC warfare is happening nor any activities that would warrant the slow down in pulse length.   I've attached the db to this thread, as it will show what I'm experiencing.   I saw other forum posts that were experiencing similar problems, one appeared to resolve itself and the other went on for a year with no resolution.   It's unclear how to fix this outside of just iterating time and hoping it resolves itself, but I didn't see anything in the db that would warrant this change in pulse.

Usually when I see this happen it is because a NPR ship is jumping back and forth every increment for some reason. Usually if you can find this from the game log it is possible to just move the fleet coordinates and let the AI figure out how to solve that problem.
Title: Re: v1.12.0 Bugs Thread
Post by: wqcoleman on February 01, 2021, 11:49:54 AM
Quote
Usually when I see this happen it is because a NPR ship is jumping back and forth every increment for some reason.   Usually if you can find this from the game log it is possible to just move the fleet coordinates and let the AI figure out how to solve that problem. 

I've looked everywhere in the db and to find the offending ship is a bit of a challenge.  .   Some are reporting that they cannot refuel, but I have no idea if this is the problem.    This happened all of a sudden, and was not an issue at all in the game.    It seemed to happen right after I set a bunch of ships to overhaul and then it stopped iterating normally, but this is a bit misleading, since many ships came out of overhaul before this started happening consistently.   I tried deleting those ships, and that didn't work.   Also, checked all the fire controls, nothing, targets, nothing.   Oddly, when a ship comes out of overhaul, their shields are active, vs.  when they started overhaul with no shields active
Title: Re: v1.12.0 Bugs Thread
Post by: unkfester on February 02, 2021, 01:19:06 AM
Game reverts to 6 hour or 2 hour increments for play on 5 and 30 day respectively.   There is nothing in the DB that suggests NPC warfare is happening nor any activities that would warrant the slow down in pulse length.   I've attached the db to this thread, as it will show what I'm experiencing.   I saw other forum posts that were experiencing similar problems, one appeared to resolve itself and the other went on for a year with no resolution.   It's unclear how to fix this outside of just iterating time and hoping it resolves itself, but I didn't see anything in the db that would warrant this change in pulse.

Usually when I see this happen it is because a NPR ship is jumping back and forth every increment for some reason. Usually if you can find this from the game log it is possible to just move the fleet coordinates and let the AI figure out how to solve that problem.
I got same problem,  how do you look at Game log? (Can you explain in newbi terms)
Title: Re: v1.12.0 Bugs Thread
Post by: Jorgen_CAB on February 02, 2021, 01:46:56 AM
Game reverts to 6 hour or 2 hour increments for play on 5 and 30 day respectively.   There is nothing in the DB that suggests NPC warfare is happening nor any activities that would warrant the slow down in pulse length.   I've attached the db to this thread, as it will show what I'm experiencing.   I saw other forum posts that were experiencing similar problems, one appeared to resolve itself and the other went on for a year with no resolution.   It's unclear how to fix this outside of just iterating time and hoping it resolves itself, but I didn't see anything in the db that would warrant this change in pulse.

Usually when I see this happen it is because a NPR ship is jumping back and forth every increment for some reason. Usually if you can find this from the game log it is possible to just move the fleet coordinates and let the AI figure out how to solve that problem.
I got same problem,  how do you look at Game log? (Can you explain in newbi terms)

You have to use an application to open the database (DB browser for SQLite) and start by locking in the FCT_GameLog table. This table will list both player and NPR logs... from there you can usually see if there is some sort of issue and which ships are having them. You should then be able to track down which fleet or fleets are having a problem and just change the coordinates of those fleets and it should fix itself.
Title: Re: v1.12.0 Bugs Thread
Post by: Black on February 02, 2021, 02:45:42 PM
I have naval officer with Xenoarchaeology skill, that should not be possible, right?

(https://i.ibb.co/LkBzTqB/xenoarcheology.png) (https://ibb.co/2nR7zLR)
Title: Re: v1.12.0 Bugs Thread
Post by: Xanithas on February 03, 2021, 02:07:19 PM
Looks like I stumbled on a small bug.   In my current campaign I have awards that I created that the criteria was met for (researched a tech, generate 10k RP) and they are not being awarded automatically.   I can still award these manually.   I have also tried to remove the ones I made and remake them but no luck. 
Title: Re: v1.12.0 Bugs Thread
Post by: Droll on February 03, 2021, 02:14:33 PM
Looks like I stumbled on a small bug.   In my current campaign I have awards that I created that the criteria was met for (researched a tech, generate 10k RP) and they are not being awarded automatically.   I can still award these manually.   I have also tried to remove the ones I made and remake them but no luck.

Were there officers that fulfilled the criteria before the medals were made? Are those the only officers that do not get medals? If you answer yes to both those questions then it's WAI.
Generally speaking it's recommended that you create medals at the start of a campaign so that this doesn't happen.

If you answer no to both of those then there is a bug.
Title: Re: v1.12.0 Bugs Thread
Post by: Froggiest1982 on February 03, 2021, 02:49:15 PM
Looks like I stumbled on a small bug.   In my current campaign I have awards that I created that the criteria was met for (researched a tech, generate 10k RP) and they are not being awarded automatically.   I can still award these manually.   I have also tried to remove the ones I made and remake them but no luck.

Were there officers that fulfilled the criteria before the medals were made? Are those the only officers that do not get medals? If you answer yes to both those questions then it's WAI.
Generally speaking it's recommended that you create medals at the start of a campaign so that this doesn't happen.

If you answer no to both of those then there is a bug.

In addition to this and avoid a possible extra post, the medals currently work on a OR base and not AND. Meaning the medal you have created will be awarded if the officer will research a tech "or" generate 10k RP. So if you wanted to create one that would be awarded for an officer that will research a tech "and" generate 10k RP is currently not possible.
Title: Re: v1.12.0 Bugs Thread
Post by: LiquidGold2 on February 04, 2021, 12:58:07 AM
Civil shipping is delivering too many of a requested item to a colony.  This isn't a big deal when moving infrastructure by the thousand and a few hundred extra show up, but it's a problem when one mass driver is requested and six are delivered, starving out other requests for them.

Speaking of infrastructure, I dunno if this is strictly a bug, but I suspect it's not intended behavior: Colonies that start with pops only in orbital habs appear to either be still building their own infrastructure or demanding it on the civil market when the OHs reach capacity.  Either way, once the first ground-based infrastructure is down, the floodgates open for more to be requested and/or placed.  If left unchecked, this will cause the worker percents to shift towards the body's colony cost values, which can ruin (previously) OH colonies build around venetian or other high cost worlds.
Title: Re: v1.12.0 Bugs Thread
Post by: pwhk on February 04, 2021, 06:17:50 AM
NPR Surrendered ships still firing AMMs despite no more valid targets. (AMM then promptly self destruct themselves).
Title: Re: v1.12.0 Bugs Thread
Post by: Kylemmie on February 04, 2021, 10:52:27 AM
NPR Surrendered ships still firing AMMs despite no more valid targets. (AMM then promptly self destruct themselves).

Interesting. Makes sense to ask if this is a bug. Even if it is a bug, I'd be curious if this wasn't actually proper behavior on accident. Spiking your guns when you surrender is a long standing procedure. Firing off 1000's of valuable missile to self-detonate in a non-threating manner seems like a smart move to deny your enemy free munitions.
Title: Re: v1.12.0 Bugs Thread
Post by: TMaekler on February 06, 2021, 01:04:42 PM
System Generation and Display - Window:

When you want to rename the system via the "Select Name" button and close that new "Select Name"-Window via the X at the top of the window all names of all planets and bodies are erased.
Title: Re: v1.12.0 Bugs Thread
Post by: Warer on February 07, 2021, 01:27:25 PM
STO Point defense checkbox not working, only changes range not tracking speed. Maxtech game, ~6years in TN start I think. Improved and Advanced Cargo Shuttles not appearing component screens (for construction and design)
maybe I just obsoleted them on accident

The Cargo Shuttle Bay component is the advanced Cargo shuttle bay. my bad
Title: Re: v1.12.0 Bugs Thread
Post by: nuclearslurpee on February 07, 2021, 07:46:22 PM
STO Point defense checkbox not working, only changes range not tracking speed. Maxtech game, ~6years in TN start I think. Improved and Advanced Cargo Shuttles not appearing component screens (for construction and design)
maybe I just obsoleted them on accident

The Cargo Shuttle Bay component is the advanced Cargo shuttle bay. my bad

The STO point defence checkbox works fine, however in order to use a tracking speed greater than your racial tracking speed you must place the weapon in a turret. This is the same as for ships except that a STO has zero speed and thus uses racial tracking instead of ship speed. Just confirmed this in-game, it's WAI.
Title: Re: v1.12.0 Bugs Thread
Post by: Warer on February 07, 2021, 08:09:10 PM
STO Point defense checkbox not working, only changes range not tracking speed. Maxtech game, ~6years in TN start I think. Improved and Advanced Cargo Shuttles not appearing component screens (for construction and design)
maybe I just obsoleted them on accident

The Cargo Shuttle Bay component is the advanced Cargo shuttle bay. my bad

The STO point defence checkbox works fine, however in order to use a tracking speed greater than your racial tracking speed you must place the weapon in a turret. This is the same as for ships except that a STO has zero speed and thus uses racial tracking instead of ship speed. Just confirmed this in-game, it's WAI.
Thank you for clearing up my incompetence.
Title: Re: v1.12.0 Bugs Thread
Post by: Barkhorn on February 07, 2021, 09:13:36 PM
I don't know if it's right to put this here, but it's not really a good fit for the suggestion thread either.  Right now, the AI uses huge numbers waypoints to move its fleets around, and never cleans them up after using them.  Tens of thousands of them pile up.  I think this probably negatively effects performance.
Title: Re: v1.12.0 Bugs Thread
Post by: nuclearslurpee on February 07, 2021, 10:50:16 PM
I don't know if it's right to put this here, but it's not really a good fit for the suggestion thread either.  Right now, the AI uses huge numbers waypoints to move its fleets around, and never cleans them up after using them.  Tens of thousands of them pile up.  I think this probably negatively effects performance.

I think Steve mentioned in another thread that these were supposed to be getting deleted after ~3 months but were not, so he fixed for 1.13, however I'm not certain and it may have been something related to the game logs instead.
Title: Re: v1.12.0 Bugs Thread
Post by: Wieseltrupp on February 08, 2021, 04:23:13 PM
Hello
I set up my automated grav- and geo survey vessels like this:

Primary Standind Order: Survey Next Three System Locations (for GravSurvey) / Survey Next Thirty System Bodies (for GeoSurvey)
Secondary Standing Order: Move to System Requring Gravsurvey (for GravSurvey) / Move to System Requiring Geosurvey (for GeoSurvey)
Primary Condition: Deployment Exceeded
Primary Conditional Order: Refuel, Resupply and Overhaul at Colony
Secondary Condition: Fuel less than 20%
Secondary Conditional Order: Refuel from Colony or Hub(all)

the problem:
when the ship returns via its primary conditional order to earth (the only colony with polulation or facilitys at this moment) the ship will overhaul, but it wont refuel nor will it resupply
on the trip back it will only have the overhaul command in its movement order list, not the refuel and resupply order.
Earth currently has plenty of Fuel and Supplies. The planet also has its starting Spacepoprt and Refueling Station.

The function number
-there is no error message or function number involved
The complete error text
-see above
The window affected
-fleet window
What you were doing at the time
-using automated survey vessels
Conventional or TN start
-tn, Stabilized Jumppoints, no civilian harvesters
Random or Real Stars
-random
Is your decimal separator a comma?
-decimal
Is the bug is easy to reproduce, intermittent or a one-off?
-it isnt. i tried reproducing it but on my test game the ships behaved like they should, they returned, refueld and resupplied and then they overhauled, returning to their survey duty afterwards just as intended.
If this is a long campaign
-the campaign is 13 years old
Title: Re: v1.12.0 Bugs Thread
Post by: Kiero on February 09, 2021, 03:33:05 AM
Researched "Cloaking modules" are not showing in the "View Technology" window.
Title: Re: v1.12.0 Bugs Thread
Post by: db48x on February 10, 2021, 11:40:02 AM
when the ship returns via its primary conditional order to earth (the only colony with polulation or facilitys at this moment) the ship will overhaul, but it wont refuel nor will it resupply
on the trip back it will only have the overhaul command in its movement order list, not the refuel and resupply order.

This has already been reported a bunch of times, and I'm fairly certain it's been fixed for 1.13 (you can search the forum to find out for sure).
Title: Re: v1.12.0 Bugs Thread
Post by: Ektor on February 11, 2021, 10:03:42 AM
So it seems that the "Multiple Award" checkbox in the medal screen does nothing. I cannot, in fact, give the same medal to the same commander twice. When I give it again, the new medal overrides the previous.
Title: Re: v1.12.0 Bugs Thread
Post by: nuclearslurpee on February 11, 2021, 11:57:57 AM
So it seems that the "Multiple Award" checkbox in the medal screen does nothing. I cannot, in fact, give the same medal to the same commander twice. When I give it again, the new medal overrides the previous.

It does work, but the way it works is confusing and the effect is probably not what you want.

They way it is intended to work is to allow the same medal to be awarded multiple times for meeting different auto-award conditions. For example, you might set for one medal the conditions "Destroy 10,000 tons of Military Shipping" and "Destroy 100,000 tons of Commercial Shipping". Since the medal conditions are OR conditionals, the medal would awarded as soon as the commander meets one of those two criteria; selecting the Multiple Awards checkbox allows the medal to be awarded again when the same commander meets the other criterion. I don't believe this has any effect on manual awards - you can always manually award any medal for any reason if you want to.

However, the medal display does not show copies of each medal when it is awarded multiple times, it will only ever display that medal one time. This is as far as I know WAI based on how medals are implemented, but it would be an excellent suggestion to change this behavior as right now Multiple Awards medals are kind of useless in practice because of this.
Title: Re: v1.12.0 Bugs Thread
Post by: Ektor on February 11, 2021, 04:19:09 PM
I'd love it if it displayed it several times.
Title: Re: v1.12.0 Bugs Thread
Post by: Kristover on February 11, 2021, 06:40:27 PM
I'm not a fan of multiple awards being display as several versions of the same medal.  That isn't how its done in the military.  I spent 23 years in and had 7 Army Achievement Medals (minor commendation that gets handed out quite frequently, just about any career guy ends up with several of these) and it would have looked like crap to have seven of those ribbons hanging on my chest.  What happens with multiple awards is 'medal devices' - tiny little pins you stick in the ribbon. Sometimes they are stars, numbers, oak leaves...depends.  If we are going to display multiple awards, then I would support a medal device affixed to the ribbon to signify multiple awards.
Title: Re: v1.12.0 Bugs Thread
Post by: Ektor on February 11, 2021, 08:50:38 PM
I'm not a fan of multiple awards being display as several versions of the same medal.  That isn't how its done in the military.  I spent 23 years in and had 7 Army Achievement Medals (minor commendation that gets handed out quite frequently, just about any career guy ends up with several of these) and it would have looked like crap to have seven of those ribbons hanging on my chest.  What happens with multiple awards is 'medal devices' - tiny little pins you stick in the ribbon. Sometimes they are stars, numbers, oak leaves...depends.  If we are going to display multiple awards, then I would support a medal device affixed to the ribbon to signify multiple awards.

You clearly haven't seen those old Russian generals from the Soviet era with their chest lacking any further space for medals. :P

Jokes asides, you're perfectly right. There could be a way to display it better than multiple flags. I'd be satisfied if when you moused over the medal in the commander menu it would say "medal of something x2."
Title: Re: v1.12.0 Bugs Thread
Post by: TMaekler on February 12, 2021, 03:04:06 AM
When adding installations in SM Mode the UI is only updated when adding a new installation. When you increase the number of any installation that is already on the planet, the UI is not updated. The numbers are correctly added, it is just the UI that is not updated.
Title: Re: v1.12.0 Bugs Thread
Post by: Kiero on February 12, 2021, 04:31:29 AM
When you disassemble a component that will add research points to an ongoing research project that has other projects in a queue it will break the queue for all projects.

Error message:
#2169 An object reference was set to an instance of an object
Title: Re: v1.12.0 Bugs Thread
Post by: Denniz on February 13, 2021, 07:21:22 AM
White screen issue on the main system screen, but only for the Sol system.  It manifested when I opened the game this morning.  It was fine when I saved it yesterday.

Note, I saw the thread from 1. 1, but reset window didn't fix it.  I also tried switching back and forth between games.  Any idea how to get it back?

Title: Re: v1.12.0 Bugs Thread
Post by: Zap0 on February 13, 2021, 08:28:07 AM
White screen issue on the main system screen, but only for the Sol system.  It manifested when I opened the game this morning.  It was fine when I saved it yesterday.

Note, I saw the thread from 1. 1, but reset window didn't fix it.  I also tried switching back and forth between games.  Any idea how to get it back?

Zoom out. That's the sun.
Title: Re: v1.12.0 Bugs Thread
Post by: Kishmond on February 13, 2021, 03:47:45 PM
I'm seeing a bug that seems to be identical to this one from v1.9.5 (http://aurora2.pentarch.org/index.php?topic=11298.msg131674#msg131674)

Same error text in two different scenarios.
Text: Value was either too large or too small for a Decimal.
Function #2184 when viewing the colony in the Economics window.
Function #2092 when passing time.

The situation I saw it in:

Sometimes passing 5 days a couple of times removed the bug until I save and reload. Changing the mass driver destination to 'None' was a more reliable fix.
Title: Re: v1.12.0 Bugs Thread
Post by: Denniz on February 13, 2021, 04:13:22 PM
Quote from: Zap0 link=topic=11945. msg148889#msg148889 date=1613226487
Quote from: Denniz link=topic=11945. msg148888#msg148888 date=1613222482
White screen issue on the main system screen, but only for the Sol system.   It manifested when I opened the game this morning.   It was fine when I saved it yesterday. 

Note, I saw the thread from 1.  1, but reset window didn't fix it.   I also tried switching back and forth between games.   Any idea how to get it back?

Zoom out.  That's the sun.
LOL! Thanks. 
Title: Re: v1.12.0 Bugs Thread
Post by: Fray on February 14, 2021, 09:05:13 PM
When you post, please post as much information as possible, including:
The function number: n/a
The complete error text: No error
The window affected: Economics/GU Training
What you were doing at the time: Creating ground units
Conventional or TN start: TN
Random or Real Stars: Random
Is your decimal separator a comma?: No
Is the bug is easy to reproduce, intermittent or a one-off?: Easy
If this is a long campaign - say 75 years or longer - let me know the length of the campaign as well: n/a

In the ground unit training window, if you delete the active task, the task queue will not correctly advance. To reproduce:
1) Queue up a set of ground units.
2) Delete the active task. You'll see that the queue is unaffected by this.
3) Run a few construction cycles. You'll see that the queue does not advance. The first queued task will not begin.

You can create a new task, and it will become the new active task, jumping to the front of the queue. Otherwise, the queue remains frozen.
Title: Re: v1.12.0 Bugs Thread
Post by: db48x on February 15, 2021, 02:36:54 PM
New game, no error messages, period is the decimal separator, etc. I just noticed that the Per Mine rate shown for Conventional Industry on the mining tab is incorrect. They have a Production rate of 1.5, and I have a Total Mod of 1.3, so the Per Mine rate should be 1.95, but it shows 1.3. It calculates the Total Prod correctly, 628*1.95, so this must be a display error rather than a calculation error.

(http://db48x.net/Aurora/is%20the%20mining%20rate%20of%20conventional%20industry%20calculated%20incorrectly.png)
Title: Re: v1.12.0 Bugs Thread
Post by: ZimRathbone on February 20, 2021, 08:21:36 AM
Problem: Freighter in flight Refueling not working

The function number: n/a
The complete error text: No error
The window affected: Naval Organisation
What you were doing at the time: Moving Freighter groups
Conventional or TN start: TN
Random or Real Stars: Random
Is your decimal separator a comma?: No
Is the bug is easy to reproduce, intermittent or a one-off?: Easy
If this is a long campaign - no

Standard freighters and Colony ships do not refuel from attached tankers

Put a bunch of freighters in a fleet with a tanker, tanker is set to refuel own fleet, move beyond max freighter range then they will run out of fuel.  Add a few salvagers and they will be refueled but not the freighters.
Title: Re: v1.12.0 Bugs Thread
Post by: db48x on February 20, 2021, 10:29:10 PM
Standard freighters and Colony ships do not refuel from attached tankers

Put a bunch of freighters in a fleet with a tanker, tanker is set to refuel own fleet, move beyond max freighter range then they will run out of fuel.  Add a few salvagers and they will be refueled but not the freighters.

Your screenshots are much too small to read any of the text, so I've no idea if you're making a mistake or not. However, in my current game I have a fleet of six freighters and a tanker and the freighters are definitely being refueled by the tanker while in flight. Sadly I neglected the underway replenishment tech line so the tanker is not able to keep up; every so often they have to stop for a day to refuel while stationary.
Title: Re: v1.12.0 Bugs Thread
Post by: Caesar on February 22, 2021, 08:06:54 PM
It appears that player races can only set attitudes towards other empires (hostile/neutral, et cetera) if every player race has discovered at least one other alien race (it doesn't matter whether or not that race is an NPR or otherwise). If you have three races, and two of them know each other but the third knows nobody, nobody can set their attitudes to anyone. Spawning an alien that the third can detect will fix the issue for all races. Deleting that new race to empty the intelligence screen for one race will cause the bug to reappear for all races.

A more detailed discussion on the subject can be found here:

http://aurora2.pentarch.org/index.php?topic=12464.0
Title: Re: v1.12.0 Bugs Thread
Post by: TMaekler on February 23, 2021, 07:47:17 AM
Haven't figured it out exactly how to repeat, but occasionally my deep space self jumping exploration ships get stuck at a jump point and can't jump through. I then delete all commands, reinitiate the same again and it works. That a known bug?
Title: Re: v1.12.0 Bugs Thread
Post by: SpaceMarine on February 23, 2021, 07:51:10 AM
Haven't figured it out exactly how to repeat, but occasionally my deep space self jumping exploration ships get stuck at a jump point and can't jump through. I then delete all commands, reinitiate the same again and it works. That a known bug?

Thats 90% likely to just be jump shock
Title: Re: v1.12.0 Bugs Thread
Post by: Droll on February 23, 2021, 11:07:13 AM
Haven't figured it out exactly how to repeat, but occasionally my deep space self jumping exploration ships get stuck at a jump point and can't jump through. I then delete all commands, reinitiate the same again and it works. That a known bug?

Thats 90% likely to just be jump shock

Since when did jump shock prevent jumping? And if so why do some people have problems with NPRs playing peek-a-boo around JPs?
Title: Re: v1.12.0 Bugs Thread
Post by: nuclearslurpee on February 23, 2021, 11:14:40 AM
Haven't figured it out exactly how to repeat, but occasionally my deep space self jumping exploration ships get stuck at a jump point and can't jump through. I then delete all commands, reinitiate the same again and it works. That a known bug?

Thats 90% likely to just be jump shock

Since when did jump shock prevent jumping? And if so why do some people have problems with NPRs playing peek-a-boo around JPs?

It prevents jumping for a short period of time, however this doesn't apply to NPRs which is why you get the peek-a-boo behavior (fixed in 1.13). The jump shock usually doesn't last very long but if you jump and then immediately issue an order to jump back it will throw an event for at least one sub-pulse.
Title: Re: v1.12.0 Bugs Thread
Post by: Droll on February 23, 2021, 11:18:56 AM
Haven't figured it out exactly how to repeat, but occasionally my deep space self jumping exploration ships get stuck at a jump point and can't jump through. I then delete all commands, reinitiate the same again and it works. That a known bug?

Thats 90% likely to just be jump shock

Since when did jump shock prevent jumping? And if so why do some people have problems with NPRs playing peek-a-boo around JPs?

It prevents jumping for a short period of time, however this doesn't apply to NPRs which is why you get the peek-a-boo behavior (fixed in 1.13). The jump shock usually doesn't last very long but if you jump and then immediately issue an order to jump back it will throw an event for at least one sub-pulse.

I have had some of my ships (100% training for what it's worth) have trouble for multiple sub-pulses but they do always eventually transit. I guess this is why.
Title: Re: v1.12.0 Bugs Thread
Post by: Kylemmie on February 23, 2021, 11:34:21 AM
Haven't figured it out exactly how to repeat, but occasionally my deep space self jumping exploration ships get stuck at a jump point and can't jump through. I then delete all commands, reinitiate the same again and it works. That a known bug?

Thats 90% likely to just be jump shock

Since when did jump shock prevent jumping? And if so why do some people have problems with NPRs playing peek-a-boo around JPs?

It prevents jumping for a short period of time, however this doesn't apply to NPRs which is why you get the peek-a-boo behavior (fixed in 1.13). The jump shock usually doesn't last very long but if you jump and then immediately issue an order to jump back it will throw an event for at least one sub-pulse.

I have had some of my ships (100% training for what it's worth) have trouble for multiple sub-pulses but they do always eventually transit. I guess this is why.

I see this effect (not a bug for me) if I send a scout into a system for a peek and scoot if I give them a 'jump back' order on the tick they announce 'orders complete'. It will announce something about the Engines not being correct, but it's really Jump Shock causing the delay.

Ignore, continue time and the ship will jump next tick.
Title: Re: v1.12.0 Bugs Thread
Post by: Droll on February 23, 2021, 01:51:37 PM
Haven't figured it out exactly how to repeat, but occasionally my deep space self jumping exploration ships get stuck at a jump point and can't jump through. I then delete all commands, reinitiate the same again and it works. That a known bug?

Thats 90% likely to just be jump shock

Since when did jump shock prevent jumping? And if so why do some people have problems with NPRs playing peek-a-boo around JPs?

It prevents jumping for a short period of time, however this doesn't apply to NPRs which is why you get the peek-a-boo behavior (fixed in 1.13). The jump shock usually doesn't last very long but if you jump and then immediately issue an order to jump back it will throw an event for at least one sub-pulse.

I have had some of my ships (100% training for what it's worth) have trouble for multiple sub-pulses but they do always eventually transit. I guess this is why.

I see this effect (not a bug for me) if I send a scout into a system for a peek and scoot if I give them a 'jump back' order on the tick they announce 'orders complete'. It will announce something about the Engines not being correct, but it's really Jump Shock causing the delay.

Ignore, continue time and the ship will jump next tick.

It sounds like the real "bug" here is the message attached to the "transit failure" entry - I think it should tell the player "the jump engine is not ready" instead.
Title: Re: v1.12.0 Bugs Thread
Post by: nuclearslurpee on February 25, 2021, 12:18:47 AM
Bug seen in the image below:

On the intel screen, Gauss cannon weapon damage is cut off so that the number of shots per gun/turret cannot be read. This is not a screen size problem as the window fits comfortably within my 1920x1080 monitor with room to spare.

(https://i.imgur.com/Rpze4NR.png)
Title: Re: v1.12.0 Bugs Thread
Post by: nuclearslurpee on February 26, 2021, 09:16:57 PM
Precursor missile base does not fire at an approaching fleet until the fleet is within point-blank range. Active sensor should have no problem resolving my fleet well beyond this range. Database attached.

No function number.
No error text.
No specific window affected. Fleet movement and (lack of) combat observed in the tactical window.
What I was doing at the time: gave fleet move order to hostile contact and advanced time manually until fleet was in range.
TN start, 2b pop, 30% ruins chance.
Real stars.
Decimal separator is a period as God intended.
Steps to reproduce: Order Second Fleet (Devils' Hand system) to move to hostile contact Yuan 002, optionally specify a minimum distance. Advance time. Yuan 002 despite being a missile base armed with size 6 ASMs will not fire on the fleet as it approaches.
Length of campaign is six years and a few months, not very long at all.

I've messed around with various tries of moving fleets in and out of the system, changing orders, SM, etc. and found no workaround. Would appreciate a workaround as I'd like to report this combat in my AAR.

EDIT: I did finally find something resembling a workaround, which was to go into the DB and delete the alien contact data entries. Obviously not a recommended practice but it did get the other guys to shoot at me like normal. My best guess is that the AI tracked the PD capability of my fleet and decided not to "waste" missiles, however (1) this doesn't explain why they then decided to fire at point-blank (~350,000 km) once my beam ships were nearly in range - this seems poor tactics even for the NPRs, as if they're going to fire at all they'd best do it from well outside of beam range, yes? And (2) it would make much better gameplay for the player if the NPR decided to try and mount a defense anyways instead of patiently waiting for their inevitable demise.
Title: Re: v1.12.0 Bugs Thread
Post by: TMaekler on February 27, 2021, 03:10:23 AM
1.12: Is it possible that the pop growth calculation on a planet with Installation AND orbital habitats is mixed up and that somehow causes an error in unrest calculations?

According to the values, the total population is below the maximum of OH plus I (5.10 of 5.17). I still get unrest and the annual growth rate on the (limited) OH is up to 10.5% but 0% on the surface... .

[(https://i.ibb.co/GC1pCW7/Unrest.jpg) (https://ibb.co/frKFrkM)
Title: Re: v1.12.0 Bugs Thread
Post by: Kiero on February 27, 2021, 03:52:36 AM
You don't have enough protection.  :o
Title: Re: v1.12.0 Bugs Thread
Post by: TMaekler on February 27, 2021, 05:42:10 AM
You don't have enough protection.  :o
I do. It says 3 required and 1222 is there.
Title: Re: v1.12.0 Bugs Thread
Post by: Harbinger1 on March 01, 2021, 03:54:31 PM
Not sure if working as intended or a bug, but in my current game I experienced a long slowdown and poked at the DB to see why, and found that the starting NPR had triggered NPR creation in another system. . . and it spawned THREE new NPRs on the exact same planet, who promptly began blowing each other to bits.  If spawning multiple on the same planet is intended, they should probably not be starting their existence with all out warfare with each other otherwise it is not a very interesting mechanic.

 Is the NPR creation by chance recursive? As in when an NPR is spawned, does it count as "discovering" its home system and therefore run the NPR generation check again? I suppose I could test setting it to 100% spawn chance and see if it crashes.
Title: Re: v1.12.0 Bugs Thread
Post by: TheTalkingMeowth on March 01, 2021, 06:57:50 PM
Not sure if working as intended or a bug, but in my current game I experienced a long slowdown and poked at the DB to see why, and found that the starting NPR had triggered NPR creation in another system. . . and it spawned THREE new NPRs on the exact same planet, who promptly began blowing each other to bits.  If spawning multiple on the same planet is intended, they should probably not be starting their existence with all out warfare with each other otherwise it is not a very interesting mechanic.

 Is the NPR creation by chance recursive? As in when an NPR is spawned, does it count as "discovering" its home system and therefore run the NPR generation check again? I suppose I could test setting it to 100% spawn chance and see if it crashes.
There is a chance for NPRs to spawn multi-faction starts (shared homeworld). Which seems like it would be cool, but as you have observed generally just devolves into them blowing the smeg out of each other a few months after spawning. The difficulty is that they get very mad at each other for being in each others systems, since naturally all their explored systems overlap.

I had a game that ended because I found TWO such shared homeworlds. As soon as the first war had more or less died down (in that everyone was dead courtesy of them nuking their own planets), the second one started up.
Title: Re: v1.12.0 Bugs Thread
Post by: Droll on March 01, 2021, 08:20:03 PM
When I got a shared planet one they were actually quite cordial with eachother. But I did help them by providing a common enemy.

Me.
Title: Re: v1.12.0 Bugs Thread
Post by: Harbinger1 on March 01, 2021, 11:36:36 PM
This has been mentioned a couple times previously, but my experience is not exactly as described before:
With the "unload all installations" order after loading 2 different types of installations I am seeing ships unload all of one installation type, followed by all but one of the other installation.  Loading 5 fighter factories followed by 7 mass drivers, then unloading all left 1 mass driver behind.  Loading 5 fighter factories followed by 5 fuel refineries left 1 fighter factory behind, so it is not always the second loaded that fails to fully unload, and the # of each does not have to be different.  Loading 2x each of fighter factory, refinery, mass driver resulted in all 3 installations being unloaded properly.
Title: Re: v1.12.0 Bugs Thread
Post by: nuclearslurpee on March 02, 2021, 12:13:16 PM
This has been mentioned a couple times previously, but my experience is not exactly as described before:
With the "unload all installations" order after loading 2 different types of installations I am seeing ships unload all of one installation type, followed by all but one of the other installation.  Loading 5 fighter factories followed by 7 mass drivers, then unloading all left 1 mass driver behind.  Loading 5 fighter factories followed by 5 fuel refineries left 1 fighter factory behind, so it is not always the second loaded that fails to fully unload, and the # of each does not have to be different.  Loading 2x each of fighter factory, refinery, mass driver resulted in all 3 installations being unloaded properly.

I have observed the same behavior. Glad to know I'm not crazy.
Title: Re: v1.12.0 Bugs Thread
Post by: TMaekler on March 05, 2021, 07:32:56 AM
When "Auto Include LP-Points" is deselected they are ignored when you hand-click the targets. But when you let the game auto-create a route by system the LP points are integrated no matter what the checkbox is set to. This happens in the starting system if there is a shortcut possible between a planet and the initial jump point.
Title: Re: v1.12.0 Bugs Thread
Post by: chrislocke2000 on March 07, 2021, 06:07:39 AM
When selecting 1.25 multiple on beam range I get the 0.25 multiple applied. 1.5 multiple etc seem fine and the actual 0.25 multiple for range also works.
Title: Re: v1.12.0 Bugs Thread
Post by: Droll on March 07, 2021, 10:18:58 AM
When selecting 1.25 multiple on beam range I get the 0.25 multiple applied. 1.5 multiple etc seem fine and the actual 0.25 multiple for range also works.

This bug has been fixed for 1.13
Title: Re: v1.12.0 Bugs Thread
Post by: MuthaF on March 09, 2021, 03:43:12 PM
Seeing as it was not reported, is it only my game where NPR research is not working?
No NPR in my unmoded game researches anything.   Labs available but no research progress in their logs, no research queue, although one of them is building more research labs. 
Only research messages in NPR logs are from NPR creation initial research. 

Also swarm spawning - do they need habitable planet?
First 2 swarms i spawned at Planet X were empty (race created with no units/ships), 3rd on Titan spawned okey. 

[edit]
Self-answer for Swarm spawn conditions:

1) No precursors or aether rifts generated in the system
2) At least one system body with a Swarm Mining Score of 4

The Swarm mining score for a system body is calculated as follows:

1) Total accessibility of minerals where the deposit is at least 1000 tons
2) Accessibility is counted as double if the deposit is 1m tons or more.
3) Accessibility is counted as 1. 5x if the deposit is 100k to 1m tons.
3) Accessibility is counted as 1. 25x if the deposit is 10k to 100k tons.
Title: Re: v1.12.0 Bugs Thread
Post by: Froggiest1982 on March 09, 2021, 03:50:43 PM
Seeing as it was not reported, is it only my game where NPR research is not working?
No NPR in my unmoded game researches anything.  Labs available but no research progress in their logs, no research queue, although one of them is building more research labs.
Only research messages in NPR logs are from NPR creation initial research.

Also swarm spawning - do they need habitable planet?
First 2 swarms i spawned at Planet X were empty (race created with no units/ships), 3rd on Titan spawned okey.

NPRs don't do individual research. Instead, they have projects which are a bunch of research all tied together and released as techs once the number of required research points have been reached.

In slow research games, it could take up to 10/20 years to actually see new NPRs techs to be spawned.
Title: Re: v1.12.0 Bugs Thread
Post by: MuthaF on March 09, 2021, 04:00:14 PM
Quote from: froggiest1982 link=topic=11945.  msg149729#msg149729 date=1615326643
Quote from: MuthaF link=topic=11945.  msg149728#msg149728 date=1615326192
Seeing as it was not reported, is it only my game where NPR research is not working?
No NPR in my unmoded game researches anything.    Labs available but no research progress in their logs, no research queue, although one of them is building more research labs.   
Only research messages in NPR logs are from NPR creation initial research.   

Also swarm spawning - do they need habitable planet?
First 2 swarms i spawned at Planet X were empty (race created with no units/ships), 3rd on Titan spawned okey. 

NPRs don't do individual research.   Instead, they have projects which are a bunch of research all tied together and released as techs once the number of required research points have been reached. 

In slow research games, it could take up to 10/20 years to actually see new NPRs techs to be spawned. 

Well this game is going on for 34 yrs but the logs dont, so its possible.  although they got 50-60 labs.   Will be on a watch-out.   Thanks
Title: Re: v1.12.0 Bugs Thread
Post by: nuclearslurpee on March 11, 2021, 06:58:01 PM
This is probably a WAD but not WAI behavior. All the usual conditions apply - no DB modding, period as decimal, etc. etc.

Recently had an NPR decide they hated me and they informed me of this by blowing up a few of my unarmed scout ships, JP monitors, and so on. Shortly after this, before I could retaliate in kind, I received an event message on the construction tick that the NPR now regarded me as neutral. Shortly after this, I encountered multiple fleets of this NPR consisting of warhips, which I attacked and destroyed without the NPRs firing a shot. Once the next construction tick occurred, the next NPR fleet I encountered fired at my ships as expected.

It seems to me that the NPR AI is not smart enough to realize that "the other guys are shooting us" should trump "our diplomatic rating was great two days ago" when deciding whether to defend themselves.
Title: Re: v1.12.0 Bugs Thread
Post by: wilhecomp2 on March 19, 2021, 08:09:43 AM
I initially modified and set up a new game.   Then deleted and retried the set up when I noticed that I could not modify population, factory's, fighter's, mine's, automated mines' and etc.      Then when I did it I continue to get the error:

1. 12. 0 Function #1424:  Index was out of range.   Must be non-negative and less than the size of the collection.   Parameter name: index

Then followed by a whole lot of other errors:   I've tried a number of other setups and continue to get the error.     I finally got fed up and deleted the C# version.     Sorry. . . . .
Title: Re: v1.12.0 Bugs Thread
Post by: wilhecomp2 on March 19, 2021, 08:46:12 AM
I have redownloaded the game again and still have the same problem now:   These errors also repeat:

1. 12. 0 Funtion #1612: Object Reference not set to an instance of an object

1. 12. 0 Funtion #1607: Object Reference not set to an instance of an object

1. 12. 0 Funtion #1562: Object Reference not set to an instance of an object

1. 12. 0 Funtion #1423: Object Reference not set to an instance of an object

1. 12. 0 Funtion #1424: Index was out of range.   Must be non-negative and
less than the size of the collection.  Parameter name: Index

1. 12. 0 Funtion #1612: Object Reference not set to an instance of an object

1. 12. 0 Funtion #1607: Object Reference not set to an instance of an object

1. 12. 0 Funtion #1562: Object Reference not set to an instance of an object

1. 12. 0 Funtion #1423: Object Reference not set to an instance of an object

Index was out of range.   Must be non-negative and
less than the size of the collection.  Parameter name: Index
Title: Re: v1.12.0 Bugs Thread
Post by: TheTalkingMeowth on March 19, 2021, 08:54:11 AM
I have redownloaded the game again and still have the same problem now:   These errors also repeat:

1. 12. 0 Funtion #1612: Object Reference not set to an instance of an object

1. 12. 0 Funtion #1607: Object Reference not set to an instance of an object

1. 12. 0 Funtion #1562: Object Reference not set to an instance of an object

1. 12. 0 Funtion #1423: Object Reference not set to an instance of an object

1. 12. 0 Funtion #1424: Index was out of range.   Must be non-negative and
less than the size of the collection.  Parameter name: Index

1. 12. 0 Funtion #1612: Object Reference not set to an instance of an object

1. 12. 0 Funtion #1607: Object Reference not set to an instance of an object

1. 12. 0 Funtion #1562: Object Reference not set to an instance of an object

1. 12. 0 Funtion #1423: Object Reference not set to an instance of an object

Index was out of range.   Must be non-negative and
less than the size of the collection.  Parameter name: Index

Without more detail diagnosis is hard, but here's a guess. Is your decimal separator a comma (i.e. Windows is not set to use US/UK number displays)?

The game requires you to set your decimal separator to a period. Not doing so can cause all sorts of issues.
Title: Re: v1.12.0 Bugs Thread
Post by: wilhecomp2 on March 19, 2021, 11:21:09 AM
Thank You.     I've keep both the commas and periods were appropriate and still have the problems:

(http://)
Title: Re: v1.12.0 Bugs Thread
Post by: wilhecomp2 on March 19, 2021, 11:22:03 AM
2nd part
Title: Re: v1.12.0 Bugs Thread
Post by: TheTalkingMeowth on March 19, 2021, 03:45:25 PM
2nd screen shot looks like you've successfully changed numbers like starting military academies. Does the error happen when you click create race?
Title: Re: v1.12.0 Bugs Thread
Post by: nuclearslurpee on March 19, 2021, 03:50:21 PM
Thank You.     I've keep both the commas and periods were appropriate and still have the problems:

(http://aurora2.pentarch.org/index.php?action=dlattach;topic=11945.0;attach=6349;image)

You have Minimum NPR Distance set to 75 LY and Maximum NPR Distance set to 50 LY. Try switching those around so they're in the correct order (Min < Max) and see if that solves it.
Title: Re: v1.12.0 Bugs Thread
Post by: wilhecomp2 on March 19, 2021, 05:12:55 PM
nuclearslurpee

Opps. . . .

You were right. . . .     I switched the 75 to Max and 60 to Min. . . . .

Thank you
Title: Re: v1.12.0 Bugs Thread
Post by: TMaekler on March 22, 2021, 12:09:02 PM
Changing a cycle command: A command chain set on cycle leads to an interesting effect when one changes the last command. I had exchanged a fuel depot fleet with a new fuel depot because the old one didn't work - I had to add a refueling hub. So I thought I could simply change the refuel fleets when that command is at the last position in the queue. But that somehow garbles the flight direction of the refueling fleet. They simply go off into space not flying towards the target planet anymore.

A bit strange and I cannot pinpoint it exactly but this is at close as I could get to the bottom of some fleets flying off into the distance.
Title: Re: v1.12.0 Bugs Thread
Post by: nuclearslurpee on March 22, 2021, 12:20:21 PM
Changing a cycle command: A command chain set on cycle leads to an interesting effect when one changes the last command. I had exchanged a fuel depot fleet with a new fuel depot because the old one didn't work - I had to add a refueling hub. So I thought I could simply change the refuel fleets when that command is at the last position in the queue. But that somehow garbles the flight direction of the refueling fleet. They simply go off into space not flying towards the target planet anymore.

A bit strange and I cannot pinpoint it exactly but this is at close as I could get to the bottom of some fleets flying off into the distance.

Does this happen if you turn off order cycling, make the change, and turn cycling back on? If nothing else knowing a workaround will help anyone else with the same bug.
Title: Re: v1.12.0 Bugs Thread
Post by: TMaekler on March 22, 2021, 12:37:13 PM
Haven't checked if the error occurs this way also... . I'll check.
Title: Re: v1.12.0 Bugs Thread
Post by: TMaekler on March 22, 2021, 03:08:27 PM
V1.12
====

After a fuel transfer to a fuel hub, the fuel ship has a negative value of -137.150. Attached is a zip that contains the DB before and after the transaction. Before is a little time before it happens (29-Aug) and after is on (15-Oct).

https://drive.google.com/file/d/1UIPtHpLrSnK-Url5uYs5WsSaxl6V0DZx/view?usp=sharing (https://drive.google.com/file/d/1UIPtHpLrSnK-Url5uYs5WsSaxl6V0DZx/view?usp=sharing)

Edit: Also the Fuel Depot with the refuel hub is loaded over its maximum. Somehow this over amount of fuel is added beyond the capacity of the fuel depot.
Title: Re: v1.12.0 Bugs Thread
Post by: bsh on March 24, 2021, 07:31:27 AM
So I tried to use the advanced search to look these up on the bugs thread, but didn't quite found this, but it can be my fault. Probably used wrong search terms.

Bug #1: combo grav+geo survey ship standing orders: survey next body, survey next survey location, if fuel less than 30% - refuel and resupply at colony or hub (all), if deployment exceeded - refuel, resupply and overhaul. Whenever deployment time is exceeded, I get two error messages (I'll look up the function number when I'm at home) in a row, then the ship goes to overhaul site, but does not refuel or resupply.

#2: survey ship standing orders: survey next three bodies or survey locations, move to system requiring grav survey (the rest is as above). when all known systems are fully surveyed, some ships still decide to move to a specific system (there's nothing there to survey), and then jump back through the entry jump point, then again to the system, forever. sometimes even if not all systems are surveyed, it still chooses some random system (relative nearby) instead of one that actually needs survey, and goes there and does the back and forth jumping.

#3: when an allied race gives me grav survey information, the log says something like "blah blah blah data provided by" - I guess it should be followed by the race's name or maybe their ship's name, but nothing.

#4: i think this is already reported: when transporting multiple installations with own freighters, they only unload some fraction of it at the target. sometimes a fraction even gets lost.

The function number: - will look this up if needed.
The complete error text: - will look up.
The window affected: - all
What you were doing at the time: - probably smoking.
Conventional or TN start: - TN
Random or Real Stars: - real
Is your decimal separator a comma? - normally yes but changed it
Is the bug is easy to reproduce, intermittent or a one-off? - easy
If this is a long campaign - say 75 years or longer - let me know the length of the campaign as well: - roughly 200 years but it was happening in the beginning too
Title: Re: v1.12.0 Bugs Thread
Post by: TMaekler on March 24, 2021, 09:37:19 AM
Bug #1: combo grav+geo survey ship standing orders: survey next body, survey next survey location, if fuel less than 30% - refuel and resupply at colony or hub (all), if deployment exceeded - refuel, resupply and overhaul. Whenever deployment time is exceeded, I get two error messages (I'll look up the function number when I'm at home) in a row, then the ship goes to overhaul site, but does not refuel or resupply.
Known and fixed in upcoming 1.13. Rest of your list never heard of...
Title: Re: v1.12.0 Bugs Thread
Post by: TMaekler on March 30, 2021, 04:54:51 PM
A refuel fleet with two tankers inside when added as a sub-fleet and both ships set to "refuel own fleet tankers" to refuel the fuel depot will lead to one of the two tankers emptied and the other one will never be touched. They are two different classes of tankers (one older class with a slower FPH transfer volume). Maybe it is caused by that?
Also, if I set only one of them to refuel the base fleet it automatically refuels the other tanker and no fuel goes to the base fleet.
Title: Missile Bug
Post by: Needler on March 31, 2021, 10:25:56 PM
Having an issue with my missile pod fleets.  I like to group missile pods in large bunches of say 100 and detach smaller bunches to deal with individual targets.  I had a pair of spoiler ships squadron transit in and begin a run back out the warp point.  I detached 2 groups of 10 and 15 at the same time and fired.  Both launched correctly but failed to kill either ship.  I then detached 2 more groups of 10 and fired.  Both groups reported successful launches and the missiles were gone from the magazines, but the missiles never appeared on the tactical screen.  I detached more groups over several more pulses, varying the names and double checking target and launch settings.  Those missiles disappeared too.  After the enemy escaped (should have been dead 3 times over. . . ) I went back over the pods and could find nothing amiss.  There were some beam warships also shooting, they showed no abnormal behavior.  This has happened before, but that game bugdeathed shortly after, so I chalked it up to that.  Will add DB when I have more time.     


The function number: No error
The complete error text: n/a
The window affected: Tactical
What you were doing at the time: Missile Combat
Conventional or TN start: TN
Random or Real Stars: Real
Is your decimal separator a comma?: Yes
Is the bug is easy to reproduce, intermittent or a one-off?: Has happened Twice, am Reloading and waiting. . .
If this is a long campaign - say 75 years or longer - let me know the length of the campaign as well: 25 years
Title: Re: Missile Bug
Post by: nuclearslurpee on March 31, 2021, 10:33:56 PM
Having an issue with my missile pod fleets.  I like to group missile pods in large bunches of say 100 and detach smaller bunches to deal with individual targets.  I had a pair of spoiler ships squadron transit in and begin a run back out the warp point.  I detached 2 groups of 10 and 15 at the same time and fired.  Both launched correctly but failed to kill either ship.  I then detached 2 more groups of 10 and fired.  Both groups reported successful launches and the missiles were gone from the magazines, but the missiles never appeared on the tactical screen.  I detached more groups over several more pulses, varying the names and double checking target and launch settings.  Those missiles disappeared too.  After the enemy escaped (should have been dead 3 times over. . . ) I went back over the pods and could find nothing amiss.  There were some beam warships also shooting, they showed no abnormal behavior.  This has happened before, but that game bugdeathed shortly after, so I chalked it up to that.  Will add DB when I have more time.     


The function number: No error
The complete error text: n/a
The window affected: Tactical
What you were doing at the time: Missile Combat
Conventional or TN start: TN
Random or Real Stars: Real
Is your decimal separator a comma?: Yes
Is the bug is easy to reproduce, intermittent or a one-off?: Has happened Twice, am Reloading and waiting. . .
If this is a long campaign - say 75 years or longer - let me know the length of the campaign as well: 25 years

Can you confirm that your version number is 1.12? I'm not sure but this sounds like something I remember seeing attributed as a bug in 1.5 that was later patched out.
Title: Missile Bug
Post by: Needler on March 31, 2021, 10:35:09 PM
Yes, version 1. 12
Title: Re: v1.12.0 Bugs Thread
Post by: Droll on April 01, 2021, 09:57:51 AM
What was the cause of the bugdeath? Did this save come with the cardinal sin of DB editing at any point? If yes, what did you edit?
Title: Re: v1.12.0 Bugs Thread
Post by: Pesinario on April 01, 2021, 04:57:29 PM
TL;DR: Mass drivers with only restricted minerals to send seem to be buggy.
So, i ran into this bug (Image attached) while passing time (Anywhere from 2-100 times that error message), started after i created a couple of new ships, three at a time, one was able to get fueled completely, one partially and the last one not at all, this may be related or not.  (I added this here because the situation described below is a common occurrence in my games and never had any issues before)
The cause seems to be related to this other bug report from v1. 9. 5 (hxxp: aurora2. pentarch. org/index. php?topic=11298. msg131674#msg131674) (What for him showed up as #2092, the mineral tab works fine for me).
After trying a couple of things, setting mass driver destination to "None", saving, and restarting the game ended out fixing it.  Then i tried one by one with my few colonies and figured out that the one creating the issue was mercury, which had no mineral production, two mass drivers and the only minerals it had were the ones reserved in the stockpile for ground unit production.  (I have done this before without any issues)
I have attached a screenshot of the error message and the game file in case you want to check it yourself (Pesinario's Game #9).
Title: Re: v1.12.0 Bugs Thread
Post by: Needler on April 01, 2021, 05:49:12 PM
Quote from: Droll link=topic=11945. msg150083#msg150083 date=1617289071
What was the cause of the bugdeath? Did this save come with the cardinal sin of DB editing at any point? If yes, what did you edit?

There were no "cardinal sins" until bugdeath, when I tried to rescue the game.  It was an infinite 5sec, left it running for almost 5 hours.  Opened up the DB and playered all the races, never did find the cause.  Wiped and reinstalled game.
Title: Re: v1.12.0 Bugs Thread
Post by: cah7777 on April 01, 2021, 06:29:37 PM
I developed some new engines and laid down about a dozen ships in various shipyards on Earth.   Now when I load the game and click on the industry tab, I get the Function #2185 error.   The industry tab pulls up, but all shipyard operations have disappeared.   The mining tab shows no minerals in the shipyard tasks column.   The individual shipyards that were building ships have 0 available slipways - like they are still being utilized.   Anyone have any idea how to reset the shipyards?  This campaign was just starting to get interesting.

The function number: #2185
The complete error text: 1. 12. 0 Function #2185 Object reference not set to an instance of an object.
The window affected: Industry/Shipyard/Shipyard Tasks Tab
What you were doing at the time: - nothing exciting IG
Conventional or TN start: - TN
Random or Real Stars: - real
Is your decimal separator a comma? - no, a period
Is the bug is easy to reproduce, intermittent or a one-off? - one-off so far
If this is a long campaign - say 75 years or longer - let me know the length of the campaign as well: - about 75 years
Title: Re: v1.12.0 Bugs Thread
Post by: nuclearslurpee on April 01, 2021, 06:36:32 PM
Quote from: Droll link=topic=11945. msg150083#msg150083 date=1617289071
What was the cause of the bugdeath? Did this save come with the cardinal sin of DB editing at any point? If yes, what did you edit?

There were no "cardinal sins" until bugdeath, when I tried to rescue the game.  It was an infinite 5sec, left it running for almost 5 hours.  Opened up the DB and playered all the races, never did find the cause.  Wiped and reinstalled game.

The 5-second loops are not a bugdeath, they are always due to the AI behavior getting stuck in a loop and usually can be fixed. However setting NPRs to player races is not a good way to fix this and is liable to introduce any number of unpredictable bugs. The "correct" solution is to use the DB to review the game logs to identify the cause - for example you may find an NPR fleet jumping in and out of a jump point on a loop, and in this case you can fix it by simply changing the location of that fleet away from the JP. This does require a small DB edit but is much safer than making the NPRs player races.
Title: Re: v1.12.0 Bugs Thread
Post by: Needler on April 01, 2021, 07:34:49 PM
Quote from: nuclearslurpee link=topic=11945. msg150092#msg150092 date=1617320192
Quote from: Needler link=topic=11945. msg150090#msg150090 date=1617317352
Quote from: Droll link=topic=11945.  msg150083#msg150083 date=1617289071
What was the cause of the bugdeath? Did this save come with the cardinal sin of DB editing at any point? If yes, what did you edit?

There were no "cardinal sins" until bugdeath, when I tried to rescue the game.   It was an infinite 5sec, left it running for almost 5 hours.   Opened up the DB and playered all the races, never did find the cause.   Wiped and reinstalled game.

The 5-second loops are not a bugdeath, they are always due to the AI behavior getting stuck in a loop and usually can be fixed.  However setting NPRs to player races is not a good way to fix this and is liable to introduce any number of unpredictable bugs.  The "correct" solution is to use the DB to review the game logs to identify the cause - for example you may find an NPR fleet jumping in and out of a jump point on a loop, and in this case you can fix it by simply changing the location of that fleet away from the JP.  This does require a small DB edit but is much safer than making the NPRs player races.

1.  I know all this, I did your "correct solution" for the bugdeath first, found NO obvious reasons, Playered all races and individually searched for the cause.  For 5 hours.  Have done this successfully before in other games.  Not this time.

2.  The bugdeath IS NOT what is being reported, the missiles disappearing is.
Title: Missile Bug
Post by: Needler on April 02, 2021, 05:16:24 AM
Who do I send the rapidshare link to?
Title: Re: Missile Bug
Post by: xenoscepter on April 02, 2021, 09:02:52 AM
Who do I send the rapidshare link to?

 - If it's it to your DB, you can just upload it here in an attachment. If that's not working though, the Rapidshare Link goes here as well... if it's for the DB of course. :)
Title: Re: v1.12.0 Bugs Thread
Post by: Needler on April 02, 2021, 04:23:11 PM
Ok, Here's the databases and the txt explanation.
Title: Re: v1.12.0 Bugs Thread
Post by: Black on April 05, 2021, 02:48:47 AM
I developed some new engines and laid down about a dozen ships in various shipyards on Earth.   Now when I load the game and click on the industry tab, I get the Function #2185 error.   The industry tab pulls up, but all shipyard operations have disappeared.   The mining tab shows no minerals in the shipyard tasks column.   The individual shipyards that were building ships have 0 available slipways - like they are still being utilized.   Anyone have any idea how to reset the shipyards?  This campaign was just starting to get interesting.

The function number: #2185
The complete error text: 1. 12. 0 Function #2185 Object reference not set to an instance of an object.
The window affected: Industry/Shipyard/Shipyard Tasks Tab
What you were doing at the time: - nothing exciting IG
Conventional or TN start: - TN
Random or Real Stars: - real
Is your decimal separator a comma? - no, a period
Is the bug is easy to reproduce, intermittent or a one-off? - one-off so far
If this is a long campaign - say 75 years or longer - let me know the length of the campaign as well: - about 75 years

Got the same bug today, I put two new ships into production and closed the game. Today when I started, I got this error.

Some more info: I got single shipyard on different planet and that one was not affected. I tried deleting shipyards and ships that were in refit, but it had no effect.
Title: Re: v1.12.0 Bugs Thread
Post by: nuclearslurpee on April 05, 2021, 10:42:56 AM
I developed some new engines and laid down about a dozen ships in various shipyards on Earth.   Now when I load the game and click on the industry tab, I get the Function #2185 error.   The industry tab pulls up, but all shipyard operations have disappeared.   The mining tab shows no minerals in the shipyard tasks column.   The individual shipyards that were building ships have 0 available slipways - like they are still being utilized.   Anyone have any idea how to reset the shipyards?  This campaign was just starting to get interesting.

The function number: #2185
The complete error text: 1. 12. 0 Function #2185 Object reference not set to an instance of an object.
The window affected: Industry/Shipyard/Shipyard Tasks Tab
What you were doing at the time: - nothing exciting IG
Conventional or TN start: - TN
Random or Real Stars: - real
Is your decimal separator a comma? - no, a period
Is the bug is easy to reproduce, intermittent or a one-off? - one-off so far
If this is a long campaign - say 75 years or longer - let me know the length of the campaign as well: - about 75 years

Got the same bug today, I put two new ships into production and closed the game. Today when I started, I got this error.

Some more info: I got single shipyard on different planet and that one was not affected. I tried deleting shipyards and ships that were in refit, but it had no effect.

Is the fleet that the ships are supposed to go into deleted or not located at the planet?
Title: Re: v1.12.0 Bugs Thread
Post by: Black on April 05, 2021, 12:10:56 PM

Is the fleet that the ships are supposed to go into deleted or not located at the planet?

Ships in refit were in orbit of Earth and for quite some time as they were getting new engines. But I just started construction of two new ships, those would go to default Shipyard Fleet that is also in orbit of Earth. I think that the bug was caused by the new constructions, but I have no idea why. I checked the events log and there were no new events connected to shipyards for quite some time.

I attached the database, if anyone wants to check.
Title: Re: v1.12.0 Bugs Thread
Post by: cah7777 on April 05, 2021, 11:52:39 PM
Quote from: nuclearslurpee link=topic=11945. msg150164#msg150164 date=1617637376
Quote from: Black link=topic=11945. msg150154#msg150154 date=1617608927
Quote from: cah7777 link=topic=11945. msg150091#msg150091 date=1617319777
I developed some new engines and laid down about a dozen ships in various shipyards on Earth.    Now when I load the game and click on the industry tab, I get the Function #2185 error.    The industry tab pulls up, but all shipyard operations have disappeared.    The mining tab shows no minerals in the shipyard tasks column.    The individual shipyards that were building ships have 0 available slipways - like they are still being utilized.    Anyone have any idea how to reset the shipyards?  This campaign was just starting to get interesting. 

The function number: #2185
The complete error text: 1.  12.  0 Function #2185 Object reference not set to an instance of an object. 
The window affected: Industry/Shipyard/Shipyard Tasks Tab
What you were doing at the time: - nothing exciting IG
Conventional or TN start: - TN
Random or Real Stars: - real
Is your decimal separator a comma? - no, a period
Is the bug is easy to reproduce, intermittent or a one-off? - one-off so far
If this is a long campaign - say 75 years or longer - let me know the length of the campaign as well: - about 75 years

Got the same bug today, I put two new ships into production and closed the game.  Today when I started, I got this error.

Some more info: I got single shipyard on different planet and that one was not affected.  I tried deleting shipyards and ships that were in refit, but it had no effect.

Is the fleet that the ships are supposed to go into deleted or not located at the planet?

Mine were also being built into the default Shipyard Fleet which was present at the planet and had a few ships in it.
Title: Re: v1.12.0 Bugs Thread
Post by: MuthaF on April 09, 2021, 05:44:46 AM
Didn't find this reported yet:
After loading/starting a game, colony summary screen at first load will always show population growth = 0%
Reloading said screen will fix the shown value.
Seems that population growth calculation shown is not executed properly at first load, or more likely, one of the variables needed for said calculation is not initialized before result getting displayed.
Title: Re: v1.12.0 Bugs Thread
Post by: nuclearslurpee on April 16, 2021, 10:12:21 PM
When a ship surrenders, the targeting lock on that ship is not broken and it is possible for your own ships to fire on the surrendering vessel in the same increment. When a ship surrenders, any ships which were targeting it should immediately release their target locks and not fire.
Title: Re: v1.12.0 Bugs Thread
Post by: Garfunkel on April 17, 2021, 09:06:17 AM
When a ship surrenders, the targeting lock on that ship is not broken and it is possible for your own ships to fire on the surrendering vessel in the same increment. When a ship surrenders, any ships which were targeting it should immediately release their target locks and not fire.
I disagree. If it's the same increment, then they should fire because there is no way they could have known that the ship was going to surrender then and there.
Title: Re: v1.12.0 Bugs Thread
Post by: nuclearslurpee on April 17, 2021, 10:30:35 AM
When a ship surrenders, the targeting lock on that ship is not broken and it is possible for your own ships to fire on the surrendering vessel in the same increment. When a ship surrenders, any ships which were targeting it should immediately release their target locks and not fire.
I disagree. If it's the same increment, then they should fire because there is no way they could have known that the ship was going to surrender then and there.

This is certainly reasonable, although I would argue not as fun as a player - in my mind, it's entirely possible for a ship to signal surrender and the captain to order the guns to hold fire in less than 5 seconds.

However, the targeting still persists beyond that increment, so I believe the bug is a correct assessment. This took me by surprise when one ship surrendered, didn't get blown up on that increment, but did blow up 5 seconds later.  :o
Title: Re: v1.12.0 Bugs Thread
Post by: Garfunkel on April 17, 2021, 11:00:25 AM
Yeah that's a different issue and likely a bug - the targeting should not persist. Sounds like a similar issue to the "destroyed FC keeps trying to target"-bug we had before.
Title: Re: v1.12.0 Bugs Thread
Post by: bsh on April 22, 2021, 12:25:04 PM
sorry if this is not a bug or has already been reported.
I'm sometimes getting these messages, "xyz has been detected here and there". But I never ever found them there or anywhere near. Not even in the db. The Campina Grande Kingdom hasn't even discovered the McCormick system.
This time while trying to check if my ship in that system has a contact, I saw this:
https://imgur.com/a/052G9Mg (https://imgur.com/a/052G9Mg)
My ship is in the McCormick system, but system locations (and contacts) show a different system. Maybe that alien population contact form the AX Microsopii causes the game to think it sees the alien race in the MCormick system, while they are not there?
There are also many ships from another (alllied) race in McCormick. Maybe those trigger these messages? (Becaue every time this has happened there were other ships in the reported systems.)

And this is another suspicious one:
L.H. McNelly 001 has moved from Epsilon Indi to HIP51317 within 14 hours. That is a 20 day trip at ~10k speed. And it is coming through Gliese 33 which isn't even connecte towards Epislon Indi. No hidden or undiscovered dormant jump points in an of those three systems.
https://imgur.com/a/1NEBifJ (https://imgur.com/a/1NEBifJ)

I think my game is starting to get f* up.
Title: Re: v1.12.0 Bugs Thread
Post by: skoormit on April 22, 2021, 01:23:19 PM

My ship is in the McCormick system, but system locations (and contacts) show a different system.


The locations and contacts shown in the fleet order window are the ones in the system that the fleet will be in after it finishes all orders in the orders list.
In this case, the fleet will be in AX Microscopii, because that is the last jump point transit in the order list.

Are you sure that there is no contact for the race in question in the McCormick system?
Title: Re: v1.12.0 Bugs Thread
Post by: bsh on April 22, 2021, 01:40:16 PM
The locations and contacts shown in the fleet order window are the ones in the system that the fleet will be in after it finishes all orders in the orders list.
In this case, the fleet will be in AX Microscopii, because that is the last jump point transit in the order list.

Are you sure that there is no contact for the race in question in the McCormick system?

oh, silly me, you are right. ;D
well I never found them anywhere where reported. and as far as I can tell from the db, they are not there. The MCormick system is only known for race 216 (me) and race 223 (verbania khanate). the campina grande kingdom is 217. there are no fleets in mcormick for race #217. there are no populations there either, for anyone.
Title: Re: v1.12.0 Bugs Thread
Post by: skoormit on April 22, 2021, 01:50:12 PM
The locations and contacts shown in the fleet order window are the ones in the system that the fleet will be in after it finishes all orders in the orders list.
In this case, the fleet will be in AX Microscopii, because that is the last jump point transit in the order list.

Are you sure that there is no contact for the race in question in the McCormick system?

oh, silly me, you are right. ;D
well I never found them anywhere where reported. and as far as I can tell from the db, they are not there. The MCormick system is only known for race 216 (me) and race 223 (verbania khanate). the campina grande kingdom is 217. there are no fleets in mcormick for rac #9217. there are no populations there either, for anyone.

When you double-click that event in the Events window, does it center the map on the location of the bogus sighting?
If so, note the heading and distance of the location relative to the system center.
Then look at the equivalent location (heading and distance from center ) in the Microscopii system.
Is that the location of the known population of race 217 in that system?
If so, this looks very similar to a bug I reported ages ago about false detection reports.
Title: Re: v1.12.0 Bugs Thread
Post by: bsh on April 22, 2021, 02:11:37 PM
When you double-click that event in the Events window, does it center the map on the location of the bogus sighting?
If so, note the heading and distance of the location relative to the system center.
Then look at the equivalent location (heading and distance from center ) in the Microscopii system.
Is that the location of the known population of race 217 in that system?
If so, this looks very similar to a bug I reported ages ago about false detection reports.

I have a save from the exact moment. I can send it to you if you wish.
Doubleclicking the event centers on the Epsilon Eridani jump gate in McCormick. Here is a side by side picture comparing to AX Microscopii.
The heading is similar but the rougly the opposite.
https://imgur.com/a/p8kax53 (https://imgur.com/a/p8kax53)
Title: Re: v1.12.0 Bugs Thread
Post by: skoormit on April 22, 2021, 03:02:21 PM
I have a save from the exact moment. I can send it to you if you wish.

Can you attach the DB here?
Title: Re: v1.12.0 Bugs Thread
Post by: bsh on April 22, 2021, 09:32:12 PM
Can you attach the DB here?
i can try.
Title: Re: v1.12.0 Bugs Thread
Post by: skoormit on April 23, 2021, 07:49:03 AM
Can you attach the DB here?
i can try.

That worked. I was able to open the game with your db and take a look around.

Unfortunately, I don't see any obvious explanation.

My only thought about a possibility:
1) A CGK ship (a scout, perhaps) had been in Epsilon Indi. (This seems reasonable, because the "Known Systems and Populations" list for the CGK includes Epsilon Indi--at some point you (or perhaps an ally) observed a CGK presence there.)
2) That ship jumped into McCormick 541.
3) The allied VER fleet that is parked on that JP saw the ship.
4) Since VER are allies, they alerted you about the CGK presence, but you don't see a contact because the CGK ship is not within range of any of your own sensors.


With #4, I'm only guessing. I'm not sure how contact sharing with allies works.
Perhaps someone familiar with those mechanics is reading?
Title: Re: v1.12.0 Bugs Thread
Post by: bsh on April 23, 2021, 09:54:04 AM
Taht's a possibility. But sharing info between allies is mysterious to me too. But that doesn't explain why the CGK hasn't "dicovered" McCormick system if they jumped there. (Unless I'm looking at the db wrong. Can you check it please?) Oh well.
Title: Re: v1.12.0 Bugs Thread
Post by: skoormit on April 23, 2021, 11:30:24 AM
Taht's a possibility. But sharing info between allies is mysterious to me too. But that doesn't explain why the CGK hasn't "dicovered" McCormick system if they jumped there. (Unless I'm looking at the db wrong. Can you check it please?) Oh well.

You are correct. If my explanation were correct, CGK would have discovered that system.

I conclude this is a bug.
I suspect that it is related to the presence of the VER fleet.
In fact, I suspect that the game logic is mistaking a VER ship as belonging to a ship class for the CGK.
It could be that one of the ships was captured from the CGK?
I can't verify that in the database, though.
Title: Re: v1.12.0 Bugs Thread
Post by: ExChairman on April 24, 2021, 12:30:18 AM
Trying to open Intelligence window, when I try it becomes white and nothing can access it... ??? Everything ells seems to work as intended
Title: Re: v1.12.0 Bugs Thread
Post by: skoormit on April 24, 2021, 07:55:26 AM
Trying to open Intelligence window, when I try it becomes white and nothing can access it... ??? Everything ells seems to work as intended

Sounds like a bug for sure. Can you post your game db?
Title: Re: v1.12.0 Bugs Thread
Post by: bsh on May 05, 2021, 11:51:55 AM
Ok, I'm still on 1.12 and reporting in case this bug may be also present in 1.13.
So this is what happened:
The TL;DR version: after conquering an alien capital, the conquered population appears to have human race, and not the conquered race.
Long version:
I've been trying to defeat a pesky alien race's capital for YEARS. due to required force bugs I had to spawn in a lot of ground forces, and that was not even 1/10th of the required force. So I sent in terraformers and started to give them some nice gases and take away atmosphere to reduce temperatures. This has worked for long time, but slowly. So I helped it a little with same laser ships. This dropped the population and the force requirement too. But then it started to groq again! I figured they migt have infrastructure to grow, or building it (although intelligence suggests they don't have much factories). So I have gotten enough and bombed the place with missiles until population reached 0. When I started shooting, population was 104m.
Now the conquered population seems to have 104 million humans in it? That can't be right?

https://imgur.com/a/7ECiAvX (https://imgur.com/a/7ECiAvX)