persistence of deep space Rock Hermits in 1.77.1

[Commander McLane]

A question to the developers: IIRC, Rock Hermits are becoming persistent in their location, and are already so in 1.77. Also, there are now Rock Hermits in deep space, and this is maybe also true already in 1.77.

Now my question: are these deep space Rock Hermit also meant to be location persistent? This would be enormously helpful for both Randomshipnames OXP and this new little project.

I'm asking because I have currently a problem with a deep space Rock Hermit in the Esxear system in Gal 8. When I first jumped into the system it was located at (-560032, -187248, 96795.9). But when I jumped out and in again it was located at (-563880, -174748, 154804). Close, but no cigar. It's definitely well outside the persistence check that the Randomshipnames script uses, thus the script doesn't recognize it as the same hermit and slaps a new name on it for the second visit.

Another possibility is that this particular hermit wasn't added by the populator, but by some script. However, I am not aware of scripts in my installed OXPs that add Rock Hermits plus a small asteroid cluster in deep space. Does anyone off the top of their head know such a script?

[Cody]

Curious - I was about to ask a question about rock hermits and Random Ship Names, so I'll drop it here: running trunk, when I save at a RH, it has an RSN name, but after quitting/reloading it is only named Rock Hermit on F5. When I switch to another screen, then back, or launch, it then has a new name - will you be able to work around that, McLane?

[cim]

They're supposed to be semi-persistent like the on-lane ones in 1.77.1 but due to a bug with the populator code they can move by up to a few hundred kilometres between visits.

They are fully persistent in 1.79.

[Commander McLane]

Curious - I was about to ask a question about rock hermits and Random Ship Names, so I'll drop it here: running trunk, when I save at a RH, it has an RSN name, but after quitting/reloading it is only named Rock Hermit on F5. When I switch to another screen, then back, or launch, it then has a new name - will you be able to work around that, McLane?

I haven't yet run any trunk version yet, and as I haven't even brought all my OXPs up to 1.77 I'm not too keen on already beginning to accommodate them to 1.79, especially as the changes from 1.77 to 1.79 are huge.

As to the problem you mention, I'm not sure at this point whether I'll be able to work around it. It all depends on the order of things happening. The list of existing names is retrieved from the save file on startUp. The current script assumes that all entities in the system are only spawned after the startUp event. Thus at the time of spawning a Rock Hermit its name can be looked up in the list.

However, I'm not sure what the execution order is if the player begins their game on a Rock Hermit. If it remains the same:

1. startUp first: no system exist yet, all scripts and lists etc. get initialized first
2. entities (including the Rock Hermit around the player) get spawned, randomshipnames' shipSpawned event triggers, name is retrieved from the list, displayName is adjusted
3. F5-screen is called

then the Rock Hermit should already have its previous name on the F5 screen when it first comes up.

Apparently this is not the case. But I'd need to know more about the inner workings of the new save-and-load-on-Rock-Hermits mechanism in order to guess where it goes wrong.

[Commander McLane]

They're supposed to be semi-persistent like the on-lane ones in 1.77.1 but due to a bug with the populator code they can move by up to a few hundred kilometres between visits.

Up to a few hundred kilometres is too much for any script algorithm to match them reliably. So the only workaround that I see is to exclude them from the beacon-giving mechanism until 1.79.

Another question: is there a maximum number of deep space Rock Hermits per system? And if so, does it happen to be 1? If there's guaranteed to be only one deep space Rock Hermit per system, then I can assume identity across visits without having to match coordinates.

[Cody]

... is there a maximum number of deep space Rock Hermits per system? And if so, does it happen to be 1?

I believe that to be the case, yes. At the moment (1.77.1), a deep space RH is only spawned if the populator doesn't spawn a normal RH (I think).

[cim]

It all depends on the order of things happening.

1.77.1:
- ships added to system by main populator,
- startUp JS event,
- on with the game, shipSpawned events fired

1.79:
- planet, sun, main station added to system,
- startUp JS event,
- populator JS event to fill system populator settings
- system populator runs to add core (and perhaps OXP) ships
- if not saved at main station, player moved to saved-at station assuming it still exists,
- new startUpComplete event (for OXPs which need to know what station the player is docked at before doing startup stuff)
- on with the game, shipSpawned events fired

EDIT: Sorry, I forgot a detail, so the above was wrong in a crucial detail: shipSpawned is not fired until the first update after that ship has been added to the universe. Orders of events above corrected. For 1.79 you would need to check if the player's current station had a preserved name in the startUpComplete event, if you wanted to name it before the F5 screen was first displayed.

Another question: is there a maximum number of deep space Rock Hermits per system? And if so, does it happen to be 1?

For the main populator in 1.77.1, yes. As Cody says there will either be 1 or more on-lane hermits, or exactly 1 deep space one.

OXPs might add more, though - I think Pirate Coves only adds on-lane hermits, but Rescue Stations certainly adds some deep space ones occasionally.

[Commander McLane]

Curious - I was about to ask a question about rock hermits and Random Ship Names, so I'll drop it here: running trunk, when I save at a RH, it has an RSN name, but after quitting/reloading it is only named Rock Hermit on F5. When I switch to another screen, then back, or launch, it then has a new name - will you be able to work around that, McLane?

Actually, Cody, strike my first reply to your report.

I was under the impression that I had released the randomshipnames version that stores the names of hermits, and that it therefore wouldn't work in 1.79. Only that's not the case. So you don't even have it yet. Which means that I don't need to worry about why it doesn't work in 1.79.

I'll rectify this ASAP. And then it should keep the name of the hermit you've saved on consistent, and also display it right after loading. At least I can't see why it shouldn't.

[cim]

They're supposed to be semi-persistent like the on-lane ones in 1.77.1 but due to a bug with the populator code they can move by up to a few hundred kilometres between visits.

Up to a few hundred kilometres is too much for any script algorithm to match them reliably. So the only workaround that I see is to exclude them from the beacon-giving mechanism until 1.79.

It's an easy bug to fix in the old code, so 1.78 will position them consistently.

[Cody]

I was under the impression that I had released the randomshipnames version that stores the names of hermits, and that it therefore wouldn't work in 1.79. Only that's not the case. So you don't even have it yet. Which means that I don't need to worry about why it doesn't work in 1.79.

<chortles> Cool!

[Commander McLane]

Another question: in 1.77, when Rock Hermits last for about 90 days, do they all change at the same time, or is different for every single hermit?

So, when the Rock Hermit beacon OXP that I'm working on discovers that its stored hermit positions for the current system are not the actual hermit positions, should it only rebuild the list for the current system, or can it trigger a rebuilding of the complete list?

[cim]

They all change at once.

[Commander McLane]

I hadn't thought to ask whether it's game days or real days. Which is it?

I am currently running a test where I'm jumping around a lot, checking the positions of Rock Hermits. Over 200 game days have passed since I started, and no position change has occurred yet.

[cim]

Game days. The code looks correct for a 97ish-day change (and a ~25,000 day full cycle) though possibly there's a subtle bug somewhere.

Actually, now I look at it, I'm not sure how the hermit positions for lane 1 are deterministic at all in 1.77/1.78.

... test, test, test ...

No, they're not. And because they're not, the lane 2 ones aren't always either. Try Zasoer in Chart 1 (NW of Lave) from a new game. Jumping back and forth to Relaes should give you a variety of outputs of S.shipsWithPrimaryRole("rockhermit");.

Systems which never have a lane 1 hermit (which is deterministic) will have fixed positions for the lane 2 hermit, though.

... test, test, test ...

Ah, and the function which supposedly rotates the random seed every 97 days is in fact doing something very bizarre (and I have no idea why it doesn't give a compiler warning). So yes, that's broken too: apart from the occasional system like Zasoer, lane hermits are fixed in 1.77.1.

That particular bit is still broken in 1.79, so this was definitely worth investigating - thanks for the pointer.

[Commander McLane]

Gosh! That seems a little messy.

I hadn't noticed the lane 1 anomaly (or else I had certainly reported it, too), because in all systems that I've investigated deeper so far there were only lane 2 (or deep space) hermits.

I recall passing through a communist system with three lane 1 hermits, but because I have Commies OXP installed, all those were actually astromines, which are explicitly excluded from the beacon code OXP, because they come with beacons of their own. (I should do something about them in randomshipnames, though, because they have a police scan class, and currently get police designations for names. I'm not totally happy with that.)

Okay, if the lane 1 positions are not fixed, it's good that I've implemented the list-rebuilding mechanism on a per-system basis. So my code should be able to deal with it. It means, though, that both names and beacons for lane 1 hermits will only last during one visit of the system. Such is life.