TiktaalikDreaming

Those are the variants of config provided via Module manager. There's a Realism Overhaul MM config. But there's also a RealFuels without RO config for those people using real fuels but not RO. There's also MM config for RealPlume and Connected Living spaces (mostly so the lab decoupler doesn't break access), but as those don't interfere with anything else, there's no special A without B type config.

Anything but estimates would be a lie. But yeah, a combo from different sources, as some of the estimates don't seem to be sane. And KSP seems to handle 50 engines OK (on an i5 2500K, 16G RAM, w/ nVidea 960)

I'm not going to suggest timelines for others, but I will say that the chance of NathanKell looking in to fixing the FASA landing legs before KSP 1.2 comes out, with included fixes for legs and wheels, is slim. And not a lot of point fixing the legs up to work in 1.1.3 when leg/wheel modules are changing (I don't know how much, but reportedly fixed). AFAIK, the only main hold-up left is the landing legs from the LEM )and the other mercury legs no-one uses). After 1.2 comes out, someone from the community could maybe fix the legs rather than pile everything onto poor old Nathan, who's really just taking over to organize a collaboration. Well, that's what I thought. I think before Christmas is probably doable and not unreasonable. Promises would be unreasonable. :-)

It's inherent in the crazy A-10 tank design. But, it's avoidable by having as close to zero rotation as possible during separation. Which of course is easier said than done with no reaction wheels, little atmosphere and no RCS. When I get around to making a decoupler to match (so far I've been using stock parts for that), I'll experiment with higher or lower decouple forces. I suspect a good kick to get it free before rotation has it collide with the inside walls of the A-10 tank will mitigate somewhat. Finished some math on circles of circles and packing 50 engines into a symmetrical pattern. I'll be going with concentric circles to enforce balance, with circles of 2, then 8, then 16 then 24 engines. That'll make the outside diameter of the craft about 8.7 time the diameter of the A-10 engine. So the outside diameters of those engine rings will be 8.2m, 14.8m, 25.1m and 35.5m. So about 3.5 times as wide as a Saturn V. Then I'll scale to 64% for KSP of course, so it'll be 22.7m in (stock) game.

There's a few sources of info on the A-11 and 12, and they mostly disagree on several factors. Still, I grabbed the approximate dimensions from http://weebau.com/rocket/a11.htm. But, basically, if it shows the swept wing A-9 and says 34 engines, instead of the A-4b style wings, and 6 A-10 engines, then it's based on early work, rather then the later estimates. I'll end up taking masses and thrusts etc from http://www.astronautix.com/a/a9a10a11a12.html But, I've been looking into the A-12, and there's some packing constraint issues with 50 A-10 engines in an 11m diameter, so I may end up ignoring their dimensions. 50 circles is quite plainly a pain in the rear end. I'm probably going to go with four expanding circles of engine mounts, each circle with evenly spaced mount points, which will force it into something of the order of 32m diameter. And ice-cream cone looking. For about the thrust of a Saturn V using WWII era rockets, it'll be impressive. Anyway, I put in some work and got a basic A-11 (which is less ice-cream-cone-constrained) and ran a test flight or two. There's no texture, no fairing, or anything but a blankish part, but it flies; It's pre-wing, but it's surprisingly stable using just the thrust vectoring on the 6 A-10s. Due to the A-10 sitting on top of, instead of inside of, the A-11 separation works nicely. At least until I get them fairings. :-) A-4 from A-10 separation is still a recipe for exploding parts of course.

And I've discovered, which led me to https://github.com/evilC/TacLib Which would be that ancient code I didn't have source for. :-) Could never find TacLib, only TacLibGUI, probably because it's not actually TaranisElsu's. This _should_ bypass a lot of the need for rewriting stuff. Also, I've decided to do some less ambitious projects to warm up to this. My main problem is that I just lept in too deep to start with. So, I'm going to code up my "if you have a spare wheel, you don't need an engineer to fix your flat" code. Which should be simpler. At the very least, it'll be from scratch and thus easier to understand for me. It may end up a horrible unsupportable mess, but it'll be MY horrible unsupportable mess. :-D

Thanks @Crzyrndm. As I said, any help is appreciated.

At this stage I'm just asking for general assistance, so no specifics. More like all of the code. I actually just meant that I thought all of the coded UI had changed linkings. I could be wrong. But either way, I've actually never seen the UI. But it'd be a list of pulse unit sizes, with either a toggle button or an on and an off button each. So, for example; -------------------- 10kT [toggle] 5kT [toggle] 1.5kT [toggle] -------------------

Due to being able to spot red squiggly lines and follow some guesswork when the temperature variables in KSP changed, I've stumbled into being the nominated code maintainer for Nyrath's USAFOrion. While I'm perfectly at home with modelling parts, I find myself a bit lost in this C# stuff the modules are written in. Part of the problem is that, instead of needing to update from 1.0 to 1.1 code, the code is actually dependent on some libraries from the dawn of time. I suspect KSP 0.25, as the UI elements never worked in 0.90 onwards (or was that 0.80, I forget). And now, there's no available source code for the 3rd party libraries that the source code I have is dependent on. So, I'd LIKE to clear out all the UI components of the code and rewrite them. The UI is pretty much completely new in 1.1 anyway, and all it needs is a window with some buttons. "How hard could that be?" he said... Initially, I really wanted to do this all myself. I wanted to wrap my head around how C# worked, and how the orion code worked, so I could maintain it properly. But, I find every time I look at stuff, I get lost incredibly easy. I can't figure out what calls to make or how to find variables to use from KSP libraries. I don't know what half the compile errors are suggesting and so on. I can follow the logic of the code just fine. I just never know which bits come from where. If you want to take a gander at the source before mentioning anything, it's at https://github.com/cerebrate/USAFOrion I'm happy with any level of assistance at this stage.

I gotta say the spare and especially the insides are looking pretty darn fine. Also, it reminds me I should do something about some equivalent parts for Nexus second stage fuel tanks, as that was one of their intended uses. There'll be some more elbow room there though.

Updated. Now there's two flavours of actual airlock. And the WIP super thin weird dimension airlock/hatch. @DStaal's request for the cheaty airlock's IVA to be on the outside instead of the inside has been implemented as well. Although the IVA may change at any time. It's basically the blender equivalent of thinking out loud at the moment. I gave up on the season 17 or whatever thing with walkways and stairs etc, and went for the classic, esp seeing as I found a scan of the BBC set design from season 6.

:-) I had a vague feeling you'd posted more info before. Your post made me think "hey, wouldn't it be good if..." though.

For anyone mentioning site performance and availability, it'd be really nice if you could include a rough location of where you are. Or at least where your DNS server will think you are. Many people don't seem to have got the memo that spacedock is distributed, and you'll get different servers depending on location. If you want to be enthusiastic, then you can mention your ISP as well. It'll help correlate dumb ISP routing issues, esp if a bunch of other people chime in with "Hey, I'm on <ISP> as well!". Just a handy hint. I'm not picking on people, and I have no authority to do so, or to ask that people do this. I just think it'd be handy to have those bits of info for the Site admin dudes (all 3 of them, who all have day jobs and mods to maintain as well, as well as lives) we expect to rush to help us out. I'm in Australia/Brisbane, using TGP for an approximation of Internet, and spacedock is working nicely. Firefox keeps crapping itself though. I don't expect Vitas to help with that though ;-)

For all I know, black magic. There was no functional throttle on the engines, so differential throttling wouldn't have worked. It was pretty clear by the time they got to functional A-4s that the little flaps on the wings were woefully inadequate. Maybe they were hoping the control vanes would still work sufficiently when spread over multiple engines. And maybe they were hoping for Grampus to steer. I should make a guestimate of the A-11, just to see. I expect hilarity.

My understanding is the A-10 engine was to be used for the A-11 and A-12 stages, just more of them. The tankage and thrust structure would change, but it was the engines and controls that were sinking a lot of development time and money, so they were planning on just more engines.

Yeah, A9/A4/A4b === A10 === A11 === A12 is the final goal of the mod, and probably the VonBraun Moon rocket idea if I stumble over some time warp that lends me massive chunks of spare time.

Um... I've never seen that. Hopefully someone will have an idea. Part tools + Unity really seem to hate you. It could be an issue with a specific version of Unity. The recommended version to match Squad's stuff in KSP 1.1 is not the latest (I'm at work and can't easily check right now), so maybe there's a bad interaction between your Unity version and PartTools

The seats in the config need to match transforms in the model, aka empty unity objects. If there's only two seat transforms then the part tools may be trimming the config to fit.

I checked and double checked, Fuel and thrust are about right. Mass is not. Mass of the fuel tanks is 0.2 but should be about 4.45

It's gone missing. I did one up with IVA and all, but I can't find it now. I've been ignoring the parts for this until I get the module for the orion drive working, but I can dig up my space taxi parts. I still have the models, and the Unity outsides, but not the insides, and I seem to have over-aggressively-cleaned my GameData folder at some stage and completely lost the part. I'll rebuild and make it an independent mod.

The A-10 needs more work. I copied the ISP and so on from the A-4, but the A-10 was going to run on diesel oil and nitric acid, which would mess with the ISP quite a bit. Many of the newer parts (pretty much those mentioned) don't have working MM conversions for RSS or RealFuels yet.

Um,.. I have zero idea. I always figured the stock IVAs were done with a cut-away external to get those windows, and never loaded one up (at least, not since 0.9 days, and those didn't have the windows) to see such wizardry. ... runs off to load an IVA into Blender ... It seems there's a separate folder full of overlay masks that are referred to by the config file as extra models. Most appear to be a simple mesh with normals facing outward, and gaps where the windows are. They're layer 16, untagged, so I guess KSP knows secondary meshes on IVAs are masks.

I have an update imminent. I'm getting some issues with having resources changed over for the Real-Fuels-but-not-realism-overhaul config of the fuel cell, but most of everything else has tested fine. So, there should be an update very soon. Imgur album embedding is currently offline for the forums, so my quick run through will have but one pic. So, the docking nodes are elabourated on. There's the one that's been part of the mod for a while, plus (finally) the socket end of the probe/drogue docking node set-up. Also, I've added a (not quite happy with it's lower edge but releasing anyway) shielded docking node for the ascent module. In some testing, because the colliders match the probe and drogue (concave cone, that drogue word gets over used), it actually functions a bit like it should. It won't make docking amazingly easier, but it will cut out some of the annoying in that final connection. The two truncated aerospikes now actually gimbal instead of just pretending to. In reality, you'd thrust vector using differential throttling of the nozzles around the spike, but both engines are small enough to just add gimbaling. Also, I increased the gimbal range on the descent engine as it was insufficient to counter the CoM offset without chutes. Continuing on the engines, I changed their exhaust effects so it's a series of exhausts around the centre (much like the Nexus mod, just less, um, big), and added Real Plume config. Now, the pic of the ascent module reminds me I added an antenna to it, although it's not finished. There's one arm that comes out to the side after the initial extension, the intention being several of those arms. I thought I'd be able to just copy and rotate in Unity, but alas, twas not to be. Yes, it's modeled on umbrella arms. At some stage, the flag decal on the ascent mod has got rotated around and obscures one window. I'm aware of it, but as it's not like that in either Blender or Unity, I'm unsure how to fix. The cargo frame is much updated, and now only rarely tips over when the ramp is extended. It's still a work in progress though. Non-Stock configs are greatly expanded. The main flavours of when things change are now; Real Fuels but not Realism Overhaul Realism Overhaul (big thanks to @Zuppermati for his work on this) Real Plume (independent of the others) Connected Living Space (often lumped in with realism overhaul, but can live independently)

I normally use a mod-light dev install of KSP. AKA KSP without much mod. I actually use my base Steam install, as it forces me to update things fairly quickly. :-) If the exceptions aren't stopping anything, then just ignore them. The first blob looks to be regarding tweak scale, and I'd lay odds that it just won't matter. So, basically you've highlighted the reasons for pointing PartTools at an active KSP GameData. It needs that to see assets like the IVA props. I'd assume it's the same for the packaged UI elements introduced in 1.1 that no-one uses (as in, modders, and mostly, OK I haven't touched them). Like the KSPedia stuff. But you *could* create a fresh folder, and maybe just copy in elements you want to use. But then there's a lot of messing around when you get to testing as well.

Only for those users that can load all the gigapixel images into RAM at once while still having the base KSP loaded into RAM. :-) I have a dodgy laptop I test things on so I don't get too complacent with my main PC and it's 16G RAM and fancy graphics card. Still, there's something to be said for releasing 2 versions of mods, one with full rez and one at sane rez. Unity has a very easy image rescale option in the texture management area. As does the KSP DDS converter.