I don't know what's going on.

On my Mac install, I can't update to the 2.0.1 telescope without messing up the extender OXP, but on my Windows install, apparently I updated already, and it was fine. I'm just not going to worry about it!
Moderators: winston, another_commander
With any luck, the newer ones should trump the older when you start up a new game.arquebus wrote: ↑Wed Dec 01, 2021 11:12 pmOk so I have a feeling I'm not actually running the Telescope from the dropbox link. I think my settings are still showing up as mass lock BORDERS instead of RING when I switch through the options.
So here's my question: the dropbox OXPs have different names from the ones downloaded from the installer. Should I just remove the installer ones and put in the dropbox ones, without changing any names, or will I break my existing telescope if I don't rename the OXPs to match what was there before?
Wait, isn't that backwards? I thought Managed AddOns was the Expansions Manager directory, and AddOns is the manual install one. Anything I put in AddOns doesn't show up in the manager list.Cholmondely wrote: ↑Wed Dec 01, 2021 11:47 pmWhere things are also matters. There is the Managed AddOns folder and the AddOns folder. AddOns trumps Managed AddOns, apparently, But oxp's only get "picked up: in AddOns, whilst oxz's downloaded through the in-game Expansions Managed get bunged in the Managed AddOns (but work fine in AddOns).
The core-game loads the Managed AddOns first, therefore an OXP in the AddOns will overwrite the managed packages. To make everything a bit more exciting, under windows there is an additionally alphabetical sort. A zz.oxp would overwrite an aa.OXP.arquebus wrote: ↑Thu Dec 02, 2021 12:17 amWait, isn't that backwards? I thought Managed AddOns was the Expansions Manager directory, and AddOns is the manual install one. Anything I put in AddOns doesn't show up in the manager list.
I put all of my OXPs in Managed, but I should probably separate them out. It seems like all the downloaded ones start with "oolite.oxp" so in theory it should be straightforward to find the non-managed ones and move them over to AddOns.
You must be using the in-flight config utility. Turns out that it treats MassLockRings as a toggle, not the flags in the station options
Related to the above, I forgot to change the word 'borders' to 'rings' in the mode/activate functions. Now all the 'borders' should be gone.
This oxp is still in Beta so it's not (yet) ready for the installer (expansion manager) and is incompatible with those in the installer.arquebus wrote: ↑Wed Dec 01, 2021 11:12 pmSo here's my question: the dropbox OXPs have different names from the ones downloaded from the installer. Should I just remove the installer ones and put in the dropbox ones, without changing any names, or will I break my existing telescope if I don't rename the OXPs to match what was there before?
The extender is part of Telescope but separate as it modifies the game play (some would say it's a cheat). They are quite intertwined, so version 2 of the extender goes with version 2 of the telescope (I made more manifest changes).
arquebus wrote: ↑Thu Dec 02, 2021 12:17 amWait, isn't that backwards? I thought Managed AddOns was the Expansions Manager directory, and AddOns is the manual install one. Anything I put in AddOns doesn't show up in the manager list.Cholmondely wrote: ↑Wed Dec 01, 2021 11:47 pmWhere things are also matters. There is the Managed AddOns folder and the AddOns folder. AddOns trumps Managed AddOns, apparently, But oxp's only get "picked up: in AddOns, whilst oxz's downloaded through the in-game Expansions Managed get bunged in the Managed AddOns (but work fine in AddOns).
I put all of my OXPs in Managed, but I should probably separate them out. It seems like all the downloaded ones start with "oolite.oxp" so in theory it should be straightforward to find the non-managed ones and move them over to AddOns.
I try not to mix because I never get it right. I'm on Windows and Managed AddOns loads first but won't load the AddOns ones.
Code: Select all
[oxp.conflict]: OXP Norby.cag.Telescope.oxz conflicts with
oolite.oxp.Norby.Telescope.ver.1.15.oxz and
was removed from the loading list
Code: Select all
[oxp.duplicate]: OXP ../AddOns/HUDSelector-1.18.oxp has the
same identifier (oolite.oxp.Norby.HUDSelector) as
D:\testrelease/oolite.app/GNUstep/Library/ApplicationSupport/Oolite
/ManagedAddOns/HUDSelector-1.18.oxz which has already been loaded.
Thanks! I'll get those slotted in.
Turns out, this new version appears to break the masslock rings entirely. I can configure them in the in-flight utility to be on (Lightballs: bright masslock rings), but they do not appear, whether or not I have my weapons on, and regardless of the status of my torus drive (active or inactive).
In the version you use in your AddOns please try to remove the manifest and change the OXZ to an OXP. While not all of my overrides work as intended, at least most of them do after some workarounds.
This was a tricky one. The in-flight configuration treats masslock as a toggle, while in Station Options, it's a group of flags. Telescope 1.15 had hard coded green alert or weapons off-line as criteria. My previous attempt was to preserved your Station Options setting across the toggling you get in thearquebus wrote: ↑Tue Dec 07, 2021 3:38 amTurns out, this new version appears to break the masslock rings entirely. I can configure them in the in-flight utility to be on (Lightballs: bright masslock rings), but they do not appear, whether or not I have my weapons on, and regardless of the status of my torus drive (active or inactive).
"off", "navigation only", "ships", "masslock rings", "bright masslock rings", "large"
sequence. This does make a lot of sense. When I switch the rings around in a given state (green, yellow, red; plus weapon status), I'm doing so because the settings for that current state aren't what I want. I don't necessarily want to override any other state, and since I'm doing it "now" then the most obvious state to change is the one that's happening "now." I think any other method (that doesn't involve completely revamping the in-flight options) would be less intuitive.cag wrote: ↑Fri Dec 10, 2021 5:50 amThe fix in the latest release is to fold your current state into the Station Options flags.
Eg. you set MassLockRings in staton to be green alert, weapons on or off and launch. Since you in a station's aegis, you're in yellow with weapons on-line, if you use the in-flight config to turn on the rings, that's what will appear when next you dock and look at the MassLockRings setting (green, weapons on or off and yellow, weapons online). The same thing will happen if you turn off masslock rings; your current state of alertCondition and weaponsOnline will have its flag reset.
done.arquebus wrote: ↑Fri Dec 10, 2021 6:28 amI do think that separating lightballs from rings would be a good idea, and having the rings setting in in-flight be listed as something like "Rings in current context:" so that it's clear you're only modifying the current position in the matrix of condition & weapon status.
I think I've got a fixCholmondely wrote: ↑Wed Dec 01, 2021 10:20 am...
Edited to add: the only really important issue that I have (and have had) with any of the versions of Telescope is "death by ILS". The other problems I find rather minor. As mentioned elsewhere, in my early days, I died 5 times by ILS/Telescope whilst being murdered only twice by pirates!
...
ILS
is set to the player's ship, all automatic targetting is suspended. If you disengage ILS
, it resumes as normal. I usually land manually, so am not that familiar with ILS. Those of you who've become tri-dimensionally challenged in the past would be better able to judge, so please give it a try and let me know.I'm not sure what you're asking here. Telescope operates quite differently depending on whether weapons are online (Cholmondely wrote: ↑Wed Dec 01, 2021 10:20 am...
iii) I don't understand how the fast activation system works, but is it possible to have the spotting of other "targets" disabled by a fast activation button? Or disabled when ILS is operating? The first suits me better, but ...
AutoLock
) or off-line (GravLock
). Either can be altered to any value that suits (0 (off) to 180 degrees (full sphere). Are you looking for a temporary suspension, based on time or context (alertCondition/weapon state)? Or a manual toggle to flip at your discretion? This last is problematic until we get more buttons, as Telescope already has RemoveInFlight
option.