v4.5 Bugs

[Steve Walmsley (OP)]

A thread for v4.5 bug reports. If you are still using v4.46, please post those bug reports in the v4.46 thread

Steve

[ussdefiant]

for some reason my survey ships are acting wonky with regards to their condictional orders.

I send a group of six of them into a system, with Transit and divide orders, and the following Default/Condionals.

Defaults
Primary: Survey Nearest Planet or Moon
Secondary: Move to Entry Jump Point

Conditional Order A: Fuel less than 30%
Orders: Refuel at Colony or Tanker within 4 jumps

Conditional Order B: Parent Fleet in system
Orders: Join Fleet

First off, when they jump in, i get a message that one of them is out of fuel, and it promptly merges with the main fleet, while having 100% fuel. Then i get messages from the rest of the subfleets saying they have been given orders to join the first survey ship, but nothing shows up but a Join *BLANK* order which starts all sorts of error messages going. Then, when i get rid of the Join Parent fleet condition due to not doing what i want, the subfleets decide they all want to go back to Sol to collect some fuel.

Question:
How exactly do i get a group of 4 or 6 geosurvey vessels to properly split up and survey everything in the system, and then merge back together?

[Steve Walmsley (OP)]

I'm bringing this up not because of the particular failure mode (i.e. running out of surveyed planets), but rather because yoyoing seems to be a common failure mode that brings the game's updates to a screeching halt.  I think this problem needs a general solution.  The problem is that I haven't got even an inkling of an idea to suggest as to how to go about solving it - the only thing that I can think of at all is for each fleet to keep some sort of history of recent things it's tried to do, and detect repeating patterns (or just yoyos) in it.  I can see lots of problems with this idea though, so it will probably require a better solution.

I have managed to fix a few yoyos in the last couple of hours, mainly through three different databases that people sent me.

1) Some precursors with empty magazines were running away from an NPR. The precursors were faster so they would get out of range and stop. Then the NPR would catch up and the precursor would start running again. Each time this happened it was causing an interrupt. I have fixed this through changing the way that precursors behave once they run out of ammo and possible resupply.

2) Two NPRs had been fighting a huge battle and a now a large NPR fleet was trying to destroy the shipyards of the other NPR. The shipyard was getting hit by 200+ 2-point railgun rounds every increment. The percentage chance of a shipyard being destroyed is (Damage / SY Capacity) * 10000. In this case, that works out to (2/46,000) * 1000 = 0.04, which is getting rounded down to 0. Which means the NPRs couldn't 't destroy the shipyards but they would keep trying forever. Partly this was caused by the introduction of commercial shipyards, which are much larger than I anticipated when I write that code. So the capacity of Commercial Shipyards is now divided by 10 for combat purposes and the minimum chance of destroying a shipyard can not be lower than 1%.

3) An NPR was then trying to blast the population of a second with railguns, which it couldn't do because of the atmosphere. I've fixed it so NPRs will now check for atmosphere before selecting a population as a beam target.

4) Somehow in one game, an NPR had established a neutral relationship with the precursors , although that wasn't specifically the cause of the problem as the following could happen with any pair of neutral NPRs. A precursor fleet and an NPR fleet were both monitoring one another but they had slightly different ranges at which they were choosing to do that. When the Precursor, which was faster, moved away, the NPR lost contact and started heading in a different direction. When the precursor moved after it, the NPR detected it and moved toward it, at which point the precursor moved away and the whole process started again. It's a very unusual situation as the distances between them varied very slightly depending on who was chasing who and the detection range of the NPR fitted in between those two ranges. I have fixed this by changing NPR behaviour so that instead of monitoring neutral contacts, they just confirm their identity with an active scan and then ignore the same neutral contact in the future. I think a few of the yoyo issues are to do with monitoring neutral contacts so I hope this will fix some other potential problems as well.

These changes have required some database mods so I will release a v4.6 in the next few hours
 
Steve

[Steve Walmsley (OP)]

for some reason my survey ships are acting wonky with regards to their condictional orders.

I send a group of six of them into a system, with Transit and divide orders, and the following Default/Condionals.

Defaults
Primary: Survey Nearest Planet or Moon
Secondary: Move to Entry Jump Point

Conditional Order A: Fuel less than 30%
Orders: Refuel at Colony or Tanker within 4 jumps

Conditional Order B: Parent Fleet in system
Orders: Join Fleet

First off, when they jump in, i get a message that one of them is out of fuel, and it promptly merges with the main fleet, while having 100% fuel. Then i get messages from the rest of the subfleets saying they have been given orders to join the first survey ship, but nothing shows up but a Join *BLANK* order which starts all sorts of error messages going. Then, when i get rid of the Join Parent fleet condition due to not doing what i want, the subfleets decide they all want to go back to Sol to collect some fuel.

Question:
How exactly do i get a group of 4 or 6 geosurvey vessels to properly split up and survey everything in the system, and then merge back together?

Definitely some bugs here. I just set this up and got all kinds of weird results. Other people have reported similar problems as well so I need to have a look at this and get back to you.

Steve

[sloanjh]

I think a few of the yoyo issues are to do with monitoring neutral contacts so I hope this will fix some other potential problems as well.

This is my impression as well.

Vague (but probably hard to code) idea for a general fix for a large class of yoyos (and weird NPR behavior) - give the NPRs a "memory" of contacts.  It seems like you've describe two large classes of yoyo causes:

1)  NPR momentarily loses a contact and switches to a completely different behavior

2)  Combat attempts that have 0% chance of success (e.g. the SY example).

For #1, it might help a lot for the NPR to take a while to decide that the contact is lost and change its mode to something else.  One way to do this would be for the NPR to remember the lost contact's course and speed, and keep updating an estimated position where it thinks the lost contact is.  Every update it could then check against a probability of giving up the pursuit, e.g. 10%/hour.  It wouldn't have to keep this estimate for every contact - just the one that it was reacting to.  A typical yoyo I've seen involves an NPR unarmed ship (e.g. geosurvey) running away from a ship I've got picketing a WP with active sensors.  As soon as the NPR loses contact, it turns around and heads back for the WP.  A more sophisticated version of memory would have the NPR remember the estimated contact even after it "gives up".  If the contact shows up again in the predicted place (e.g. my ship is still picketing the WP), the the probability of giving up on the next yoyo would be reduced.

I was going to say I had no ideas for #2, but while typing it I realized that a different sort of memory trick might work.  Basically, an NPR that is performing some task (chasing a ship, bombarding a planet, ...) could perform a check against a probability of giving up and doing something else.  So the ship firing at the SY would eventually figure out it's indestructable, and put that particular action into a list of "things I'm not going to try to do again for the next few days" (btw, that's another way to fix the yoyo in #1 - have the unarmed ship give up on transiting the WP for several days and instead do something else.)

Just thoughts - hope they're useful.  Thanks for spending time on this.

Best,
John

[Steve Walmsley (OP)]

for some reason my survey ships are acting wonky with regards to their condictional orders.

I send a group of six of them into a system, with Transit and divide orders, and the following Default/Condionals.

Defaults
Primary: Survey Nearest Planet or Moon
Secondary: Move to Entry Jump Point

Conditional Order A: Fuel less than 30%
Orders: Refuel at Colony or Tanker within 4 jumps

Conditional Order B: Parent Fleet in system
Orders: Join Fleet

First off, when they jump in, i get a message that one of them is out of fuel, and it promptly merges with the main fleet, while having 100% fuel. Then i get messages from the rest of the subfleets saying they have been given orders to join the first survey ship, but nothing shows up but a Join *BLANK* order which starts all sorts of error messages going. Then, when i get rid of the Join Parent fleet condition due to not doing what i want, the subfleets decide they all want to go back to Sol to collect some fuel.

Question:
How exactly do i get a group of 4 or 6 geosurvey vessels to properly split up and survey everything in the system, and then merge back together?

There is more than 1 bug at work here

Firstly, when I updated the code to objects from mainly DB-related, I forgot to exit if the primary default order is fulfilled, which means any ship with both primary and secondary default orders will try to do both. To make it worse, a default order is always placed first in the queue so the secondary order, which is checked after the primary one, is then placed before the primary one in the orders queue.

Secondly, when a fleet divides partway through the movement phase, I create a new DB record for that fleet (which is working fine) plus I also create an object to use in the rest of the movement phase. During object creation, I reference the database record I just created for the name of the new fleet. What I forgot was that adding a record to an Access recordset does not set that as the current record, so the fleet name assigned to the object is actually the first record in the recordset. In the case of my database, it is set to "Shipyard TG".

I am not sure what is happening with the refuelling issue as I can't recreate that but it is possible it was caused by one of the other bugs and I inadvertently fixed it.

Anyway, all the above is fixed and it seems to be working as intended now. The bug fix will be in v4.6

Steve

[Steve Walmsley (OP)]

1)  NPR momentarily loses a contact and switches to a completely different behavior

For #1, it might help a lot for the NPR to take a while to decide that the contact is lost and change its mode to something else.  One way to do this would be for the NPR to remember the lost contact's course and speed, and keep updating an estimated position where it thinks the lost contact is.  Every update it could then check against a probability of giving up the pursuit, e.g. 10%/hour.  It wouldn't have to keep this estimate for every contact - just the one that it was reacting to.  A typical yoyo I've seen involves an NPR unarmed ship (e.g. geosurvey) running away from a ship I've got picketing a WP with active sensors.  As soon as the NPR loses contact, it turns around and heads back for the WP.  A more sophisticated version of memory would have the NPR remember the estimated contact even after it "gives up".  If the contact shows up again in the predicted place (e.g. my ship is still picketing the WP), the the probability of giving up on the next yoyo would be reduced.

The problems are generally caused by a run-away order so its probably only that one I need to worry about. As NPRs only run from active contacts and I keep the out-of-date active contacts in the DB, perhaps the simplest thing way to implement the above is to change the runaway check from current active contacts to active contacts that are less than 12 hours old or 24 hours old.

2)  Combat attempts that have 0% chance of success (e.g. the SY example).

I was going to say I had no ideas for #2, but while typing it I realized that a different sort of memory trick might work.  Basically, an NPR that is performing some task (chasing a ship, bombarding a planet, ...) could perform a check against a probability of giving up and doing something else.  So the ship firing at the SY would eventually figure out it's indestructable, and put that particular action into a list of "things I'm not going to try to do again for the next few days" (btw, that's another way to fix the yoyo in #1 - have the unarmed ship give up on transiting the WP for several days and instead do something else.)

This is trickier because the problems have occurred not when the NPR has 0% chance to hit (which is already covered in the code) but when the damage is insufficient to affect the target. Damage resolution is handled after all combat is complete so there is no direct correlation between the attack and the damage inflicted later. I don't even record the attacking ship. It is possible I could create some type of counter against a hostile contact so that x number of failed attacks excludes the target but that is tricky and probably would cause other problems due to unforeseen consequences. However, I am less concerned about the situations in #2 because they are usually easy to solve once they are spotted. #1 is a lot more nebulous in nature.

Steve

[Steve Walmsley (OP)]

The problems are generally caused by a run-away order so its probably only that one I need to worry about. As NPRs only run from active contacts and I keep the out-of-date active contacts in the DB, perhaps the simplest thing way to implement the above is to change the runaway check from current active contacts to active contacts that are less than 12 hours old or 24 hours old.

I have made this change. NPR runaway orders now use any active contact that is less than 24 hours old as the basis of their running away, rather than just current contacts. This will affect civilian fleets as well. I'll see how this works in playtest for v4.6 and then make any further modifications as necessary.

Steve

[sloanjh]

The problems are generally caused by a run-away order so its probably only that one I need to worry about. As NPRs only run from active contacts and I keep the out-of-date active contacts in the DB, perhaps the simplest thing way to implement the above is to change the runaway check from current active contacts to active contacts that are less than 12 hours old or 24 hours old.

I have made this change. NPR runaway orders now use any active contact that is less than 24 hours old as the basis of their running away, rather than just current contacts. This will affect civilian fleets as well. I'll see how this works in playtest for v4.6 and then make any further modifications as necessary.

Steve

Cool - I think this will help a lot, not only in fixing the yoyos, but in getting rid of a lot of unnatural behaviors (e.g. faster NPR is running from a missile attack, then stops the moment contact is lost, allowing attacker to maintain the engagement).

John

[waresky]

Pls..too many tread.

NOW r 4.60 ACTIVE
ty