Poppa Wheelie

That did it! Thanks!

I'm walking down this train of thought (everything in quotes is actually me, paraphrasing - not actual quotes): I'm hearing that "we apply physics at each joint", and that "the physics that we apply to each joint is pretty accurate" There seems to be a fairly universal agreement that there should be no wobble in certain parts of the stack. Maybe that's "no wobble per stage", or "no wobble per stack of same size per stage", or maybe it's something else. One of the short-term options the team is looking at would be to reduce the wobbly impact of physics applied to some of the joints. But I understood Trigger's concern with this would be that this would actually incur a performance hit (that would not be scalable to larger vehicles) because the implementation of such a solution (which I'll call "auto-strut-like") would look like more joints to the physics engine (more connections at each joint looking like more joints, requiring more work from the physics engine). Thus, the problem with this is that it would apply even more physics to each joint. I think what I've said so far is pretty accurate. If so, then I would like to suggest a possible solution that should actually reduce the physics load, should be scalable to much larger vessels, and so could be a potential long-term solution: determine joint-by-joint which joints will not have physics applied to them at all. In effect, this would convert some sets of parts into "blocks" of parts that, as far as the physics engine was concerned, would each appear to be a single part. This could take one of several forms. I'm sure there are probably many more ways to implement this, but here are a few thoughts: When loading a vehicle at launch, apply a "no physics" tag to each applicable joint When loading a vehicle at launch, "auto-weld" each applicable set of parts into a single part I love this game! Press on, team!

I cannot capture button 12 (bottom row, second from the right). I'm using the same process to define the button delegate functions, and to assign those delegate functions. My delegate function is called correctly when I press each of the other buttons. But pressing button 12 behaves as if I had pressed that button from the top-level MFD page. Files: Complete ks file (2 small applicable screenshots are below): https://1drv.ms/u/s!AijA8HUkaaOEmQPtOJwnpJmoEqd2?e=RuuLdI Video showing all buttons working except button 12 (1min4sec): https://youtu.be/AA2meCzG1v0 KSP log: https://1drv.ms/u/s!AijA8HUkaaOEmQE6MCiyj9WaJoPY?e=jpdDv1 Player log: https://1drv.ms/u/s!AijA8HUkaaOEmQKKTd9wjCHncTq5?e=FeWVRw Here's a screenshot of the button 12 delegate function definition: Here's a screenshot of the button 12 delegate assignment:

Woot!

How do I change the text colors of a print command string? Such as the "This is a test with color that changes back." example seen in the screenshot at the top of page 1? Nevermind: I think I've got it. Either: Include specific RBG into the text string, as follows: “[#rrggbb]” Example: “[#4286f4]” Include a pre-defined color into the text string, as follows: “{COLOR}” Known pre-defined colors: “{COLOR}” The default green of text in the terminal “{CUSTOM1}”, same as “[#4286f4]” A light blue “{CUSTOM2}”, same as “[#efce39]” A light orange “{CUSTOM3}”, same as “[#9d39ef]” Magenta purple “{CUSTOM4}”, same as “[#291fe2]” Very dark blue that’s difficult to see on the black background I figured this out from this post from the developer:

Update: Yes, upgrading from the kOSPropMonitor version on CKAN (1.5.1) to the version available on SpaceDock (1.7.2) is required to get past this error, and to get buttons working. I find the script itself kind of wonky to work with. It's difficult to figure out how to move between screens, how to provide input to the various screens, when to use buttons and when to use keyboard, etc. But, I've learned a lot by looking through the code. I'll probably take some parts of this as starting points and write some scripts of my own.

Yeah, this code definitely does not work "out of the box". Instead of toggling the CLOBBERBUILTINS option, I went into the code and made a few edits to my local copy, such as: Changing "set throttle" to "lock throttle", and making sure there was a corresponding "unlock throttle" Changing one instance of "set steering" to "lock steering", and making sure there was a corresponding "unlock steering" Setting "sas on" after "unlock steering" in maneuver functions Commenting out one instance of "ag3 off" Now I no longer get the CLOBBERBUILTINS error, but I get the following: This looks very similar to the error in Frostiken's note from last year (4 Sep 22). I didn't get the "SETDELEGATE not found on object BUTTONS", but perhaps that text scrolled off the top. I first got this error for button 3. I noticed that this was the first "buttons:setdelegate" that the code attempts to perform, so I commented it out - result, the error moved on to the very next buttons:setdelegate attempt (for button 4 instead of button 3). I also see that 610yesnolovely said on 5 Sep 22 that I need to be using kOSProp Monitor v 1.7.2., and that the CKAN version is outdated. I checked CKAN, and sure enough I'm using 1.5.1. So, questions: Do I need to upgrade kOSPropMonitor to 1.7.2? Will these button delegations not work otherwise? Is there an updated version of the BakerOS? Both CKAN and SpaceDock provide what is titled as v 2.2.0, but the comment at the very top says this is v2.1.0. Is there a more current version somewhere else?

I copied the save file to my Ships > Script directory (volume 0), where I have some other scripts that I have written. I named it baker220.ks. I then did "run baker220.", and got this: Archive:/baker220 line:401 col:21 not allowed to set a name that will clobber or hide the SYSTEM_lock called 'throttle'. See kOS documentation for CLOBBERBUILTINS for more information. Here is line 401: set throttle to 1. Do I need to do some kind of setup to deal with this before I run baker220?

18Watt has approved polar (vs equatorial) circumnavigations before, including my Gilly mission. I don't think equatorial is a requirement or an expectation at all.

Looks like the text that should follow this is missing.

Can you give some detail on what we're looking at here? I think I see some fairings and clipping at the front, but can't really tell what's going on. Two blue stripes up front - is that a kerbal helmet? More fairings at the back? Maybe you're doing some things with the fairings to reduce drag? Any details you feel like providing would be great.

OK, thanks!

Anyone? Anyone? Bueller?

I read through the documentation, and see that it is possible to query the status of each Action Group (AG). Is it also possible to query which Action Set (AS) is currently in use? Or to set the desired AS? Also, is it possible to search and find specific IVA Prop labels, and then to set them? Here's what I envision: Find ActionGroupsProp Set ActionSet to 4 Set ActionGroupsProp:ActionsLabel to "AS4 Actions" Set ActionGroupsProp:AG1Label to "MyLabel1" Set ActionGroupsProp:AG2Label to "Another" Set ActionGroupsProp:AG3Label to "3rdLabel" etc

Confirmed, this worked.

Details after "Empty path name is not legal." Details after the "Object reference not set to an instance of an object." Details after selecting "Quit" @HebaruSan, the forum software merged the comment below with my previous post. Wanted to make sure you saw it: I restarted, and at the instance selection window I selected an instance, checked "Set as default", and continued. Same errors. No hurry, I'll wait for the hotfix. Thanks for looking into it, and thanks for CKAN!

I love CKAN! But it's not working right now. I updated to the new version. Now I can't start a KSP1 game. Here's what happens: CKAN v1.33.0 opens to the "Loading registry..." spinning green progress bar screen, with the "Manage Game Instances" window on top of that When I select an existing instance, I'm get the "Check for updates" on start-up window. I answer, "Yes, check for updates". "Loading registry" window is still spinning The main CKAN window now shows what looks like my instance main screen (I see the selected instance listed at the very top of the window). "Add available updates" is not greyed out, as if I have updates. Nothing is listed in the mod list, although this instance does have mods. And, at this point, the following error window pops up: Unhandled exception has occurred in your application. If you click Continue, the application will ignore this error and attempt to continue. If you click Quit, the application will close immediately. Empty path name is not legal. If I select "Continue", the error window disappears, and I'm left with the main CKAN window for the selected instance, with no mods listed If I select "Add available updates", I get this error: Unhandled exception has occurred in your application. If you click Continue, the application will ignore this error and attempt to continue. If you click Quit, the application will close immediately. Object reference not set to an instance of an object I didn't attempt to select "Launch Game" Please let me know if there are logs somewhere, or any other details, that I need to provide for you.

@610yesnolovely, thanks for the quick response. It seems to me that MJ and the IVA MFD don't run the same code to execute the burn. If there was someone still maintaining this IVA, or this MFD prop, I could ask them to look into this. I would be willing to do this, if there was a way to do so from within the IVA. This IVA does not have the prop I've seen in some other IVAs with a multi-switch for throttle thrust limits. And I don't see a method in either of the 2 included MFDs. So I would have to leave IVA to set an engine thrust limit, then return to IVA. Any thoughts on how to do thrust limiting from within IVA without a dedicated thrust-limiting prop? Yes, it has RCS. I'll try with RCS on to see if that helps. And I feel pretty good about their balance. I've manually (not in IVA) done the intercept and rendezvous with this station, and done the docking using RCS. Thanks! I wanted a small, single-engine single-seat SSTO that I could fly to and from an LKO station, while also providing excellent visibility, and with no need to exit IVA (for Map View, or to set thrust limits, or for any other reason). If the functions in this MFD worked as expected, I would be set. So I think these are some of my options: Keep looking to see if I can find someone to "fix" the functions of this MFD (I've also found that it doesn't create the same "Match target velocity at closest approach" node as MechJeb). I see that, as you suggested, MOARdV has stepped back from supporting MAS. Any other thoughts? If I'm confident in the node created within IVA, I can always execute that node manually. I can also do some things manually without a node, such as matching target velocity I could stay in IVA, but F2 to bring up MechJeb functions and use them when needed (like to create better nodes, or to do an auto-execution) I could drop out of IVA for things like thrust limiting or to use Map View, then return to IVA. Thanks again!

When I create a node in the DE+MAS IVA, and then execute that node using the “AUTO” execution function within the IVA, the execution behavior is significantly (detrimentally) different from the execution behavior when executing an identical node using MechJeb’s Rendezvous Planner, “Execute Next Node” function. Is there a different way I should be using these tools to get identical results as MechJeb? If not, can this be addressed and fixed? I’m using the DE+MAS IVA. Reviva is the only mod I’ve found so far which provides the MFD described below, and I’ve only been able to use this IVA, with this MFD, when I have Reviva loaded. This is why I’m reporting it here. When I load individual IVA mods, without Reviva, I never get this DE+MAS IVA. Can you help me find the root cause of the problem, and if I need to report this to a different mod, I’ll do that. All of the IVA functionality discussed here is found within this MFD: MAS ALCOR MFD2 Powered by MOARdV’s Avionics Systems V1.3.7.30145 Here’s what I’m comparing, which you can see in the following video (4m19s): Load a save made shortly after achieving LKO Go to IVA On the MFD, select a space station also in LKO as target On the MFD, create a Hohmann Transfer maneuver node to the target space station Time warp closer to burn time On the MFD, select the “AUTO” function to automatically execute the node Watch the node execution go crazy It overshoots the dV, then chases the maneuver icon around the navball while in low thrust for awhile Reload the same save Within IVA select target, create Hohmann Transfer node, time warp closer to node On the MFD, select the “AUTO” function to automatically execute the node Exit IVA, time warp up a little closer Watch the node execution from 3rd person (outside the IVA) The crazy behavior is easier to see from this perspective Reload the same save again Staying in 3rd person (and Map View), select the target, create the node (MJ Rendezvous Planner, “Intercept with Hohmann transfer”), and time warp Staying in 3rd person, select MJ Rendezvous Planner, “Execute next node”, then time warp up Watch the node execution done perfectly I “think” I’ve correctly calculated the real clock times at which some events in the video occur. I’ve noted those times in the video, thinking the times may help finding the right spot in the log files. Log files: KSP: https://1drv.ms/u/s!AijA8HUkaaOEmGYhP0_sCHBuSm-j?e=cvRHRY Player: https://1drv.ms/u/s!AijA8HUkaaOEmGcAO8kvPUioNcFd?e=1S44TM Video (4m19s): https://youtu.be/g0I9u0wmzdE

This is what I want - name priorities. For example: In KSP1 I might have a mothership, with a lander, all docked to a station. I might give the station naming priority 20, the mothership naming priority 10, and the lander naming priority 5. When the lander docks with the mothership, the combination will have the mothership's name When the mothership docks with the station, the combination will have the station's name When anything undocks, we'll see correct names for the pieces

I'm interested in how you got the functionality to set radio frequencies and then have the navigation cues on the navball to guide you to a runway landing

Very nice! Two questions: How did you raise and lower the seat? How did you get the landing guidance? Does each of these requires an additional mod?

20230626: My Octo-Girder Octagonal Docking Connector docking ports will not dock. I see a very similar report from 2019, linked below. Is this the same issue? Is there a workaround? 20230627: I have partially solved this, using initial orientations of Prograde / Retrograde or Radial In / Radial Out, but it still doesn't work for initial orientation of Normal / Anti-Normal. See "Another Update" below for details, screenshots, and new logs. Two screenshots from me. "screws facing out" on both the upper and lower connectors, which I'm pretty sure is correct. 2019 report, which looks very much the same issue as this. I tried going very slowly 0.1m/s approach speed, with docking attraction force set to 5%, as suggested in this post. I also tried approaching with the orange orientation arrow of the docking alignment indicator pointing each of the 4 directions (12, 3, 6, and 9 o'clock). No luck. Update: I tried a much smaller test rig. I still can't get it to work in space, but got it to work on the runway. Logs: KSP: https://1drv.ms/u/s!AijA8HUkaaOEmFKYUecyZLrqTZxQ?e=AJ9oeL Player: https://1drv.ms/u/s!AijA8HUkaaOEmFPCx2tUbKyn1GXP?e=m09QO1 Another update (20230627): I got the test rig above to work, as follows: SAS to Prograde SAS to Stability Assist Undock Use RCS to back one pod away from the other Use RCS to approach Keep approach speed to 0.4ms This worked for initial orientations of Prograde/Retrograde and Radial In/Radial Out. I tried again with Normal/Anti-Normal, using the same approach as described, but still no luck. Approaches faster than 0.4ms may work for the successful orientations, but I didn't try any other speeds. Screenshots using the Radial In / Radial Out initial orientation: Today's Logs: KSP: https://1drv.ms/u/s!AijA8HUkaaOEmFb7tVhblAAYWhXS?e=WeTK3P Player: https://1drv.ms/u/s!AijA8HUkaaOEmFUGDlQKgV1_m8yL?e=PpNJhZ

Adding the -popupwindow option does work, and is the solution to your problem. The Borderless game option is what has not worked properly.

Saving and reloading is what breaks it. The labels are good before a save, but after a save and reload the labels are gone. Thanks for looking into this, and I completely understand that real life is the priority. No emergency here.