TiktaalikDreaming

A quick example of what I mean as troublesome, http:// kspmods [.] net/ (after editing this a couple of times I've realised the forum is auto mangling my links, awesome. If it's still mangled, kspmods dot net is the offending site) Don't bother complaining, a bunch of us tried some time ago. That's when I started including text in the readme with stuff telling people where to get the latest versions.

Just a thought. Many of the various share-alike licenses are a bit vague on how exactly you should give credit. I can see there's credit given for much in an early post here; That alone probably took a bit of compiling. I think (seeing as many people would be grabbing this without ever seeing the forum posts) that including the text (I would hazard a completely un-official legal opinion, with no weight) without any of the hyperlinking etc in the license text file that's part of the mod would solve many grey areas about whether attribution was given. The license files are generally included with mods, because that way they get moved around with the mods, even when dodgy sites re-upload them (I've had that happen, great fun), or whatever. So, it solves the issue of "did you include a note of the original license" that seems to always be in the creative commons type license stuff. I personally, like the idea someone's used some assets of mine. I only started getting fussy when there was a site uploading old copies of things, often with the wrong info. But re-use in a different mod doesn't worry me, and @FreeThinker has clearly aimed at attributing sources. I just think putting the license in the text file avoids possible excrements. For a bunch of reasons. end of my 2c Carry on.

You can just download a zip from the "clone or download" button. I just didn't think of checking. Game loads.

Ha! Thought I should check dates. I was grabbing the bundled release zip file. Um, from 2015. I'll grab the current files.

OK, poking about at different mods it is then. This mod-building install has no TCA or trajectories. I should have TCA for working on some tweaks for a different mod, but it's not there. But there's other stuff, and some test code for other things. It may be easier to just make a fresh KSP. OK, I'm going with "this stuff hates my PC". Fresh KSP, nothing but module manager, Squad and the UmbaSpaceIndustries folders in GameData. Gonna remove MM as well. And try a steamy file fixup. The basic version still works fine. I also tried adding that first, and putting this over the top, in case there were missing files.

@helaeon, is the stuff you've done compiled against KSP 1.3.1? I'm getting crashes. And before I go off diagnosing which other mod might be interfering, I thought I should check.

I'll certainly take a look. I'm not really sure when. Stupid life.

I've only been half following this, but it looks like about time to take a gander. warp factor slide to the end Mr Sulu!

After my foray into micro service bays, and a version that includes an antenna, I have burnt some time trying to work out if I can get a dish to expand using a baked cloth simulation for a foil based parabolic antenna. I'm still not sure what the answer to that is, but the rough version is "I probably won't be able to make it work". So, to target something I know I can make work, I've turned my attention back to those docking ports. Now, I've configured the top surface area to take stock docking nodes. So there's no need to have docking nodes. But this thing does date to Apollo era, and I always wanted to animate my docking probe whatsit. So, I've rejigged the old node, removed duplicate bits, broken it all up, UV unwrapped it, animated it and re-duplicated the rotationally copied parts. There's no textures yet, just a generic "chrome" applied in Blender, but it now looks like; Next up, the rather boring female end of the docking pair.

Agreed. The only F-1B I know of is the recent redesign based loosely on taking apart an old F-1, with the view to using it for an early version of the SLS.

Surface Attach Backwards OK, I should be going off to work about now, but I've just struggled with an issue and couldn't find any info on it (possibly due to lack of google-fu). @Nertea had the solution. It wasn't actually a problem with my part at all. So, what was this problem? I'm going to try to describe this as many different ways as possible to have it match searches well. I made a mini cargo module that can fit where the chutes go. You should only need 2 chutes, so the other two slots are meant for either redundancy or other things. The issue I was having is that when I went to attach parts, aka use surface attach, the parts would rotate around so they were attached to the other side of the part. What would be the outside, except of course that means inside the rest of the craft. Here's a thermometer; This is clearer; I checked the colliders were all set up in Unity correctly. Went back to Blender and checked the collider normals (which afaik unity ignores for colliders, but, gotta check all the things); So, turns out there's zero wrong with the part. So, players will also come across this (possibly it's common knowledge, but spending time making parts, doesn't lead me to finding this stuff out). The "snap to" option, for angle and position, doesn't handle inside spaces worth a damn apparently (at least with thin fiddly colliders, maybe it's OK on those big shuttle cargo bays). Never occurred to me. Turn it off, and suddenly the inside spaces are available for you. Hopefully that's wordy enough a description to show up next time someone searches for this. And also forestalls a wave of people asking this for this very part.

I am still alive. Been a bit snowed under with work and so forth, plus it starting to get too hot here to think straight. But, I've been slowly progressing on some parts to round this out. Since adding the revised ascent module system, I've been meaning to add these;

Considering RSS doesn't claim to work in 1.3 yet (spoiler :it does anyway) I think begin off by the third version increment is fine. IMHO

Call it kerbal mythos then. Same thing as the evil word, but triggers less arguing and moral panic. Or, culturally propagated shared delusional framework.

The KSSpresso has made it to the github sync. I'll pack and release an update for Spacedock shortly.

Nice, and gratz.

um... what you do in the privacy of your own home is of course fine, but there's such a thing as oversharing.

Many were made to go in a science lab part. As far as future expansion is concerned, props are the sort of thing I do as sort of a still life practice thing. A great way to practice 3d.so there will be more. Working on a ksspresso at the moment (see ISSpresso). Which isn't a lot more than a box, but your Kerbanauts need to relax with a cuppa from time to time.

I posted it 'cos it took me a while to work it out and a few attempts. I have previously thought the :HAS[] thing was just for modules. eg: :HAS[moduleEngines]. All I can say is Yay for Alt-F11. I'll be adding the above patch to the Nexus, and similar ones to the USAF Orion and associated bits. And changing the patching for the MEM. At the moment it chooses North American Rockwell in the presence of Realism Overhaul, but it'd be better to pick it if it finds this.

So, playing around adjusting mods, seems the following MM patch style works fine, @PART[*]:HAS[#manufacturer[Konvair*]]:NEEDS[CommunityRealAgencyPack] { @manufacturer = Convair } This is obviously an example. If you wanted more detail you'd do specific parts, rather than blanket changes. EG: If changing the Saturn V you'd switch the whole lot to NASA, or switch parts to Boeing, NAA, or Rocketdyne, ... etc. And doing a part specific MM patch is pretty obvious, but I was wondering if I could blanket change a bunch of parts, and the answer was yes.

No, props can't really do that, although you could link switches to actions. They're just static furniture to make the IVAs look more interesting.

Just a quick note. As I moved a copy of my ModPod props into the NAR MEM mod, and was basically running with two copies, I've created a new mod with just the shared prop assets and will mark that as a dependency going forward. At the moment everything still points at the mod-local prop assets, but once netkan updates to include the props, I'll mark it as a dependency, then update the two mods to point at the new(ly renamed) props. So, if manually installing, I'll be packaging the prop mod with these, so it will still be a case of unpack all the GameData stuff. If using ckan, it should be automagic. After I wrestle with netkan

Just a quick note. As I moved a copy of my ModPod props into this mod, and was basically running with two copies, I've created a new mod with just the shared prop assets and will mark that as a dependency going forward. At the moment everything still points at the mod-local prop assets, but once netkan updates to include the props, I'll mark it as a dependency, then update the two mods to point at the new(ly renamed) props. The latest version of this mod on either spacedock or github references props in TDProps. The CKAN file marks that as a dependency. It's also included in the zip. There's missing ddsification on the spacedock version because I usually copy and tidy up the mod to a build folder, then DDSify it, then pack and upload it. I cleverly DDSified the dev folders and didn't notice until after I uploaded. Corrective action expected later today. So, if manually installing, I'll be packaging the prop mod with these, so it will still be a case of unpack all the GameData stuff. If using ckan, it should be automagic.

This is a pack of the Props I've been using in the ModPods mod and NAR MEM (aka NKR DEM). Rather than keeping duplicates, I'm splitting this off to a mod to mark as a dependency. On it's own, this does nothing. If you're creating IVAs, feel free to use the props, although they're really not very polished yet. They're also more furniture pieces than gauges etc. But if they help anyone out, then that's good. Available from SpaceDock: https://spacedock.info/mod/1546/TDProps Or Dev version on Github https://github.com/TiktaalikDreaming/TDProps Album (hopefully imgur don't change their embedding again)

OK, updated the spacedock (and thus also ckan) edition, plus the github release. The other issue was just rushing the config change from moduleEngines to moduleEnginesFX, and skipping the link to the effects. Exactly what the issue looked like. I also spotted the surface effects weren't linked to the actual thrust transform and fixed that. And the smoke generation is now larger for the larger engine. https://github.com/TiktaalikDreaming/ModPods/commit/fe38eef6b0ec9b9cbb5cadc994ecd70f8ae0f40f#diff-9f6308e4bd85b6945778f2e7a6596a1f Thanks again @Capt. Henry Morgan