Aurora 4x
C# Aurora => C# Bug Reports => Topic started by: Panpiper on January 15, 2021, 12:54:41 PM
-
I have of course tried to fix this, trying all manner of button click variations on the 'Select Increment Length' buttons. The net result of that is that I have gone from two-hour increments to 20-minute increments per button click. This is 'regardless' of what button I actually click! If I click advance 30 days, I advance twenty minutes. I've tried shutting the game down and reloading. Nothing I do seems to fix this.
Have I "done something" to cause this situation? I am not aware of having done anything out of the ordinary. That said, in my newbieness, I do tend to do a whole heck of a lot of stumbling about in the menus and buttons, so I suppose I 'could' have inadvertently done something to cause this.
-
This is probably caused by an NPR ship trying to instant-jump through a jump gate at every sub-increment, since combat would be interrupting you at 5-sec intervals. To fix it you will probably need to muck around in the DB to find the fleet that is doing this and then move it away from the jump gate.
-
The game will change the time increment when due to NPR activity.. it does not have to be anything that you do.
Just select one or five day increments and leave it on auto until the NPR are finished with whatever activities it is doing.
-
I find this is really common (and annoying) when 2 NPRs find each other. The one time I've directly observed it, 2 NPRs were staking out the same jump point and blinking their active sensors at each other. I think they usually give up once their relations deteriorate far enough.
-
The game will change the time increment when due to NPR activity.. it does not have to be anything that you do.
Just select one or five day increments and leave it on auto until the NPR are finished with whatever activities it is doing.
This isn't true. When it does that, it tells you, this is a bug.
I turned my NPRs to playable (and then back) a while ago because I was having the same problem. It was two fleets from different NPRs sitting at a JP trying to shoot each other without the parts to do so, one of them might also have been trying to jump away with no functional JDs. They were broken up from either lack of maintenance or combat. I deleted the fleets and the problem went away, maybe you could try something like that.
-
The game will change the time increment when due to NPR activity.. it does not have to be anything that you do.
Just select one or five day increments and leave it on auto until the NPR are finished with whatever activities it is doing.
This isn't true. When it does that, it tells you, this is a bug.
I turned my NPRs to playable (and then back) a while ago because I was having the same problem. It was two fleets from different NPRs sitting at a JP trying to shoot each other without the parts to do so, one of them might also have been trying to jump away with no functional JDs. They were broken up from either lack of maintenance or combat. I deleted the fleets and the problem went away, maybe you could try something like that.
Yes... I have had that happen to me too... but it is not what happens every time. Sometimes it just require you to make it resolve itself.
-
I find that literally every game where 2 NPRs find each other devolves into multiple month-long periods of endless 2hr increments. Most of the time it resolves itself after a few real time hours - sometimes it doesn't. If it requires database editing to recover the game, it probably belongs in the bugs forum.
-
I find that literally every game where 2 NPRs find each other devolves into multiple month-long periods of endless 2hr increments. Most of the time it resolves itself after a few real time hours - sometimes it doesn't. If it requires database editing to recover the game, it probably belongs in the bugs forum.
I think Steve had made some mention of correcting the instant-jump problem that was causing a lot of these issues, which in my experience seems to be the main thing that two NPRs interacting can cause.
Probably a helpful suggestion would be to not allow NPR vs NPR events to pause the game clock (although adjusting the sub-increment, sure), though this is probably tricky for Steve to implement.
-
I'm not sure it's the only cause, but the main cause does seem to be the instant NPR jumping. If an NPR catches a hostile NPR fleet at a jump point, they might instantly jump across to escape, but then immediately jump back in, creating an endless loop since neither side can attack each other.
-
Probably a helpful suggestion would be to not allow NPR vs NPR events to pause the game clock (although adjusting the sub-increment, sure), though this is probably tricky for Steve to implement.
It think a problem with this that Steve himself mentioned was that the NPR interrupts are an important part of how the AI actually reacts to events so he would need to rework a bit of the AI to make that work.
-
Probably a helpful suggestion would be to not allow NPR vs NPR events to pause the game clock (although adjusting the sub-increment, sure), though this is probably tricky for Steve to implement.
It think a problem with this that Steve himself mentioned was that the NPR interrupts are an important part of how the AI actually reacts to events so he would need to rework a bit of the AI to make that work.
Yes, that is correct.
-
Probably a helpful suggestion would be to not allow NPR vs NPR events to pause the game clock (although adjusting the sub-increment, sure), though this is probably tricky for Steve to implement.
It think a problem with this that Steve himself mentioned was that the NPR interrupts are an important part of how the AI actually reacts to events so he would need to rework a bit of the AI to make that work.
I posted a temporary workaround for that until that kind of rework happens in the suggestion thread. While it won't prevent those interruptions, at least the player can still have the desired time pass before having to click again, except for "Player" interrupts.
-
I have to say that to date this is the thing that has killed more of my games then anything else. If anyone has tips on what to look for in data base or how to spot those repetitive moves. It feels like the AI needs some break to say if the sam3 thing has been attempted 50 times without success it needs to stop!
-
Set all AIs to player control, load the game and look around for stuff on a jump point. Progress time to find the issue if you need to. When you have identified the problem (or a potential problem), reload and delete or move the ships in question and save again without progressing time. Then flip the AI flags back and pray you didn't break anything important.
-
This seems to be inevitable whenever two NPRs spawn in close proximity. It seems like the AI isn't programmed to withdraw unarmed fleets from contested systems (or maybe it's just not being triggered), so you have two unarmed, hostile fleets facing off against each other, but obviously they don't fight, so it just drags the game down. It seems like usually it's something like a salvage vessel or an unescorted tanker or fuel harvester.
Suggestion:
Make the AI more defensive when it comes to withdrawing noncombat ships from contested systems
Exempt systems from the time increment check when no combat ships are present
Just like you can set a minimum distance for NPRs to spawn from Earth, have a minimum distance between NPRs so they don't start in the next system over and lag down the entire game.
-
I've noticed that oftentimes when I manage to observe NPRs jump back and forth, it seems to be fleets that are trying to head to a base due to being out of fuel which encounter an enemy concentration (read: one unarmed scout ship) and jump away in terror, then jump back again because their AI thinks they need fuel... and so on.
-
I'm having this problem too... but sometimes I have pulses of 6 hours and sometimes 2 hours. How can I make NPRs playable to check? (I tried to deleting all the civilians and it does not work)
Although that is a bit sad, because I don't want to know where are they.. :(
-
I thought I was the only one experiencing this but I had to abandon a recent game cause I was stuck in 3 hour increments for like 5 months. I couldn't find out what caused it to I just called it a loss and started a new playthrough.
-
Mine solved alone after 3 or 4 months. No idea what happened, but I understand you when you resigned... i was veeery near to start a new game.
-
I'm having this problem too... but sometimes I have pulses of 6 hours and sometimes 2 hours. How can I make NPRs playable to check? (I tried to deleting all the civilians and it does not work)
Although that is a bit sad, because I don't want to know where are they.. :(
I thought I was the only one experiencing this but I had to abandon a recent game cause I was stuck in 3 hour increments for like 5 months. I couldn't find out what caused it to I just called it a loss and started a new playthrough.
Almost always, the solution requires digging into the game logs in the DB to identify what is usually an NPR fleet causing the problem (often due to constantly jumping back and forth due to an AI hiccup). Often the problem can be solved by either relocating an NPR fleet, or by deleting the fleet entirely. A bit drastic, but necessary.
-
And.. how can we do that? ??? ???
-
And.. how can we do that? ??? ???
Any SQL browser/editor can let you work with the database and make small changes if needed. For example, DB Browser for SQLite (https://sqlitebrowser.org/).
The table "FCT_GameLog" is your starting point and you can see if for example a particular NPR fleet is jumping back and forth at every sub-increment. You'll have to get comfortable with exploring different tables to find the spot you need to make a change. For example, changing the NPR fleet's position to be away from any jump point may solve the problem.
-
I'm in the precisely same situation, i.e. stuck in 2-hour increments. I've used DB Browser (for the first time) on a copy of the DB and found a suspicious entry at about the time the trouble began: "Destination of FAC Hunter Squadron - Jump 011 cannot be found. Please issue new orders". I deleted that fleet and its ships and the result was that I'm now stuck on 6-minute increments.
I'm not about to give up, but I have no idea how to identify a fleet trying to jump or anything like that. The move orders are incomprehensible. Could anybody walk me through this, or give me a hint how to proceed?
These are the last log entries. Some of these messages already appeared before the 2-hour problem began.
-----------------------------------------
GE Gwanggaeto the Great 002 is unable to carry out its primary standing order: Refuel from Colony or Hub (All)
GE Gwanggaeto the Great 003 is unable to carry out its primary standing order: Refuel from Colony or Hub (All)
GE Gwanggaeto the Great 004 is unable to carry out its primary standing order: Refuel from Colony or Hub (All)
Stabilisation Squadron 003 is unable to carry out its primary standing order: Build Jump Gate at Nearest Jump Point
Stabilisation Squadron 004 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
Stabilisation Squadron 004 is unable to carry out its primary standing order: Build Jump Gate at Nearest Jump Point
JD Saint Augusta 001 is unable to carry out its primary standing order: Join Operational Group
JD Saint Augusta 002 is unable to carry out its primary standing order: Join Operational Group
GE Thufir Hawat 002 is unable to carry out its primary standing order: Refuel from Colony or Hub (All)
DDG Iri IV 039 is unable to carry out its primary standing order: Join Operational Group
DDG Iri IV 040 is unable to carry out its primary standing order: Join Operational Group
FT Viroconium 013 is unable to carry out its primary standing order: Join Operational Group
DDG Iri IV 041 is unable to carry out its primary standing order: Join Operational Group
DDG Iri IV 042 is unable to carry out its primary standing order: Join Operational Group
DDG Iri IV 043 is unable to carry out its primary standing order: Join Operational Group
DDG Iri IV 044 is unable to carry out its primary standing order: Join Operational Group
DDG Iri IV 045 is unable to carry out its primary standing order: Join Operational Group
DDG Iri IV 046 is unable to carry out its primary standing order: Join Operational Group
DDG Iri IV 047 is unable to carry out its primary standing order: Join Operational Group
DDG Iri IV 048 is unable to carry out its primary standing order: Join Operational Group
DDG Iri IV 049 is unable to carry out its primary standing order: Join Operational Group
DDG Iri IV 050 is unable to carry out its primary standing order: Join Operational Group
SS Modena 001 is unable to carry out its primary standing order: Refuel from Colony or Hub (All)
SS Modena 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
SS Modena 003 is unable to carry out its primary standing order: Refuel from Colony or Hub (All)
Stabilisation Squadron 002 is unable to carry out its primary standing order: Build Jump Gate at Nearest Jump Point
DDG Exodus II 003 is unable to carry out its primary standing order: Join Operational Group
DDG Exodus II 004 is unable to carry out its primary standing order: Join Operational Group
Stabilisation Squadron 003 is unable to carry out its primary standing order: Build Jump Gate at Nearest Jump Point
Stabilisation Squadron 004 is unable to carry out its primary standing order: Build Jump Gate at Nearest Jump Point
GE Patecatl 001 is unable to carry out its primary standing order: Refuel from Colony or Hub (All)
GE Patecatl 002 is unable to carry out its primary standing order: Refuel from Colony or Hub (All)
SS Chalchiutotolin 003 is unable to carry out its primary standing order: Refuel from Colony or Hub (All)
SS Chalchiutotolin 004 is unable to carry out its primary standing order: Refuel from Colony or Hub (All)
BDB Judas Priest III 001 is unable to carry out its primary standing order: Join Operational Group
BDB Judas Priest III 002 is unable to carry out its primary standing order: Join Operational Group
BDB Judas Priest III 003 is unable to carry out its primary standing order: Join Operational Group
SV Grizzly Bear 001 is unable to carry out its primary standing order: Join Operational Group
As per standing orders TT Brundisium 003 is moving to join Troop Transport Group - Jump 006
-
I'm in the precisely same situation, i.e. stuck in 2-hour increments. I've used DB Browser (for the first time) on a copy of the DB and found a suspicious entry at about the time the trouble began: "Destination of FAC Hunter Squadron - Jump 011 cannot be found. Please issue new orders". I deleted that fleet and its ships and the result was that I'm now stuck on 6-minute increments.
I'm not about to give up, but I have no idea how to identify a fleet trying to jump or anything like that. The move orders are incomprehensible. Could anybody walk me through this, or give me a hint how to proceed?
These are the last log entries. Some of these messages already appeared before the 2-hour problem began.
-----------------------------------------
GE Gwanggaeto the Great 002 is unable to carry out its primary standing order: Refuel from Colony or Hub (All)
GE Gwanggaeto the Great 003 is unable to carry out its primary standing order: Refuel from Colony or Hub (All)
GE Gwanggaeto the Great 004 is unable to carry out its primary standing order: Refuel from Colony or Hub (All)
Stabilisation Squadron 003 is unable to carry out its primary standing order: Build Jump Gate at Nearest Jump Point
Stabilisation Squadron 004 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
Stabilisation Squadron 004 is unable to carry out its primary standing order: Build Jump Gate at Nearest Jump Point
JD Saint Augusta 001 is unable to carry out its primary standing order: Join Operational Group
JD Saint Augusta 002 is unable to carry out its primary standing order: Join Operational Group
GE Thufir Hawat 002 is unable to carry out its primary standing order: Refuel from Colony or Hub (All)
DDG Iri IV 039 is unable to carry out its primary standing order: Join Operational Group
DDG Iri IV 040 is unable to carry out its primary standing order: Join Operational Group
FT Viroconium 013 is unable to carry out its primary standing order: Join Operational Group
DDG Iri IV 041 is unable to carry out its primary standing order: Join Operational Group
DDG Iri IV 042 is unable to carry out its primary standing order: Join Operational Group
DDG Iri IV 043 is unable to carry out its primary standing order: Join Operational Group
DDG Iri IV 044 is unable to carry out its primary standing order: Join Operational Group
DDG Iri IV 045 is unable to carry out its primary standing order: Join Operational Group
DDG Iri IV 046 is unable to carry out its primary standing order: Join Operational Group
DDG Iri IV 047 is unable to carry out its primary standing order: Join Operational Group
DDG Iri IV 048 is unable to carry out its primary standing order: Join Operational Group
DDG Iri IV 049 is unable to carry out its primary standing order: Join Operational Group
DDG Iri IV 050 is unable to carry out its primary standing order: Join Operational Group
SS Modena 001 is unable to carry out its primary standing order: Refuel from Colony or Hub (All)
SS Modena 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
SS Modena 003 is unable to carry out its primary standing order: Refuel from Colony or Hub (All)
Stabilisation Squadron 002 is unable to carry out its primary standing order: Build Jump Gate at Nearest Jump Point
DDG Exodus II 003 is unable to carry out its primary standing order: Join Operational Group
DDG Exodus II 004 is unable to carry out its primary standing order: Join Operational Group
Stabilisation Squadron 003 is unable to carry out its primary standing order: Build Jump Gate at Nearest Jump Point
Stabilisation Squadron 004 is unable to carry out its primary standing order: Build Jump Gate at Nearest Jump Point
GE Patecatl 001 is unable to carry out its primary standing order: Refuel from Colony or Hub (All)
GE Patecatl 002 is unable to carry out its primary standing order: Refuel from Colony or Hub (All)
SS Chalchiutotolin 003 is unable to carry out its primary standing order: Refuel from Colony or Hub (All)
SS Chalchiutotolin 004 is unable to carry out its primary standing order: Refuel from Colony or Hub (All)
BDB Judas Priest III 001 is unable to carry out its primary standing order: Join Operational Group
BDB Judas Priest III 002 is unable to carry out its primary standing order: Join Operational Group
BDB Judas Priest III 003 is unable to carry out its primary standing order: Join Operational Group
SV Grizzly Bear 001 is unable to carry out its primary standing order: Join Operational Group
As per standing orders TT Brundisium 003 is moving to join Troop Transport Group - Jump 006
My rough guess is that you deleted the operational group, which most newly produced things try to join...
I guess a new OG should be automatically created when a new construction cycle starts - at least, if you have the patience to make it to that...
-
Thanks, but no
- I tested my tinkering on a copy of the game DB. The 2-hour breaks happen in an unmodified game.
- Many construction cycles have passed now.
- Some of these same ships tried to join OpGroups when Neil Armstrong was still wearing diapers.
-
Further research indicates that the move orders are not incomprehensible, but there's 3000 of them. And a fleet jumping back and forth would not leave an entry in the log.
-
Further research indicates that the move orders are not incomprehensible, but there's 3000 of them. And a fleet jumping back and forth would not leave an entry in the log.
I have a suggestion, take another copy of the DB, and in the FCT_Races table switch the NPR race to user-controlled (from 1 to 0 I think). That will allow you to examine what's happening first-hand, and try some solutions.
I never tried giving orders to the NPR as user-controlled, then switching it back to NPR, so I don't know if that would work, but at least you might be able to figure out what the exact problem is.
-
Praise the Lord! It fixed itself - somebody must have blown the bugger to bits.
Thanks, anyway.
Oh, and here's something from another thread that might help in this kind of situation (I haven't checked this out):
"I think i have found the problem - at least the cause of it: after my last battle quite a few unlucky crewmembers where left behind in their lifepods. those must have triggered an interupt - because as soon as the lifepods expired, time increments went back up."
But I'm still wondering: how can you tell from a look at the log or ship or move order table if a fleet is jumping back and forth?
-
But I'm still wondering: how can you tell from a look at the log or ship or move order table if a fleet is jumping back and forth?
You could look in the fleet history?
-
Sigh... it unfixed itself. Back to 2-hour turns.
Now, not being one to give up easily and following Migi's advice, I found the following fleet history entries from recent turns that look decidedly fishy:
43 23300 Asteroid #70: Move to Location 2121525110.0
43 23300 Asteroid #70: Move to Location 2121532310.0
43 23300 Asteroid #70: Move to Location 2121539510.0
[repeated many more times]
43 23333 JP3: Tomten (JG): Standard Transit 2121525110.0
43 23333 JP2: System #53 (JG): Standard Transit 2121532310.0
43 23333 JP3: Tomten (JG): Standard Transit 2121539510.0
43 23333 JP2: System #53 (JG): Standard Transit 2121546710.0
43 23333 JP3: Tomten (JG): Standard Transit 2121553910.0
43 23333 JP2: System #53 (JG): Standard Transit 2121561110.0
43 23333 JP3: Tomten (JG): Standard Transit 2121568310.0
43 23333 JP2: System #53 (JG): Standard Transit 2121575510.0
[repeated many more times]
43 26979 Amity-A I: Move to Location 2122237910.0
43 26979 Amity-A I: Move to Location 2122245110.0
43 26979 Amity-A I: Move to Location 2122252310.0
43 26996 Acute-A VI: Move to Location 2122396310.0
43 26999 Acute-A VI: Move to Location 2122396310.0
43 27002 Acute-A VI: Move to Location 2122396310.0
[repeated many more times]
43 23883 Armendáriz Resources Limited: Refuel from Colony 2122072310.0
43 23883 Armendáriz Resources Limited: Refuel from Colony 2122086710.0
43 23883 Armendáriz Resources Limited: Refuel from Colony 2122101110.0
[repeated many more times]
43 24176 Asteroid #284: Refuel from Colony 2121532310.0
43 24176 Asteroid #284: Refuel from Colony 2121546710.0
43 24176 Asteroid #284: Refuel from Colony 2121561110.0
43 24176 Asteroid #284: Refuel from Colony 2121575510.0
43 24176 Asteroid #284: Refuel from Colony 2121589910.0
[repeated many more times]
43 24222 Fantomen-A II - Moon 1: Refuel from Colony 2122201910.0
43 24222 Fantomen-A II - Moon 1: Refuel from Colony 2122216310.0
43 24222 Fantomen-A II - Moon 1: Refuel from Colony 2122230710.0
43 24222 Fantomen-A II - Moon 1: Refuel from Colony 2122245110.0
[repeated many more times]
43 24435 JP4: Allentown (JG): Standard Transit 2122129910.0
43 24435 JP1: Albuquerque (JG): Standard Transit 2122137110.0
43 24435 JP4: Allentown (JG): Standard Transit 2122151510.0
43 24435 JP1: Albuquerque (JG): Standard Transit 2122165910.0
43 24435 JP4: Allentown (JG): Standard Transit 2122180310.0
43 24435 JP1: Albuquerque (JG): Standard Transit 2122194710.0
43 24435 JP4: Allentown (JG): Standard Transit 2122209110.0
[This one is pretty bad and #1 on my to-hit list]
43 25107 Semarang Prime: Refuel and Resupply from Colony 2121964310.0
43 25107 Semarang Prime: Refuel and Resupply from Colony 2122396310.0
[repeated many more times]
43 25359 JP1: Albuquerque (JG): Standard Transit 2121525110.0
43 25359 JP3: Annapolis (JG): Standard Transit 2121532310.0
43 25359 JP1: Albuquerque (JG): Standard Transit 2121539510.0
43 25359 JP3: Annapolis (JG): Standard Transit 2121546710.0
43 25359 JP1: Albuquerque (JG): Standard Transit 2121553910.0
43 25359 JP3: Annapolis (JG): Standard Transit 2121561110.0
[very, very often]
43 26298 Ag Mines Corporation: Refuel from Colony 2121820310.0
43 26298 Ag Mines Corporation: Refuel from Colony 2121834710.0
43 26298 Ag Mines Corporation: Refuel from Colony 2121849110.0
[repeated many more times]
43 27662 Annaj Prime: Refuel and Resupply from Colony 2121532310.0
43 27662 Annaj Prime: Refuel and Resupply from Colony 2121546710.0
43 27662 Annaj Prime: Refuel and Resupply from Colony 2121561110.0
These are SQL-pulled from the last 383 increments, all 2-hour (7200 sec) turns. Now, which fleet is the culprit? I notice that e.g. the last bunch (Annaj Prime: Refuel and Resupply from Colony) does not have 7200 sec between entries, but why is the fleet repeating this order? Does any of this look legitimate?
I could delete or move all fleets that seem suspicious but I'd prefer minimally invasive surgery on the DB. Some advice would be welcome!
While we're at it: is it enough to change the current x-coordinate to move a fleet?
-
43 23333 JP3: Tomten (JG): Standard Transit 2121525110.0
43 23333 JP2: System #53 (JG): Standard Transit 2121532310.0
43 23333 JP3: Tomten (JG): Standard Transit 2121539510.0
43 23333 JP2: System #53 (JG): Standard Transit 2121546710.0
43 23333 JP3: Tomten (JG): Standard Transit 2121553910.0
43 23333 JP2: System #53 (JG): Standard Transit 2121561110.0
43 23333 JP3: Tomten (JG): Standard Transit 2121568310.0
43 23333 JP2: System #53 (JG): Standard Transit 2121575510.0
[repeated many more times]
43 24435 JP4: Allentown (JG): Standard Transit 2122129910.0
43 24435 JP1: Albuquerque (JG): Standard Transit 2122137110.0
43 24435 JP4: Allentown (JG): Standard Transit 2122151510.0
43 24435 JP1: Albuquerque (JG): Standard Transit 2122165910.0
43 24435 JP4: Allentown (JG): Standard Transit 2122180310.0
43 24435 JP1: Albuquerque (JG): Standard Transit 2122194710.0
43 24435 JP4: Allentown (JG): Standard Transit 2122209110.0
[This one is pretty bad and #1 on my to-hit list]
43 25359 JP1: Albuquerque (JG): Standard Transit 2121525110.0
43 25359 JP3: Annapolis (JG): Standard Transit 2121532310.0
43 25359 JP1: Albuquerque (JG): Standard Transit 2121539510.0
43 25359 JP3: Annapolis (JG): Standard Transit 2121546710.0
43 25359 JP1: Albuquerque (JG): Standard Transit 2121553910.0
43 25359 JP3: Annapolis (JG): Standard Transit 2121561110.0
[very, very often]
Any one of these is the most probable candidate, possibly even all three which would be quite a cluster... probably the next thing is to try and pull apart the fleet orders in the relevant table and figure out where each one is going, then try to move it away from the JP so it cannot just insta-transit and might complete its orders.
While we're at it: is it enough to change the current x-coordinate to move a fleet?
Yes.
-
Have to bother you one more time....
I'm definitely getting somewhere. After adding "1" to the first digit of the four suspects' x-coordinates, I got 30 hours of gameplay in three increments (what unit is this, anyway? Kilometers?). Then I was back to 2 hours, because presumably, they were back at the JP.
Problem is, two of the four fleets are troop transports with proper orders to go to some planet (that I've never heard of). The two others are Jump Point defence fleets. The buggers don't even have orders, they just jump for the fun of it.
edit: it appears the transports are causing the problem.
Given that deleting a fleet seems fraught with peril (operational groups, what have you), what's my best course of action? How can I move them e.g. to their home planet?
-
Ideally you want to try and dig into the fleet in other tables to try and figure out what it is trying to do, and then tune your "fix" to help them accomplish that. A common one is a fleet trying to head home to refuel, but the route home runs through an enemy-infested system and the AI is too stupid to not jump in anyways, and too stupid to once in make a run for it instead of jumping back out. In that case you may be able to help by shifting that fleet towards the jump point they actually need to go through.
Hopefully the rework to jump shock in v2 will help correct this behavior.
-
I'm slowly getting the hang of it, but I'm not making this a hobby any time soon...
My biggest problem is a fleet of five jump point defenders who have been doing the old back-and-forth for a looong time now. They have no orders, no fuel, there seem to be no standing orders for the NPRs I could edit and I don't want to delete them. I teleported them to a faraway place in-system, but like a zombie they always come back. I just switched off their sensors, hoping they'd get blown to bits. No such luck. I'll teleport them to an even further-away place now.
How can teleport them to another system?
-
For others with the same problem: I got rid of these issue several times now.
- Download DB Browser for SQLite
- Save Aurora game, exit Aurora
- Make a backup of your Aurora DB!
- Start DB Browser, load DB
- Find table FCT_Increment. If you're stuck with 2-hour turns, you'll see a lot of 7200 second increments at the end of the table. Choose one that is several increments before the last and copy the timestamp (e.g. "2135824235.0").
- In the SQL command tab enter (with the timestamp from the step above):
SELECT * FROM FCT_FleetHistory
WHERE GameTime > 2135824235.0;
- Run it (click the Play button). You'll get the last couple of actions of all fleets. That should tell you which ones are misbehaving by jumping back and forth.
- Find these fleets in FCT_Fleet. There's a field called Xcor, the x-coordinate of the fleet. Change it by adding a large number. For example, if it reads "-1628493155.80953", change it to "-991628493155.80953". That should teleport the fleet many billions of km away from the jump point.
- Save changes. Done.
That fleet will spend several weeks or months moving back to the jump point. By that time, the reason for going back and forth (most likely an enemy fleet) might have disappeared. If not, rinse and repeat.
Disclaimer: Resist the urge to muck around with too many things in the DB. If you screw up your database, it's your problem. But then you made a backup, didn't you?