TiktaalikDreaming

Notes for 1.1 based on prerelease; The module/plugin doesn't work, as all plugins won't without recompiling. Parts not related to Orion propulsion should work. I'm not sure when I can get the module fixed up, seeing as I have no idea what I'm doing. I have solicited help, so we might even get a working UI by the end of this (the existing UI depends on a separate library that's not in 1.1 afaik).

Actually, seems like a broken save or something with the game itself. Ignore me.

Except that appears to have been a corrupt save or something. Also couldn't use airlocks, ladders, etc

Is everyone going to use this single topic to discus module debugging moving forward or will we be creating new topics in this forum (until actual 1.1 release that is)? Assuming option 1, I don't know what I'm doing, but I can't get my stuff to accept that there's a ConfigNode method to override, and all the new DLLs are linked in. If I knew enough to look further I'd be annoyed or something, but I don't, which is probably the issue. But I'm going to post a couple of questions here to clarify things for others. 32 vs 64 bit? I notice the KSP_Data/Managed cache of DLLs comes in 32 and 64 bit flavours. Do mods need to be compiled twice, once for 64bit and once for people with ancient kit? What on Kerbin are these new fangled IDE things? Related question: Can I rewrite my module in bash? Is anyone interested in helping a C# n00b out with some code updating? I can swap you some 3D modelling. Not all questions are of equal seriousness.

Warning, I can't seem to get the docking node to work. It may require adjustings.

I'm getting the same thing, but not if I EVA from the craft with the parts. EVAing from a nearby craft (to transfer crew) is causing this for me. And the only crew parts on my interplanetary ship were from this mod, so I can't tell if it's a KSP bug or a mod bug.

OK, well, I sorted some issues and have uploaded a new version. Now working: The Lab's airlock/hatch. It was being obstructed by colliders on the base/heat shield which have been rebuilt as they were massively over complex. DeOrbit motor has a gimbal that should be enough to not spin like a crazy top. Also, I fixed up the decoupler to increase the gap between stack nodes (when the stack nodes are really close is when it's hard to get the parts to link in the VAB, which I think you'll agree is insanely frustrating). Interstage decoupler (between descent and ascent modules) has had it's stack nodes shifted apart, at the expense of burying the stock node into the ascent engine a bit. Base/Heat Shield has been slightly redesigned, no stair to a lower level. I WAS thinking of an outside stair, but seeing as a kerbal can almost jump over the whole landed craft it might not be necessary. Next I'll be working on a basic shroud/hangar type thing for the DEM. For either adding inline or sticking out the front of a craft (original plan was for this, but it mostly excludes single launch options) Also, craft file: https://www.dropbox.com/s/rc5o3lpz3q0he4h/Duna%20Excursion%20Module.craft?dl=0

OK, "solved". Either there's issues with overly complicated sets of colliders, or (I'm leaning towards this explanation) there was something out of place with one of my 27 colliders. I removed all the colliders, created new collider meshes in blender that merged a bunch of the others and dropped the colliders for the part down to 13 simple ones (2, replicated in a circle of 6 plus a central one). And now it works.

While people ponder if 27 meshes for collider shapes might be too much, I'm redesigning those. It occurs to me that; 1. The gap for Kerbals to go between layers and walk out along the landing legs only ever worked because I had a full scale part with half scale kerbals. Now that I've kerbal scalled the parts, it doesn't work. So I can remove some complexity and the stairs. 2. The floor and base colliders can be the same. Esp considering item 1. And the inside and outside wall colliders can also be the same.

OK, I've organized screen shots. Colliders are a bit hard to see. (Anyone else have that thing in Unity where they're invisible until you untick and retick Convex?) @NecroBones the hatch box doesn't intersect the pod's collider. It did initially, but I already chased that rabbit hole. It sits a short distance away, helped by the hatch mesh shape protruding past the pod collider. @nli2work my bet is on some sort of clipping, yes. I'm about to start disabling colliders to see what's causing the issue. I'm starting to think the collection of 27 mesh colliders in one part might be going too far, and KSP is doing some summarization.

Yep. The hatch works. There's multiple parts. The lab piece has a hatch. The descent base obstructs it. Just the lab, the hatch works fine. I just added parts, tested, one at a time, and it's definitely the descent base obstructing the hatch. But no component of that part *should* IMHO. That said, the descent base collider is a group of colliders. Possibly the most complex collider I've built yet.

I've been working on building a NAR MEM (Mars Excursion Module). My issue is that the moment I attach the base, the lab's hatch is obstructed. And it shouldn't be. At least as far as I can tell. I'm wondering if anyone has a really clear idea of what triggers the "hatch obstructed" message. I've moved a lot of colliders. Some I've even shifted to non-convex, even though that will stop working after 1.1. even though those didn't really obstruct anyway. Visible, non-collider mesh doesn't appear to be obstructing either. Is there some implied bubble of "do not obstruct" space I should know about? I'm assuming a kerbal sized space outside the airlock part-trigger/collider. But I just can't get this working.

Something tells me they were hoping for lift to keep progressing the same as it did for subsonic, so very little surface needed. It does look nice and sleek and sexy. While it nose dives into the ground.

Slightly more wing than (That's the only shot I have on imgur of my A-9 parts, so the only one I can get to at work)

Yep. And the proliferation of wild loony wing designs tested for the A-9 shows they were aware it wasn't working. I've done some testing with a fairly badly formed A-9 wing in KSP. It models the "doesn't work" quite nicely. :-)

In order. The yellow colouring will probably stay, although I don't much like it. It was one of the US post WWII paint schemes for test firings, and happens to be the only scheme that has the same pattern in rotational symmetry for the wings. Which makes it hugely beneficial to me texturing the thing. The later stages had some far fetched plans to fly down on lifting bodies devoid of reentry heat protection. I was hoping to have a working A-10 type thing before anyone noticed there was no provision for getting back down. The A-10 engine is massive. And I think it's much bigger than the V-2 without RSS as well, but I'll check when I get home.

I was just testing what I thought was a version with all the parts working when I realized the discardable outer shell used during reentry covers where I put the chutes. I have a hairy descent for Jeb and co coming up, then a bit of adjusting.

It's a lot of work. You'd have to keep changing install schemes everytime each OS was patched. It'd be easier I guess to insert extra code to block OS updates. What could possibly go wrong with that? OK, I'm going to stop taking the liquid out of this now. Just in case someone's reading and thinking "Hey, that's a good idea!" And really, how much comedy value is there in poking holes in this. It's one of those "funny, cos people do this sort of dumb thing, so it's sad as well" things.

Well, some viruses manage it via vulnerabilities, aka, things that shouldn't work. But yes, having web sites capable of installing code remotely is a bad idea, in big flashing lights, with exclamation marks and all that. And as has been pointed out, installing mods on KSP is about as easy as... no, it is the easiest mod install ever. CKAN is awesome, but not because it can install a mod. but because it'll tell me when they're updated, chase down dependencies, and all that stuff.

Descent tank stack node fixed. And I've gone through and half scaled everything. Thankfully, when you use the rescale attribute in KSP, KSP rescales the stack node positions. Praise Jeb. Hopefully I got everything right with that. I'm aware of an issue with the interstage decoupler not connecting without swearing while standing on one leg, holding your tongue just right and rubbing your hair counterclockwise. I suspect that's due to mismatched stack node sizes, but I keep forgetting to test. Maybe next version it won't be horrible. Next version should have the docking port (I have to go back to some old stuff to try to reremember how to do docking nodes, it's a transform or sumfingk) and updated chute units that will fit in where they should now obviously be intended to fit. And some week soon, textures! But at least now, you don't have to try getting a 10m thing to Duna, a more kerbal 5m will still require some serious piece of work without other over-sized mods, but not like 10m did.

Descent tank attach nodes are waaay out. Sorry. Fix in next version

I've converted the bases for the descent tanks to radially symmetrical. As it was, you could match the planned look only by rotating every tank to match, which was a pain in the proverbial. I'm also looking at how the descent stage's RCS, Legs and Lab all interfere with each other. The original placement of the RCS and Legs would have RCS nozzles intersecting with leg components. Rotating either by 15 degrees sets RCS to either across the leg components (in an OK way) or no-where near them. BUT, if I rotate the RCS, it then occupies space used by the lab. If I rotate the leg gaps, then placing the damned things will be a huge pain in game. So, I'm going to rotate the lab and thus the ascent stage, 15 degrees clockwise, with the RCS. All those Jeb damned radial stack nodes change. Ascent Module rotated. Thank Bob for spreadsheets with trig. I think just a docking part and fixing the lab are next, then all the parts are basically functional. I feel I should note here that, unlike virtually every stock (aka, non Realism Overhaul) mod with historical parts uses a scaled down edition of the original. Partly because the VAB isn't really big, and partly because kerbals and kerbin are smaller than humans and Earth. And so far, this WIP has been full scale. So, at some stage soonish, I'll be embarking on half scaling this. Which will muck up any craft anyone has built with the full scale parts. But seeing as the released zip is missing some significant parts, I suspect that won't really annoy anyone.

A note on what's in progress and what I know isn't there. The base is insanely too light, because I stole the config from a stock heat shield, hacked it about and haven't adjusted mass yet. And it doesn't have RCS, RCS propellant, fuel/oxidizer tanks, the discarded centre piece of the heat shield, or the shell that covers the ascent stage. But by god it has a lot of work sunk into it. Those damned legs. Although I've provided the Ballute and Drogue, they're expected to fit into a top mounted docking port that isn't yet in game (although I have a blender shape for it). Once I have that piece, I'll start messing with how the drogue chute and ballute connect. Current attachment points are best viewed as wildly speculative. Many of the parts have a centre at the centre of the full MEM, although their attachment points are adjusted. This could result in daftness, especially when trying to place them in the VAB. And probably f'cks up the mass distribution. Or in the case of this, unfairly makes the mass distro easy. The engines both have stupidly large gimbals. This is because the original plan was to have the engines canted at 13 degrees to counter the offset of the centre of mass. So I set the gimbal to 15 degrees. Without adding the gimbal speed option it's a bit silly though, so expect to see the gimbal get slower than infinitely fast soon. And then it's still a band-aid solution to the core issue of the whole thing is a bit deranged.

From Scott Lowther's USSP #04 The intention of this mod is to provide the parts to build said craft. Keep in mind this was a module for landing on Mars and not staying for months. It's small and cramped, used a fairly horrible oxidizer, and in short, wouldn't be used today. But, the basic design has persisted. See also http://www.projectrho.com/public_html/rocket/realdesigns.php#id--North_American_Rockwell_MEM At the moment I'm just planning on the base MEM design itself. The various logistics landing craft can mostly be put together with existing parts, especially the various procedural parts mods. What sets the MEM apart is the way the various parts interlock. Depends on (and repackages) Prop assets from https://forum.kerbalspaceprogram.com/index.php?/topic/166433-13-tiktaalik-dreaming-props/ Download from SpaceDock http://spacedock.info/mod/425/NKR's%20DEM Dev things are available on github https://github.com/TiktaalikDreaming/NAR_MEM/releases I use github to sync and backup my work, so the git version will usually be tga file textures instead of dds and a few other little things I tend to clean up for spacedock release not done. Gratuitous pictures; Parts available: https://imgur.com/a/epec8 Now mostly updated for 1.1. 1.2.2 1.3 How to use this thing? Here's a mission cycle starting from Duna orbit. Real solar system versions would be similar but with larger numbers. Click album link for the mission cycle; https://imgur.com/a/FGQa0

Reading up about drag cubes because my Mars landing ballutes are behaving like they don't exist (although they're now very pretty, animated, pointing in the right direction and so on. I stuck a 28m ballute on a mechjeb pod and it accelerated at the ground. So, I figure there's something messed with my drag cubes, or which cubes are which (there's at least 3 for a chute). Open partDatabase.cfg and find PART { url = NAR_MEM/Parts/MEM-Ballute/Ballute/MEMBallute DRAG_CUBE { } } Not filling me with confidence. Deleting to see if it'll generate them. Deleted my cached drag cube stanza (I hesitate to say I deleted my drag cubes, seeing there wasn't one) and it didn't generate. For a ballute, I'm happy to actually create one (or steal the one from the XL chute and hack around with it), so I know what it'll be using. It'd be nice to know why it didn't create one though.