• Content Count

  • Joined

  • Last visited

Community Reputation

381 Excellent


About Wyzard

  • Rank
    Junior Rocket Scientist

Profile Information

  • Location Array

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Checking for buggy docking ports may be useful, but I think it'd make more sense as a separate mod that can be installed independently of DockRotate. Having it here seems like scope creep.
  2. Nice! I diffed the old & new files, and saw that you found and fixed a bunch of stuff beyond the places I'd reported — additional parts with commas instead of semicolons in the switcher, something else that was mistakenly patching the radial tank, more parts that were missing from ModuleKISPartMount, that sort of thing. Thanks for the thorough bugfix pass. On a separate note — are there any plans to add a 1.875m cylindrical fairing in a future update? It looks like the only thing that's currently compatible with the the 1.875m 6-bay core is the 1.875-to-2.5 tapered fairing, and that only fits the core's quad-height variant. (Or maybe I'm overlooking something?) I know the whole 1.875m diameter is still sort of a second-class citizen in KSP, so it's not really a big deal, but I figured I'd ask. (The reason I went looking for a 1.875m fairing is that I have a satellite design with a bunch of DMagic experiments on a 3-height 1.25m core, and I wanted to widen it to 1.875m to match the CYL satellite parts from Near Future Exploration, and shorten it to 2-height in the process. That quad-height 1.875-to-2.5 fairing seems too bulky for the satellite, since it's twice as tall as needed. Also, the petal doors get in the way of the DMagic RPWS wedge's long antenna arms — though there are a few places where it fits without clipping.)
  3. Glad to see a release! US2 is one of my favorite mods so I'm glad to see its 1.9 update out of beta. I created Bitbucket issues for several bugs that are still present in the release. They're things I'd reported earlier in the forum thread, but probably "fell off the radar", so to speak, as the thread moved on. (I should've put them into Bitbucket earlier, but it gave me errors last time I tried to do that. It worked this time, though.)
  4. That's a bug that was fixed by an update to CryoTanks, but the CryoEngines release hasn't been updated so it still has the buggy version bundled with it. You can download the fixed CryoTanks separately from its own GitHub releases page, to replace the copy bundled with CryoEngines.
  5. Aha — I was looking for the shape of 1.25m docking ports, and forgetting that the bigger ones aren't as thick relative to the diameter, and they don't have the flange that the smaller ones have. Thanks, now I see.
  6. @Nertea, how would you feel about adding a small number of tank options to the B9 switcher on the Octo-Girder Micro and Mini? Those parts are too small for things like LFO tanks, but the Mini would nicely fit xenon or ore, and both Micro and Mini would fit "support" (batteries and monoprop). On the larger Octo-Girder parts, those configurations use models made from repeated instances of smaller objects, so it should just be a matter of re-using parts of models you've already made, rather than having to make whole new ones. (For example, just one xenon sphere in the Mini, vs. the two or four spheres in the larger parts.) In particular, I often find myself wishing for a Mini- or Micro-sized battery option, and a Mini-sized ore tank (similar to the stock 2.5m ore tank, but in an octo-girder).
  7. Out of curiosity, how'd you put that together? In sections using USI Konstruction ports, or built in-place with GC/EPL, or something else? I'm assuming you didn't launch that whole thing from Kerbin fully assembled, but I don't see any docking ports (aside from the ones for the rovers).
  8. I was surprised by the news that 1.10 is adding a mini klaw: I've never wished for one of those, but I've often wished for a bigger one. The 1.25m klaw looks silly on a spacecraft designed for asteroid mining, with the 2.5m ISRU converter and the big orange drills. If Squad is only adding a small one, maybe Restock+ can fill the 2.5m klaw niche.
  9. All that's in Extras is optional metal textures. Install it if you want that, but it's not needed for the parts to work correctly. The error you're getting is caused by a known KIS limitation: expandable parts (like the Bagel) don't support personal inventory for kerbals in them. This is unrelated to the 1L container inventory that you mentioned; a kerbal's personal inventory is stored separately from that. The kerbal's inventory is stored as data on the part where the kerbal is sitting, and when you transfer a kerbal from one part to another, KIS needs to transfer the associated inventory data from the old part to the new one. However, expandable parts don't have a place to store personal inventory data, so KIS blocks the crew transfer because the alternative would be to have the kerbal's inventory items just vanish. The workaround is to empty the kerbal's personal inventory before transferring into the Bagel (or any other expandable part). Give the items to another kerbal, or put them into a regular KIS container. (Separately from that, though, the Bagel's 1L container inventory does seem weird. It probably ought to be either bigger, or not there at all.)
  10. I'd suggest "<%" and "%>", since those are the digraphs in C and C++ for "{" and "}". Better to be consistent with an existing standard for a language with similar syntax (even if it's an ugly and little-used part of that standard). Plus, the angle brackets make it more clear which one belongs on which side. However, as you said, there's no need to replace those characters anyway if it's a whole new language that doesn't go through KSP's config parser. However, as others have said, building a whole new scripting language and interpreter is a lot of work. It's a nice idea, but probably a pie in the sky. A possible alternative that comes to mind: using Lua scripts instead. There's already a Lua interpreter for .NET, so it'd just be matter of bringing that in and building an API to expose KSP's config database to Lua code. Still a pie in the sky, but at least at a lower altitude.
  11. C++ is a complex language, but for KSP modding you actually want to learn C#. Similar name but different language. C# is simpler — though it'll still be a lot to learn if you have no programming experience at all. (Strictly speaking, you can use any language that can compile to .NET, including C++/CLI — but pretty much all KSP mods are written in C#, and that should generally be your default choice unless you know what you're doing and have a good reason to use something else.)
  12. @cukkoo, to summarize: You don't edit DLL files directly. Those files contain compiled bytecode that's not meant for editing. Instead, you edit the source code and recompile to produce a new DLL file. The source code for USI-LS is here, on GitHub. The .cs files are source code written in the C# programming language. To work on it, you need to understand C#, as well as some related things like how to set up a development environment, how to compile the code after making changes, and how to submit pull requests on GitHub. It sounds like you don't have any experience with programming. If you're interested in learning, that's great, and there are plenty of resources available for that on the net. But don't expect to work on USI-LS as your first attempt at programming — it's complicated code written by a professional programmer, and isn't geared toward beginners. You'll want to start with a basic tutorial or something and work your way up.
  13. I don't know what a beepbox is, but here's a patch that you might find helpful. It enables the stock "collect all" button on all parts that can hold science, instead of just that one little box.
  14. In case anyone's interested, here's an unofficial part config I made to add a Snacks recycler to US2: This is a copy of the US2 Parts/Processors/WaterPurifier.cfg file, but configured for SnacksUtils instead of other LS mods. It doesn't conflict with the regular WaterPurifier.cfg, because that file doesn't create the part at all when using Snacks, and this file doesn't create the part unless using Snacks. (Ideally this ought to be integrated into the main WaterPurifier.cfg, but there isn't a Git repo where I can submit a patch, so I'm keeping it in a separate file in my own installation.)