Snoman314

I think I've narrowed it down to Tweakscale. Which so many mods are dependant on going without is not really an option. If anyone else is having the same problem, my new approach is to not worry about re-using parts (because it's no longer possible), and change the KCT settings to increase the build factor. That way I still get benefits from re-using parts I've used before, I just have to rely on the increased production speed, rather than being able to re-use anything.

Does anyone know what sort of reasons might cause this? This happens as soon as I enter the editor after clicking edit on a recovered craft. This is after I tried uninstalling Scrapyard - with Scrapyard the Edited percentage is always zero. I build the craft, roll to launchpad, recover to VAB, wait for recovery, click edit, and immediately get the above - I have to rebuild the whole vessel from almost scratch if I want to refuel it.

Yeah all seems to be fine here now as well. Love your work!

As always, love your work. I feel really fortunate that you're still so reliable at fixing bugs and updating this tool that I love, after all this time. That said, I think you introduced another bug.. It looks like you fixed the out of memory error for my Minmus encounter scenario, but now it's not detecting the SOI change. I created another similar situation to check: In-game I've definitely got a Minmus encounter: And yet when I import that state to MA, I fly straight past (coast set to Periapsis): The same thing happens with the mission file I originally uploaded. I'm 99% sure that should have been a Minmus encounter as well.

Another bug report. I decided to branch out and use the Optimal Two Burn Orbit Change tool, and it's not sending values to the manoeuvre node uploader: Both burn 1 & 2 come up all zeroes in the upload screen. Zeroes are in fact what KSP receives. I've tried with both the 2021 and 2022 pr6 versions, same thing.

Back to reporting errors. Whenever I try to set a coast to periapsis of Minmus at the moment, the Mission Architect has an Out of Memory error: https://imgur.com/doKJWf1 Mission file causing the error: https://drive.google.com/file/d/1d2-ljODWscWlpxRf4HZOGO9LywzkSIhy/view?usp=sharing As you can see from the screenshot, this is on the 2022 pre-release, but it's doing the same thing for me on the 2021 version.

Can do: CPU: Intel Core i9-9900K RAM: 32 GB

Yep, that seems to have fixed it

OK that makes sense, and I instinctively tried to do that right at the start. That's not what I was seeing though. I consistently had no response when right clicking on list entries. I think I reproduced the bug though... Once. After creating a new Mission Plan, to try and do what you said, I found it was all working as intended. But then when I accidentally click 'Insert Sequential Event' and then just close the popup window without interacting with it, all events seem to become bugged. So basically, I think I broke it... But then I tried it again and can't reproduce But it's working now, so that's nice.

OK... Yeah I can't figure out how to do that, sorry. Do I right click on one of the events in the list, the whitespace in the event list box, or somewhere else? I'm right clicking all over and nothing's coming up. Yay! Thanks

OK, I have MATLAB Runtime 9.10 installed, which is apparently == R2021a. Which is apparently the correct one from the OP? But nothing works, so I dunno? (exaggerating).

OK, So I went from my last post to trying to use the LVD instead. I can't seem to edit sequential events after I first set them. Subsequent double-clicks do nothing. I'm going to go check my Matlab runtime version...

I'm back for another play through, and trying to plan an insertion of a commsat into formation. The following mission file consistently crashes in the mission architect when I try to optimise, giving error message 'Unrecognized field name "propTypeEnum".' This occurs with all three algorithms selected. It seems to be related to the other spacecraft constraint. Mission file: https://drive.google.com/file/d/1d2-ljODWscWlpxRf4HZOGO9LywzkSIhy/view?usp=sharing

Same here. Spectre only, and getting the same log spam.

Thanks for taking the time to give me such a thorough reply. Steps 1-4 are pretty much what I already do, with my current 'step 5' being to upload a manoeuvre node to execute. From what you're saying, it comes down to just coming up with a direction to point the vessel, burning for a set time, and hoping for the best. I'll just have to put up with any steering and velocity errors and do a later mid-course correction or something like that. OK, I still don't have the first clue how to use the X/Y/Z mode. Given that step one for, say, a trans-munar injection burn would be to create a manoeuvre node prograde with approx 840m/s, roughly 90 degrees behind the Mun's current position, and then let the optimiser figure out where to go from there - where do I start if using X/Y/Z? How do I input a burn that's in the ballpark, so that the optimiser has a place to start?

A slight side-track, so a separate post, but this last conversation got me thinking about how everyone else executes manoeuvre nodes. The reason I want to be able to follow the in-game node pointer, is that I can access that vector from inside kOS, and I've written a manoeuvre node execution program that can get extremely high burn accuracy, by adjusting the pointing direction to follow the node vector to compensate for any errors during the burn, and throttling down to a stop with sub mm per second precision. It's so good that I have to be careful using the Rendezvous Maneuver Sequencer (sic), because I'll usually end up impacting the target vessel near the end of the second burn if I don't do something to prevent it. BUT!, that's for high TWR ratio vessels! Now that I'm playing around with high ISP engines with low thrust, my old methods don't work so well. Reading some of @Arrowstar's comments above, it would be easy enough to use kOS to point the craft at a given attitude or whatever, and burn for a given amount of time, sure. But without the feedback I get from the game in regards to dV remaining, and the direction of the remaining dV vector changing due to small errors, I will not have the same accuracy as I'm used to. So, how do you guys do it?

Good to know, thanks! Ah OK, that all makes sense, thanks. OK, I've dabbled with the LVD, so I at least know what you're talking about when you say 'steering law', but I've yet to figure that one out fully. I'll assume for now your reply there will make more sense as I figure the LVD out more. In the meantime, using the Mission Architect, does this mean that if I want to be able to continue following the manoeuvre node in-game (for a finite duration burn), I need to set the mission up using inertial vector mode? Can you give me a hint as to where the X/Y/Z components point relative to Prograde? Not knowing what those values mean is the reason I've never tried that mode. Thanks again for your help

I'm also finally getting into Ion engines. I have questions about the manoeuvre execution assistant (MEA), as well as finite duration DV manoeuvres in the Mission Architect. The questions are around when the burn will be executed for the finite duration burns, and where the rocket is pointed for both. For time, am I correct in assuming that the for finite duration manoeuvre's, the idea is that the burn will start at the end of the previous event (e.g. coast to a specific TA etc)? (As opposed to impulsive dV Manoeuvre's, where I'm used to starting the burn before the node's time, so that 1/2 dV is before, and 1/2 after the node time). For the MEA, is the idea here to just aid in executing/timing impulsively calculated dV Manoeuvre's? It looks like the idea is to point at the manoeuvre node in-game as well? (instead of say, sticking to prograde). If that's the case, I can continue to use my manoeuvre node timing code I wrote for kOS, and not worry about this tool. But the finite duration manoeuvres in the Mission Architect confuse me no end. How are they supposed to be executed? I tried pointing at the node, and starting the burn and t = 0, and that did not work, lol.

I found someone interested in letting me play mission control with the MCC RTS, for them as they play KSP. Doing a search of this thread, it looks like we'll need to forward ports 8282 and 8295. Anything else?

Yeah I'm having the same issue. The wheels turn only when they're retracted. It's like there's a variable or something that's out of sync with whether the wheels are deployed or not.

Now for another one unfortunately: I tried to set up the same mission in the LVD. (I can set initial state now, so that's working ) I didn't get as far as optimising this one however. I had two main problems Putting in coast events to True Anomalies (to coast to apoapsis or periapsis), it didn't always propagate to where I'd expect. i.e. if I set the Termination condition to a TA of 0, the event would end immediately at apoapsis. 90 degrees and 45 degrees both got the graphic to display periapsis. When I set two body propagation, I get this: Mission file: https://drive.google.com/open?id=1wA1JKlEH4mB0ktQwRr1apYdFEpOb10TD

Thanks again for all your work on this. I think I've found a bug though. I keep getting this error message when trying to optimise in the Mission Architect: Mission file: https://drive.google.com/open?id=1d2-ljODWscWlpxRf4HZOGO9LywzkSIhy Log file: https://drive.google.com/open?id=136mMM_Dxa8itown92urP4s-UbsLqvAvZ I've tried turning off Parallelisation, restarting KSP TOT completely, and changing optimisation algorithm. Same results every time.

OK, here's the .mat file: https://drive.google.com/file/d/1d2-ljODWscWlpxRf4HZOGO9LywzkSIhy/view?usp=sharing This was made in pre-release9, if it matters.

It's literally just: Import initial state -> add coast to ascending or descending node -> errors. I'll fire it back up and upload shortly.

OK I got an additional out of memory error on pre-release 7. Next up pre-release 6. That's awesome, I look forward to start learning how to use it. While you're squashing bugs... Pre-release 6 is the latest version I can find that has a working Mission Architect. See posts above about the orbit propagation erroring out.