Cockpits, HUDs and other displays

[hiran]

Observations and suggestions:

I'd already done the config in ~/.oolite-starter.conf, so had clues to work with. Maybe give an example URL like tcp://127.0.0.1:1883. Could the 'sane example' server URL be pre-filled in that field when no user content? It is after all, what the majority will be needing during 'baby steps'.

I tested Prefix with 'games/oolite/debug' (deliberately omitted the trailing '/') and ended up with messages in games/oolite/debugoolite/starter. If this behaviour isn't a "feature", then this field could be parsed to deal with the slash/no-slash situation.

Showing the fully constructed topic somewhere (under that field?) might help some grasp what's happening. If this could be done during form-filling, then the slash can be auto-added, and there will be less need to document the process. Simply, type into the field and see what the topic will be 'as you go'. When blank, oolite will be shown as the topic, type a letter 'a' into the field and the line below will show a/oolite etc.

Leading slashes, although 'not-normal' in MQTT discussions, seem to be valid as topic characters, so if a user wants them, they should probably be left alone:
Prefix : games/oolite/debug/ : Test arrived at games/oolite/debug/oolite/starter
Prefix : ///games/oolite/debug/ : Test arrived at ///games/oolite/debug/oolite/starter

Buzzing!!!

Thanks again.

I'll take a look. The changes are getting smaller and targeting at usability of the existing stuff. I like it.

[Cholmondely]

You are in a good position and welcome to test the build that MrFlibble handcrafted for Apple x86 hardware. While it does not carry the latest experimental code (MQTT) it is still very shiny and deserves to be checked.

https://github.com/OoliteProject/Oolite ... ag/v0.1.31

It installed!! Thanking you both, gentlemen.

I need to come up with some new text for the flavours page.

...And would it make sense to include a button for each flavour which takes one to a list of the relevant OXPs?

...And should vanilla even be on the list? The way the text is worded, it "sounds" identical to the Strict Game, which is already in Oolite as an option.
I'd envisaged it more as a basic empty template allowing one to develop one's very own suite of OXPs (from back in the day when each flavour was exclusive in leaving out other OXPs). Maybe it is no longer needed at all? But then there might need to be some explanatory text...

[Cholmondely]

New Text for "Flavours" page

Vanilla

A basic template with nothing in it for building up your own personal flavour (to be stored/reloaded on the "Expansion Set" page)



Beginner's Set

A basic set containing vital OXPs for new players but also ones useful for more seasoned players. These provide more information about the game (a Ship's Manual, a HUD with warning signs, comparisons for commodity prices) as well as some cheap equipment helping with targeting, docking etc.



Stranger's World Set/Depth Set

(No changes to the text)



G1 Missions & Activities

Adds Missions and Activities which are either just for galaxy 1 - or are generic for all 8 galaxies.



Additional Planets & Stations

Adds Planets and Stations around them just as Strangers World does. But the emphasis is more on playability rather than astrophysical realism. There is no tweaking of trade.



Order of Flavours
I'd move Stranger's World to just before Additional Planets and Stations. - or maybe it should be after (it is more complex) and the text of both should be changed?

[hiran]

You are in a good position and welcome to test the build that MrFlibble handcrafted for Apple x86 hardware. While it does not carry the latest experimental code (MQTT) it is still very shiny and deserves to be checked.

https://github.com/OoliteProject/Oolite ... ag/v0.1.31

It installed!! Thanking you both, gentlemen.

I need to come up with some new text for the flavours page.

Perfect! So finally we found the root cause for your problems. Kudos to MrFlibble who identified the issue and found a workaround.

For the suggestions on flavors:
They are meaningful but do not require any change in OoliteStarter. The flavors are hosted in the website directly:
https://github.com/OoliteProject/oolite ... .0/flavors

Changes there will take effect on all versions of OoliteStarter. Be them already installed or future.

[hiran]

Observations and suggestions:

I'd already done the config in ~/.oolite-starter.conf, so had clues to work with. Maybe give an example URL like tcp://127.0.0.1:1883. Could the 'sane example' server URL be pre-filled in that field when no user content? It is after all, what the majority will be needing during 'baby steps'.

I tested Prefix with 'games/oolite/debug' (deliberately omitted the trailing '/') and ended up with messages in games/oolite/debugoolite/starter. If this behaviour isn't a "feature", then this field could be parsed to deal with the slash/no-slash situation.

Showing the fully constructed topic somewhere (under that field?) might help some grasp what's happening. If this could be done during form-filling, then the slash can be auto-added, and there will be less need to document the process. Simply, type into the field and see what the topic will be 'as you go'. When blank, oolite will be shown as the topic, type a letter 'a' into the field and the line below will show a/oolite etc.

Leading slashes, although 'not-normal' in MQTT discussions, seem to be valid as topic characters, so if a user wants them, they should probably be left alone:
Prefix : games/oolite/debug/ : Test arrived at games/oolite/debug/oolite/starter
Prefix : ///games/oolite/debug/ : Test arrived at ///games/oolite/debug/oolite/starter

Buzzing!!!

Thanks again.

I'll take a look. The changes are getting smaller and targeting at usability of the existing stuff. I like it.

So here is the next version which directly visualizes the effect of user input. Regarding that slash magic: OoliteStarter will not intermingle - users can directly see the impact of their deeds before any harm was created and react.

OoliteStarter v0.1.32-gelsemium.11

[MrFlibble]

So here is the next version which directly visualizes the effect of user input. Regarding that slash magic: OoliteStarter will not intermingle - users can directly see the impact of their deeds before any harm was created and react.
OoliteStarter v0.1.32-gelsemium.11

Coolness!

Code: Select all

[WARNING] Some problems were encountered while building the effective model for oolite:OoliteStarter:jar:0.1-SNAPSHOT
[WARNING] 'dependencies.dependency.version' for net.bytebuddy:byte-buddy:jar is either LATEST or RELEASE (both of them are being deprecated) @ line 326, column 22
[WARNING] 
[WARNING] It is highly recommended to fix these problems because they threaten the stability of your build.
[WARNING] 
[WARNING] For this reason, future Maven versions might no longer support building such malformed projects.

Do you think that's a warning?

This builds and runs and IS gelsemium.11 (the fun I had getting jbuilder to work with THAT!).

I ended up just bodging around it with sed, and feeding $MacVER to jbuilder

Code: Select all

distVER=0.1.32-gelsemium.11
MacVER=$(echo "$distVER" | sed 's@^0\.@@;s@-gelsemium\[email protected]@')
echo "Using $MacVER instead of $distVER for jbuilder"
Using 1.32.99911 instead of 0.1.32-gelsemium.11 for jbuilder

... then replacing $MacVer with $distVER in the output file moves.

So, here are my Mac x86_64 builds of that.
OoliteStarter-0.1.32-gelsemium.11-x86_64.pkg (57.89 MB)
OoliteStarter-0.1.32-gelsemium.11-MacOS-x86_64.zip (58.18 MB)
Those uploads will self-destruct in 30 days

Oooh! I just sussed how to get debug up on the Mac version. The game is impossibly slow on my notamac, but perhaps I can in some ways help those who have a real one.

I like the real-time refresh of topic very much.

On my 1080 laptop screen it's just fine as is, but the list goes way off screen if not using a high-res monitor (1280x800 on my test-env). Would it be simpler/cleaner/smaller to list the sub topics beside/over/under/separately from the live-changing parent topic? Like "Starter will use this topic: [changeable parent] to contain these subtopics: [static list (as paragraph to avoid falling off the screen)]".

I expect I'm using the wrong terms (parent/sub-topic), but I'm sure you catch my drift.

[hiran]

Coolness!
Before I play, here are my Mac x86_64 builds of that.

Thanks for including our AppleMacintas.

Cholmondely? Please take over...

While building that, I noticed this:

Code: Select all

[WARNING] Some problems were encountered while building the effective model for oolite:OoliteStarter:jar:0.1-SNAPSHOT
[WARNING] 'dependencies.dependency.version' for net.bytebuddy:byte-buddy:jar is either LATEST or RELEASE (both of them are being deprecated) @ line 326, column 22
[WARNING] 
[WARNING] It is highly recommended to fix these problems because they threaten the stability of your build.
[WARNING] 
[WARNING] For this reason, future Maven versions might no longer support building such malformed projects.

Do you think that's a warning?

Yes, it is a warning. I checked the dependency, and that library is just required for the test phase. So as long as the build finishes with a nicely wrapped package the danger is over. But I have a couple of other warnings, too.

[hiran]

So here is the next version which directly visualizes the effect of user input. Regarding that slash magic: OoliteStarter will not intermingle - users can directly see the impact of their deeds before any harm was created and react.
OoliteStarter v0.1.32-gelsemium.11

Coolness!
Before I play, here are my Mac x86_64 builds of that.

OoliteStarter-0.1.32-gelsemium.11-x86_64.pkg (56.67 MB)
OoliteStarter-0.1.32-gelsemium.11-MacOS-x86_64.zip (56.96 MB)


EDIT: My builder had re-packaged the old versions it seems. I'll redo and re-upload.

Whoops! I just uploaded them.

But wouldn't it be nice if you could directly upload to Github rather than going yet another hop?
@a_c, @phkb? Could you fix that?

[MrFlibble]

So here is the next version which directly visualizes the effect of user input. Regarding that slash magic: OoliteStarter will not intermingle - users can directly see the impact of their deeds before any harm was created and react.
OoliteStarter v0.1.32-gelsemium.11

Coolness!
Before I play, here are my Mac x86_64 builds of that.

OoliteStarter-0.1.32-gelsemium.11-x86_64.pkg (56.67 MB)
OoliteStarter-0.1.32-gelsemium.11-MacOS-x86_64.zip (56.96 MB)


EDIT: My builder had re-packaged the old versions it seems. I'll redo and re-upload.

Whoops! I just uploaded them.

But wouldn't it be nice if you could directly upload to Github rather than going yet another hop?
@a_c, @phkb? Could you fix that?

I'd be up for that. I've edited my previous post.

[hiran]

Whoops! I just uploaded them.

But wouldn't it be nice if you could directly upload to Github rather than going yet another hop?
@a_c, @phkb? Could you fix that?

I'd be up for that. I've edited my previous post.

Uploaded to Github.

[hiran]

Now that OoliteStarter is easy to configure and sends data reliably. I managed to create a dashboard. This time in a browser based on node-red. It is impressively fast. Seems this is the most straightforward way, and Maik had demonstrated it long ago.

The limits I am hitting is that we actually have only three entities to render: Speed, Alert Status and comms messages. Well, it was a proof of concept.
But now I'd like to add some flesh.

I think what would help me most is better visualization when I am tense and busy looking at something that either does not display the data or is small enough I continually overlook it. Sometimes I even have the logfile displayed alongside of Oolite just to know a little more.

Thus I'd like to know the shield level of my target. I'd like to see my missiles, and launch them with a single tap on the display (assuming a touchscreen).
1) which data would I have to read from Oolite?
2) which commands would I need to select and fire a missile?

[phkb]

For 1,
player.ship.target.energy
For 2, you could try
player.ship.fireMissile()
But I’m not sure if that would work for the player ship. Worth a try though.

[hiran]

For 1,
player.ship.target.energy
For 2, you could try
player.ship.fireMissile()
But I’m not sure if that would work for the player ship. Worth a try though.

I seem to be doing something wrong as I do not see the desired reaction from Oolite.
While I get the acknowledge that my request was received the expected response is missing...

@MrFlibble: Could you check if these commands can be used in a meaningful way on the debug console?

[MrFlibble]

For 1,
player.ship.target.energy
For 2, you could try
player.ship.fireMissile()
But I’m not sure if that would work for the player ship. Worth a try though.

I seem to be doing something wrong as I do not see the desired reaction from Oolite.
While I get the acknowledge that my request was received the expected response is missing...

@MrFlibble: Could you check if these commands can be used in a meaningful way on the debug console?

You must have read my mind. I tried it as soon as I saw it. PS.fireMissile() does the job. I couldn't (quickly) find a way to switch missiles. PS.target.dumpCargo() is fun

Exception: TypeError: PS.target.energy is not a function. Tried PS.targetEnergy() as well.

edit: PS.target.energy without brackets does pop the relevant data

Code: Select all

> PS.target.energy
406
text = Incoming missile.
text = Fer-de-Lance Enemy ejected!
Increasing player score from 8935 to 89351
text = Enemy derelict!

The score increase by "an order of magnitude plus one" looks a bit iffy!

I've been toying with using Tasmota on a TTGO T-Display (rolling a custom image with more MQTT goodies). It's got a tiny colour screen and two buttons which understand multiple clicks. Maybe half a dozen actions can be set up to fire at the debug topic. I'm looking forward to tying micro-controller toys in with Oolite.

[Wildeblood]

MQTT

MQTT is the IoT protocol, yes? Are we ever going to get, "Hey Google, fire a missile."?

Asking for a friend.