Oolite Bulletins

Cody wrote:

Can the trunk rock hermit roles be easily added ...
have you just done exactly that, Norby?

Yes, in v1.6.
Thanks for spotting!

Excellent! Thanks for doing!

Hello. I think the immersion aspect of this one is great, must remember not to be miserable and start with the problem. There is a clash, though, it stops Bounty Informer working. That's also a nice little thing to plug into Oolite. It seems what is happening is that both try to add to the ship name and RSN wins. The informer works without RSN but bounties are whatever they are so it's easy enough to live without that. Just something I noticed. Thanks for the work on this. Rich.

richard.a.p.smith wrote:

Hello. I think the immersion aspect of this one is great, must remember not to be miserable and start with the problem. There is a clash, though, it stops Bounty Informer working. That's also a nice little thing to plug into Oolite. It seems what is happening is that both try to add to the ship name and RSN wins. The informer works without RSN but bounties are whatever they are so it's easy enough to live without that. Just something I noticed. Thanks for the work on this. Rich.

Bounty informer, maybe. Bounty scanner, though, seems to work quite well with Random Ship Names:
http://wiki.alioth.net/index.php/Bounty_Scanner

Not available through Download Manager, alas.

(also posted in RH thread)

I'm currently flying a Fer-de-Lance 3G+(t) and installed Random Hits Shipset to have opponents (pirates, assassins) that can match that ship.

Since randomshipnames leaves RH ship names intact to preserve RH mission flavour, this leads to a weird effect :

pirates with names like "Hired Goon" , "Trusty Sidekick" and such.

Could randomshipnames detect whether a RH ship is not part of a RH mission and change the name in that case only ?

This OXP conflicts with bounty informer, as both modify the ship's name. Having Randomshipnames installed negates Bounty informer's effect for anything but asteroids (as asteroids don't get a name). After glancing over the codes, I suspect that what's happening is that setting ship.displayName (which is what Randomshipnames does) makes setting ship.shipUniqueName invisible (which is what bounty informer does)

The documentation is a bit unclear if changing shipUniqueName will change displayName too and/or if changing displayName directly will lead to Oolite ignoring shipUniqueName. But Randomshipnames is ignoring shipUniqueName completely, because it has been written for Oolite versions prior to 1.79. I don't now if anybody still uses a 1.7x version, but to be sure, a modification of Randomshipnames should check the version before referring to shipUniqueName in any way.

Fritz wrote:

The documentation is a bit unclear if changing shipUniqueName will change displayName too and/or if changing displayName directly will lead to Oolite ignoring shipUniqueName. But Randomshipnames is ignoring shipUniqueName completely, because it has been written for Oolite versions prior to 1.79. I don't now if anybody still uses a 1.7x version, but to be sure, a modification of Randomshipnames should check the version before referring to shipUniqueName in any way.

No need for checking the Oolite version, it being an oxz should suffice. And if really needed, put a version limit to the manifest.

So referring an unknown property will simply be ignored? I'm asking because I'm working on a ship naming OXP myself.

And I wonder how/when the ship class is added into the displayed name string mix then...
I fixed it for now by making bounty informer use displayName; its code obviously is called afterwards as it's using shipTargetAcquired and it tries to concatenate to any already existing name. And Randomshipnames's code is way too complicated to grasp for me in some minutes, but making it use shipUniqueName feels like the cleaner solution.

Randomshipname is quite simple in this respect: It checks displayName for ":" (and some other characters) to see if the ship has a name already. If yes, this ship will simply be ignored, if no, a name will be appended to displayName.

I don't know Bounty informer but I assume it is writing the bounty into shipUniqueName. So, depending on the execution order, which can be seen as undefined (we had a discussion in "Scripters cove" some days ago), Randomshipnames would have to recognize the bounty part (I assume, a number in brackets or something similar) and Bounty informer would have to check for a ship name and append the bounty information to it.

I had a look at it now. Being only here for some months I have a bad feeling saying this, but I don't think that giving a ship a name like "Bounty 30 Cr" is a good idea at all, even if the conflict displayName vs. shipUniqueName is solved somehow. It doesn't only collide with naming OXPs, it will also be given by Comms Pack A as the ships name. The bounty part should go into the part of the display with the legal status, e.g. "Fugitive, Bounty 98 Cr", but I don't know if this would be possible.

I've played around a bit, and here are the facts:

- execution order is not an issue because bounty informer is doing its "naming" during targeting and not during ship spawning
- because of this order, randomshipnames never has to deal with existing bounty information
- on spawning, displayName is set automatically if shipUniqueName is set (by a modernized randomshipnames or any other naming OXP)
- a later change of shipUniqueName won't change displayName automatically again (!), and that's why bounty informer doesn't work with randomshipnames

To fix it, bounty informer must modify displayName and not shipUniqueName (IMO the latter shoudn't be used for additional information anyway). If this is changed, it is irrelevant if randomshipname changes shipUniqueName or displayName, so a modification of randomshipnames isn't necessary in this case (but certainly wouldn't be wrong).

The second problem remains: The bounty information is considered as part of the Ship name by Comms Pack A, so bounty informer shouldn't change displayName at all but modify the legal information.

Fritz wrote:

So referring an unknown property will simply be ignored? I'm asking because I'm working on a ship naming OXP myself.

Wasn't 1.79 the version that introduced both, the oxz file type and shipUniqueName property? If my memory serves me right and it was so, then you should not have that problem with an oxz. If you want to build something (an oxp) that's compatible with previous versions, then you need to check, but for an oxz, the check shouldn't be needed.

Randomshipnames does contain code that checks for earlier versions, but perhaps it was an OXP and not an OXZ at the time, and the code has somehow survived.