A conversation I just had with Svengali about this issue:
Svengali wrote:
Comms and Message GUI are cleared when the HUD switches (e.g. switching to F7, then back). This is serious trouble for missions and ship2ship communications. Probably you should talk with the devteam if it's possible to keep the messages.
My reply was:
CommonSenseOTB wrote:
What actually is happening is this: when the hud switches it does not clear the guis, only when the hud switches and new guis have been defined. Only then are the guis cleared if they have been redefined. You will find proof of this in in the operation of the gun cameras huds in MFLPS. Use the standard hud and switch from the main view to the custom view. The custom views hud does not have a comms gui defined and neither does the standard main hud so it uses the core code predefined position. When you switch back and forth between huds, the comms gui is not cleared. I caught on to this phenomena and deliberately ommitted a comms gui definition in the gun camera hud.
I assume this is standard operation of the guis when redefined that they must be cleared. Maybe a workaround is possible to store in a string everything that comes into the comms gui between hud switches and when the hud is switched then send it back to the comms gui. This could be done in core code or maybe as an oxp script addon to help with hud switching. I only really just got my head into this problem a few weeks ago and haven't had the time to pursue an oxp workaround. Would be part of any hud scripting. If you feel that this is a bug pertaining to redefining the comms gui then please feel free to take it up with the devs. You may quote what I have said and use MFLPS as an example of how it is the redefining of the comms gui rather than hud switching itself that is the issue.
The other thing in the back of my mind is: wasn't there an issue with sticky messages in the past that was addressed and maybe that is why things work the way they do today. If so, then the operation, as such, is as was intended.
I tell you what. I'll post this in the bugs and see what the devs say.
Well what say you devs? Is this a bug that needs to be fixed or something that should be an oxp workaround for hud developers to script when redefining the comms and message GUIs and if it should be an oxp workaround then what would you suggest? Also to consider would be a way to clear the comms gui if this was fixed in core code. There are other possible uses for the comms gui and having it cleared might also be required. This appears not to be a straightforward issue.
Take an idea from one person and twist or modify it in a different way as a return suggestion so another person can see a part of it that can apply to the oxp they are working on.
Hi, I'd consider the present behaviour a bug, and fix it so that the comms & message GUIs are not cleared (ie should be able to have that fix before 1.76).
However - and this is for after 1.76 - I'm not too clear about the need for a clear comms and/or clear messages commands.
Bearing in mind that we do store the message history inside savegames too, in what circumstance would it be desirable for an OXP to erase the message history?
As I have not yet pursued any other oxp use of the comms gui for displaying other information, I am not yet in a position to answer whether the comms gui would actually need to be cleared. If the comms gui has an unlimited size then it might be required to save what's in it, clear it, put data into it for another use, and then clear it when done and restore the original information. That's if what I'm imagining is even possible. If not then probably wouldn't need to clear it.
Take an idea from one person and twist or modify it in a different way as a return suggestion so another person can see a part of it that can apply to the oxp they are working on.
Sort of.
The comms log is kept between resizing of the comms log & the last couple of lines of the message_gui are kept when switching message_guis
There's a couple of not-quite right things still, but short of a total gui rewrite, that's the best we can get. And there won't be a total gui rewrite before 1.76.
It should now be possible to play around with gui settings.
Plus, the documentation never mentioned that you can also have
"comm_log_gui" = {
permanent = YES; // if not specified, defaults to NO
automatic = NO; // if not specified, defaults to YES
};
Why automatic instead of auto I don't quite know anymore... maybe to avoid associacions with cars...
They've been there for quite a while (1.74?), but they were 'slightly' buggy until today, so it's probably a good thing they weren't documented!
"comm_log_gui" = {
permanent = YES; // if not specified, defaults to NO
automatic = NO; // if not specified, defaults to YES
};
Now we're cooking!
Take an idea from one person and twist or modify it in a different way as a return suggestion so another person can see a part of it that can apply to the oxp they are working on.
Plus, the documentation never mentioned that you can also have
......
Why automatic instead of auto I don't quite know anymore... maybe to avoid associacions with cars...
They've been there for quite a while (1.74?), but they were 'slightly' buggy until today, so it's probably a good thing they weren't documented!
HUD documentation didn't even exits until a few months back
I thought I added all keys I found in the code. I must have missed them, or they were at a place I didn't look. Undocumented was also the use of "title" This does add a title, but the background colour is that one line off. "title" was probably an experimental feature and that was intentionally not documented by me.
