OXPConfig in it's current state couldn't support that, but I know Svengali was working on expanding things towards that direction. If that comes to pass I've no issue at all to make that link.
In any case next time I update the script I'll make the colours used a pair of variables, so you will only need to manually adjust them once in the script to make changes. Plus I'll include instructions in the readme on how to do that.
OXPConfig in it's current state couldn't support that, but I know Svengali was working on expanding things towards that direction. If that comes to pass I've no issue at all to make that link.
Yes, the fabled OXPConfig2. Now with integers!
Bear with me for a second while I air a wild and crazy idea I had back in 2008 when I first found oolite, and which I still have not yet totally abandoned: An external OXP manager app. Like, it could let you have OXP "sets", with different ones activated for different commanders, or galaxies or whatever. (Yes, I realize that not everybody plays more than one commander. Some do.) It could easily install or de-install any given OXP. It could tell you things like which ships an OXP provides. And it could, in the ideal case, let you configure various behaviors of OXPs that had them. One of the things that kept me from starting such a thing back then, and is still stopping me, is how to make something that's portable across all three of oolite's platforms. But as I said, I still haven't totally abandoned the idea.
Thargoid wrote:
In any case next time I update the script I'll make the colours used a pair of variables, so you will only need to manually adjust them once in the script to make changes. Plus I'll include instructions in the readme on how to do that.
That'll help. I react violently when I have to duplicate non-trivial values in my code.
Thargoid wrote:
Anyway glad you're liking the functionality there
I certainly am, and thank you very much for writing so many great OXPs.
As I've said before a third party app or even a Oolite internal thing would be a lot better and could do it a lot better, because there are a few limits a oxp solution has to live with (and this is good).
But it's future music - my machine had some problems and I've 'lost' nearly two month with reading tech docs and hardware specifications, trying tools, etc. without touching a single line of code, didn't knew anything about these things before. I was only wondering about strange FPS drops and peaks in CPU usage, D-Cache latency, I/O accesses, clock timings, etc. causing stuttering (=unplayable) in Oolite. Funny, eh? The good news is that some tiny tweaks to voltages and some changes in the gfx driver plus some registry tweaks have changed the situation, but some performance and stability tests still have to be done. This has priority.
Oh, and the festival season has started, so don't hold your breath... .-)
I had used TAP in the past, but removed it because it seemed to take to long to act, and i often had a target set already.
Recently i switched to a Dragon M (3 turrets) , and felt TAP might help making the turrets more effective.
I have however encountered the autolocking on my own ship many times, and it kept coming back even if i used U.
Once i was some distance away from the last fight area, this stopped.
Maybe i was flying through plasma clouds from my own turrets, and thus was 'attacked' by myself ?
If it helps, I've been running r4356 (first with TAP 1.10, then with TAP 1.12), on and off most of today, and had no problems or log errors with either.
I would advise stilts for the quagmires, and camels for the snowy hills
And any survivors, their debts I will certainly pay. There's always a way!
While TAP+ is useful, at times it can be so annoying that i remove it (and re-add later).
The main problem i have with it is when i am fighting several ships at once, and the first one that attacks is not the target i want to focus on at that time.
To get the target i want, i often have to use the u-key repeatedly.
Since there are already many oxps that use Shift+n/n , maybe the u-key can be used as a switch to enable/disable TAP+ ?
-----------------------
In a previous post you mentioned it was your intention to make the scanner colors configurable through OxpConfig once this was possible.
I think it is now possible, do you still intend to change this ?
Indeed it would, but unfortunately not possible (aside from the n/shift-n as already noted, too overcrowded). Simpler is probably just to leave the lock in place until you get your sights on the target you actually want, and only then press u followed by t or r.
If the player ship already has a target then TAP+ won't do anything.
In a previous post you mentioned it was your intention to make the scanner colors configurable through OxpConfig once this was possible.
I think it is now possible, do you still intend to change this ?
I think it's not really easy to achieve this with the current version of OXPConfig, specially if you want to do this for more than a few colors. I could add some functionality to OXPConfig to adjust let's say 20 settings for scanner colors which are stored in an array (and maybe additional as mV). OXPs could pick up this array (or the mV) and users can adjust the colors if they want through the GUI in OXPConfig. This way different OXPs could use the same color schemes.
The script is configured so that you only need to change a couple of variables to change the colours (there are two variables, one for each colour). That's as close as I could come to this kind of configurability - as Svengali says doing it in any other more graphical way gets complex.
The script is configured so that you only need to change a couple of variables to change the colours (there are two variables, one for each colour). That's as close as I could come to this kind of configurability - as Svengali says doing it in any other more graphical way gets complex.
Check latest OxpConfig version, svengali implemented a mechanism for color choosing.
The script is configured so that you only need to change a couple of variables to change the colours (there are two variables, one for each colour). That's as close as I could come to this kind of configurability - as Svengali says doing it in any other more graphical way gets complex.
Check latest OxpConfig version, svengali implemented a mechanism for color choosing.
Capt. Murphy just reminded me that it's a trunk only version as it uses a HUD to display additional infos (uses equipment_required in legends) on different screens... so v2.0.8 is online too.
