Problem:
Sometimes the Autolock will target my own ship when I'm shot at, as opposed to it's normal function of targeting the attacker. It tends to happen when in a really hot furball, and persists until I save, quit, and restart the game.
By doing that, it looks similar to the old 1.73.x "shoot yourself" bug, except for actually lasering myself to death which fortunately doesn't happen.
It could be a bug in either Oolite or Target Autolock. Either way, the log is giving no clues.
Running Oolite buttery smooth & rock stable w/ tons of eyecandy oxps on:
ASUS Prime X370-A
Ryzen 5 1500X
16GB DDR4 3200MHZ
128GB NVMe M.2 SSD (Boot drive)
1TB Hybrid HDD (For software and games)
EVGA GTX-1070 SC
1080P Samsung large screen monitor
This was reported a few weeks ago (here). I think it's just TAP showing up the old underlying bug and making it more common due to the increase in lock-ons.
I can easily code TAP to throw out self lock-ons (I've got v1.11 on my USB key that does so), but I'm loathed to release it as I'd much prefer that the underlying bug was fixed rather than partially hidden by TAP.
But if it does become an annoyance and you want v1.11, send me a PM and I'll sort out a separate download for it.
Trying TAP 1.11, it mostly nullifies the effects of the "shoot yourself" trumble.
However, even TAP 1.11 can be overwhelmed in certain situations, such as this one:
I did a deliberate misjump, and wound up in an epic battle between the Thargs and the Navy. The immediate space was crawling with Bug combat craft, and their drones. Frak! Tibecia all over again! And the Bugs were NOT happy to see my Caddy Omega arrive; they suddenly got hellbent on trying to kill this defiant Lizard.
Soon enough, the TAP was locking onto my ship instead of the Bugs.
I really hope this annoying pain in the tail gets BBQ'd soon. It's putting a damper on my Bughunting expeditions.
Running Oolite buttery smooth & rock stable w/ tons of eyecandy oxps on:
ASUS Prime X370-A
Ryzen 5 1500X
16GB DDR4 3200MHZ
128GB NVMe M.2 SSD (Boot drive)
1TB Hybrid HDD (For software and games)
EVGA GTX-1070 SC
1080P Samsung large screen monitor
I haven't looked at the script but I do know that occasionally a timer is garbage collected after a few minutes in the system. That might well be by design though.
I haven't looked at the script but I do know that occasionally a timer is garbage collected after a few minutes in the system. That might well be by design though.
The documentation wrote:
Note: in order for a timer to work consistently, you must keep a reference to it as long as it is in use. The easiest way is to make it a property of your script: this.timer = new Timer(this, this.doSomething, 5, 5). If this is not done, the JavaScript runtime may delete the timer at any time to free up memory.
But having now looked at the script there doesn't seem to be any reason for the timer object being collected while in flight. this.targetTimer is valid from it's instantiation through to leaving the system. It's only a hunch, but if it is the garbage collector being too hasty moving the:
this.targetTimer = new Timer(this, this.lockOn, 0, 0.25);
to this.startUp and leaving the this.targetTimer.start(); condition in this.shipTargetAcquired may reveal something if the Timer starts disappearing for no reason as it wont be continually reinstantiated. I have no idea why it might target the player ship though. The only reason I've noticed it is because I've been staying in the same system for upward of 10 minutes recently, it happens on random hits too.
That’s hard to say… it’s very occasional and when it happens, it’s always during an intense firefight, with five or more bandits, and I’m taking multiple hits. At that stage I’m usually zoomed right in, so I can’t say how many other ships are in-system. The last time, the bandits were the only ships on scan.
I would advise stilts for the quagmires, and camels for the snowy hills
And any survivors, their debts I will certainly pay. There's always a way!
.
