Oolite Bulletins

Anything that I can do to help with the Stranger's World issues?

As mentioned above there is the "unidentified" issue which plagues the F4 interface (& the sun too, when viewed on the MFD). But here is a new variation on the theme which just recently surfaced:

Riredi (Stranger's World)


Rejoice! You have answered the clamorous requests for Binary Sytems in duplicate! (or should that be quadruplicate?). I can't see the other three - is that because they are antimatter or black holes or something? Or is something wonky with my monocle? I swear that my nose has not moved one iota! Or is it some sort of terrifying Thargoid tactical invasion force masquerading in mufti?

I await your next variation on the theme with trepidation, timorosity and just a tiny tinge of terror!

...Araminta is just gobsmacked by the entire shebang. She's booked an eyetest with the dynastic optician for the instant we get back home. She's never taken to the lorgnette before, but is convinced that she now has no choice...

EDITED as found the cause of the bug wasn't what I first thought!

EDIT 2 : This Bug is fixed by Cag's Version 2.0 of Telescope.

I’ve been mainly focusing on optimising the MFD code and adding the ships to the database (just 10 more to check now). However, I have found the problem with Planet and Star name appearing wrongly. It isn’t a bug as such, but the problem is with Telescope OXZ. It has always been possible to add displayName to planets, moons and gas giants, however the Almanac is the first OXZ to actually use this function. At the time Telescope was written, no OXZ named planets or moons, so perfectly sensibly Telescope names all planets moons and gas giants by System Name and Number and you actually target an invisible 'ship' rather than the planet itself. If it didn't then without the Almanac installed all planets moons, stars and gas giants would appear as "Undefined" when targeted by Telescope. The Galactic Almanac has only renamed the planet, NOT the invisible ship added by Telescope to enable you to target the planet.

The problem isn’t with Strangers Worlds, as the same issue arises with System Redux.

The three stars issue I think is because another OXZ really has added two invisible suns to the system. The Almanac only expects one sun to be present so gives the Sun name to all three objects as the Almanac will add the local stars name to any object which has the isSun flag set to true . I’ll add that to the Exclude list for V1.5. Although I do a count for every other object (so each station and planet in each system is given a different name) I hadn't reckoned on someone adding another object as the with a isSun flag. I think Oolite won't allow more than one sun to actually appear in the system, so you are only seeing one sun, but the Almanac is labelling the the other two objects with isSun up as Suns. They seem to be real objects in the game as telescope is giving you a distance reading on them. But Oolite isn;t allowing them to appear as its a one sun hard limit per system. I'll add a counter for suns and if a second or third invisible object is present it'll classify it as a black hole.

Screen shots below show the Almanac running with System Redux and Telescope installed.

Planets and Moons correctly named on the F4 Screen:


Stations correctly named on the F4 Screen:


Ships, Stations and other objects which are not planets, moons or stars correctly named in flight as these objects have displayNames and so Telescope is using their actual display names (which have been changed by Random Ship Names and the Almanac). So no problem with Stations or Ships. As Telescope is showing the actual displayName of the object you target when you target a ship or station, it reads the changes made by Random Ship Names and the Almanac respectively to Ship and Station names as both Naming OXZs change an objects displayName:-



Screenshot showing the problem. Telescope handles planets differently to ships and stations and doesn't show their displayName when targetd by Telescope (whereas the native ASC does). The Almanac MFD is showing the name given by the Almanac as is the ASC, as these both read the objects displayName.. But when Targeted by Telescope the planet shows as Cettiti II. I need to look through Telescope's code, but it is not normally possible to target a planet. I suspect what it is doing is spawning an invisible ship at the planet's surface (this is how planetfall works) and it is that object rather than the planet as such that you are actually targeting. The Almanac has only renamed the planet NOT the ship added by Telescope. The ASC and the Almanac MFD are both showing the planet's displayName - so they both show the change made by the Almanac, but as I haven't changed the name of the 'fake' ship you are actually targeting when you target the planet Telescope still shows the name as Cetti II as I havent changed the name of that object. It (famous last words) should just be a case of checking though Telescope's code to find the role for the object and then adding one line to change this object's name at the same time that the planet's display name is changed. If you have a look at the distances in the screenshot below you can see what Telescope is up to. The Distance to the Target shown as the planet by Telescope is 60kms closer than the planet is. I think this is because Telescope is floating a NO_DRAW class object just above the planet to allow you to target it.

Telescope also allows objects to be targeted at distances much greater than 25km. The Almanac doesn't expect this so if you target an planet with the ASC it shows the composition correctly. But if you target a station or ship which is further away than 25km, the distance is not shown, nor is the designer until you come within 25km. Also to fix in 1.5.

The ASC and the Almanac both show the correct name for the planet, but it still appears under its old name when targeted with Telescope. On my to Fix list!




EDIT. Version 2.0 of Telescope fixes this issue:

Screenshot shows the same system and planet running with Telescope V2.0
:

HIMSN: we want the HIMSN stations not to show up on the Galactic Almanac in the station or on the MFD until one is "on top of them" and can see them visibly.

LittleBear: Is there some sort of code that we can include in the HIMSN.oxp which will achieve this?

Beta 1.5 (finishing off at the moment) will make telescope and the MFD computable as the MFD will now read the target markers added by telescope.

As far as the Almanac is concerned, the MFD will only show objects transmitting a beacon readable with an ASC. So if you haven't added a beacon to your station then it won't be listed by the MFD. You would have to come within 25 km of the Station and target lock it for the MFD to read it. So you don't need to add any code to make the station not appear. Its only if you wave your beacon flag that either the naïve ASC or the MFD can see you without a target lock from the ID Computer.

Unless your station has a beacon it will not be listed on the F4 Screen either. The rational is that if your station has a beacon then you can be detected by anybody with a 650 Credit ASC, so GalCop would know about stations which are actively transmitting a beacon. Despite budget cuts, the Records Department can afford an ASC. But unless you have given your ship or Station a beacon in shipdata, GalCop won't know about it. It won't appear on the F4 Screen and can't be targeted by the MFD until you come within 25kms and target lock it. The MFD will give the name of the station and its distance but will report that No Data is Available as the designer.

The Galactic Almanac doesn't automatically give any information about any object in the game unless it is either a moon, planet, gas giant or star. For ships and stations only objects which have a beacon and so appear on the ASC anyway are shown by the Almanac.

LittleBear wrote: ↑Mon Dec 13, 2021 2:12 pm

It has always been possible to add displayName ...

As you're doing more than just planet & moons, be aware that some oxps use the beaconLabel and/or beaconCode without altering displayName. VimanaHUD checks in order: .beaconLabel, .displayName, .name, .beaconCode, while I've been toying with using the longest name (telescope 2 has a name shortening algorithm so the MFD doesn't use really slim characters).

LittleBear wrote: ↑Mon Dec 13, 2021 2:12 pm

But Oolite isn;t allowing them to appear as its a one sun hard limit per system. I'll add a counter for suns and if a second or third invisible object is present it'll classify it as a black hole.

or a brown dwarf (too dim to see) or a neutron star: no accretion disk or rotation axis at angle (ie. no x-rays) or old & cold (too small to see)

LittleBear wrote: ↑Mon Dec 13, 2021 2:12 pm

I suspect what it is doing is spawning an invisible ship at the planet's surface (this is how planetfall works) and it is that object rather than the planet as such that you are actually targeting.

Actually, it's an invisible ship close to the edge of scanner range. The core only allows targeting within scanner range.

LittleBear wrote: ↑Mon Dec 13, 2021 2:12 pm

The Distance to the Target shown as the planet by Telescope is 60kms closer than the planet is. I think this is because Telescope is floating a NO_DRAW class object just above the planet to allow you to target it.

No, I've been subtracting the collisionRadius (as does 1.15) from distances to reflect the distance to the surface/hull. I thought of not subtracting for gravity scanner targets but that would just be confusing. I will stop doing that with orbs (sun(s), planets & moons) so the numbers will match. There was a reason it's done it for ships but my memory fails me.

I'd had a poke through Telescope's code and saw that when you appear to be targeting an object more than 25 Kms away you are actually targeting a ship called "Telescope Marker" - Cunning!. I think this is why some objects were appearing as undefined as the MFD was reporting information on the Telescope Marker ship that you are actually targeting rather than the entity it is 'spoofing'. I've done a workaround for that by checking that if the target.name is Telescope Marker, then the distance calculating code goes off to find the entity in the system with the same display name and reports information on the real entity rather than the Telescope Marker Ship. I've tested B1.5 a lot with Telescope and I think its now playing nicely with it.

Also added in Beta 1.5 are:-

* Supports the Star Classifications used by Distant Stars as well as Distant Suns.
* Fixes a bug where with Strangers World installed a KOS station is named twice if it replaces the main station (noticed watching Arquebus'. Videos).
* Compatible with Telescope V2.0.
* MFD fully implemented with 738 known ships and stations.
* Naming code under this.Ship Spawned better optimised.
* Optimises the MFD Identification code.
* Adds more custom named Systems (610).
* Adds three more News Broadcasts.

The coding is done and I'm given it a final playtest, so I'll release Beta 1.5 in a couple of days.

To accommodate different OXZs using different ways of naming things the code does a check with:-
That (should) really find any objects name. Watching Arquebus playing with Strangers World Installed he doesn't seem to have hit the bug with planets appearing as undefined, but Cholmondely has it it. Beta 1.5 will be better compatible with Strangers World, but I still need to track down the names of some objects in the Strangers World code that are coming up as Undefined as the code isn't finding their name. For Version 1.6 I'll be playing with Strangers World installed. Beta 1.5 should be a big improvement though.

Screen Shots show the MFD running with Beta 1.5. When Telescope Markers are targeted the MFD now switches its target to the thing the Marker is Marking, so you get the correct distance and information reading.

Telescope Moon Marker Targeted.



Telescope Station Marker Targeted.

Update, Beta 1.5 will be compatible with Strangers World as well as Telescope, System Redux and Orbits.

I have found the problem. It is that Strangers World is using the old method of adding planets and moons in batches when the player launches and exits hyperspace rather than using the modern method of this.system.will.populate. This is probably why it is incompatible with System Redux, Orbits and Distant Suns. This is a shame really as System Redux, Orbits and Distant Suns all play nicely together and distant suns really adds a lot to the game into terms of more realist solar systems. Its a case of to each his own and I want to make the Almanac support all possible planet adding OXZs. I don't think there is any reason in principle why Planetary Systems could not be made compatible and the better solution might be to update the Planetary Systems and Moons scripts to the modern method.

Anyway I have a work around, which doesn't involve me having to do any monkey patching. I do get a massive slow down on launching though with Planetary Systems that I don't get with System Redux (to be fair for testing I am playing both OXZ with every single texture loaded and the moon and planet adding options cracked up to the max). But because Planetary Systems is doing all its donkey work of loading textures and moving moons and planets about when the player launches, this causes a slow down. Once Planetary Systems has sorted itself out then the game runs normally, but as a suggested update to Planetary Systems its would be an ideal to make it compatible with the other solar system changing OXZ if Planetary Systems ran its moon and planet populators together under this system,will,populate. This would solve the oddity of planets coming into existance and being moved around on first launch. Also, I suspect a lot of players who like the realism of Strangers World would also like distant suns / stars and system redux. Would be cool to have all of them running together for more variety in textures and solar systems.

Problem and my Fix

The reason that Cholmondely was getting the undefined error is that the Almanac was correctly reporting that those planets don't exist yet and so they are undefined as Strangers World hadn't added them when the system populated. The Screenshots show a new Jameson starting at Tionisla running Planetary Systems.

So on Beta 1.4.1 all the planets appeared as undefined (cos they were!).


The fix I've added is to pause the planet scanning code if we hit an undefined object and run it again once Planetary Systems has finished adding its planets and moons. This works and all the Planets added by Strangers World at this point get names. So far so good:-



And if we launch, the MFD also shows 7 Worlds.



But whilst we were launching Strangers World has created another 10 Planets which didn't previously exist. So if we dock and check the F4 Screen, there are now 17 worlds in Tionisla. The Almanac has named those extra worlds, but as you can see some of the names have repeated. This is because although I have 20,000+ names for planets and moons the OXZ works by counting along each pool. I wasn't expected to be naming planets in two batches so the counter started at 1 again. That is a fairly easy fix and doesn't need me to monkey patch Planetary Systems as I now I know that extra planets can pop in to existence on launching I can just do a test for the stranger's world scripts and if they are installed save the position from the first naming batch and run it again on launching, picking up where we left off.

Screen shots showing that after launching 10 new Worlds have appeared. The Almanac has detected and named them (but with the - to fix - issue of the counter starting from 1 for the second batch when we want it to continue counting from the first batch.

As you can also see the, planets and moons have also changed position. This is because Planetary Systems does it's adding and moving objects around on Launching. So the Almanac is correctly reporting the names and positions of the objects as they existed before Strangers World moved them around when we loaded and then when we docked it is showing them after Stranger's World has repositioned them. This would be another good reason to run the script under this.system.will.populate as that we also solve this oddity. This isn't a bug in the Almanac, its just how Planetary Systems works and the Almanac Code is designed to show you exactly how the system is each time you run it.




On Launching again the MFD is also finding those 10 extra worlds and is now showing 17 worlds in Tionisha.




So, to sum it up. Beta 1.5 will work properly with Strangers World. But when you load from a save game you will have the oddity of some planets appearing after you launch. They will all then remain consistent for the rest of your play session. If anyone is maintaining Planetary Systems though it would be better if it was updated to use the populator method as this isn't something I can change without having to monkey patch Planetary Systems.

I'll get a Beta 1.5 up after Christmas .

Great detective work! And I could even understand what you said (shock! horror!).

Quick question: Any idea why Strangers World bungs SLAPU'ss & CZGF's so far away from the sun? Is it to do with these extra suns?

Edited to add: just bumped into this in the Habitable Planets Description

The distance between the witchpoint and the main planet in the vanilla game is a pseudo-random value in the range 10...14 times the main planet radius. Since Oolite 1.82 this distance has been defined as an absolute value – parameter planet_distance. Therefore increasing Lave's vanilla radius from 4116 km to 5821 km (for example) will only slightly affect the distance from the witchpoint to the main orbital station - and the corresponding travel time. The main orbital station is always positioned at a distance from the main planet surface equal to the main planet radius: so some OXPs using absolute coordinates for positioning additional objects will not function as intended after installing Habitable Main Planets (''eg'' the Tionisla cemetery).

Awesome work, LB - so thorough!

Pretty much there now with making Beta 1.5 fully support Strangers World. Screen Shots below show the OXZ running on Strangers World.

1) Detects if the Stranger's World Planetary Systems OXZ is installed and gives an Almanac Unavailable Screen until Stranger's World has set up the system. Workaround for the fact that Stranger's World uses the old system population method. When you first load, the system generated by Stranger's World is Schrodinger's Universe. Until you observe it by launching it doesn't exist so attempts by the Almanac to name it will go horribly wrong! The Almanac code now pauses until Stranger's world has set up the system to avoid undefined object errors:




2) Detects and uses the Star and Planet Classifications used by Strangers World and names planets and moons added by Stranger's World. As moons orbit planets with Stranger's World installed moons of planets inherit the orbital position number of their parent planet.



3) Star Categories used by Strangers World detected and added to the F7 Screen.



4) Detects and names the Stranger's World Orbitals. Naming schemes are also themed to planet descriptions. Here, the inhabitant's fondness for cricket is reflected in some of the station names and the purposes they use habitats for.




5) MFD Identification Code completed and compatible with objects added by Stranger's World.

Beta 1.5 is now available.

Documentation and downloadlink on the Wiki Page (on my signature).

I'll update the first page.

Edit:-

Download link is now on the Wiki Page (link to Wiki Page on my Signature) and in the 1st Post.

Thankee!

I'm running pretty basic trunk, with no extra planets, moons etc, and the only extra stations are Torus stations, but GA seems to throw these errors:

14:11:31.592 [shipData.load.error]: ***** ERROR: the shipdata.plist entry "cb68_sodalite_station-riredi-coluber_no_beacon_version" has unresolved subentity cb68_sodalite_station-dock-riredi-coluber.
14:11:31.592 [shipData.load.error]: ***** ERROR: the shipdata.plist entry "pagroove_superhub_station_mainhull_no_beacon_version" has unresolved subentities pagroove_superhub_dock, pagroove_superhub_station_ring1, pagroove_superhub_station_ring2.

Edit to add: I am running HIMSN, but I thought HIMSN used Kiota stations?


I see you're using Orthodox Units for OU, but I thought OU were Ostronomical Units?

The errors it is throwing are harmless (but are a fault with my code). Basically, both of these stations have beacons but can replace the main station and be called as an extra station orbiting an extra planet by Extra Stations for Extra Planets. As native Oolite automatically adds a beacon to the Main Station and Extra Stations for Extra planets automatically adds a beacon to any stations it summons, these stations can end up with two beacons if they are called as a replacement for the Main Station or by Extra Stations for Extra Planets. The tweaked version in the Almanac's Ship Data File is just used to get round this by substituting a clone of the station but without a beacon when it replaces the main station or is summoned by Extra Strations for Extra Planets to avoid the station appearing twice on the ASC. As you don't have the Station installed, Oolite is complaining that the ship data doesn't match a station. Since these stations won't appear in your game, I don't think it will cause any difficulties but I should fix it for the next version.

The Almanac will give data on the designers of the ships from HMSN (although some will appear as classified), but I haven't yet added a naming scheme for the stations it adds (will add in the next version). The Almanac deliberately reads station roles rather than just the graphics of the station in order to give names which suit the style of the station and the purposes it is being used for. The Kioto stations are civilian in nature and normally appear as farms, factories, transmitters, scientific research bases, habitats and so on in Thargoids original version. So the name styles I've assigned to Thargoid's original Kioto stations wouldn't really suit a military version of the station. They also appear in Stranger's World and are named from a different civilian style pool when they appear as KOS Orbitals. I could add a naming scheme along the lines of "GSS Daring", "HMS Audacity" etc for the next version.

Screen Shot shows the Kioto Habitat, Research and the KOS Versions. The six versions of the Kioto that can appear are named from different pools, but I haven't added a pool for the HMSN version yet. Whilst "McMillan's Poet Farm" would be appropriate for a Kioto Biosphere appearing in a system known for edible poets, you wouldn't really want a military base to be called this.