TGs stopping

[mckamx (OP)]

I am running into a problem with some of my TGs stopping midway through an order.    I noticed the problem when a TG did not reach a rendevous.    I looked around for the TG, and found it several systems back.    It claimed to be moving at full speed, but there was no motion "tail", and several weeks later it was still in the exact same spot.    I can sometimes get the TGs to move by changing the commanded speed, or by clearing and reissuing the orders.   I have tried splitting the ships from the TG, and issuing the orders again, but that does not always seem to work either.

I am running version 5. 3.   I am also getting one or two "Error in ExecuteOrders, error 6" errors every turn that may or may not be related.    I do not have the DB password, so havent been hacking the DB.   However, I have had a couple of times when Aurora basically locked up (turn still running after several hours), where I have kill the Aurora processes and restarted.    This seems to have worked, but there is no telling what that sort of thing might do to the DB.

Any ideas on how I can get my TGs to behave?

[EarthquakeDamage]

It sounds like the TG may be held up by some shipyard orders.  Check your shipyard tasks (as in the ones already in progress).  That TG may be the target for new ship construction.  I don't think any ships in a TG can start a repair or overhaul mid-flight, though it may be possible.  Either way, if that TG appears in the Shipyard Tasks tab of the Population/Production (F2) screen for one of your colonies, then that's the problem.

[mckamx (OP)]

Thanks for the response.   It doesnt seem to be a shipyard order in this case.   I have done that in the past, but was able to figure out what the problem was.   In this case, I have had the most success with setting the TG speed to 1, then setting it back to Max.   However, the issue has me worried about my survey fleets that I usually just give "standard orders" to, then deal with only when they have a problem.  If a survey fleet is "stuck", I might not know about it for years, and I have enough of them that manually checking is tedious.

[Ziusudra]

What are the orders of the stuck group?

[mckamx (OP)]

The group that is acting most wonky is a hyper-capable courier that is on a refueling mission for a GeoSurvey ship that is about 50 billion km from the nearest jump point.  The latest oddity was that when the courier reached its final WP before making the long run to the GE TG, it teleported itself to the primary star of the system and refused to budge.  I finally solved that problem by doing a SM transfer of the ship from the courier's TG to the GE's TG, and then did the refueling.

Now I have given the courier orders to run back from the GE to a WP outside the hyper limit: I will see if the courier decides to move or not.

I have a couple of jumpsurvey TG that might be stuck, or might just be pausing between checking survey points.   For right now, I am ignoring them.

Still having Error in ExecuteOrders, error = 6 Overflow, indicating that either I or an NPR has some orders that Aurora doesnt like.

[sloanjh]

The group that is acting most wonky is a hyper-capable courier that is on a refueling mission for a GeoSurvey ship that is about 50 billion km from the nearest jump point.  The latest oddity was that when the courier reached its final WP before making the long run to the GE TG, it teleported itself to the primary star of the system and refused to budge.  I finally solved that problem by doing a SM transfer of the ship from the courier's TG to the GE's TG, and then did the refueling.

Now I have given the courier orders to run back from the GE to a WP outside the hyper limit: I will see if the courier decides to move or not.

I have a couple of jumpsurvey TG that might be stuck, or might just be pausing between checking survey points.   For right now, I am ignoring them.

Still having Error in ExecuteOrders, error = 6 Overflow, indicating that either I or an NPR has some orders that Aurora doesnt like.

Try clearing the orders and re-entering them.  Sometimes you can get a ship in one system with orders to go to another system (this can happen if you change systems in SM mode).  The ship tries to go to a weird location in that case - this could also be the source of the overflows (from the time-to-target calculation overflowing).  The other thing to try is to hit the "max speed" button a couple of times (or enter manually) - speed 1 can also cause overflows.

John

[mckamx (OP)]

After careful monitoring of my TG's, I think that only one is stopping.   This TG is hyper-capable, and is running at hyper speed.   I think I am seeing a pattern where the problem occurs only at certain sub-pulse settings:

If I specify a 30-day advance with 1-day subpulses (yielding the fastest turn processing), the TG stops
If I specify a 30-day advance with automatic subpulses (effectively 6 hour subpluse, yielding a bit slower turn processing), the TG moves.

My hypothesis is that Aurora is calculating the distance traveled per sub-pulse, and one day at hyper-speed is overflowing the calculation.

[sloanjh]

After careful monitoring of my TG's, I think that only one is stopping.   This TG is hyper-capable, and is running at hyper speed.   I think I am seeing a pattern where the problem occurs only at certain sub-pulse settings:

If I specify a 30-day advance with 1-day subpulses (yielding the fastest turn processing), the TG stops
If I specify a 30-day advance with automatic subpulses (effectively 6 hour subpluse, yielding a bit slower turn processing), the TG moves.

My hypothesis is that Aurora is calculating the distance traveled per sub-pulse, and one day at hyper-speed is overflowing the calculation.

This is a reasonable conjecture - I would log it in bugs.  Be sure to mention what the TGs max speed is (w/o hyper) and what the system scale (the green number above the little line in the upper left corner)  is when you push the "min zoom" button on the F3 map - these might affect the overflow.

John

[Father Tim]

The latest oddity was that . . .  it teleported itself to the primary star of the system and refused to budge.

The system primary is always located at co-ordinate [0,0].  Any time something ends up on top of it, it means that that thing had its location wiped somehow.