Formatting text msgs on a HUD

[Kaks]

manually for each and every message of every OXP

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:

Code: Select all

this.startUp = function()
{
    player.consoleMessage = player.commsMessage;
}

Thanks to javascript's function overriding feature, any further calls to consoleMessage() will be redirected to commsMessage()...

[CommonSenseOTB]

Great tip Kaks.

[JazHaz]

Would that have the effect of having the same messages appear in both message areas?

[Kaks]

Yep!

[sdrubble]

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:

Code: Select all

this.startUp = function()
{
    player.consoleMessage = player.commsMessage;
}

Thanks to javascript's function overriding feature, any further calls to consoleMessage() will be redirected to commsMessage()...

This is AWESOME, Kaks !!!

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

[Eric Walch]

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

When you also want the messages to go to the normal log file, you can add

Code: Select all

this.commsMessageReceived = function(message, sender)
{
 log("Player", player.ship.displayName+" received message: "+ message + " from ship: " + sender.displayName);
}

to the same script file. 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.

[sdrubble]

[ . . . ] 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.

That's really great Eric !

Now the only thing really missing is a function to remind me to actually READ the log file after a looooong game session... before it gets overwritten by the next couple sessions.

Cheers ! Sorry for the late reply - RL keeping me busier (and lazier ) these days.

EDIT: wait a minute !!! It has just downed on me (after implementing BOTH tips from Kaks and Eric): next time I'm thru some memorable and hectic moments like THESE , I won't have to play modest and shrink the subjective count of Thargoid Battleship kills - it will all be recorded for posterity in the log !!!

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]

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.

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]

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.

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.

Oh well... nothing is perfect I guess.

So it seems that, in the end, the MANUAL-and-individual commsMessages replacements I've done should show up in the log, while Kaks' automagically-en-masse-transmogrified ones will not (if I got this right). My own broader testing of this is still pending - I refuse to do anything else in Oolite [gaming proper included ] 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).

And Eric, may I ask - how did you happen to notice a simple EDIT to an older post of mine in a thread with no other recent posts

As usual, thx a lot and cheers

[Kaks]

The 'automagic' ones do appear on the log too.

[sdrubble]

Hi all !!!

I've been working on a number of tweaks to a HUD (specifically it happens to be the Chupacabra HUD). And the tweaks I'm concentrating on at the moment are all related to [color=#0000FF]'comm_log_gui'[/color]and [color=#0000FF]'message_gui'[/color].

I had mentioned previously - here in this thread, and also in the Chupacabra HUD's own thread - that I was intending to start a NEW thread to publish my tweaks and findings. However, while in the middle of the tweaks and tests, I've changed my mind about the 'NEW' thread bit. So that, whatever I end up publishing about HUD's - be it specific to the Chupacabra or maybe applicable to other HUDs - will be placed in this very thread here.

Depending on how all of this goes along, I might consider changing the thread's name as well, to something more generic like "HUD tweaks" [thx to CSOTB for the suggestion ! ].

My initial and quite pretentious idea was simply to publish a set of snippets and a corresponding set of screenshots. But as the work progressed and progressed and progressed, with no end in sight, I felt I should reassess and reframe the whole idea.

Main reasons for this were:

. . . - there are multiple ways to skin a cat (i.e., different coding snippets to arrive at similar results);
. . . - the same snippet would probably cause different results for different users due to differences in OSes, graphic chipsets & cards, driver versions, monitor resolutions, fullscreen x windowed mode, etc. etc.;
. . . - many of the experimentations I was doing were not clearly documented at http://wiki.alioth.net/index.php/Hud.plist .

So while my actual code-test-recode-retest saga is still a WIP (RL issues of all sizes and a good bit of laziness are the main stumbling blocks ), I feel I could start at once posting some comments about some Wiki entries.

Let it be clear that I'm not trying to 'correct' or 'complete' the Wiki entries. Pls consider these as mere random notes from some un-knowledgeable user making empirical tests based on the current Wiki descriptions.

So, here we go.

1 - origin vs. origine (already FIXED in the Wiki)

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.

2 - y_origin conflicting statements (already FIXED in the Wiki)

Code: 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. 

3 - background_rgba undocumented placement (see Eric Walch's comment, 2 posts below, with possible reasons for the omission)

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).

4 - [s]background_rgba[/s] default values (the Wiki example now shows the DEFAULT value)

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.

5 - background_rgba color tips

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 !!!)

6 - and, finally, voilá - The Black Art of GUI Positioning:

In order to correctly place either '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

while all six parms are somewhat individually documented in the Wiki, there's a devilish undocumented interaction among them which caused me no end of tweaks and tests. I'm currently in the middle of this process, which will now (at least I do hope so) become a bit easier, thru my discovery mentioned in #03 above... and yeah, now we could call '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.

So, my TOTALLY EMPIRICAL (and somewhat incomplete) tests led me to the conclusions below - someone else's validation would be welcome here, and it would be even better if some form of this (after the required corrections of course) could find its way into the Wiki. Let's see then:

6A

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.

6B

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.

6C

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.

6D

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.

6E

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.

6F

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.

Well, now I'm expecting someone to tell me I figured this all wrongly (really, I MEAN it !!! ) and of course suggest a proper rewrite of the offending statements. We'd all learn quite a bit BTW.

Cheers

EDITs:
- replaced a couple of words with others with more appropriate meanings.
- added statements: 'notes 01, 02 and 04 now fixed', 'note 03 under discussion'.

[maik]

I love the idea. I have also been thinking about how to improve the documentation for modding Oolite, along the lines of the official PHP documentation. There, each function has its own discussion where people post code snippets just like yours in order to clarify its use.

I don't have a good idea on how to do it though, given that the wiki needs authorization and given that response time to authorization request is not always lightning-fast

[Eric Walch]

1 - origin vs. origine

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. Is that a typo or a mixing with languages?

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.

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.

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.

[sdrubble]

1 - origin vs. origine

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. Is that a typo or a mixing with languages?

Hehe, not being a native speaker myself I know what you mean.

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.

Well, at least for the moment it's working for me. 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'.

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, 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 ?

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.

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.

Cheers and a lot of thx