Waifu Art Thou Romeo

I mean that if I use "keep transform" when I reparent some component, the component stays in the same location visually. But when I export the .mu file, the component is in a very different spot. And not even all components would stay the same visually; some messed up immediately. For some reason that I don't understand, they would always end up (visually) with the transformations from the property window relative to the global origin, but when I reimport them, they would be relative to the parent's origin, still using the transformation it got relative to the global origin. So if it needed to be 1m down from the parent's origin and 3m down from the global origin, it would end up 3m down from the parent's origin. And the .blend file wouldn't show me that. It could look fine in the .blend, but when I exported the .mu (to actually use in-game) it would be all messed up It's probably something I'm doing wrong, but I'm too new at this to be able to differentiate my human error from a bug

EDIT: It's not solved, but I've finally figured out what's happening. I don't think it has anything to do with KSP and is just a Blender issue. For reasons I haven't yet figured out, it's not adjusting the translations to be relative to the new parent. I have no idea why that's happening or why I have to reload to see if it happened. I am brand new to modelling and Blender, so this might have a very obvious answer, but googling has not helped so far. I am using taniwha's Blender (2.83+) .mu import/export addon and Blender 2.83 I am working on some models someone else created for wheels, and I am trying to format the parent/child relationships in the model to look more like the stock wheels. However, when I reparent using "keep transform" the transforms are not preserved. Initially, they appear to be preserved (the model looks exactly the same as before reparenting), but when I export the model and re-import it, the model looks as though I reparented without "keep transform". If it helps, this is the model I'm working on. I am creating an empty at the part origin, making that empty a child of the part, and then making the bay doors children of that empty. Again, it appears to work until export. Is this an issue anyone already knows about and are there any solutions for it? If more information is needed, I am happy to provide it, but I don't know what else will be needed since, again, I am brand new to this. P.S. I have seen that "keep transform" does not work with skew transformations, but I don't think deformation of any kind is occurring with these models, and that does not appear to be the problem. EDIT: So far, the only clue I've found is that I can get the same effect as the error by manually rotating the object around the root into the position/rotation I want and then selecting "clear parent inverse". This puts it back into the same wrong position as just reparenting

Excellent |m|

Do you mean "should" as in "ought to" or "I have reason to expect it will"?

I'm not exactly sure how to phrase this question, but I'm going to try my best. What kind of code access will we have to the non-active vessels? Or how are non-active vessels handled differently in KSP2? The fact that colonies will be included in stock makes me think they would have to be handled differently than in the first game. Is this true? The reason I ask is because, whenever Principia comes out for 2, I would like to start building systems to automate certain aspects of station-keeping, or in my most hubristically hopeful case, entire missions (e.g. for supply runs to colonies) that can run in the background. END OF QUESTION, but for anyone wondering "Why?", the goal would be to be able to build much more sophisticated and intricate supply networks throughout the solar system, which is technically possible currently, but requires a level of micromangement that I do not enjoy doing.

I *had* seen that and wondered what it was about. Thank you for explaining. Does "patch" mean the whole file or the individual code blocks? And how do you mean "AFTER implies FOR"? You have to declare a name with :FOR in order to reference that name somewhere else with :BEFORE or :AFTER What I ended up doing was a :FOR in my non-rescale files, and then an :AFTER in each code block of my rescale file to address how rescaling interacts with each mod. That was the most object-oriented way I could think to do it. e.g. Also thank you for the resources. That handbook is a lifesaver

Hi! I already know about this tool for editing .mu files and it seems to be functioning fine, but I was wondering if anyone knows about any good tutorials for using it. I know almost nothing about Blender and I'm having a strange phenomenon where my .mu files are doubling in size when I edit them. I'm only importing, changing some float values, and exporting again, so I would not expect this behavior. Therefore, I am probably doing something wrong during export but I have no idea how to troubleshoot it.

Just finished implementing the new nodes. If anyone who is comfortable editing .mu files passes through here, I could really use some help figuring out where some extra kilobytes are coming from between my .mu files and the originals. My intention was to only change the rotations on some transforms, but some of the files have nearly doubled in size. I don't know if that is a reconversion problem from the Blender .mu plugin or if I've done something wrong. Here's the commit where I made the changes so you can see the size increase for yourself

There's two ways to do nodes. Either directly in the config OR by making a transform on the model where the node will go and then declaring that transform to be a node like this. The second way seems to be more correct since it lets scaling work more sensibly, which is important to me since I want to make this thing full scale. I figured out how to rotate the transforms and re-export the .mu files, and it looks like that's working correctly so far. Fingers crossed that I don't run into more bugs And I am definitely learning this on-the-fly too lol. Do not mistake me for someone who knows what they're doing. I'm just Googling a lot lol

Wait, @NiL, were you saying you need something other than the .mu files? I'm currently trying to fix the nodes on the pieces by rotating some transforms in Blender from the .mu files, and you could save me a huge amount of wasted energy if you know that's not going to work. oh but I think I fixed FAR completely. We still might need to fudge some numbers to get it to fly well, but I think FAR compatibility is at least error-free right now on my fork.

Yeah, it seems to have balanced out. I'm still getting bizarre results though. The lift from my wings is about 1/10 of what I would expect. These wings are 13m at the root and they're getting completely out-classed by Delta Wings. What am I doing *wrong*?? The little blue dot even moves *away* from the wings on the right when I put them on. Something is screwy here. Here's my full FAR config and my parts configs if anyone wants to take a look. I'm gonna keep digging, but I think I see why Kipard gave up on this

I can't be the first person with this problem, but I also can't figure out how to Google it to find an answer. Is there a way to control (or at least know) what order config files will be loaded within a single plugin? For example, I'm making some parts FAR-compatible, but I have another patch that does a rescale. Is there a way to ensure that the rescale happens first so that I can scale up the aerodynamic properties for FAR correctly (e.g. "MAC = 10 * rescaleFactor")? If the FAR config is loaded first, the scaling won't happen correctly. I naively tried to append ":AFTER[my_far_config.cfg]" to the "PART" preprocessing function, but that doesn't seem to work EDIT: Okay, so I think I get it now. The functionality I wanted was to have a name that I could reference for the load order. The way you do this is with the :FOR[arbitrary_name] command, which is used only once in a config file and specifies basically a timeslot in the load order. Then, :AFTER[same_arbitrary_name] refers to the timeslot immediately after that one, which is why you can't have multiple BEFOREs and AFTERs in the same step. Is this right?

If anyone is still interested, there are live repositories for this still. I recommend JadeOfMaar's repo and I have my own fork where I'm working on 1) getting a 1:1 model working for Realism Overhaul and 2) fixing FAR compatibility. I think I fixed the FAR instability issues, but the control surfaces still need their config files tweaked to make the aerodynamics more reasonable

@Alioth81 I don't think that was my problem, but there is some great information in your post, and thank you very much for that. Per this post from Ferram, I added in ```node_attach = 0, 0, 0, 1, 0, 0``` to all the left pieces, and ```node_attach = 0, 0, 0, -1, 0, 0``` to all the right pieces (in the original part configs, not the FAR config file). It seems like the lift was flipped because FAR was measuring both pieces from-right-to-left, instead of just away from the body. This has fixed the aerodynamic overlay, but does my logic sound right? And I don't know what "e" is either. I inherited it from previous maintainers. Is it incorrect?

When making a new part, what determines where the CoL of that part will be? I am picking up where Cpt. Kipard left off trying to get FAR compatibility for their Skylon mod, but I'm seeing lift show up at weird places on the parts, causing wild instability Is there something in the config that can change where the lift comes from? Here's the current config in case that helps somehow (I have not yet tuned it at all, I'm just trying to get it to be sane first): @PART[KipEngSkylonCanardLeft]:NEEDS[FerramAerospaceResearch|NEAR] { // zero out all stock values, remove stock module @maximum_drag = 0 @minimum_drag = 0 @angularDrag = 0 @dragCoeff = 0 @deflectionLiftCoeff = 0 @ctrlSurfaceRange = 0 @ctrlSurfaceArea = 0 !MODULE[ModuleControlSurface] {} // add custom FAR values MODULE { name = FARControllableSurface MAC = 1.985 MidChordSweep = 42.695 b_2 = 4.02 TaperRatio = 0.25 e = 0.87 nonSideAttach = 0 maxdeflect = 15 ctrlSurfFrac = 1 } }

Thank you. I'm gonna explore a code-based solution first (I think I can extend either Engineer or Mechjeb to display the info I want), but if I can't get that, I'll just use a dummy vessel Edit: I got Kerbal Engineer to display it with a little bit of coding. They have a lot of internal code for viewing the fine details of something's orbit, though it looks like it's mostly nonsense in stock. So far RSS/Principia's results seem plausible though.

Yeah, I see that. I finally found this post which essentially says you have to code it yourself. I'm looking into doing that now. I think you're right that I don't need to, but I don't see how. In hindsight, I'm having a hard time arguing how it was going to work. My logic was that I would line up the vessel's AN/DN relative to earth with the moon's AN/DN relative to earth. By using the moon's time-to-AN/DN, I would have a specific point I was targeting, and knowledge of when the moon would be at that point. That way I can target any point in the moon's orbit, which is all I really want.

Is there a way to display orbital info like time-to-ascending-node for an arbitrary body? I know about the target section in Kerbal Engineer but it doesn't have all the information I want. I am playing RP-1/Principia, and I want to aim for the lunar L4/L5 points, but I really don't want to manually calculate my launch window since it seems like the information I need is probably already calculated somewhere. Do I have to just bite the bullet and make my own estimates? Sorry if this is a duplicate. All my searches kept giving me things about the vessel's orbit info relative to the target body instead of the orbital info of the target body itself. Mission info in case it's necessary: Launch a sat to LEO from Svobodny (~51° inclination), maneuver to the moon's AN/DN with the earth, arriving ~5 days before the moon does, burn retrograde (earth-moon barycentric) and hang out at the lagrange point