[RELEASE] HUD Requests OXP and LogEvents OXP

[Norby]

Hi Players and Developers!

Instead of simply write down my requests about HUD improvements I decided to write an OXP to exemplify why I think that these are usable to make more advanced HUDs. I hope the core developers will check this and players will try it and send feedbacks.

This is a tech demo to make semi-dynamic HUD menus and contain requests for new features to make more dynamic HUDs. The HUD Menu OXP with a menu-making howto will be scheduled after some requests are coded.
A mini game is included if you choose the Oolite misison: you win if no aliens remaining, and the log will contain your combat statictics.

Let's take off and talk with the Nav Buoy!


LogEvents OXP

This script catch all available handlers and write into the Logs/Latest.log to help developing and to review a battle, or find out why the police attacking you suddenly.
Originally maded to log all laser hits earned in the built-in mini game in the HUDRequests OXP, but separated due to it is useful to everybody, while usually realize it after something happened.

Download HUD Requests OXP
Download LogEvents OXP














LogEvents output:


Download HUD Requests OXP
Download LogEvents OXP

More screenshots are uploaded into my box, but better if you play without knowing all of them.

[pagroove]

Looks interesting and nice. And Welcome!

[cim]

Interesting ideas.

So, regarding your requests:
1) Not in that exact form, but something with similar functionality is on my list for 1.79/1.80

2) Unlikely. I think there'd be a need to demonstrate that you can't make a good interface with just two first, and even then keys are expensive - we have very few keys left at all which can be used, and giving two more over to the OXP equipment would seriously reduce our scope for adding more core functionality which required keys later on.

3) Ctrl-<cycle equipment> already does this. (Or at least, it should...)

4) Not in that exact form, but something with similar functionality is on my list for 1.79/1.80. The hud-overrides approach wouldn't scale if more than one OXP wanted to do this.

5) Not in that exact form, but something with similar functionality is on my list for 1.79/1.80, at least for this sort of thing.

6) I'll have to think about this one in more detail. I suspect that you could only use it safely if you knew what HUD was in use, at which point the existing techniques for conditional display of HUD items might be sufficient.

7) A "text entry" option for mission screens is on my list to consider. Probably not as an in-flight thing, though.

8) Shouldn't be necessary with the way I plan to do things for 1.79/1.80. For more general cases I'd have to look up why guiScreenChanged isn't sent while paused in the first place.

(As regards the cryptic comments about "similar functionality", I'm hoping to find time soon to write my notes up into something suitable for OXP developer comment)

[JazHaz]

I selected "No" for the poll, as I wouldn't get it myself, but I do think it could be good for newbies to the game.

[Norby]

First of all I thank you for all "similar functionality".

The Ctrl-N is working well, I missed it due to it is not referenced in the keyconfig.plist nor in the OoliteKeyconfig1.1, and I read the official Reference Sheet too much time ago to remember. But now I commented the keyconfig.plist with the Ctrl keys, you can put it into the next release.
I removed this 3. request from the OXP, so all others got lower numbers in the update (v1.1).

Take after this the Ctrl-b and Ctrl-n are good also to extend the usability of the equipments if these keys are not so much expensive.

6) I'll have to think about this one in more detail. I suspect that you could only use it safely if you knew what HUD was in use, at which point the existing techniques for conditional display of HUD items might be sufficient.

I think the key is to how to get exactly a hud item in js. My simplest solution is to give an id field into the legends of the hud.plist:

legends = ( { id="myhud_energy"; equipment_required="EQ_MYHUD_ENERGY"; x=-180; y=60; text="256"; }, ... )

The id can contain the name of the targeted hud also to avoid the name collisions.
In this case a js can do something like this to changing and moving the legends:

player.ship.hudlegends["myhud_energy"].text = player.ship.energy;
player.ship.hudlegends["myhud_energy"].x = -170;

Another advantage if the position is changeable then do not need EQ to hide, just simply move out of the view.

[Norby]

I selected "No" for the poll, as I wouldn't get it myself, but I do think it could be good for newbies to the game.

The question is misunderstandable (and I can not edit to fix it): the menu itself will not made directly to the players but the OXP developers who can made nice "glass" Mission talks during fly and other never seen visual effects which should be increase the playing experience.

A better question is something like: "do you want better visual effects?" and should be answered with "yes" by all players.

[Smivs]

...nice "glass" Mission talks during fly...

If you are talking about in-flight mission screens, the idea has been discussed before. The most often mentioned 'problem' is that you don't need distractions on-screen while you are fighting in particular. Even in a quiet place you could be distracted enough to fly into an asteroid or something

[Norby]

...nice "glass" Mission talks during fly...

If you are talking about in-flight mission screens, the idea has been discussed before. The most often mentioned 'problem' is that you don't need distractions on-screen while you are fighting in particular. Even in a quiet place you could be distracted enough to fly into an asteroid or something

It is only a part of the possibilities. Some can help to navigating and others in fight if designed well (using the alert level and others). The goal is to made better HUDs which can be simpler also if there are more dynamic functionality.

Personally I prefer many informations like on the Numeric HUD, and do not like the blind feeling when I change to the status screen in-flight.

I can improve these with the current tools a bit only and with a lot of repetitive work, so I try to ask some core improvement. Maybe I will dig into the core source deeper to make patches if something need too many work in js due to the limitations and the core team is too busy to improve it, but of course after the idea is discussed only.

[Svengali]

It is only a part of the possibilities. Some can help to navigating and others in fight if designed well (using the alert level and others). The goal is to made better HUDs which can be simpler also if there are more dynamic functionality.

*Grins* - welcome aboard, Norby.

Yep, it would need changes to the core to get this stuff working dynamically and easily scriptable. Currently the only other option is to use [wiki]Cabal_Common_Library[/wiki]. This OXP ships the possibility to create inflight overlays (via shader, so it does not alter HUDs) and ship2ship comms (or worldScript2ship).

[Norby]

use [wiki]Cabal_Common_Library[/wiki]. This OXP ships the possibility to create inflight overlays (via shader, so it does not alter HUDs) and ship2ship comms (or worldScript2ship).

Hi Shader Master!

I looked a lot of your sources in Vector and CCL but I need to learn the shaders better and how to use of your codes also before I can make my owns, so please give me some time. My first surprise was about this that how well documented in the wiki, the second was after I read all pages that I still not understand it.

This is an interesting area of the programming in my eyes so I plan to do improvements when I get into, but currently seems to be the hardest way to earn what I wish. But this can be the most eye-catching solution also, so please be ready when I start asking questions.

[Smivs]

(I) do not like the blind feeling when I change to the status screen in-flight.

True. While not generally in favour of in-flight overlays, I agree that in a few specific situations these could be useful. This is not a feature I would like to see over-used however.
Also, relying on shaders is un-wise, as there are still many players whose computers do not support shaders. The ability to make normal overlays with transparent backgrounds would be preferable.

[Svengali]

I looked a lot of your sources in Vector and CCL but I need to learn the shaders better and how to use of your codes also before I can make my owns, so please give me some time. My first surprise was about this that how well documented in the wiki, the second was after I read all pages that I still not understand it.

This is my fault. The CCL documentation still needs to be improved, so any question will help .-)

Also, relying on shaders is un-wise, as there are still many players whose computers do not support shaders. The ability to make normal overlays with transparent backgrounds would be preferable.

Yes, simple inflight overlays is one of the features which are better done without the need of shaders. More complex things can't be done with materials or HUD entries though - and it probably wouldn't make sense to do this on lower end machines at all.

[Zireael]

This looks amazing, going to check it out!

[Norby]

Meantime we got in nightly builds: MFDs which cover some requests (similar HUD menus can be made in MFDs), and a text entry which is used in Gallery OXP. Thanks to the core developers!

[dertien]

Hi Norby,

I would like very much to see the face of the freighter pilot I need to escort, the face of the gun for hire that watches my back, or who I would need to take out in random hits etc...This is without a doubt a lot of work since such an oxp would need to interact with existing ones by different authors, and I am thinking out aloud again. But if you would need some nav buoy, station docking control or other NPC muppet-pictures (aliens and humans) that would show up in the top left or right of the screen I have just the thing for you. This would for example add something more of a less disembodied (no pun intended sir!) " docking granted message" and welcome message across.

I made these for another mod and another game, but I don't see why they could not be used here if such a project were accomplished here.

A couple of screenshots:







If anyone wants the complete pack in a zip file, pm me. They are all online so feel free to use them.