Discussion ICARUS Terminal (Pre-Release)

I was really hoping to make it to LaveCon this year - and maybe get to chat to some other developers - but was a bit poorly and despite being all jabbed up have been knocked out with COVID for a couple of weeks now (boo) and that's coming off the back of a holiday so much activity on the last month.

Still, I have managed to get some playing and some small tweaks in!

Feedback from @Deadweasel above got me thinking, while there are still a bunch of known issues (and new features I'm still working on!) maybe it's at the stage where openly tracking bugs and feature requests on GitHub would be worth doing to help prioritise work, so might do that soon so folks can help prioritise things (and remind me to fix issues I keep forgetting about).

Some folks on GitHub kindly offered to help with translation, so am going to see what I can do there.

More updates soon I hope. Have a lovely weekend all!
Ugh that damned 'rona... Hope you feel better soon! I feel like we're running around in a hailstorm with all the variants at this point, ducking and dodging trying not to get hit!

As for the vertical panels, there is a limit to how narrow the resolution can get before the UI gets cut off. Currently I'm running them at 720x1280, with the browser's zoom set to 150%, or 1080x1920 with browser at 200%. Those are the sweet spots for readability and UI visibility on a 7" scren, I think.
 
Have to say, I just discovered this, and it's quite incredibly well done. I've done some UI programming in the past and this is clean, functional, well done artwork and nicely implemented.
I was going to roll my own thing using EDCD market connector or something, for my replica of the in-game stick, control panels and throttle...I've just gotten a perfectly sized 4.3" hdmi screen for the left side panel next to the throttle (in game there's like a palm rest thing underneath it). I currently have icarus terminal on it from windows - and I'm wondering, is there any way to bind joystick buttons to the tabs/functions? I could then make the custom buttons on the palm rest I'm building control the interface, that'd be super cool (and I'd happily lend a hand with the code/graphics).
Failing that, I think I'll have to bust out a raspberry pi and make the buttons (all backlit etc) correspond to keyboard or something...not sure if the web elements are keystroke linked tho are there?
Here's my build thread (i'll be adding photos with Icaraus on the panel tomorrow!):
 
Hello, I have a qol request:

Please add the number of total and scanned bodies to the list of the current system.

Zwischenablage01.png


The fss event:
"event":"FSSDiscoveryScan", "Progress":1.000000, "BodyCount":1, "NonBodyCount":0, "SystemName":"Col 173 Sector HK-Z b29-1", "SystemAddress":2887425074577 }
 

Attachments

  • Zwischenablage01.png
    Zwischenablage01.png
    676.2 KB · Views: 73
Managed to get the top of my info-panel printed (bottom is still to be done. 14 hour print!). Screen looks great with Icarus loaded in.

I might be being stupid, but is there any way to interact with the terminal whilst you’re in-game (running it on the same machine as the game, on secondary hdmi display)? Maybe even bind joystick buttons to switch tabs etc?

8E042362-3DF8-475A-9DF5-90D069EF70FF.jpeg
 
Hello, I have a qol request:

Please add the number of total and scanned bodies to the list of the current system.

The fss event:
"event":"FSSDiscoveryScan", "Progress":1.000000, "BodyCount":1, "NonBodyCount":0, "SystemName":"Col 173 Sector HK-Z b29-1", "SystemAddress":2887425074577 }

Completely agree! This is definitely something I want to have for when exploring too.

(Although the most recent updates have taken me out of the black and back to the bubble!)
 
Managed to get the top of my info-panel printed (bottom is still to be done. 14 hour print!). Screen looks great with Icarus loaded in.

I might be being stupid, but is there any way to interact with the terminal whilst you’re in-game (running it on the same machine as the game, on secondary hdmi display)? Maybe even bind joystick buttons to switch tabs etc?

View attachment 317058

Oh wow, that is so cool, thanks for sharing! Let me know if you have any feedback on how it could work better for a setup like this.

Hmm I'm not sure how best to handle interactions on another display; I've run both the game in Windowed mode and then ICARUS Terminal on another display but of course means focus is switched. Having an option to refocus the game client (if running) after interacting with ICARUS Terminal might be one way to solve for that.

Not sure how I could listen for keypress globally to allow keyboard driven control, might have to read up on the Windows APIs for that.
 
As for the vertical panels, there is a limit to how narrow the resolution can get before the UI gets cut off. Currently I'm running them at 720x1280, with the browser's zoom set to 150%, or 1080x1920 with browser at 200%. Those are the sweet spots for readability and UI visibility on a 7" scren, I think.
Oh! Hmm so it shouldn't cut off, at least not exactly, but it should toggle between Portrait and Landscape views (e.g. phones, tablets, rotated monitors, tall skinny windows, etc). Faffing with the browser zoom is a handy thing to do for some displays (super large / small) so good tip for folks there!

If it looks like it's doing something janky and cutting stuff off I'd love a screenshot to understand better (even if it's snapshot of screen from a phone!)

PS: I'm really happy to look at special behavior for small displays. Currently the smallest display I use ICARUS Terminal with is about 7" (an older Amazon Fire Tablet with Chrome, which is not super snappy but a good baseline) as well as my Pixel 3A Phone (which is old but works great, but I don't want to upgrade from because I like the size/features). Mostly I use a Chromebook which is quite a bit bigger/faster but annoyingly the current release of ChromeOS seems a little janky at rendering.
 
Oh! Hmm so it shouldn't cut off, at least not exactly, but it should toggle between Portrait and Landscape views (e.g. phones, tablets, rotated monitors, tall skinny windows, etc). Faffing with the browser zoom is a handy thing to do for some displays (super large / small) so good tip for folks there!

If it looks like it's doing something janky and cutting stuff off I'd love a screenshot to understand better (even if it's snapshot of screen from a phone!)

PS: I'm really happy to look at special behavior for small displays. Currently the smallest display I use ICARUS Terminal with is about 7" (an older Amazon Fire Tablet with Chrome, which is not super snappy but a good baseline) as well as my Pixel 3A Phone (which is old but works great, but I don't want to upgrade from because I like the size/features). Mostly I use a Chromebook which is quite a bit bigger/faster but annoyingly the current release of ChromeOS seems a little janky at rendering.
It’s pretty good on that 800x420 display I’m using but obviosuly everything’s needs to scroll etc.

I don’t think you could reasonably use it any smaller than 800xsomething resolution and it’s already a “bit” small on 4.5” physical size…

(Regarding your other points you may be right. I was hopeful there is someway of interacting via a joystick/game pad control, cos then I could build said joystick control but I have no idea how windows programming goes for HID events!)

One bit of immediate feedback tho might be for screens like navigation to have the most relevent stuff at the top. Eg where you are AND where you’re currently going. I found that’s the things I usually wanna know if I’m on the info screen. Current system, and if I’ve got a route planned, next system and how many jumps etc.

Not sure if that info IS actually displayed further down the screen, but I’d want that at the top if I could.

I probably will end up having to switch to a raspberrypi zero for this I think (when I can get one! All out of stock), cos I need interaction with the terminal. I accept my use-case is probably quite rare or even unique tho I imagine there will be a few others who have external displays and control boxes etc so I absolutely don’t expect you to do any recoding regarding input-whilst-unfocused.


If there isn’t a way of getting input directly, actually something that WOULD be amazing (and definitely possible) would be to bind keyboard buttons to various interface bits for the web view; that’s just some JavaScript - and would mean those like me using a control box could bind buttons to key input on a rPI or other device, a voilà, the buttons on my palm pad could change tabs etc (tho I can at least implement page up/down fairly easily I’m sure!)
 
One bit of immediate feedback tho might be for screens like navigation to have the most relevent stuff at the top. Eg where you are AND where you’re currently going. I found that’s the things I usually wanna know if I’m on the info screen. Current system, and if I’ve got a route planned, next system and how many jumps etc.

Oh same! I would love to have that in the header (when in the ship) and then when on the ground (SRV/on foot) maybe display other info (e.g. waypoint indicator).

Been thinking that might be a good place for warnings too (e.g. low on fuel, limpet controller but no limpets, before jumping into a Neutron / White Dwarf / Wanted System, etc).

If there isn’t a way of getting input directly, actually something that WOULD be amazing (and definitely possible) would be to bind keyboard buttons to various interface bits for the web view; that’s just some JavaScript - and would mean those like me using a control box could bind buttons to key input on a rPI or other device, a voilà, the buttons on my palm pad could change tabs etc (tho I can at least implement page up/down fairly easily I’m sure!)
Oh for sure!

That would be easy and I should really do that.

The prototype had full in-game style keyboard navigation with arrow keys + WSAD but I haven't done any keyboard navigation for it as is, although that constraint has informed all the design (another reason why it made sense to mimic the in-game panel UI).

I'll have a think about that.

I could use Function Keys for the Primary Navigation (Panels) and then numeric keys for the Secondary Navigation (with tab & shift tab / arrow keys for in-panel navigation).

It's a bit of extra work to implement custom key bindings so will probably start with some sensible defaults that would work regardless of keyboard layout. Happy to take suggestions as to what might work well if folks can see any issues with those options!
 
Having done some similar UI programming in the past, looking at the keybinds & keyboard stuff I’d honestly say “stick this on the roadmap” (at whatever priority level you can give it. I’d hope for “OMG right now” but I accept it’s your Funtime project and other demands are more processing from other users etc) but implement it customisable from the get go.

Don’t waste your time implementing it “fixed” now; do the full implementation when you can. Nothing is more dispiriting than having to go back over old code to implement the thing you should have done the first time (not to mention for users, seeing a feature they really want/need but because it’s the wrong key etc, they can’t use is more infuriating than no feature at all!)

Obviously, my use case means I couldn’t use it unless it’s customisable anyway cos I need joystick bind etc - but others will have similar issues.

I’d also avoid function keys and numpad. Lot of people don’t have a numpad anymore and F keys are often already in use by game/windows/other apps etc.

Implement a key grab function; bind said key to the “thing”. People can choose whatever they need etc.

I have looked into it briefly; apparently windows makes this fairly easy to do with global hooks. Tho maybe only do it for the web page - that would only need JavaScript etc. to listen for keyboard events.



Oh same! I would love to have that in the header (when in the ship) and then when on the ground (SRV/on foot) maybe display other info (e.g. waypoint indicator).

Been thinking that might be a good place for warnings too (e.g. low on fuel, limpet controller but no limpets, before jumping into a Neutron / White Dwarf / Wanted System, etc).


Oh for sure!

That would be easy and I should really do that.

The prototype had full in-game style keyboard navigation with arrow keys + WSAD but I haven't done any keyboard navigation for it as is, although that constraint has informed all the design (another reason why it made sense to mimic the in-game panel UI).

I'll have a think about that.

I could use Function Keys for the Primary Navigation (Panels) and then numeric keys for the Secondary Navigation (with tab & shift tab / arrow keys for in-panel navigation).

It's a bit of extra work to implement custom key bindings so will probably start with some sensible defaults that would work regardless of keyboard layout. Happy to take suggestions as to what might work well if folks can see any issues with those options!
done
 

Release Notes for 0.16.0

In replying to all the other posts, I almost forgot to post the release notes for the latest update I released over lunch!

I've had a bit of a break over the last month - the heat has been crushing! - but have returned to active development.

This update includes changes to the Ship Panel and the System Map.

Ship Panel​

  • Fixed issue with secondary navigation (on the left hand side) not highlighting correctly when focused on the first item in the list.
  • Split "Status" (aka Instrumentation) and "Modules" (aka Ship Internals) views into separate views. I intend to improve on both views, especially the Modules/Ship Internals view - to suggest Engineering options and give more information about module stats.
  • The Ship Status/Instrumentation panel now takes up the entire panel and auto-scales the UI, as well as being fluid and responding to different screen orientations and display ratios.
  • The Ship Instrumentation now includes absolute values for Cargo and Fuel, as well as still displaying progress bars for quick at-a-glance reading.
  • Toggle switches relocated to the top of the instrumentation (note: toggle switches are not yet interactive in release builds).
  • Minor changes to some text labels, including the text for the 'Hardpoints' toggle is now displayed as 'Hard Points'. The former is Technically Correct but the latter allows the indicator text to wrap better on some devices/resolutions and the style is in keeping with rest of the toggle switch indicators.
There are some minor kinks in the new Ship Instrumentation at some edge case display sizes / in some browsers, but overall it seems to be working well enough to release and iterate on. I'd love to do more with the Ship Panel, including showing ship schematics and hardpoint placement and would love feedback about it.

Navigation Panel​

  • Improved appearance of header on System Map view, simpler, less clutter and improved clarity of information.
  • Improved appearance and icons used in System Information pop up on the System Map. System scan progress will likely end up being displayed in here, and will be added to both List and Map views in future.
  • Fixes to the text that displayed for various system states.
  • Improved animation timing on System Map view and added subtle "swipe" effect to rendering of System Map. This also inadvertently impacted the tinting of the System Map background and has made it darker, but I like the result so left it in.

Other​

  • The behavior of the 'Copy' functionality (when you hover over text like a system, planet or station name, or material, commodity, etc. so you can copy it to the clipboard) has been improved. The notification message now clearly confirms exactly what text was copied. Improvements also allows the text in the UI and the text in the clipboard to differ slightly, so you can have text like "Alioth System" in the UI (which scans better) but "Alioth" is what gets copied to the clipboard (as that's more useful for copy/pasting).

Known Issues​

This is not an exhaustive list, just some things are currently bugging me.
  • Ship Cargo not updating in real time in some scenarios (should be listening for 'Cargo' events)
  • Various issues with Station/Port/Settlement/Megaship data being incorrect in some systems. This usually (but not always) stems from incorrect data in EDSM and am looking to resolve it by incorporating local data, which will also facilitate showing which bodies have been scanned with the FSS.
  • Objects that are orbiting null points in space are not very well handled in the Navigation view (they are rendered, but could be done better).
  • Ship Modules inspector doesn't have a lot of information (e.g. no text or base stats) for some modules) so isn't very useful in some cases.
  • Route Map view should clearly indicate up coming Neutron Stars / White Dwarf stars on the route (and not just say they are 'Fuel Stars', as that's a bit misleading) and could draw better attention when about to jump into a system that is not a fuel star.
 

Release Notes v0.16.1​

Minor improvements and bug fixes.

The issue with the Cargo count on the Ship Instrumentation not working was bugging me, so rolled out a fix for it, and threw in some other minor updates!

Ship Panel​

  • Fixed issue with Cargo count on Ship Instrumentation always displaying zero (even though progress bar would update correctly).
  • Fixed issue with occasional flicker / redrawing of Ship Instrumentation on initial render.

Navigation Panel​

  • Added system Population to System Information widget on System Map view.
  • Improved appearance of System Information widget. This is mostly a cosmetic change, but I think it looks more interesting (subjective).
  • Filtered out "Rescue Ships" from list of megaships included in Navigation panel views. These were almost all outdated and sometimes appeared more than once depending on how many times a megaship had previously appeared in a system and the data for them was still in EDSM. They should ultimately return in a future update (along with the option to view Fleet Carriers) in a more robust manner.
  • Improve animation timing of System Map view so that there is less delay and the animation duration is shorter so that the UI feels snappier.

Other​

  • Improved animation of list views throughout the app. This is both a change in appearance but also the mechanism for animation. It is significantly faster, looks better and scales so that animations work regardless of display size as effects are applied to all visible elements not just the first {N} items drawn on screen (something 4K monitors or portrait displays will appreciate); this also changes how animations are applied so reduces time-to-interactive for animated elements. The new animation also resembles the in-game style a bit more; although I have had to strike a balance and keep it short, simple and functional so that it works well on lower powered devices.
 
Thanks, restarting my computer seems to have fixed the issue, but for a while the tab wasn't loading at all.
Oh that's great, thanks for the update!

Hopefully it was just a glitch but if you (or anyone reading this) see something like that again please do let me know, especially if it is more than a one off.

I pushed out a small mostly cosmetic update today (v0.16.3) and there some changes to how things are rendered in the previous release too, so am keeping an eye out for any reports of issues with those changes.
 
Hi Flash, I have been using Icarus Terminal for a couple of weeks now, and its great! It is exactly what I have been looking for, something with a nice easily readable clean layout, that I can add to extra screens to show current system info and at least how many jumps I have in my route so your route page was a very nice bonus! Including the ease of throwing it on a tablet through the browser chefs kiss.

I am predominantly exploration focused and had a question around Geo and Bio count/existence on a body being displayed in the system list view icons like you have for Atmo, Volcanic etc. I'm assuming that you pull system info from EDSM and don't check the journal file for system/body info so this might not be possible as EDSM doesn't have that info, but if by chance you do check or can use info from the journal then the FSS Body Signals event contains the count for Bio and Geo signals on a body, obviously this is just a count and not the info (needs DSS) but that would make a huge difference to, at a quick glance see if there are any there and its a body of interest.

At risk of this post being too long... for my use case just displaying this as the events are generated when you FSS and not retained for display on another visit would be suitable as once your moved on from the system you have either got the Geo/Bio or your not bothered this prevents need to have DB or store anything. I know this likely wouldn't suit everyone and it relies on the player uploading to EDSM while they scan undiscovered systems for them to show up in Icarus but wanted to throw these thoughts your way with no expectation, but that it might spark an idea that you could incorporate. :)


Anyway... Great work on this, I love it and keep developing as you see fit!
 
Just installed the latest version 0.16.4 it's stalling while trying to load. Been over 20 minutes now

Weird! Hmm nothing in the way data has loaded as changed in months and not seeing any issues on systems here.

There is no diagnostic system in the UI currently so it's hard to see what might be causing that.

If shutting down/restarting doesn't help I can only suggest maybe checking out any antivirus software. The releases are all signed with a digital signature, but sometimes things like Windows Defender can be aggressive and stop applications from working / accessing files.
 
Yeah I have checked the firewall and the permissions are as I originally set them. Just tried again and it's the same stops at 125.23kb and just hangs indefinitely not had any previous issues with it prior to this.
 
Back
Top Bottom