For information and discussion about Oolite.
https://bb.oolite.space/
To avoid the tedium of rewriting all player.consoleMessages, if you have a script.js file inside AddOns/Config/ you could have something like this:manually for each and every message of every OXP
Code: Select all
this.startUp = function()
{
player.consoleMessage = player.commsMessage;
}
Kaks wrote:To avoid the tedium of rewriting all player.consoleMessages, if you have a script.js file inside AddOns/Config/ you could have something like this:
Thanks to javascript's function overriding feature, any further calls to consoleMessage() will be redirected to commsMessage()...Code: Select all
this.startUp = function() { player.consoleMessage = player.commsMessage; }
This is AWESOME, Kaks !!!
When you also want the messages to go to the normal log file, you can addsdrubble wrote:Great info... won't spare me the dozens of replacements already done, but I will certainly implement this as soon as possible so as to never worry again about missed msgs. OTOH, comms will become quite busier from now on... well, nothing is perfect.
Cheers and take care
Code: Select all
this.commsMessageReceived = function(message, sender)
{
log("Player", player.ship.displayName+" received message: "+ message + " from ship: " + sender.displayName);
}
That's really great Eric !Eric Walch wrote:[ . . . ] That way you can read back all messages ever received during the game from your log file. Sometimes useful during a mission when there were a lot of messages during the last combat and you want to be sure you didn't miss one.
) these days.
I think my addition will only log the real commsMessages. I sort of thought that a combination would also log the consoleMessages, but that was bad thinking of course.sdrubble wrote:EDIT: while Kaks' tweak works neatly, Eric's one (done on the same file) does not seem to (in some limited testing I'm doing while endlessly tweaking a HUD). I will research this a bit further when I'm done with this damn GUI tweaking.
Eric Walch wrote:I think my addition will only log the real commsMessages. I sort of thought that a combination would also log the consoleMessages, but that was bad thinking of course.sdrubble wrote:EDIT: while Kaks' tweak works neatly, Eric's one (done on the same file) does not seem to (in some limited testing I'm doing while endlessly tweaking a HUD). I will research this a bit further when I'm done with this damn GUI tweaking.
] until I'm done with the endless-recursive-repetitive-and-slow HUD tweaks I'm currently hooked on (which *MIGHT* deserve their own forum thread depending on which percentage of me is still alive in the end). 
[color=#0000FF]'comm_log_gui'[/color]and [color=#0000FF]'message_gui'[/color]. ]. 
), I feel I could start at once posting some comments about some Wiki entries. 
2 -while[b]x_origin[/b]and[b]y_origin[/b]seem to be the correct labels, there are additional mentions to[b]x_origine[/b]and[b]y_origine[/b](typos ?) which can be a bit misleading.
y_origin conflicting statementsCode: Select all
one of these is probably wrong:
y_origin = -1.0 means that y is relative to the screen bottom.
y_origin[e] = -1.0 means that the y co-ordinate is interpreted relative to the top of the screen. background_rgba undocumented placement (see Eric Walch's comment, 2 posts below, with possible reasons for the omission)4 -while[b]background_rgba[/b]is given as a coding element for'comm_log_gui'only, I found thru experimentation that it also works under'message_gui'(but it's not mentioned there).
[s]background_rgba[/s] 5 -one of my tweaks revealed that, after commenting out the'background_rgba'entry that came with the Chupacabra HUD under'comm_log_gui', the end result became visually much more pleasing - it seems that the default values for'background_rgba'came into play. However I couldn't find WHICH are such default values - if these would be published, a lot of future trial and error interactions could be skipped when trying to tweak these values.
background_rgba color tips6 - and, finally, voilá - The Black Art of GUI Positioning:there are a number of resources, both inside and outside the Wiki, that might help an average Joe to experiment with'background_rgba'cryptic values with an actual sense of purpose instead of doing it in an erratic manner. My personal list of references which might possibly be added just below the command would include:
http://wiki.alioth.net/index.php/Materi ... ed_colours
http://wiki.alioth.net/index.php/Materi ... GBA_tuples
http://wiki.alioth.net/index.php/Materi ... ctionaries
http://en.wikipedia.org/wiki/HSB_colour_space#Swatches (mouse over !!!)
'comm_log_gui' or 'message_gui' in the positions we want, we have to fiddle with no less than SIX parameters: Code: Select all
x & y
x_origin & y_origin
width & height'background_rgba' the SEVENTH 'magic' parameter, which will allow one to actually SEE the originally invisible borders of 'message_gui'. It can be commented out again AFTER the final gui location is determined, in order to achieve the original transparent effect.Code: Select all
when 'x_origin = -1' (meaning that "the horizontal reference point is the LEFT side border of the screen"):
the 'x' (positive) value determines the HORIZONTAL OFFSET between the LEFT side border of the screen and the RIGHT side border of the GUI;
a negative 'x' value is INCORRECT (placing the RIGHT side border of the GUI off the screen, further to the left of the LEFT side border of the screen).
the 'width' (positive) value determines the HORIZONTAL OFFSET between the RIGHT side border of the GUI and the LEFT side border of the GUI.Code: Select all
when 'x_origin = 1' (meaning that "the horizontal reference point is the RIGHT side border of the screen"):
the 'x' (positive) value determines the HORIZONTAL OFFSET between the RIGHT side border of the screen and the LEFT side border of the GUI;
a negative 'x' value is INCORRECT (placing the LEFT side border of the GUI off the screen, further to the right of the RIGHT side border of the screen).
the 'width' (positive) value determines the HORIZONTAL OFFSET between the LEFT side border of the GUI and the RIGHT side border of the GUI.Code: Select all
when 'x_origin = 0' (or when the parameter is ABSENT) (meaning that "the horizontal reference point is the horizontal CENTER of the screen"):
the 'x' value determines the HORIZONTAL OFFSET between the horizontal CENTER of the screen and the OUTWARD lateral border of the GUI, as follows:
an increasingly POSITIVE 'x' value shifts the OUTWARD lateral border of the GUI further to the RIGHT of the horizontal CENTER of the screen;
an increasingly NEGATIVE 'x' value shifts the OUTWARD lateral border of the GUI further to the LEFT of the horizontal CENTER of the screen;
the 'width' (positive) value determines the HORIZONTAL OFFSET between the OUTWARD lateral border of the GUI and the INWARD lateral border of the GUI.Code: Select all
when 'y_origin = -1' (meaning that "the vertical reference point is the BOTTOM border of the screen"):
the 'y' (positive) value determines the VERTICAL OFFSET between the BOTTOM border of the screen and the TOP border of the GUI;
a negative 'y' value is INCORRECT (placing the TOP border of the GUI off the screen, further BELOW the BOTTOM border of the screen).
the 'height' (positive) value determines the VERTICAL OFFSET between the TOP border of the GUI and the BOTTOM border of the GUI.Code: Select all
when 'y_origin = 1' (meaning that "the vertical reference point is the TOP border of the screen"):
the 'y' (positive) value determines the VERTICAL OFFSET between the TOP border of the screen and the BOTTOM border of the GUI;
a negative 'y' value is INCORRECT (placing the BOTTOM border of the GUI off the screen, further ABOVE the TOP border of the screen).
the 'height' (positive) value determines the VERTICAL OFFSET between the BOTTOM border of the GUI and the TOP border of the GUI.Code: Select all
when 'y_origin = 0' (or when the parameter is ABSENT) (meaning that "the vertical reference point is the vertical CENTER of the screen"):
the 'y' value determines the VERTICAL OFFSET between the vertical CENTER of the screen and the OUTWARD vertical border of the GUI, as follows:
an increasingly POSITIVE 'y' value shifts the OUTWARD vertical border of the GUI further ABOVE the vertical CENTER of the screen;
an increasingly NEGATIVE 'y' value shifts the OUTWARD vertical border of the GUI further BELOW the vertical CENTER of the screen;
the 'height' (positive) value determines the VERTICAL OFFSET between the OUTWARD vertical border of the GUI and the INWARD vertical border of the GUI.I wrote that wiki page after long hesitation as I found it the primary job of hud designers to make the first start of the page. Anyhow, "origine" is the dutch spelling for "origin". Because of the resemblance and the dutch word still sound english to me, I often have the feeling the "e" is missing and add it without thinking.sdrubble wrote:1 - origin vs. origine
Is that a typo or a mixing with languages? Hehe, not being a native speaker myself I know what you mean.Eric Walch wrote:Anyhow, "origine" is the dutch spelling for "origin". Because of the resemblance and the dutch word still sound english to me, I often have the feeling the "e" is missing and add it without thinking.sdrubble wrote:1 - origin vs. origine
Well, at least for the moment it's working for me.To the missing key in one of the guis:
Maybe I noticed a bug there and left it out intentionally, or I just didn't test it because it seemed not functional there.
But while it's a very useful tool to visually demonstrate the full positioning of the gui regardless of the presence of actual messages, I'm not sure if I'll be keeping it after I'm done with moving the gui around. Will keep an eye for possible bugs though, while it's still 'on'.Well, I checked the page history and found that, at some point BEFORE removing that key, you've left it in there for a while IN DUPLICATE. Maybe your bugs came from the duplicate entry ?There is stil another key I left out completely. (If you look in the pages history, you can find it). But on testing I noticed that one is buggy and I removed the entry from the wiki. That is a much easier fix than correcting the code.
Well, while I'm by no means a hud 'creator', I'm already doing my little bit as a tester and doc-drafter. Fair enough.Anyhow, as I never work with huds, I leave it to the hud creators to find the bugs in the documentation and correct that wiki page.