TiktaalikDreaming

The other thing to watch for is the texture load. Any texture maps get loaded up into RAM, which increases how much RAM KSP uses. Less of an issue now that 64bit works again. But still best not to over-do it. :-)

Acceptable poly counts for parts depends on how much work you want people's GPUs to be doing, and that's not normally a big issue for KSP. So you can actually scale up poly counts quite a bit from stock parts with no noticeable difference in performance. BUT, this is dependent on the type of PC running KSP. If you end up with large poly counts, then laptop users and people running on integrated graphics will tend to have things slow down. I've got parts with 40,000+ polygons (a V-2 engine, it's got nightmarish plumbing) that don't seem to slow anything down. Now, the second "but". Collision meshes. KSP's physics mostly works on the collision meshes. Make those as simple as you can. Adding complexity to the collision meshes can make huge differences in game performance. Where possible use the sphere, capsule, and box colliders built into Unity as well. The same thing goes for "Part Triggers" type colliders, airlocks, ladders and so on. Keep the physics simple, and you can go nuts on the poly count without really affecting game performance. Up to a point. I've found high detail Blender models on the Internet that pretty much make Unity crash, or think so long I wish it'd just crash. Those were all in the multiple million poly size.

I know you've moved on, as I read through the remainder of the topic, but... Actually, before the but, this is a thread that will remind most modders of how they started out. Which makes it a useful thread for any starting modder. And several people have volunteered some really good info. Back to the but. The MM config @PART... (as @NecroBones rightly says) is clearly for editing a part. Just for the record, if you're going to make a copy of a part, the easiest way to start is by copying everything and just changing the part name in the regular, non-MM cfg file. Then you should have a duplicate part. And then you can start messing with it from there. No need to mess with MM directives like @ and ! etc. If you want to delete a module, just delete it. By making the part's cfg file MM based, it's now dependent on the old part existing.

Can do.

Hell, I have most of the external model (it's currently one sided, but took hardly any time, and copying things in Blender is a bit like copying things in any program.) And I do intend the control room to get somewhat more detailed than the ugly roughing out shown. I can donate that bit of time, no trouble. I am starting to think I should have chosen season 2's interior, which from the shots I could find on the Internet, looked like a small basement room at the BBC with a hexagonal console in the middle. But, the airlocks are distracting me from the Duna Excursion Module, which is distracting me from the Aggregate rockets, which are distracting me from the Nexus rockets, which I'm using to procrastinate fixing the Orion drive. I'm wondering if I could be biting off more than I can chew here. I'll do up a Tardis outside to send you as a mu. The inside is (very much) a WIP.

Sad that I can only like this once. Even with parts, where you can adjust, reload, repeat, that takes ages. I've only done a tiny bit of coding for KSP, and I sympathize deeply for the coming time when you have to get around to testing within KSP.

And the inside space is a poodle. (EDIT: I have no <expletive> idea what I meant to say there before autocorrect butchered it, so I'm just going to leave it as is.)

Not enough fish available for this comment

I'll take a look. The capsule hatches generally are just hatches, albeit enthusiastically sealed compared to a planet bound hatch. And they tend to be very much integrated into shape of the craft. But some might be suitable as independent parts. I immediately thought of the Tardis (although I've never been a watcher of the show, which is very ungeek of me) due to the bigger on the inside features. And in 1.1+, the insides will be visible due to the IVA overlay. So, once I have a Tardis insides (proving to be a lot trickier and varying a lot per season than the outside) then I can just re-use that for all the hatches that aren't really airlocks.

The good news is that based on devnotes, the dev version (not available, don't ask) apparently has fixed up legs/wheels, to the point they're taking out the bandaid code (aka Wheel Blocked!). I don't know what the release schedule for this is, but it's fairly hopeful. It does depend on updating to Unity 5.4 from 5.3 (and updating their physics engine), so I expect they need to make sure all the other physics bits work as well before they can release the update. No "just release the wheel fix" on the horizon.

I'm going to call the Japanese Airlock complete (until bug reports). I've updated the mod on Spacedock. It now looks like; With IVA view looking like; And I've started work on my "outrageously cheaty" airlock, which will basically match stock hatches by not adding bulk or weight or any of that realism stuff. You'll still need to transfer Kerbanauts to the airlock part to EVA, but the part itself won't take any significant space outside the craft, or intrude on the space inside other parts' IVAs. Just some early modelling work;

Working on sorting textures before moving to other airlocks. Just need some added detail on the outside sections and done, but the basic look is fairly well sorted;

Helmets do seem useful for airlocks. Kerbal helmets are huge though, so it's always going to be the limiting factor.

No worries. It was actually showing still for me until the java/whatever reloaded at some stage.

I've added imgur albums before. I think you'll find the IMGUR album button has been removed pending investigation into it's current weirdness. @KasperVld is on it.

Awesome speedy response. Or, seeing I posted the bug report type thing just before heading to bed, and it's been addressed when I got out of bed, it 's certainly fast enough for me. :-)

Hi, when I try to add an imgur album at the moment, it looks like the pop-up window asking for the Album ID isn't sending the data correctly to the post editing. I end up with an A ref link as just Imgur Album (indented) that goes to http://imgur.com/{option},which isn't really helpful. :-) The html source added in is; <div> <blockquote class="imgur-embed-pub" lang="en" xml:lang="en"> <a href="//imgur.com/%7Boption%7D" rel="external nofollow">Imgur Album.</a> </blockquote> </div> So, to me, it looks like the button to add an imgur album is misbehaving. I can't really confirm if it's browser based right now. My current browser is Firefox 47.0. Imgur is working OK in the same browser, but I do note they've changed their layout in the last few days.

This mod will be a few add on airlocks, mostly as surface attachable parts. Over on the G+ community for KSP someone mentioned it would be nice to be able to add hatches to parts. That's a task I leave to someone who wants lots of coding headaches. However, and Airlock is quite fine. Basically a small part, with a crew capacity of one, with a hatch. I'll be adding in the MM config for Connected Living Space, so if you're using that, they'll be usable. For us non-realism type users, they are available to add hatch functions to any part. Now, they're not hatches. You first need to transfer your kerbal to the airlock. Then EVA them. Repeating the process on the way back. This is both because KSP requires the hatch to be on the part that holds the EVAing kerbal. And because airlocks just work that way. Now, initially, I'm making just two parts, mostly-replica of the ISS's Japanese Lab's Airlock, as it's about the smallest genuine airlock I could find. (There's a challenge!). Anyway, should be safe. There's two versions, the full Japanese Airlock has some science lab features and lives in the Science section. The shorter model, is just big enough for a kerbal, and has no functions other than an airlock, and lives in Utility. Anyway, Download here: http://spacedock.info/mod/865/Tiktaalik's Airlock Collection Dev versions can be found here (no promises on anything, sorry, but it IS just parts, so likely won't kill anything else) https://github.com/TiktaalikDreaming/Airlocks Still a WIP, but included: Totally cheaty airlock/hatch. A REALLY small hatch that is impossibly small for anyone who just wants to add a hatch, and is OK transferring Kerbals to wafer thin strange dimensions in limbo until they're EVAed. Future plans; A hatch and docking node set for any sizes that aren't completely ludicrous (I'm not sure if the small docking node is big enough for a sane looking hatch, haven't checked yet). So basically a part that's both a docking node and an airlock. I'll base at least one of those on the Common Berthing Mechanism. The part will be a bit longer than the existing docking nodes, but use the same widths for sizes 1, 2, and 3. Anyway, pics or it didn't happen; Note, at time of writing it seems imgur album links aren't working (if posting, you'll notice the icon/button has been removed until fixed), but I have an album of various progresses at; http://imgur.com/a/VXPd1

Yep, works fine on 1.1.3. Apart from some edge cases with wheel blocking after impacts and so on.

Yeah I switched to a cube. :-) The shown example was just for my testing. Pretty sure if it's doing anything to Ferram's code it's still calculating at least vertex positions. I used the existing mesh so I had some idea of required extra scale. eg: does it get better at 3x or 5x the original mesh size? It does seem to work nicely as a mitigation. The issue still happens under extreme loads (so far). But if I can get by with working under most conditions, I'll be very happy. I need bigger cubes!

There have been lots of questions regarding building craft and/or mods to avoid the lovely wheel blocked work around/bug/thing. However, I've been getting situations where a vehicle that doesn't have the wheel block issue later develops it. Usually mixed with the wheel moving to the upper limit of it's suspension. So it's like a suspension collapse. And it usually coincides with something like a heavy landing, so presumably it makes some sort of sense. (although the one that triggers me to ask this is a rover I sent to Duna, that was suspended by a docking port, so no forces would have been pushing the wheels up, and I didn't discover it until I got to Duna) It'd be really nice if the situation could be repaired. Like fixing a flat tire. I assume it's a cause of the wheel passing a safe distance and being blocked/locked by the code that does the wheel blocking. Can anyone think of a fix, or mod that allows suspension repair?

Or not so much. I've shrunk the drogue silliness to where it doesn't always show. I'll shrink it some more.

All roads lead to doughnuts. ;-) I've never attached wings before. For some reason, it never occurred to me. Rockets, jets, helicopter blades, and all sorts of other things, never wings.

And, well, framing the question well enough to ask, leads to obvious avenues of investigation, and fixed. Just a mesh, no render, no collider needed. Larger than the part. I just copied the part mesh, removed the render from it, and stretched it a bit and it's now happy.