v1.12.0 Bugs Thread

[Steve Walmsley (OP)]

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.

[John Schilling]

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.

[db48x]

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:

• edited compressed fuel storage cost (http://aurora2.pentarch.org/index.php?topic=11945.msg141435#msg141435)
  
• removed spinal railguns (http://aurora2.pentarch.org/index.php?topic=11945.msg141443#msg141443)
• made engineless sensor bouys follow planets when using "drop ready ordinance" (http://aurora2.pentarch.org/index.php?topic=11945.msg141486#msg141486)
• fixed "#248 input string was not in a correct format" error when editing the Colony Importance field (http://aurora2.pentarch.org/index.php?topic=11945.msg141488#msg141488)
• fixed renaming an obsolete ship class throws an error unless "show obsolete" is checked (http://aurora2.pentarch.org/index.php?topic=11945.msg141496#msg141496)
• automatic govenor assignments will no longer reassign your sector govenors (http://aurora2.pentarch.org/index.php?topic=11945.msg141497#msg141497)
• group contacts no longer throws "#1938" error when trying to shorten short alien class names (http://aurora2.pentarch.org/index.php?topic=11945.msg141575#msg141575)
• fix "#2092 Value for decimal too small/big" error when you have a mass driver on a planet with no manufacturing sector alongside manual mines (http://aurora2.pentarch.org/index.php?topic=11565.msg140735#msg140735)
• fixed "#3334: Object reference not set to yadda yadda yadda" error when editing fleet formations (http://aurora2.pentarch.org/index.php?topic=11945.msg141608#msg141608)
• "Habitable-Range Worlds - Include Low Gravity" now counts worlds correctly (http://aurora2.pentarch.org/index.php?topic=11945.msg141615#msg141615)
• setting your beam fire control to "1.25 Size 1.25 Range" now creates a ×1.25 sized BFC rather than a ×0.25 BFC (http://aurora2.pentarch.org/index.php?topic=11945.msg141639#msg141639)
• ships set to "refuel, resupply, overhaul" as a conditional order will now refuel and resupply even if they have to jump to another system to do so (fixes errors #730 and #722) (http://aurora2.pentarch.org/index.php?topic=11945.msg141995#msg141995)
• system body survey percentage will now be reported correctly (http://aurora2.pentarch.org/index.php?topic=11945.msg142022#msg142022)
• corrected occupation strength required for pacification (possibly just a display bug) (http://aurora2.pentarch.org/index.php?topic=11945.msg142032#msg142032)
• no longer can you add multiple spinal weapons to the same ship class, even if they are of different sizes (http://aurora2.pentarch.org/index.php?topic=11945.msg142034#msg142034)
• fixed something to do with the minimum cloak size tech (http://aurora2.pentarch.org/index.php?topic=11945.msg142119#msg142119)
• no longer can you design geosurvey bouys or missiles that don't work before you have geosurvey sensor tech (http://aurora2.pentarch.org/index.php?topic=11945.msg142164#msg142164)
• weapons that didn't fire because they are out of ammunition will not break down (http://aurora2.pentarch.org/index.php?topic=11945.msg142181#msg142181)
• named the trojan asteroids (if any) of Minerva (if enabled) correctly rather than as moons (http://aurora2.pentarch.org/index.php?topic=11945.msg142183#msg142183)
• fixed the "#3353: an item with the same key has already been added" error when designing new formation element series after exiting and restarting the game (http://aurora2.pentarch.org/index.php?topic=11945.msg142203#msg142203)
• possibly changed AI to pick ship names from their name list randomly, instead of in alphabetical order (http://aurora2.pentarch.org/index.php?topic=11945.msg142244#msg142244)
• STOs can now fire on targets in range even if those targets are on another body, fixes "Function #311: Object reference…" error (http://aurora2.pentarch.org/index.php?topic=11945.msg142261#msg142261)
• Ground Support Fighters can now be given Search and Destroy missions to hostile colonies, not just your own colonies (http://aurora2.pentarch.org/index.php?topic=11945.msg142261#msg142261)
• STO units can no longer attack Ground Support Fighters on missions (http://aurora2.pentarch.org/index.php?topic=11945.msg142261#msg142261)
• Civilian Fuel Harvesters will now respect planetary bans (http://aurora2.pentarch.org/index.php?topic=11945.msg142347#msg142347)

[Demetrious]

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!

[Steve Walmsley (OP)]

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

[Steve Walmsley (OP)]

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, 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.

[Steve Walmsley (OP)]

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.

[Steve Walmsley (OP)]

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.

[Steve Walmsley (OP)]

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.

[TheTalkingMeowth]

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.

[ndkid]

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.

[Potat999]

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

[Steve Walmsley (OP)]

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.

[Steve Walmsley (OP)]

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.

[Steve Walmsley (OP)]

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 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.