Discussion ICARUS Terminal (Pre-Release)

I found a small issue with the bars in the ship and engineering tabs:
The bar colors are not consistent when viewing in different browsers?

I mainly use FireFox (95.0.2) where the bars are blue and white:
1641233654846.png
1641234416318.png

in Edge (96.0.1054.62) and Safari (iPad 15.2) the bars are orange:
1641233630604.png


Also would you consider not flashing the text when there are no pips?
I'm an explorer and 99,9% of time never have pips at weapons.
It is very distracting to have this continually flashing (maybe just turn white or red to stand out?).
 
I found a small issue with the bars in the ship and engineering tabs:
The bar colors are not consistent when viewing in different browsers?

I mainly use FireFox (95.0.2) where the bars are blue and white:
View attachment 284183View attachment 284184
in Edge (96.0.1054.62) and Safari (iPad 15.2) the bars are orange:
View attachment 284182

Thanks again for including screenshots - always very helpful.

I'm aware of the Firefox progress bar issue, It's straightforward to address, so happy to add Firefox styling support for that.

Sadly - given the rendering and use of effects is a bit more advanced than on a typical web page - there are some cosmetic issues with Firefox that I can't do much about, such tables render slightly differently, the DPI / font rendering is not quite the same, the gamma can differ and the SVG handling isn't as advanced as in Chrome. This last point is also an issue some WebKit engines, like Amazon Fire tablets, which don't texture mapping on the planets, so I have explicit handling to detect that and use solid color fills and gradients instead. In Firefox, and interestingly in Safari, the system map objects can look a little washed out; it could be that contrast filter isn't getting applied but the other effects seem to be applied just fine so maybe it just has something like a different gamma point.

Technically it should be possible to come up with workarounds for some of issues to bring the rendering closer, but probably not work the effort - it's serviceable and it's probably enough to let folks know it should work in Firefox, but it's likely to look better in Chrome/Chromium/Edge (even compared to Safari or other WebKit browsers).

If I come back to doing per-planet type styling for bodies at some point - which is partially implemented but not yet enabled (there are a lot of factors that impact appearance, so it's a decent amount of work) then I might look at system map styling again and see if there are any quick fixes for filters that would even things out.

Also would you consider not flashing the text when there are no pips?
I'm an explorer and 99,9% of time never have pips at weapons.
It is very distracting to have this continually flashing (maybe just turn white or red to stand out?).

I did that as a nudge to remind me as I would forget to reset pips sometimes, but yeah I find it a bit annoying too as sometimes it's intentional and the flashing is distracting. I'll maybe just change the text to be muted instead of flashing.
 
Thanks for your extensive explanation.
I have not seen any other odd behaviour on the pages, but I have not compared everything extensivly between different browsers.
If I find something I’ll check against my other browsers.
 
Update v0.2.20/v0.2.21 is out now!

It includes what is hopefully a fix for the issue that @Slegnor described,
It has indeed, it now detects my journals and displays all the relevant data.

One thing I have noticed, when you ctrl-scroll to scale the data everything scales together, both UI and data, however the bodies on the Navigation page don't scale at all, is this planned to be added in the future?
 
It has indeed, it now detects my journals and displays all the relevant data.

Oh that's great news, thanks for confirming!

One thing I have noticed, when you ctrl-scroll to scale the data everything scales together, both UI and data, however the bodies on the Navigation page don't scale at all, is this planned to be added in the future?

Ultimately I would like to revisit that and plot all bodies in a system on the same map and have it behave more like the in game system map (e.g. full zooming of the entire map) and it's been built with that in mind (the maps for each star in a body can be composited together and are all drawn to the same scale for a given system).

The current maps do scale with the UI, but they are designed to "scale to width" to avoid them scrolling horizontally, as that surfaces other challenges.

I'll still be making some improvements to the existing view (e.g. adding visible representations for stars) but reworking it to behave more like the in game map is probably something I'll put off till after v1.0, due to the work involved. I did actually have a go at that and functionality was nicer, but it highlighted some other work on the backend that needed to be done to make it work well.
 
Last edited:
Hi, Just found this and it looks great. I have a triple screen setup for Elite and just added a forth screen over the top for Inara and EDDB etc but felt i lost the immersion with websites sat over my space ship :) This tool looks so much better and really feels part of the game. I saw some hints on other tabs in development, CMDR and COMMS, are you planning on a trading one too? ie to help find commodities?

Looking fwd to future updates.
 
Hi, Just found this and it looks great. I have a triple screen setup for Elite and just added a forth screen over the top for Inara and EDDB etc but felt i lost the immersion with websites sat over my space ship :) This tool looks so much better and really feels part of the game. I saw some hints on other tabs in development, CMDR and COMMS, are you planning on a trading one too? ie to help find commodities?

Looking fwd to future updates.

Thanks for the feedback and glad you like it! :)

Earlier versions did have a placeholder for a Trade tab, I still want to add that but I think it it might take a decent chunk of work and so going to focus on modules and engineering (and continue to improve navigation) for now, as the engineering stuff dovetails nicely with the ship modules work.

The Trade panel will need to leverage APIs am not currently using and so is slightly different. I think the UI might also be a bit trickier to get right - i.e. enough options to be useful while still being quick and easy to to use. Like engineering, Trade will have it's own panel but ALSO be integrated into other panels (e.g. Ship inventory, Navigation) based on your ship cargo hold size, current inventory, current credit balance, etc.

I think it isn't too far off and hope to start on some trade features next month.
 
Release Notes for v0.2.23 (out now!)

Engineering Panel

  • Added navigation item for Xeno Materials (Thargoid/Guardian)
  • Added list of all Engineering Blueprints with grades, required materials for each grade, and your current stock
  • All Materials views (Raw, Encoded, Manufactured, Xeno) display all known materials (even if you don't have any)
  • New and improved icons

As with other panels, the Engineering panel is very much a work in progress and it currently has limited interactivity.

Navigation Panel

  • Added information about material composition of planet surfaces - useful for material gathering
  • Performance improvements (animations, cache usage)
  • Misc minor cosmetic improvements (e.g. text heading sizes)

Other Improvements

  • Main menu on mobile displays now displays abbreviated panel names
  • Added timestamp to Cargo view of Ship panel, displayed when not on board (i.e. when manifest may be outdated)
  • Misc minor cosmetic improvements (tables, inspectors, loaders)
  • Misc UI, UX and performance improvements for mobile and tablet displays





Next up, I'm planning on improving the Engineering panel further.

As well as exposing more detail (and a better UI for them) I want to make it possible to find Engineering upgrades and display options alongside modules in the Ship panel as well as by searching from the Engineering panel and to make it possible to pin and track Blueprints and individual Materials.

As a bit of a diversion for me I might look at adding some stats, including credit balance and current location and limpet count (if you have a limpet module on board) into the title bar.

I'm also interested in adding both the current route and 'nearby interesting systems' item to the Navigation panel.
 
I've added some build steps to the repo and README for the folks who are on Linux but are not developers, so it's easier to build:

You can also easily build a native standalone binary for Windows, Mac and Linux with:
  • npm install
  • npm run build:standalone
This will create a binary for the platform you are running in dist/icarus-terminal-service.

For usage information run icarus-terminal-service with --help.

This will build whatever is in the main branch (which might be a work in progress build!).

I've also added the ability to pass command line options to the service and display useful output on the terminal to make it more user friendly.

I don't plan on doing extra work to include cross platform builds along side the Windows installer in official releases but this should make it much easier for folks to run on non-Windows platforms, or for anyone who wants to build the standalone executable for Windows without an installer.

It doesn't include an auto-update checker or a native UI and so doesn't support native UI features (like borderless / always on top), you need to connect via a web browser. Additionally, the binary is not not optimized for size so is quite a bit larger than the packaged release.
 
i don't know exactly how privileges work in windows, but the default seems to be that processes launched by processes that have admin privileges, inherit the privileges themselves.

when the terminal is launched by the installer after updating, it is running with admin privileges.

while not terribly pressing, a process should run with the minimum amount of permissions it needs to perform its core functionality.

also, for people who use VR, they can't interact with the terminal from within VR overlays, because SteamVR and the overlays often don't run with admin privileges, and non-admin processes can't use SendInput() on admin processes.

this is especially sad, because the large font and icon size of the terminal makes it perfect for use in VR. I LOVE ICARUS TERMINAL FOR THAT REASON. THANK YOU O7

i know i can just manually re-launch the terminal, but i'd appreciate if i didn't have to.

also i like how quick and convenient the updater is.


TLDR: please make the terminal de-elevate and drop its admin privileges when launched from the updater, if possible
 
i don't know exactly how privileges work in windows, but the default seems to be that processes launched by processes that have admin privileges, inherit the privileges themselves.

That is, sadly, is how Microsoft designed UAC.

Processes with lower integrity levels can't interact with those with higher integrity levels. While elevation by spawning a new process is straightforward (and ICARUS Terminal does that when you opt to install an update) processes spawned from elevated processes keep that elevated integrity and there is no way to request a process is spawned with lower integrity. It's really bizarre that there isn't a simple way to run another process with lower integrity.

If it causes enough problems I can simply remove the option to run after installing, or refactor the installer to install as the local user, so that it never runs with elevated access. As the latter is extra work (and has pros/cons) the easiest thing for me to do is automatically remove the option to run after install or update.

There are a couple of ways to work around the underlying issue (including one approach using Windows internals - or I could use a manifest and/or signature) but they are all time and/or money and as it's not really where I want to spend either, so the easiest option is likely to be what wins out.

this is especially sad, because the large font and icon size of the terminal makes it perfect for use in VR. I LOVE ICARUS TERMINAL FOR THAT REASON. THANK YOU O7

As a tip, you can also scale the UI using the CTRL key and mouse wheel.

TLDR: please make the terminal de-elevate and drop its admin privileges when launched from the updater, if possible

I suggest folks using VR close the app and relaunch it after an install or update. As this impacts <2% of users it's probably the least worst option.

If it's a big enough of a trip hazard for VR users I can just remove the option to have it run from the installer so folks don't get confused by it not working after installing/updating.
 
It's really bizarre that there isn't a simple way to run another process with lower integrity.
i was hoping that windows would allow simple passing of a parameter to the syscall that spawns the new process to make the child process not run with privileges..

Any development invested on this issue that is more complicated than that would be a waste of your time.

I suggest folks using VR close the app and relaunch it after an install or update. As this impacts <2% of users it's probably the least worst option.
not pursuing this absolutely tiny issue further and just having users like me relaunch manually is the best option.
 
i was hoping that windows would allow simple passing of a parameter to the syscall that spawns the new process to make the child process not run with privileges..

You would think! I've look at about 5 ways of doing it and all had weird side effects or required a bunch of extra work. Super annoying.

Any development invested on this issue that is more complicated than that would be a waste of your time.

not pursuing this absolutely tiny issue further and just having users like me relaunch manually is the best option.

I'll see if I can detect the current elevation level and warn in the launcher if running with elevated and suggest to users they stop/start, so it doesn't catch folks out.
 
TLDR: please make the terminal de-elevate and drop its admin privileges when launched from the updater, if possible

In an unexpected twist, I thought about this last night and over lunch tried out a different approach for one of the known ways to hack around this, using a commonly used but unintended feature of the Microsoft File Explorer (explorer.exe) to relaunch the process as the current user when it's run from the installer. I'd previously tried this approach but without success, but I was able to make it work in this case by also modifying how the background service and new terminal windows are invoked.

This impacted a few touch points in the app. I think I've tested those scenarios sufficiently that this change won't cause problems, but if folks do have issues please do let me know. There are some edge case caveats to the approach I've used for this but I don't think they are likely to be an issue in this context (they are more likely to manifest on enterprise installations).

The v0.2.24 update is able to be installed in the usual way (e.g. via the new release prompt). To keep things simple I haven't included any other changes in the release.
 
Oh that's great news, thanks for confirming!



Ultimately I would like to revisit that and plot all bodies in a system on the same map and have it behave more like the in game system map (e.g. full zooming of the entire map) and it's been built with that in mind (the maps for each star in a body can be composited together and are all drawn to the same scale for a given system).

The current maps do scale with the UI, but they are designed to "scale to width" to avoid them scrolling horizontally, as that surfaces other challenges.

I'll still be making some improvements to the existing view (e.g. adding visible representations for stars) but reworking it to behave more like the in game map is probably something I'll put off till after v1.0, due to the work involved. I did actually have a go at that and functionality was nicer, but it highlighted some other work on the backend that needed to be done to make it work well.
Just on the scaling issue, it isn't ideal when the system contains a single body, like a lone gas giant.
The attached image is with the UI scaled to the smallest possible (tiny text) and the body doesn't fit on the screen (at 1080p)

View attachment 1642510241399.png
 
Just on the scaling issue, it isn't ideal when the system contains a single body, like a lone gas giant.
The attached image is with the UI scaled to the smallest possible (tiny text) and the body doesn't fit on the screen (at 1080p)

View attachment 286679

Good timing! I was just looking at this issue while adding the stars to the navigation map (as icons indicating type of star next to the name of each star, not to scale) and this will be improved in the next release, along with some other improvements (to both system map and engineering, I hope).

There is a bit of compromise and an art to this, given the vast differences in scale, but systems with only 2-3 orbiting bodies will no longer render massively. There are still issues on small displays when there are lots of bodies around a star, but I probably won't get round to do anything about that for a while as a bit more complicated to resolve (as hinted at in that post).

Additionally, decreasing the text size actually has a weird consequence of increasing the size of bodies, as system maps scale to fill available space and when the text is smaller there is more space, so the bodies get bigger!
 
Last edited:
I found it very useful. The interface is really prettier than the game's. I can plan my journeys without opening the game. Good work. Thanks everyone.

Thanks! I use it to help me out when I'm exploring or pottering around Colonia too, and I'm really excited about coming features to make viewing information about systems in the currently plotted route, the next hop and other nearby locations much easier.
 
Back
Top Bottom