TiktaalikDreaming

Oh gawd. Some of this mod is awful. The UV unwrap is giving me cancer. I'm quickly testing shifting the airlock trigger box, as I suspect it was just being obstructed by the ladder triggers. But I may just accidentally completely revise all the UVs and textures. That will take a bit longer than moving a box collider though.

I'll take a look at that hatch. It's been a while since I've even looked sideways at this mod.

Could I get some logs? I don't use the other mods mentioned, and haven't tested with them. But the way it fails is reminiscent of old memory limits, but that wouldn't normally be triggered by the updates for those mods as far as I know. But there will likely be hints in the output. There could be something in the koose triggering something in one of those mods.

I've never used remote tech except for when it's part of the realism overhaul package. And I certainly don't claim to have any clue about the config for it. Are you saying the module "ModuleSPUPassive" should be removed? Or is there maybe something adding a default antenna passive in a first pass that then has the patch adding the regular antenna module after? That would be easily fixed with some module manager before after tags.

Such a part might work on egress, by selecting a kerbal, and then eva, assuming it was the only batch on the craft that wasn't obstructed. But during ingress the game definitely checks for a spare seat on the part with the hatch.

You don't "live in a Rule of Law". Countries (sane ones anyway) are governed by a rule of law. But people live in societies. And, so far, the KSP modding society (societies are always nebulous) has generally stuck by the "ask first" policy. [snip]

I've updated and made a github release, 1.1.12, but I still haven't been near a pc I can test it on, so I don't want to try pushing it to Spacedock just yet.

Ah, that makes sense. I'll update. Thanks

While you're technically correct when a mod has no copyrightable material (added that although it doesn't apply to kjr, being all code, but we're in a brand new thread now) I think we'd all still prefer a community that at least tried contacting the original author for guidance and permission, even if it's not strictly required. Note, I'm not saying such efforts have not been made. And the license can include any terms the original author thought were requisite for re-use or repurposing. I just kinda made my comment in response to people claiming things were "open source therefore just steal it". Obviously the best way forward is to create a new thread and leave a post in the old thread pointing at the new one. And possibly a minor rename like adding "continued" or "redux" to the name. Although with the added libraries, maybe name it KJR2?

And I'm somewhat bizarrely the thread starter. So in the theme of internet things everywhere I feel I need to loudly claim First!

The parachute code does actually honour the names in the config. Having the out mesh called something else won't stop it working. It was the code that calculates vessel height and so on that was hard coded to the mesh name canopy. There may be other joys out there as well. If a chute isn't working, just go through and check all the unity names match the names in the config, especially the two animation stages. And sometimes you might need to reimport your blender object if things changed, and rebuild the unity game object. Some changes don't cascade through to the existing unity hierarchy, especially with legacy animations.

There's having a legal ok and there's not being a <redacted>

[Moderator note: This thread was split off from the Kerbal Joint Reinforcement thread, since it diverged into a long series of posts which are off-topic for the KJR thread since they're about general licensing / etiquette issues.] While true, I think any coding modder that could do this justice, would prefer a polite handing over of the torch, so to speak.

Check LGG's hints. Just for the record, I tested in Chrome and Firefox, following , unfollowing and following again a couple of mods. All seems to work fine. what browser are you using, and which version? And what screen rez? I notice when shrinking the browser window size, at some point it decides to stack the download and follow buttons and make them full width. While at larger widths, it has them side by side; So, if for example, you can't see your login name near the "Welcome, <username>" bit, then maybe there's something funny going on with the screen width detection? I'm grasping at straws here though. Moar info needed.

LOL. Well, I never really expected the variable names to make complete sense, but I'm, whatever. I am thinking of redoing or tidying up some parts at least. And in this post 1.3 world I could just use part variants. But I have quite a back log of things to revamp, and this isn't high on the list because it doesn't look awful. But at some stage, I'd like to fix a bunch of issues.

mmm... checking the module, I'm not sure if it's actually an option. See Public Attributes of https://kerbalspaceprogram.com/api/class_module_jettison.html You could try isFairing = false, but I have no idea what that does. Otherwise try flipping some of the various true/false things, or setting the bottomNodeName to something that isn't top or bottom (so it would not trigger the fairing for any attachment). Generally, if you want edits without stuffing up future updates, the gold standard is to write them as Module Manager patches. So, for example, you create folder in GameData for just your own custom bits, and add a whatever.cfg file and put in something like; @PART[mk2to3ServM] { @MODULE[ModuleJettison] { @bottomNodeName = notbottom @isFairing = False } } And assuming you have ModuleManager (like 99.9999999% of KSP players) then MM will edit ModuleJettison on that named part and edit those values. To add new variables, just put them in without the leading @

I'm the right click menu, you can turn it off in the VAB. You can't alter the default on v off for the part without editing the cfg file or writing an MM patch.

Well, at least on desktop it doesn't jump around all over the place. Not saying it then becomes my favourite web content editor, but it stops being next to unusable.

That's a good idea actually. Preanswer some of the "does this work in 0.80?" questions. I'll do that once at a computer. Editing forum things on mobile is still pretty horrible.

I always forget the forum thread title.

Yes. There were no changes required.

Starting to play with part variants using the stock module.

Released in all the usual places as 1.1.11 I've also noticed it wasn't marked as 1.5 kompatible. So, 1.1.11 is OK in 1.5. Technically, I think just about any part mod should be fine going from 1.4 to 1.5 without any work. Maybe some mm patching for module issues could theoretically need updating. But as far as I know there's no part file things that would have been made incompatible. There's some new options, but the old stuff still all there. Now, just to go through all the stuff I have and mark it 1.5 on spacedork.

I keep meaning to get to this and keep forgetting when I'm anywhere near a pc. But I realised what this will be. Engine heat in ksp is multiplied by the engine part's mass but in this case, the part is the whole pod. And I added heat in the config as if the part was just the SRB. So the whole pod is heating up as if it was the housing for one giant SRB rather than a pod with some advanced fireworks scale rocket attached. I shall fix shortly.

Since messing around with these things in Realism Overhaul, I've been strongly considering some 30's/40's vintage mini SRBs for ullage. That A-12 stages waaay too early in RO, the air is still very thick, and you'd need some serious ullage. Coating the A-11 in these red suckers would probably do the trick.