STATUS_DEAD not always dead

[Eric Walch]

I just encountered a pirate flying loops. On examination it was flying around a position of a dead cargo barrel, trying to scoop the non-existing thing.

Also the frustration counter was not able to break the loop as it went up/down and never reached the trigger. When looping it flew exactly as long from as to the target. I'll tweak that parameter a bit so that approach does not count as strong as going away.

On destroying 3 buoys in a row, the beacon stayed present in the compass, only the character was removed. On cycling it did not come back though. On the third buoy, I opened a target inspector before killing and it seemed that this one was also STATUS_DEAD but not removed. So all three suffered from above bug.

[Eric Walch]

The Zombie bug with DEAD ships is still present. Over the past 9 months I keep seeing it regularly while playing. It just happened again. The targeted ship exploded, but my reticule stayed on 'target'. Opening the inspector, showed the former ship. It mainly happens with thargoids for some reason.



It does mean that the memory is not released. It could be related to the weird bug of spinning stations on the mac. I also wonder: Why keep I seeing these 'Zombies' while I never have seen a report from anybody else. Is this only happening on macs?

I can't believe it is only happening on my mac. I must say that most instances are only found with the target inspector by browsing through the group of still existing ships and that is something others probably don't do to examine ships.

One symptom is a tharglet that refuses to go idle, and on examining it still has a DEAD mother as owner.

[Rorschachhamster]

I had this, once or twice... but it was always late into the night, so...
And not on a mac, windows 7.

[Commander McLane]

I had it also during my recent tests with Thargoid ships.

[cim]

Hmm, Thargoids... Okay, that was a clue. I think I've fixed this (just like I said last time!), but you'll have to wait for Berlios to come back tomorrow so I can actually commit it.

[Eric Walch]

Ah, it was not just me that could not connect... I had more problems the past week with connecting to the repositories..

It are not only thargoids, but mainly. In the system were I made above screenshot, all 'old' ships stayed hanging in status_dead. Newly spawned ships, like released cargo, or ships spawn with the console were killed normally. Among the ships that stayed in status_dead were ships with groups, but I also noticed one without any group parameter and I also noticed one with custom role. (Added by an oxp).

I have not seen a common factor, only that it is triggered faster with thargoids.

[JD]

I'm running the 1.77 deployment version on Win7, and just encountered the same problem. I don't know whether cim's latest change has cured it, so of course this comment may be redundant. However, I thought I'd throw it in in case it's useful.

I had a target lock on a pirate ship, which was then destroyed by someone else. The target lock remained until I reset the missile. After that, I wasn't able to re-obtain the lock from the targeting memory. It made me wonder whether it's the reference from the target lock that prevents the dead ship from being cleared from memory.

[Eric Walch]

Hmm, Thargoids... Okay, that was a clue. I think I've fixed this (just like I said last time!), but you'll have to wait for Berlios to come back tomorrow so I can actually commit it.

I did read this message at Berlios:

Due to maintenance work on our power supply all BerliOS Services will be not available from Friday, March 16th, 17:00 to Monday, March 18th, 12:00 CET.

I also see that you did commit new stuff the past 24 hours, but I seem to be unable to connect for over 2 weeks now. I also see that the last Mac nighty was the 2nd Feb. (The windows nighties still do work)

XCode only gives a not that useful clue. But when I look at the Berlios certificate, I see it does expire at the 13th of March 2013. When logging into their website with ssl, I can ignore the certificates expiring date, but I assume XCode only accepts a valid certificate. I assume I have to wait till they update their certificate.

[cim]

I can ignore the certificates expiring date, but I assume XCode only accepts a valid certificate. I assume I have to wait till they update their certificate.

I've filed a bug report with Berlios to ask them to update it.

[Eric Walch]

It made me wonder whether it's the reference from the target lock that prevents the dead ship from being cleared from memory.

If it is the same bug, you should be able to store the ship in a JS variable with the console, like:

Code: Select all

this.ship = PS.target

After that you can access all properties of the dead ship, even when the target lock is gone.
And when the dead ship was part of a group, you can target a living ship of that group and store the group:

Code: Select all

this.group = PS.target.group

and than access the individual ships with

Code: Select all

this.group.ships[x].foo

Those dead ships were still part of the group even when never targeted. And by setting PS.target to that ship, you get the target lock on it.

[JD]

Ah well, just a thought.

[Eric Walch]

I've filed a bug report with Berlios to ask them to update it.

When they give their certificated a validity of just a year, they should think about updating it at a yearly basis. Just strange that none of my browsers did look at the date of expiring and created a ssl connection using that old certificate.

XCode is also not looking at the date either. It is just my fault that I closed port 22 in my router around the time the certificate expired and Berlios shut down a day for maintenance. XCode was not very helpful with its error code, but now I looked into my system-log and found:

Code: Select all

19-03-13 18:24:09	[0x0-0x2ab2ab].com.apple.Xcode[4829]	ssh: connect to host svn.berlios.de port 22: Operation timed out

Seeing the port 22 in the log gave the clue, as I opened the port 22 to my nas recently and blocked it on the router to avoid access from the internet, without realising XCode also uses that port.

[Eric Walch]

Yesterday I tried a manual "svn up" on that machine and that worked without problems.

This weekend I upgraded my laptop to Mountain Lion. Than I noticed they completely removed the 'svn' command from the terminal.
Apparently you are supposed to do everything with XCode. Lucy enough they anticipated on this and in XCode, under 'preferences -> downloads' there is the option to re-install the command line tools.

[Commander McLane]

At the end of this interesting ride I fired a Killit missile at a Kiota Station, with this interesting result:




Spooky.

[cim]

This is strange. It seems that you can find it fairly reliably, too.

I modified my copy of Oolite to log when a ship is removed from the universe, and then also log in deallocation of that ship (which should follow fairly quickly afterwards), through some in-system journeys.

Four ships were removed from the universe without being later deallocated:
- one was a Cobra III ProxyPlayerEntity (from the "load game" screen, I think). Probably a bug, but not this bug.
- the other three were scooped splinters where this is correct behaviour.

Everything else that was removed from the universe was deallocated as expected.

Is this perhaps another Mac-specific problem? Is it possible that the target inspector is retaining the target? (In 1.76, you'd then have got a target lost anyway as it dropped off the universal ID list, but in 1.77 targeting uses weakrefs instead). If you use the target system memory expansion to go away from the target, can you also use it to restore the lock later? With the ghost bugs I've fixed, that did happen.