Jump to content

Waifu Art Thou Romeo

  • Posts

  • Joined

  • Last visited

Everything posted by Waifu Art Thou Romeo

  1. Does anyone know to what extent non-active vessels will be accessible? For example, I'm building a base in KSP1 right now using Planetary Base Systems and Kerbalism. And I'm able to design something that can maintain power in darkness for weeks, but only by switching over to fuel cells, which can only run for a couple weeks before eating all of the oxygen. So I need some way of automatically switching them off when the solar panels are sufficient, but in KSP1, there doesn't seem to be any way to do that, even using KOS or something since the inactive vessels are SO VERY INACTIVE. I'd be more than happy to use or build mods to do this, but that's going to require mods to be able to do it, y'know? I even get vessels being whatever level of inactive by default, but it'd be nice if mods could declare what aspects of a vessel they need to remain active so that we could build these more intricate systems.
  2. Thrilled we finally have a release date. Even early access means the mods I love can get started faster. 2 major things for modding that I've run into: Please give us better public documentation of part configs. Wheels in particular are an absolute mess to try and work with in KSP1, with certain arcane code snippets in them that only 1 person 5 years ago knew what they meant. *If possible*, can .mu files be as self-contained as possible? A lot of old part mods have been lost to the fact that all that remains of them are the .mu files, which are *heinous* to try and maintain. I get if this isn't feasible, however.
  3. First L4 sat launched from Svobodny! It's not quite stable tho. It falls out of place after about 3 years without station-keeping. How close do you have to be for Earth-L4/L5-moon to be truly stable?
  4. Could someone explain to me what "launch to target LAN" does? I kind of get it, but I'm lost on whose-LAN-relative-to-what. Like, if I set the moon as my target, and I click "launch to target LAN" 0°, then my orbit's LAN around Earth will be ~0° relative to what? Is it the moon itself? Is it the moon's LAN relative to Earth? I'm trying to find a good way to launch to L4 from Svobodny, so I need to get a grasp on this, but I'm really baffled. Unless of course, I'm just using the wrong tool anyway. But it seems like it's the right one, because I want my LAN to point in a specific direction on the moon's orbit (~5 days ahead of my target), but then how do I target a specific place on the moon's orbit?
  5. These are probably silly noob questions, but I promise I searched for the answers. Are there Lagrange points in the Kerbin-Mun system? Everything I could find talked about RSS, but nothing about Kerbin-Mun points. I don't even know if the mass ratio is sufficient between them. Okay, I found that there at least USED to be Kerbin-Mun Lagrange points, so I'll assume they're still around. What reference frame do I use and what direction do I fire my thrusters when I get to them to achieve orbit. I brute forced it a couple times in RSS, but I wanna understand in a more principled way. Obviously there isn't an L4-inertial reference frame I can select, so I thought I should use Kerbin-inertial so I could point along the direction of the Mun's orbit, but after an hour of tweaking knobs, I haven't even seen evidence that the L4 exists. Is there a tutorial somewhere that I missed in my searching? Okay, I think I get it now. So the process for the L4/L5 points is to start in Kerbin-inertial and get your apoapsis to about where you think the Lagrange point is. Then, still in Kerbin-inertial, make a maneuver node to circularize your orbit. If your guess was good, you should have something that looks like an erratic circle. Switching to the Mun-Kerbin-Orbit reveals a kidney bean shape. If your guess wasn't good, keep moving both maneuvers around in time until you succeed. This works, but is it the Right way? EDIT: Okay, I think I'm finally internalizing this. So what's cool about L4/L5 isn't that you're orbiting the Lagrange point, it's that orbiting the Lagrange point can make patched conics be an Actually Pretty Good Approximation. No station keeping, no worrying about Jupiter, just vibes. Is that about right?
  6. Sorry, I wasn't clear. It flies fine in stock (heavily using the tricks you described). It's the real design I'm not convinced about, and FAR (and especially Realism Overhaul) seems to agree with me. Yeah, no question this is an extremely hacky way to update these mods. Thank you for the explanation. I think that might be another nail in the coffin of the one I've been working on. In reparenting all the parts in the models, I don't see a way around constant exports/imports to make sure everything ends up in the right places
  7. So THAT'S where all those extra kilobytes were coming from! Noted, thank you. And no, I never found a more effective way than that. I've been taking a long break, but I think I figured out the workflow. Wheels are just so goofy in this game that it's been hard to get myself working on it. Not to mention that I'm no longer convinced the ship I'm interested in even CAN fly, regardless of how good of a computer they put on it. The CoP is just SO FAR ahead of the CoM. I don't think the Skylon design will ever work without hacks.
  8. Yeah, that's the way I've been handling this as well. It is incredibly frustrating when it comes to orienting nodes, but the rest is somewhat tolerable. And me either, sorry. I've just been using the animations provided by whoever originally created the models I'm working on.
  9. I deserve very little credit. Kipard built this, and several other people have maintained it. I'm just reparenting the components and writing some configs And probably these were built with the Unity method On closer inspection, it looks like I cannot use the Unity method anyway, since I only have the .mu files and not the original models. EDIT: Just in case anyone passes by and wants to solve my animation problem: I have found the source but not the explanation. If I have the light module in the config, retraction absolutely will not work. I have no idea why.
  10. Would you expect the animations to not function at all or just be weird? The issue I'm running into is that I can trigger any animation I want it if I set it to the spotlight animation in the config, but I can't trigger it from the deployment section (I'm working on retractable wheels) And fwiw I'm probably just going to switch to Kerbal Foundries anyway since it's so much better documented than stock, in which case I don't think I need to mess with the models anymore. But I will likely switch to Unity for doing this from here out, cause this was way more frustrating and hacky than it needed to be Lastly, to be clear, I have gotten around the issues from the top post, it was just a horrible headache to do, due to Blender not correctly showing the positions of re-parented parts
  11. Yes. Still running into problems, but I can at least successfully edit parts other people have made and load those parts into KSP doing this. I have not attempted making anything from scratch, though it looks like you can. But for all I know, this could be why I'm having so much trouble getting the animations to work, though I don't think so.
  12. You can and I have been doing so. It's just been a nightmare to do, due to the problems mentioned above. I have linked the tool that lets you do so above. I might switch to other way if it will make reparenting everything easier.
  13. 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
  14. 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
  15. Do you mean "should" as in "ought to" or "I have reason to expect it will"?
  16. 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.
  17. 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
  18. 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.
  19. 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
  20. 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
  21. 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.
  22. 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
  23. 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?
  • Create New...