Oolite Bulletins

Cody wrote: ↑Sun Mar 25, 2018 1:28 pm

Would one be able to insert a custom character pic?

Yep!

How does this addon interact with the ones it intends to replace ?
For instance, changing the difficulty level of NPCs (addon "Skilled NPCs") using OXPConfig also changes the values displayed in the "Config for Addons" menu tree. So it seems Library is designed to be compatible with the addons it intends to replace ?
Why is it not available in the addons manager ? My suspicion is/was because of conflicts ?
If some other installed addon depends on CCL, can I remove CCL now, after installing Library ? (I assume not though, probably all of the addons depending on CCL which I have installed need to be updated first...)

I wanted to configure the Navi MFD, but it only works with Library, so now I have OXPConfig and Library parallel.

Anonymissimus wrote:

For instance, changing the difficulty level of NPCs (addon "Skilled NPCs") using OXPConfig also changes the values displayed in the "Config for Addons" menu tree.

This is less to do with Library, and more to do with the fact that I added support for Library to Skilled NPC's, which should co-exist if both configuration OXP's are installed. However, more options are available through Library than through OXP Config, so if you have both installed, you should make Library your default place to change the config.

Anonymissimus wrote:

I wanted to configure the Navi MFD, but it only works with Library, so now I have OXPConfig and Library parallel.

You can have both Library and OXP Config installed - they don't conflict with each other.

Anonymissimus wrote:

If some other installed addon depends on CCL, can I remove CCL now, after installing Library ?

If an OXP requires CCL, it will still need it even after Library is installed. Library doesn't replace existing requirements, even though it is designed as a replacement to things like CCL. It must be specifically targeted by OXP authors in order to be used.

Anonymissimus wrote:

Why is it not available in the addons manager ? My suspicion is/was because of conflicts ?

I think there are two reasons (1) Svengali is giving the pre-DM release plenty of time to bed down and for bugs to be discovered, and (2) Getting time to do the work required to do the upload.

Very Impressive !!

Will the P.A.D. be accessible while in flight as well as when docked?

The ability to enter a player's own notes will be most welcome. Anything that eliminates at least some of the pieces of paper that crowd my desk while playing is a good thing.

Have you figured out the size of the custom portraits yet? Just a bit of anticipation so that something can be prepared ahead of time.

Looking forward to a release. Do take your time though. These things are never easy to get just right with all the bug squishing, feature adding, and such.

Worth repeating: Very Impressive !!

Thanks phbk .-) A +1 answer .-)

As sidenote: CCL, OXPConfig and Hyperradio have been written for Oolite v1.77 (or earlier) and are marked deprecated. Library offers so much more flexibility and has many new features, using the cleaner ways Oolite offers since v1.80. And the transition from OXPConfig to Lib_Config is easy, as they are using similiar data-structures.

Nite Owl wrote:

Will the P.A.D. be accessible while in flight as well as when docked?

No. As it is using models on the screens it won't work. What could be possible is to add a method to display a text summary - e.g. through CommsLogMFD.

Nite Owl wrote:

Have you figured out the size of the custom portraits yet?

Any square resolution will do. The textures in Lib_PAD are 128x128 px.

Custom portrait adds is easy and works.
Running a test version and liking it.

Just a note about how the PAD will work.
As we really can't handle external resources without huge efforts, code and runtime (e.g. to declare for every resource the corresponding AddOn, etc.), Lib_PAD will leave the handling for loading and storing to the inserting AddOns - because I'm lazy. It's only a tiny bit of code AND players still have the freedom to move AddOns in and out as they want - without generating errors. A simple example may show what this technical blabla means.

Let's say you need a page. Just define your data object, e.g. On .startUpComplete And save it. That's it.

For AddOn-developers:
A test-version has been uploaded and I've started to  document the PAD. If you feel that something is missing it's time to speak up, before the data-structure settles down. Please note that the test-version does not store anything yet and most of the error handling and limiting (e.g. Array length) is still missing, but should be enough to see what it does and how it works.

Was wondering if there could be a spot to list your crew. Just there position name and a mug shot.
Gunner
Engineer
Copilot
Cook
Just a thought.

BlackWolf wrote: ↑Tue Apr 03, 2018 12:00 am

Was wondering if there could be a spot to list your crew. Just there position name and a mug shot.

It is already possible to add them in the PERSONS category. But crew handling (and the consequences) is probably something for a Companion-AddOn. The PAD can be used to display the data about them like name, picture, origin, species, gender, abilities, etc. and if a special property is set to call a function in that Companion-AddOn. A similiar approach is alreay used to decrypt specific messages (undocumented yet). I'm also thinking about a way to cross-link pages, but it will be a very simple system and space on screens is rather limited. We will see.

Changes:
- The new search functionality can handle now much more data. I've just tested it with >4100 pages on my really slow machine, so I guess it's even possible to insert something like the 'New Galaxy Guide'. Funny.
- _getData() returns now null instead of false if the path is not found.
- On GALCOP and GUILDS pages rank has been replaced by kills which is probably more suitable.
- Added PERSONS Curruthers, Fortesque and Blake (Lib_PAD_Events.js).

I'm still a bit unsure about the SYSTEMS pages, but hey.

Cross-linking between pages is now possible. The system works similiar to the WIKI Categories. A page defines its parents and the parent page will get it as member.

Changes:
- Added optional third argument parent in _addPageInCategory to relate a page to its parent(s).
- Added screenhandling for relations between pages.

Has there been any update to this OXZ?
What is the current version available?

BlackWolf wrote: ↑Fri Jun 15, 2018 7:30 pm

What is the current version available?

I believe 1.6 is current - that's what I have.

Any update to the PAD feature?

@BlackWolf: I'll upload a new version and send you the link.

Library will get a new toy - In-System-Maps in 3D.

The initial idea was to improve mission briefings. Reading through a lot of text ("Find this, go there, do that and return to us.") is a little bit a thing of the 90th. We can do more - so I'm currently working on it to get some visual interesting stuff for the dull bits. There is still some work left, but I want to show you some of the features even if it's only a sneak preview.

The way it works:
A script passes an object to the Map-Script. Lib_Starmap creates a missionScreen and places the objects based on real world coordinates and assigns textures. Up to 12 elements can be shown (either standard objects like the sun, planet, mainStation, etc or custom). The object positions are scaled down for display. Far out positions beyond a hardcoded point are compressed, so it will still work even if AddOns like DistantSuns are used. The next step is to zoom the whole thing to fit in the screen. And finally it can be animated (optional) to give a visual impression of the things the player should know. The animations can contain text, sounds and movements. The created objects are just planes using a billboard vertex shader, so they will always point to the player. Standard objects like secondary stations, carriers, beacons will use a color-scheme, custom objects can use this scheme as well.



But the mechanism allows inflight usage as well. This is specially interesting for missions. The script creates a visualEffect for it and tracks marked objects to update positions on the map. If they slip away (exploded, removed or jumped) they are cleaned from the map. The map disables itself on red alert and enables itself again when things have settled. The orientation of the map is bound to the compass, so you can control it easily to see it from different angles. The visualEffect gets removed on docking/dying/jumping.



Both maps (missionScreen and inflight) will work in interstellarSpace as well, so it is possible to get back to the [0,0,0] position, which was hard before (through using the FPS display). The maps are not accessible through equipment or interface handling - they have to be called by script. And the calling script decides what kind of elements will be shown. Usage for scripts is easy - for a standard setup it's only one line of code!

The inflight map will create some garbage collection if the map is actually shown, but not if it's disabled, because all positioning and vector-math is bypassed. So I think it's not a tool for general usage - I'll see if I can reduce it even further.

On my todo-list is a method to add content to active maps for the script which has setup the map, callbacks from the missionScreen, some standard setups and more short keys for standard objects. Currently Lib_Starmap is around 7 KB, so if we end <10 KB it's a good thing.