LeroyJenkins

@djungelorm - Been reading up on the kRPC documentation (krpc.github.io/krpc/index.html), specifically the SpaceCenter APIs. Before i get into the full control console hardware design, I want to make a GUI interface representation first to be a stepping stone as I learn this stuff. I'll start with receiving telemetry from KSP2 and displaying it before creating buttons to send commands to KSP2. Kind of like the Telemetry Health and Status Displays we use in Satellite Mission Control Centers (See image at bottom of post). I have a few questions about the APIs capabilities. I'll be referencing C++, since that is what I know 1) I see how I can get the orbital parameters of a vessel by calling Vessel::orbit() and its sub functions. Does this return the parameter values for the active_vessel() only? I ask, cause I'd like to be able to display all the current vessels (in flight) orbital parameters at once. Would I have to cycle through all the vessels in std::vector<Vessel>vessels(), by setting each one in the list as the active vessel (using set_active_vessel(Vessel Value)), getting its orbit parameter and then repeating for each vessel in the array? 2) Are Vessel::Orbit() telemetry only available while KSP2 is in Flight View? Or can I continue to poll the data while in VAB, Map and Tracking Station Views? If there are current missions flying, while I am building a new rocket, I'd like the external Telemetry GUI to keep updating. 3) Under Alarms API. The current alarms are based on time, time offsets, or time to Pe, Ap or Planned Maneuver Node Points. I'd like to see if I can create Alarms for other things. For example: If a spacecraft (s/c 1) is on a long flight mission, and I am working on another spacecraft (s/c 2), I'd like to be alerted if s/c 1's EC goes below 10% of capacity. That way I don't have to keep swapping active views and checking on s/c 1's health and status, while working on s/c 2. If this not in the scope of kRPC2, I could make alarms as part of the external GUI, but then I'd have to make a DB and inference engine to track the each new current value to the set alarm limits. When we fly spacecraft we usually have four limits the system tracks for telemetry. Red High, Yellow High, Yellow Low and Red Low. Also I'd have to create a persistence and hysteresis check to ensure that if the the value is toggling back and forth over a limit, it doesn't consistently repeat the alarm every sample. Thanks for the help. This information well help me plan the architecture. This is a very basic Telemetry screen (old school style). The newer ones are more graphic and color coded.

@ShadowDev Been using this a bit and wanted to provide some feedback and suggestions: (Disclaimer, I am NOT a fully versed programmer, never created a mod, nor coded in C#, so please take my suggestions with a kind heart). 1) At Launch pad, after selecting the "Countdown" button in the apps menu it pops up and immediately vanishes. I'd suggest it stays up, and only goes away after the user toggles the Countdown App button or with launch countdown is complete. -GUILayout.BeginVertical(); if (GUI.Button(new Rect(windowRect.width - 23, 6, 18, 18), "<b>x</b>", new GUIStyle(GUI.skin.button) { fontSize = 10, })) { showUI = false; <--- Change that to true? } 2) The number displayed doesn't need 13 decimal places (see image). A typical count down format T- HH:mm:SS.s. Though here HH;mm doesn't hold value. You could set it to T-00:13.5 for esthetics. Keeping at SS.s, will help with the window resizing every time the last decimal place is zero. Timer = float.Parse(Timer.ToString().Remove(4)); <-- This line of code may be trying to do remove all the decimals. Based on reading up on Remove(), this should be removing everything after the fourth digit, so SS.ss? 3) The voice countdown to the numerical countdown is off by 1 sec. The voice says the numbers (in kerbinese) when the whole number is new, eg 2.9 is 'two', 1.9 is 'one' This should be shifted to 2.0 is 'two', and 1.0, is "one". I couldn't find in the code where this is set. It could be how you are offsetting the StartTimer variable from Game UT. StartTimer = GameManager.Instance.Game.ViewController.universalTime + 13.53; <-- change this to 12.63? I'd go into the src and try to do this myself, but I don't want to mess up the git repo by not knowing exactly how to do things. I hope this helps.

The consumables menu in the upper right hand corner of the fight view does not convey the full status of Electrical Charge (and MP, but that'll be a different post). It only provide how much power is stored. It does not show rate of discharge or charge. One has to go into the parts manager and look at each individual Solar panel or other Electrical generators to see the rate of Charge/Discharge. A total sum of discharge/charge rate should be on the summary status display. Then one should be able to click on the EC status bar and get an expanded detailed list of all the electrical sources and consumers and their individual rates. This can help quickly figure out where power issues lie within the vessel's design. A Status and Sequential Drill Down Menu Structure Layout something like: There is a discussion about Electrical Units (U and EC/s) and what it really should be for a storage (battery) and generation (Solar Panel, Fuel Cell), here: I agree it should be Watts and Watt/sec or Watt-hr, depending on capacity scales.

KSP2 Version Info: 0.1.1.0.21572 OS: Windows 11 (10.0.22621) 64bit CPU: AMD Ryzen 9 5950X 16-Core Processor (32) RAM: 130992 GPU: NVIDIA GeForce RTX 3090 (24340MB) SM: 50 (Direct3D 11.0 [level 11.1]) RT Formats: ARGB32, Depth, ARGBHalf, Shadowmap, RGB565, ARGB4444, ARGB1555, Default, ARGB2101010, DefaultHDR, ARGB64, ARGBFloat, RGFloat, RGHalf, RFloat, RHalf, R8, ARGBInt, RGInt, RInt, BGRA32, RGB111110Float, RG32, RGBAUShort, RG16, BGRA10101010_XR, BGR101010_XR, R16 Description of the bug. Expected Behavior - When pressing the Solar Panel Action Button on upper left menu, all solar panels on vessel are deployed or retracted (if able to be retracted). Observed Behavior - The action button does not do anything. Does not deploy panels or change color state when pressed. Steps to Replicate - Built a vessel, attached deployable solar panels to it, launch and while in orbit, press the action button. Fixes / Workarounds (if known..) - Select the Solar Panel part directly or via the parts manager and deploy.

Ah, good to know @TiggerTailz Thanks.

@djungelorm and @Kerbart, Thank you both for that info. I am looking to build a control panel to replace most of the keyboard mappings and trying to figure out the best way to get telemetry from KSP2 and Command into KSP2. This helps.

Will the ability to Enable/Disable Installed Mods from the ModList Manager at the Main Menu Screen, be added to SpaceWarp/BepInEx? It would be helpful to have for Debugging issues in game. To help determine if it is an issue with the Mod or the Base Game. Instead of having to delete/move the plugin folder in the install drive. I know that some Mod Devs include, mod configuration menu to enable/disable some options of their mod. But I am looking for a enable/disable of the whole mod. Any thoughts on this? Thanks

@ShadowDev Thank you for this! I suggested this to the KSP2 Devs.

how does this compare/relate to KSPSerialIO?

After speaking to the Dev of the Scale UI mod, this is most likely an issue with that mod, and not with KSP2 itself. - Not sure how to remove this bug report.

KSP2 Version Info: 0.1.1.0.21572 OS: Windows 11 (10.0.22621) 64bit CPU: AMD Ryzen 9 5950X 16-Core Processor (32) RAM: 130992 GPU: NVIDIA GeForce RTX 3090 (24340MB) SM: 50 (Direct3D 11.0 [level 11.1]) RT Formats: ARGB32, Depth, ARGBHalf, Shadowmap, RGB565, ARGB4444, ARGB1555, Default, ARGB2101010, DefaultHDR, ARGB64, ARGBFloat, RGFloat, RGHalf, RFloat, RHalf, R8, ARGBInt, RGInt, RInt, BGRA32, RGB111110Float, RG32, RGBAUShort, RG16, BGRA10101010_XR, BGR101010_XR, R16 Description of the bug. Expected Behavior - When in the Tracking Station View, and one selects an item (vessel or debris) from the left hand menu, the Information panel opens, and provide 2-4 colored buttons a the top (Focus, Control, Destroy, ??) Observed Behavior - the Destroy and 4th button are clipped by the horizontal divider bar. (see image, upper right hand corner of image, you can barely make out the red destroy button) UPDATE: Restarted the game, and at the main menu screen, I reset the Scale UI mod back to 100%, via main game settings, entered the game, and the clipped button was still there in the tracking station view. While in the game I went to main game settings, and changes the UI scale there, and the Destroy button became visible. I could now set any scale and the Destroy button remained visible. Steps to Replicate - Select an item from the tracking station (vessel preferably) to open its information panel. See if its clipped. Might need the Scale UI mod and set to 60%. My screen resolution is 3840x2160 - 4K, on a 65" monitor. Fixes / Workarounds (if known..) - might be related to Scale UI mod. I have it set at 60%. Will try 100% and see if it gets un-clipped. A list of ALL mods. If the list is long, please consider using a spoiler window. Other Notes / Screenshots / Log Files (if possible..)

KSP2 Version Info: 0.1.1.0.21572 OS: Windows 11 (10.0.22621) 64bit CPU: AMD Ryzen 9 5950X 16-Core Processor (32) RAM: 130992 GPU: NVIDIA GeForce RTX 3090 (24340MB) SM: 50 (Direct3D 11.0 [level 11.1]) RT Formats: ARGB32, Depth, ARGBHalf, Shadowmap, RGB565, ARGB4444, ARGB1555, Default, ARGB2101010, DefaultHDR, ARGB64, ARGBFloat, RGFloat, RGHalf, RFloat, RHalf, R8, ARGBInt, RGInt, RInt, BGRA32, RGB111110Float, RG32, RGBAUShort, RG16, BGRA10101010_XR, BGR101010_XR, R16 Description of the bug. Expected Behavior - When looking down through a deployed parachute, that has a gap, you'd want to see what is directly below the parachute (ground, water, capsule, kerbin) Observed Behavior - When over water the view shows ground and parachute shadow, instead of water (see image below). Even over land, its not showing the correct land that is directly underneath. Steps to Replicate - Deploy a parachute 1000m from ground, view from top down. Look through the gaps in the parachute. I did this with a non-radial chute. Not sure if the same thing happens on all types of parachutes. Fixes / Workarounds (if known..) - unknown A list of ALL mods. If the list is long, please consider using a spoiler window. Other Notes / Screenshots / Log Files (if possible..)

KSP2 Version Info: 0.1.1.0.21572 OS: Windows 11 (10.0.22621) 64bit CPU: AMD Ryzen 9 5950X 16-Core Processor (32) RAM: 130992 GPU: NVIDIA GeForce RTX 3090 (24340MB) SM: 50 (Direct3D 11.0 [level 11.1]) RT Formats: ARGB32, Depth, ARGBHalf, Shadowmap, RGB565, ARGB4444, ARGB1555, Default, ARGB2101010, DefaultHDR, ARGB64, ARGBFloat, RGFloat, RGHalf, RFloat, RHalf, R8, ARGBInt, RGInt, RInt, BGRA32, RGB111110Float, RG32, RGBAUShort, RG16, BGRA10101010_XR, BGR101010_XR, R16 Description of the bug. Expected Behavior - Though a glow on the horizon as you approach the terminator of the night into day is to be expected. The Solar flare should only be seen once Kerbol has risen over the crest of the surface horizon, from orbit. Observed Behavior - The solar flare is being project through the celestial body, while Kerbol is still well below the horizon Steps to Replicate - Occurred while in Low Orbit over Minmus. Screen capture included. It was just before Kerbol crested but I could see the sun flare through the ground of Minmus well before this screenshot was taken. Fixes / Workarounds (if known..) - Don't look directly at Kerbol? A list of ALL mods. If the list is long, please consider using a spoiler window. Other Notes / Screenshots / Log Files (if possible..)

@Socraticat True, though sometimes I want to say.....

I can see how that would be annoying. I am not experiencing that issue, with either stock rockets or my own built. Have you submitted your system specs/logs and files a bug report?

@Maria Sirona - Here, with my chicken! Let's do this! Can @Jacob Kerman rush in too?

Though I see a huge improvement in the dV burn timer UI, there are still some accuracy issues. Its stable/accurate initially but over long and multiple burns/stages (To Minimus and back) it was getting less accurate. i am collecting info before I submit a bug report. The slider bar reduces only based on 100% thrust. it does not slow down if you throttle down. I need to double check, but the timer also only counted down at a rate to a constant 100% thrust. So if you throttle down during the burn the time remaining and slider bar are off. KSP1 did adjust this, if I remember correctly. The Scale UI mod is helpful for this. I have it set at 60% and I wouldn't go any smaller. I am on a 65" 4k monitor. One improvement the burn time UI i would request is the that total dV burn has a number count down. KSP1 had this an was helpful. Example at start of a 1000 m/s dV it would show 1000/1000 m/s. The bottom would be static as it is now, but top number would reduce as you burned/throttled. I'll put this in the suggestion thread shortly.

I want to share some thoughts on how this game is coming together and the wide variety of reactions. I do acknowledge that the EA 0.1.0.0 release was very rough, but hey its EA. Yes for some the price was a bit high for EA quality, though as it was stated, the price will go up once its out of EA. So you are buying at a discount overall. If that's not your cup of soup, no worries. That's your personal choice, but it does not have be everyone's. Yes 0.1.1.0 took longer than some other games first patches, but look how much the DEVs did address, many of which were direct feedback from the player community. Which is the point of EA, and what the DEVs wanted. Those that gave constructive feedback, were definitely listened to. Yeah not everything was addressed, can't expect that either. Its still in EA and the DEVs said that they are already working on Patch 2 even before the first one got released today. Today's patch is a major improvement and not the last one we'll see, I am sure. Instead of getting frustrated, why not help the community and the DEVs with constructive input/feedback. This not only makes it a better game for you, but for everyone. Plus you can take pride that your inputs became part of a game that 1,000s will play. This kind of player/developer interaction is a new and exciting exchange that was unheard of for a long time. Trust me, when Pong or Atari Space Invaders crashed, we had know no one to chat with, provide feedback to or see an update/fix. The game was as IS. Best we could do is power cycle or blow on the cartridge. Take advantage of this unique and cool interaction rather than negatively impacting it. If your rocket blew up or crashed all of a sudden, you should not have a full on emotional melt down. The game is centered around failure, look at all the promo videos for both KSP1 and KSP2, the Kerbal's are constantly having accidents. We are supposed to push the limits of design and see what blows up and what doesn't, that's part of the fun of the game. OK, bug induced failures is annoying. But see it as a way to be more creative in your designs to get around the bugs. If it's a bug, report it constructively and move on. Just like Bram Stoker said "We learn from Failure, not Success." Avail yourself of this opportunity. Rocket Science and Orbit Mechanics are not easy in real life, why should it be so here? Just think about all the rocket launch failures around the world since the 1940's to get to where we are now. I know, I've worked in the Aerospace industry for a long time. Ive seen first hand rocket failures, learned from that and made the next a success. I would of killed for such a game as this, even in EA state, when I was in undergrad studies. It would of helped me understand difficult concepts that were explained on 2D white boards, not 3D patch conic diagrams. And this is a real life simulation of rocketry. If you don't believe me, watch the video below and you'll see many launch failures that I swear I've seen in my own playing of KSP1 and KSP2. So, go blow something up, have fun, learn from the failure, make it better for yourself and everyone. We can do much greater things together than griping alone. I've seen some amazing designs in KSP1 and already in KSP2, and all from individuals. Image what we can do collectively once Colonies and Multiplayer comes. Let's help IG get there so we can enjoy the end result together. Life is about the journey not the destination.

@Nate Simpson Outstanding update! Worth the wait. Huge list of things fixed in the release notes. Please extend a big congratulations to the dev team, take tomorrow off and enjoy the weekend. Heck take them out for Happy Hour. Well deserved! Everyone seems excited to get back into KSP2 and see the magic. I know I am. ACES!!! To Infinity and Beyond!

LOL.... I haven't played 1.1 yet, but the release notes were long. so "THUMP" is very apropos. They came through and dropped a lot of fixes. Eager to play.

Once the patch is released today, where does one find the Patch Release Notes? ie. where will they be posted?

@LameLefty Thank you. Of course the one place I didn't think to look. Doh!. I'm looking forward to the Patch tomorrow, been building and saving lots of big spacecraft just waiting to launch (to many parts dropped frame rate to 1). I just hope that the patch release tomorrow isn't.....

@Strawberry Where on Discord IG did you find that? I am looking all over General and Announcements and I can find that thread from Dakota.

Ah, sorry about that. Here's an invite https://discord.gg/vzXtBwE8