DunaColonist

Update : 0.8.0 Officially compatible with KPS2 version 0.2.1 (ie For Science!). So no more warning from SpaceDock, CKAN, or the mod loader the game.

Love this mod. It is part of my 'must' list. I am sure you already have plenty of work but it would be great to have additional com stations on Kerbin. Even with the colonies update, it would be useful because adding colonies to Kerbin won't be possible easily / early in game. I use a kestionnay sat as the closest relay to increase access to KSC. But it is hard to really keep the sat on track after long warps due to interplanitary travels. Having the com range of the KSC evolves with com technologies would be great too. It would make sense, it would avoid that tiny sat outperforms KSC and it would let players focus on a smaller number of critical relays.

Simply can't live without it. Simple mod but litteraly a must. I need to check in game but => would it make sense to have EC usage ? => are there dead lamps in the outside of the various command pods ?

Hi @Fizzlebop Smith, Well... Life... Short term : I will update soon(tm) the mod to the current version of the game. Longer term : I need first to analyse what is valuable with regard to current state of the game, future state of the game and scopes of other mods.

Update : 0.7.0 Compatible KPS2 version 0.1.4.0 (ie patch 4).

Update : 0.6.0 Fix weird transparency / ordering of spatial shapes. And cleanup visual design of HUD. HUD may partially disappear if too small when the craft is too far away from camera.

@DfA-DoM Thanks for the feedback ! Great! This KSP1 mod is a target that I would like to reach with the version 2. It is nice to have identified an user. I will welcome your feedback on the implementation once I start working on it. Ok. I will keep that in mind. I will likely add user configuration once the design is more stable. Great proposal. Nothing more to say. I should be able to add a hotkey to enable/disable display. And maybe more hotkeys for various actions later. Regarding enabling / disabling the hud display : Is there a specific key that would make sense for you ? And that would not be in conflict with other uses ? Do you know any KSP2 mod having hotkeys ? Do they provide a user configuration for the key ?

Ah and the current weird transparency is not a feature based on the colors but more like a bug / limitations of the drawing library provided by KSP2. Currently, the last line/cone that is drawn is on top of the previous ones even if does not make sense from a 3D point of view... So it's far from something the end user can configure. I will need to look into in order to understand the exact limitations and what would be the best tradeoff.

@DfA-DoM If you had those parameters/sliders what would you change and how ? I agree that the current display has to be improved. But the way I see it, it is a bit more complex than only fine tuning size and transparency. Instead of asking each user to fix the design on their own, I would rather improve the experience out of the box. That being said, all feedback are useful. Understanding what you would change and why, would help the next design.

Done. (But to be fair, it is mostly due to the work of CKAN folks.) https://github.com/KSP-CKAN/KSP2-CKAN-meta/tree/main/HeadUpDisplay I haven't tried to install it with CKAN but if anyone has any issue using CKAN, please post them. And I will see what I can do about them.

Update: 0.5.0 First version of craft attitude control ! Define horizontal and vertical angles and move your hands out of the keyboard. Great help for launch of rocket and their gravity turn. I will update image in order to show the gui... but later.

@DfA-DoM I will look into it! I haven't used CKAN for KSP2 yet. But it is yet another page / file to update...

Update : 0.4.0 The mod is compatible with patch 2. Prototype : display veritical and horizontal angles within the configuration popup. Upgrade space warp : need >= 1.1.1

Update : 0.3.1 => 0.3.2 Improvement: Fix bug of orbit path not being displayed. Transform the workaround into a fix. Thanks to @munix No need to enable / disabled the mod manually.

Short answer Juno did a good design job. Long answer The main idea In order to increase focus during a dynamic activity, a common pattern is to to display the critical information where the gaze/action is. And that's the basic concept for a Head Up Display (HUD). HMD is similar in that aspect. It is far from being specific to Juno. Does KSP2 has already a real HUD ? It could be argued that what is available in vanilla KSP2 is not really a HUD but a set of instruments. Indeed, if you want to look at the them, you need to forget your vessel for a brief lapse of time. One example could be checking the navball and then crashing into an object that was not visible with the navball but only in direct view while looking at the vessel. So the main goal of this mod is this : don't move your eyes around, keep watching your vessel / target. The critical information will be provided to you. What Juno did well They have a minimalist design with no superfluous information virtual navball with 2 circles 1 horizontal white circle 1 vertical white circle direction indicators green prograde indicator white current heading indicator blue target indicator horizontal and vertical graduation scales visible on hover Only the critical information is displayed. If something is displayed, that's because it's useful else it is not shown. So I have tried different variations with more lines, more colors but it often ends up being too complex to read and confusing. What are the main differences ? The main difference right now is the definition of the vessel heading : for Juno, the virtual navball allows to define the craft attitude. The mod does not allow it currently. But that's probably a feature that I will add soon (ie one day). The second difference is the design. The graduation scales is currently always displayed. But they add maybe too much noise. And as a consequence, they should probably be removed or displayed only on hover (see Juno minimalist design). Having different colors for the 2 circles of the navball may be confusing and not bring enough information. I am not quite sure for this point. And so on about design.

That's the main idea but the hard part is indeed how to do it. I initially assumed that I was only modifying the flight view but that's clearly not the case. I will need to find out how to differentiate between the two views somehow.

I have published a workaround with the version 0.3.1 : disabling the mod now allows to display the orbit path (eg orbits). That's indeed far from perfect but it allows to play while keeping the mod installed. And the user need right now to enable it in flight but disable while looking at the map. I will work on a real solution as soon as possible.

Thanks for the feedback! Regarding the toogle there is two ways Main game menu => mods => Open Configuration Manager => HUD In flight => APP.BAR => far right button => HUD But it doesn't seem to fix the issue which I can reproduce with the 0.3.0 version. Removing the mod does also solve the issue on my side. I will look into it.

Update : 0.2.0 => 0.3.0 Improvement: Displayed directions will now directly depend on the selected speed mode : surface vs orbit vs target. Changelog : https://spacedock.info/mod/3334/HUD : Head Up Display#changelog ----- On the left of the navball when speed mode is "surface" => prograde is surface prograde when speed mode is "orbit" => prograde is orbit prograde when speed mode is "target" => prograde is target prograde And normal and radial are only displayed when the speed mode is orbit. In all cases, target and maneuver directions are displayed if they are defined.

Update : 0.1.0 => 0.2.0 Biggest improvement: the HUD is no more hidden by weird transparent stuff (with the exception of the engine plume) More details available in changelog : https://spacedock.info/mod/3334/HUD : Head Up Display#changelog

HUD : Head Up Display Compatibility KPS2 v0.2.1.0 (ie ForScience !) SpaceWarp 1.4.0+ Virtual Navball virtual navball with 2 circles horizontal circle with north and south indicators vertical circle with sky/ground colors and prograde oriented dynamic direction indicators up indicator prograde, normal, radial indicators with standard KSP2 colors target and manœuvre indicators Displayed directions depend on the selected speed mode : surface vs orbit vs target. Craft Attitude control define horizontal angle define vertical angle Configuration enable/disable in KSP2 main menu via standard mod configuration In KSP2 main menu => mods => Open Configuration Manager => HUD enable/disable in flight via standard app bar In flight => APP.BAR => far right button => HUD Next features ? This mod is feature complete for 1.0.0 but code and UIneed polishing. Version 2.0.0 will include a virtual navaball around the player and not the craft. Revival of https://spacedock.info/mod/1574/NavHud Renewed#info ! Known limitation Other mods drawing shapes in flight may have issues. Do you know of any ? Installation Easy automatic way : use CKAN Harder manual way Follow https://spacedock.info/mod/3277/Space Warp + BepInEx Unzip and extract hud mod in BepInEx in the game folder [KSP_ROOT]/BepInEx/plugins/hud Licence: MIT Current Mod Version: 0.8.0 SpaceDock : https://spacedock.info/mod/3334/HUD : Head Up Display

I don't know the details about how Discord works but here is a working link to the discord server for those who are looking for it : https://discord.com/invite/hHW5gpHxfE

I am trying to figure out that too. But the link you provided as a part of the answer. I was able to setup the tools and build myplugin / mod. Were you blocked by something in particular ? And then if you want to get inspired by a existing mod, its source can be browsed, copied and modified...

You are free to declare any dependencies. Regarding merging different mods, you need first to validate with each mod author that you are allowed to do so. So the first option is easier to start with. For an end-user without any mods, and maybe no mod manager, a modpack is probably easier to use. But as soon as the end-user has already at least one mod already installed, working with dependencies is better because conflicts can be detected and sometimes solved. So If I were in your place, I would start with dependencies. With CKAN, it is well managed. Furthermore, you may create 'soft' dependencies ie recommendations.

Yeah, that's what I understood from @RealKerbal3x : it would be hard to extract but even if might still technically be possible that would be not be in compliance with the EULA. Of course. I wasn't planning on reusing the Anomy model (now, I know the right term, thanks) but using it as a reference. Thank you for the precision.