Mitokandria

I am seeing some odd tech tree placement in Tetrix and Quatrix. This might be because of my mod list, but I've kept it pretty lean when it comes to part mods. Quatrix: -TAC-LS 2.5m Life Support Supplies parts are listed under Heavy Rocketry -Double C Seismic Accelerometer is listed twice (Advanced Rocketry and Advanced Electronics) -Kerbal Planetary Base Systems K&K X1000 Storage parts are listed under Advanced Rocketry -Kerbal Planetary Base Systems K&K Docking Port is listed under Unmanned Tech Tetrix: -TAC-LS 2.5m Life Support Supplies parts are listed under Heavy Rocketry -Double C Seismic Accelerometer is listed under Advanced Rocketry player.log https://1drv.ms/u/s!AtJ0gZSLiapDh8ROZ00GUi-ejswQiQ?e=AAPpze MMPatch.log https://1drv.ms/u/s!AtJ0gZSLiapDh8RPzlT4y-BgUPMIDw?e=q29zzA (I am aware of the AnglecanProgression / contract configuration errors and will post those in the other thread.)

Those are the same things I'm waiting for as well! I look forward to those coming so I can really play.

I think the auto-fairing feature may be best left to modders down the line as it was in KSP-1 or as a feature to be added after 1.0. I think it's more important to replicate the ease-of-use of KSP1's fairing system than a mod-added feature from KSP1. I mentioned it earlier, but it may have gotten lost in the scuffle. I think both the KSP2 and KSP1 method can exist within the current system without needing it to be "optional" per se. The current system works great when precision is needed, but a faster less precise method would be ideal for most cases. Allowing for both the height adjustment arrow and width adjustment arrow to be toggled and tied to the mouse movement would satisfy both the need for speed and, when required, precision.

I would be ok with the current system IF there was an option for auto/procedural. It's true that the current system allows for much finer control, but the beauty of the KSP1 method was speed and ease-of-use. I think the procedural method would hit on what made KSP1 fairings feel "good". It would also be very helpful if the drag arrows moved faster. KSP2 fairings can already detect the bounding boxes of parts. The big problem I see is that KSP2 fairings likely weren't coded to allow simultaneously manipulating the length AND width. That might require nearly rebuilding the code for drawing the fairings...unless... It becomes more of a hybrid method. Instead of KSP2's click&drag method a hybrid method would make the arrows a toggle. Increase the draw speed as well would really help.

Ah! Thank you. I wasn't sure where the conflict was.

Getting some errors with B9PartSwitch. Full Log: https://1drv.ms/u/s!AtJ0gZSLiapDhZwdul22jlM3DNWcNQ?e=cXDQly [edit: Sorry if this part is not from KerbalAtomics. it was the first result in google.]

This is especially common with Bethesda games when it comes to GPUs. The only time specific hardware isn't a possible cause is with Macs and other iOS products. Say what you want about Apple products, but the reason their stuff works so reliably is because their software only needs to function for a few very specific hardware configurations. Me. I've pretty much resigned to just waiting till next year to really be able to enjoy the game. I personally prefer smaller patches with 3 or 4 fixes than large sweeping patches, but they've likely chosen their current path for reasons I'm not privvy to. No point in complaining any further if all it's going to do is make progress slower.

Oh that's easy I can do that easy-peasy since the info is already there in another format. I'll try to put that together this weekend. I also prefer the subway map style of DeltaV maps.

I think that might be Kronometer. I found that JNSQ has an Offset cfg utilizing Kronometer and JNSQ Rescale is supposed to change the offset back to 6hr/day, but it isn't recognized by RemoteTech. I commented out the offset time, but that didn't seem to change RemoteTech reading a 24-hour time. I'll probably have to reach out to JNSQ team and see if I can get some guidance on that. Since default JNSQ is a 12-hour day I'm thinking it's also possible something else is modifying the timescale. But I've derailed your thread more than I feel comfortable with so I'll move it over to JNSQ. P.S. I did learn how to open, create/edit, and recompile KSP mods~ I bow to you all in acknowledgment of how much sweat, knowledge, and expertise in astrophysics, thermodynamics, and aerodynamics goes into these mods. Thank you muchly.

Sorry for the delayed reply. Spent a good bit looking through the code and I think that's exactly what I'm looking for! I found the segment I need to change, just gotta figure out how to compile it. Thanks!

Hi! How does RSS get Remote Tech to recognize a 24 hour day? I don't see anything in the Remote Tech patch and Remote Tech doesn't seem to have a setting for it. I want to figure out how to get remote tech to recognize a 24 or 12 hour day with JNSQ. Edit: I did ask the Remote Tech team, but they directed me to see how RSS does it.

Oh thank goodness. I did go to the bug forums first to confirm, but on mobile I couldn't see the upvote/downvote buttons and thought the worst. Glad to hear they are staying!

Aww. That was my favourite part of the big forum update! I would cruise through occasionally and upvote issues i was also experiencing. I helped to see which issues were more or less common to run into.

For process' sake I added it to the github tracker. If you find the time and are able to get something working I'm happy to test if you need a tester. *excitedly going off to play KSP2* <--did not think I'd be able to say that until 2025.

I got a probe to the Mun and everything acted as expected. There is still orbital decay, but it seems like the trajectory fix may have also resolved one of the sources of orbital decay. Edit: Except for EC usage. That's still borked, but not game breaking or enjoyment ending.

Wooo! Thank you for the hotfixes!!

Totes understand. Just happy to get a reply and a note that you did look at the issue. I've upgraded my PC considerably recently so I'll have to give it another try and see if it still happens.

Oh I wasn't originally looking for help with it as it's hardly game breaking. I was more curious than anything else. I will gladly provide more information though. I should be more specific anyway. Basically it would appear that Part Commander does not hook into the Flight Computer from remote tech. Thinking about it more I'm not sure if it ever did work with the flight computer. Example of an expected result w/ remote tech: Launch craft to Mun. Open Flight Computer. Add a manual delay of 2 hours; a time when there will be no network connection. Right-Click a science experiment and click "deploy". Note that the Flight Computer now lists that the science experiment will deploy in 2 hours. Example above, but with Part Commander: Launch craft to Mun. Open Flight Computer. Add a manual delay of 2 hours; a time when there will be no network connection. Open Part Commander and select a science experiment. Click "Deploy". Science experiment ignores delay timer and immediately deploys as in vanilla.

I only just learned about it yesterday after checking out the links in your signature! I wish i had found it before getting so invested in my current game...although....maaaaybe starting over isnt SO bad..

Honestly I've always had TWP installed, but found it a little intimidating. I finally learned how the porkchop selection works in MechJeb last year so I'll give it a proper go at using it. Thanks!

I am only just realizing that if I'm playing in Science mode that means I can't unlock the nodes...oops!

Oh. I hadn't considered that. Trial and Error with some occasional trig it is then.

And it's still better than the KSP 2 version. Back on topic. Does Part Commander Continued not play nice with Remote Tech's signal delay? It seems sometimes it works and sometimes it doesn't. I have a very well packed probe [insert 'you can fit so much in this thing' meme] and having to finagle the camera to get in and click things for timed executions is rough.

I've been using the stock scale as a base instead of using the 1/4 scale. I am finding it is a slight overestimation of about 100-500m/s (LKO) depending on ascent losses. Not the most accurate, but sufficient in assisting with planning and design. So far I've used it to plan one-way trips from launchpad to minmus/mun and it's been fairly accurate. It might be a bit less accurate once I start going beyond Kerbin, but we'll see.

Want to say I appreciate the change to the ignition failure message. I played with ullage turned off for so long because I didn't understand what it meant until I watched a youtuber play.