orcmaul

Check out the included readme file for instructions. Contains prototype payload frame and engine, xenon module, solid fuel/electric RCS, and blowoff hatch.

That may have happened. I spent a bunch of time getting them to go in the frame properly and get the nodes all perfect and not a ton of time using them as engines. I'll see about a patch to make the LFO not broken. They should run out eventually. You get a fair amount of burn time from that teflon bar. Also RCS using multiple resources is bugged in stock KSP so it only kind of works properly. Experiment with it and you'll see what I mean. I think there's a couple mods that fix this that you can experiment with if the part is interesting to you. I wanted to get it out there because it amused me and no one has made anything like it. Solid fuel RCS is a cool concept.

Whee, finished testing BoxSat in time to bring you a christmas present of 0.90 tested update and some prototype parts to play with. I think I might have gotten a bit silly at some point and spray painted the xenon tank module. They're prototypes, you know how it goes. Share and enjoy!

Be sure to check to make sure you only have one copy of ModuleManager installed. Some of the mods you've listed include their own copy of MM. If you have four copies installed it's very likely you'd get the results you describe. I'm not aware of any conflicts with any of these mods as I frequently use many of them myself. The only mods on this list that I haven't tested BoxSat with myself are MKS, Regolith, and StationScience.

I'm setting up my test builds right now to test BoxSat for 0.90 so I'll be sure to test for this. Which mods were you using and which boxsat modulemanager configs do you have installed? This is a good question as well.

I'm curious about how it looks with the side nodes. Would you mind posting some pictures?

I have 4-6 installs of each version in different configurations for testing BoxSat. Then I've got a couple versions of each with various mod combinations that are fun to tinker with. So that's about half of my installs. Then I have a few x64 installs for stability testing. Recently I decided I would start preparing to play a new career game (I haven't made any serious attempts with career since 0.22). This time I want to have everything the way I want it with parts, plugins, science, kerbals, and tech tree. A total overhaul of KSP to my specifications. So I have been testing a ton of mods while organizing my ideas about the tech tree and the parts. It's been tons of fun to approach KSP with such a free hand and I've been learning a lot more about the history of space exploration in the process. My revised tech tree concept is almost complete and I'm starting to assemble test builds to confirm if I like how it plays. Hopefully it'll run with all of the parts and plugins. When I deleted 90% of the stock parts in one of my installs to free up memory to assemble a big group screenshot of all of the engines from stock and different mods all of the buildings at KSC turned pink due to missing textures (apparently they share textures with rocket parts?). So yeah, that's how I wound up with 45 installs of KSP on my SSD.

Quick testing shows the basic parts work fine. We're going to hold off on testing for 0.90 until most of the mods we support are updated. I'm also having stability issues with stock 0.90. I'm checking for issues on my end but I'm not having issues with any of my 45 other installs of KSP 0.23.5 through 0.25 other than occasionally running out of memory from too many mods.

Hello, I've been using HGR for a while now and really love it. The 1.875m form factor fits in very nicely with everything I do. That said, I've been craving a viable gemini-style capsule that will fit on top of a 1.875m rocket. I saw your other project and after a bit of math and then a bit more math I got out the hammers and whipped this up with some cfg bending. This is just kit-bashed together. I'm hoping that some day (perhaps soon) I'll have a proper gemini-style capsule and service module that will fit on a 1.875m rocket.

Hello, checking in from the local ale festival. We are also developing a payload module that will support larger experiments and engines with fuel. It will occupy an entire payload frame and may take some of the load off for some of your larger designs. We have considered a larger frame that holds multiple stacks but it is much harder to balance. If more than three frames stacked looks off consider taking advantage of the ability to swap out modules with KAS. Thank you.

I know how to add it to the MM files. I don't know the details of how it works and reading the code to understand how it is evaluated takes time. Then testing the result in MM files against this understanding takes more time. I know it's asking for a lot for there to be documentation but I do use it when it's available.

During the update for 0.25 I looked into using these new features of module manager and was unable to find enough documentation to implement without a bunch of guess and check. It may be that the documentation has improved since then but I have not checked. The NEEDS statement is something I plan to add to our MM files.

Sorry about the lack of updates. DasPenguin has had a hard road to recovery from illness and is still not in a place where he feels he could resume the pace of work he prefers without adverse effects to his health. We had been hoping to get back to development in November but his recovery just hasn't been as speedy as we had hoped. He is making progress and we do hope to resume normal development at some point.

"Local Control" is the status of a manned vehicle. As far as I know having a mechjeb module should not produce a status of "Local Control". Edit: I went and looked up the precise phrasing and confirmed that local control is a status intended for manned capsules. Unmanned vehicles should not have the status "Local Control".

BoxSat should conform to the normal behavior of RT+MJ. If it is not then this is a bug I would need to address. My understanding of RT+MJ is that when your vehicle is showing "no connection" mechjeb does not function. This situation is what the RT flight computer is for. I'm uncertain as to how KOS interacts with RT.

During development I evaluated the existing solar panels and planned the BoxSat panels using similar performance parameters. All BoxSat panels are based off of the performance of the OX-STAT panel. Here we go with some numbers. OX-STAT: 0.1818 m2, 0.75 EC/s OX-4L: 1 m2, 2 EC/s Gigantor XL: 13.5 m2, 18 EC/s BoxSat 62cm Static: 0.390625 m2, 1.6 EC/s BoxSat 3x62cm Folding: 1.171875 m2, 4.8 EC/s So why did I use the OX-STAT's performance level? If I had used the OX-4L's performance the stats for both parts would be virtually identical to the existing panels. I opted for stats that would be different from the existing parts so that there would be more variety for the player.

So Remotetech mm file works as desired and the new antenna ranges should be much more interesting. I finished testing the rest of our supported mods before starting on ActiveTextureManagement support. I subsequently spent the rest of the day on ATM. Uh, it seems to work but it's actually using more memory than if BoxSat doesn't use ATM. I'm going to hold back on releasing ATM support until I have some more time to test this. Time to do the packrat config and testing got eaten by ATM testing. Everything else is done and the update is ready to post. I'm just waiting to hear back from DasPenguin so we can get that posted.

Yeah, I see it. Rexporting the part in Unity fixed it so that's good. I've finished updating the part files for KSP 0.25 and verifying function with KSP 0.25, mechjeb, and KAS. I've also rexported all of the textures as PNGs which shaved install to about 1/4 original size on disk and reduced memory usage by about 70 mb (need to do some more testing on this to confirm). Right now I'm setting up test installs for Remotetech and ActiveTextureManagement. Once I've finished testing the MM configs for those I'll need to test tweakscale, kerbal engineer, and kOS configs. I saw the comments about Packrat compatibility. I'll have to see if I can whip up something for that and confirm it works as intended. So the list of things to do before A.02b is released is getting shorter. Ah, I've just discovered a new way to break KSP. Excuse me while I confirm this and check the bug tracker. TLDR: BoxSat update for KSP 0.25 is coming soon.

Update time. DasPenguin85's illness was pretty severe and he's going to be out of commission for a while he heals. We'll probably be restarting development in November. Since we won't be doing regular development for a while I'm going to work on a bug fix update for A.02 and try and get BoxSat ready for 0.25.

Sorry it took me a while to get around to answering this. I had to confirm RT2 still works the way it did when I used it seriously in 23.5. I also typically use the AIES antennas with RT2 and then further hand edit everything so that the antenna selection is diverse and useful. Needless to say I had to remind myself how stock RT2 works. Bigger dish, huh? Our existing dish is 0.625m in diameter and is the biggest size we feel comfortable fitting on our 0.625m frame. That dish will comfortably range out to Duna in all conditions. It's slightly less powerful than the KR-14 (2.5m diameter) provided with RemoteTech. For BoxSat this will probably be our largest antenna. I am planning on increasing the performance of the tape antennas to be more useful. That said I do want to better understand what gaps people are trying to fill in their antenna line-up so that I can plan ahead for future projects. RemoteTech includes 1.25m, 2.5m and ~3m fixed dish antennas. The stock Communotron 88-88 provides a folding 2.5m dish. So here are my antenna questions: What size antenna are you looking for? (give rough dimensions) What kind of performance do you want? (What planet will it reach?) Directional or Omni? Fixed, Hinged, or Folding? (Hinged just moves, Folding unpacks) What kind of vehicle does it mount on? Unfortunately, nesting KAS objects is really touchy. Pull the wrong bit out and everything may detach. Instant Kessler cloud. I'm trying to find a way to neatly incorporate our existing BoxSat modules into a 1.25m frame in order to support large satellites. Keeping the mass reasonably balanced with multiple module bays is difficult. So right now it's one of those "If we have time" things. This works right now. The basic probe core gets an upgrade in RT2 when you unlock Unmanned Tech. It adds a 3km omni-directional antenna to the probe core. You can fly up a new probe core to swap out on your existing satellites. Thank you for all of the great feedback! As far as I can tell the settings for crew requirement for the command station are not exposed. Yup, there it is in the ModuleSPU code. Six is the hardcoded requirement. Now, if it were changeable, I still probably wouldn't change it. Six Kerbals in a station is not difficult even with a life support mod. I suppose putting that station in orbit around another planet with a life support mod would be a bit harder but still very doable. However, the difficulty is the point of this game mechanic. You did cause me to think of a radially mounted command station part which I've noted down should we ever make some station parts. I think it'd kind of look like the part of KSP Interstellar Science Lab with all of the antennas that unfold and such. If anyone else wants to try something like this please do.

OK, I thought about how you described the situation. It sounds like you've grabbed a BoxSat module and you're right clicking the module to attach it to your BoxSat frame. The BoxSat frame is implemented as a "KAS Part Bay" (same mechanic used by the KAS Container Bay Type A/B part). This means instead of normal attachment process you instead right click on the BoxSat frame and then click the button marked "Store". This will place your module in an open slot on the frame that is "nearest" to your Kerbal. I hope this solves your problem. Please let me know if this does not resolve your issue.

DasPenguin85 and I will not be dev streaming this weekend due to illness. Hopefully we'll be back to normal next weekend.

Hooray! Someone finally noticed! You've discovered a little bonus I added for the very careful designer: unbalanced craft issues. Wait, no... don't fix it. Use other parts as ballast to compensate or throttle engines so that reaction wheels/RCS can keep up. Without unbalanced design then even the probe's very weak reaction wheel can easily keep up with most engine options. This reduces the impact of the reaction wheel part. I may need to re-examine the balance between LFO and MP options. With the new payload module engines we are developing this will become a more significant decision. I also recall this TGA vs PNG issue being discussed and I thought the conclusion was that at the time (v23.5) that TGA had an advantage. That may have changed and I'll have to look into. PM me links if you find any discussion of TGA vs PNG.

Yes, that would work but the normals would be very muddy. I'm still getting together a config that's a tad bit more gentle on the pixels. Going from a 2048x2048 texture space to a texture 256x256 space is probably adequate compression to initiate fusion. I'll post my results once I've had some time to test it under various conditions.

Can one ever have enough antennas? We've got a couple more antenna planned for BoxSat. I'll look into what is needed for an ATM config.