Author Topic: v1.12.0 Bugs Thread  (Read 70781 times)

0 Members and 2 Guests are viewing this topic.

Offline Droll

  • Vice Admiral
  • **********
  • D
  • Posts: 1709
  • Thanked: 602 times
Re: v1.12.0 Bugs Thread
« Reply #135 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.
 

Offline Black

  • Gold Supporter
  • Rear Admiral
  • *****
  • B
  • Posts: 868
  • Thanked: 218 times
  • Gold Supporter Gold Supporter : Support the forums with a Gold subscription
    2022 Supporter 2022 Supporter : Donate for 2022
    2023 Supporter 2023 Supporter : Donate for 2023
    2024 Supporter 2024 Supporter : Donate for 2024
Re: v1.12.0 Bugs Thread
« Reply #136 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
« Last Edit: November 29, 2020, 07:26:12 AM by Steve Walmsley »
 

Offline Ektor

  • Lieutenant
  • *******
  • E
  • Posts: 191
  • Thanked: 103 times
Re: v1.12.0 Bugs Thread
« Reply #137 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.
 

Offline TheTalkingMeowth

  • Captain
  • **********
  • T
  • Posts: 494
  • Thanked: 203 times
  • Gold Supporter Gold Supporter : Support the forums with a Gold subscription
    2021 Supporter 2021 Supporter : Donate for 2021
    2022 Supporter 2022 Supporter : Donate for 2022
Re: v1.12.0 Bugs Thread
« Reply #138 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.
 

Offline Malorn

  • Sub-Lieutenant
  • ******
  • M
  • Posts: 116
  • Thanked: 23 times
Re: v1.12.0 Bugs Thread
« Reply #139 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.
 

Offline Droll

  • Vice Admiral
  • **********
  • D
  • Posts: 1709
  • Thanked: 602 times
Re: v1.12.0 Bugs Thread
« Reply #140 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
 

Offline xenoscepter

  • Vice Admiral
  • **********
  • Posts: 1159
  • Thanked: 320 times
Re: v1.12.0 Bugs Thread
« Reply #141 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.
 

Online nuclearslurpee

  • Admiral of the Fleet
  • ***********
  • Posts: 3010
  • Thanked: 2266 times
  • Radioactive frozen beverage.
Re: v1.12.0 Bugs Thread
« Reply #142 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.
 

Offline Froggiest1982

  • Gold Supporter
  • Vice Admiral
  • *****
  • F
  • Posts: 1341
  • Thanked: 596 times
  • Gold Supporter Gold Supporter : Support the forums with a Gold subscription
    2021 Supporter 2021 Supporter : Donate for 2021
    2022 Supporter 2022 Supporter : Donate for 2022
    2023 Supporter 2023 Supporter : Donate for 2023
Re: v1.12.0 Bugs Thread
« Reply #143 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.

Offline Ostar

  • Leading Rate
  • *
  • O
  • Posts: 13
  • Thanked: 2 times
Re: v1.12.0 Bugs Thread
« Reply #144 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.
« Last Edit: November 29, 2020, 07:43:14 AM by Steve Walmsley »
 

Offline TheTalkingMeowth

  • Captain
  • **********
  • T
  • Posts: 494
  • Thanked: 203 times
  • Gold Supporter Gold Supporter : Support the forums with a Gold subscription
    2021 Supporter 2021 Supporter : Donate for 2021
    2022 Supporter 2022 Supporter : Donate for 2022
Re: v1.12.0 Bugs Thread
« Reply #145 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.
 

Offline db48x

  • Commodore
  • **********
  • d
  • Posts: 644
  • Thanked: 200 times
Re: v1.12.0 Bugs Thread
« Reply #146 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.
 

Offline TheTalkingMeowth

  • Captain
  • **********
  • T
  • Posts: 494
  • Thanked: 203 times
  • Gold Supporter Gold Supporter : Support the forums with a Gold subscription
    2021 Supporter 2021 Supporter : Donate for 2021
    2022 Supporter 2022 Supporter : Donate for 2022
Re: v1.12.0 Bugs Thread
« Reply #147 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).
 

Offline Ektor

  • Lieutenant
  • *******
  • E
  • Posts: 191
  • Thanked: 103 times
Re: v1.12.0 Bugs Thread
« Reply #148 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
« Last Edit: November 06, 2020, 05:41:12 PM by Ektor »
 

Offline TheTalkingMeowth

  • Captain
  • **********
  • T
  • Posts: 494
  • Thanked: 203 times
  • Gold Supporter Gold Supporter : Support the forums with a Gold subscription
    2021 Supporter 2021 Supporter : Donate for 2021
    2022 Supporter 2022 Supporter : Donate for 2022
Re: v1.12.0 Bugs Thread
« Reply #149 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).