Snark

Moving to Breaking Ground Discussion.

Many, many posts have been removed. Folks. Just a few days ago, it was made clear by the moderator team here in this thread that the topic of the version lock, and arguing about it, are done. Kindly refrain from rehashing it. Do not argue about it here, and if someone else does, just report them and do not continue the argument. Thank you.

Various content has been removed and/or redacted for personal attacks and/or flamebaiting. Folks, let's keep it friendly, please. We're expected to comport ourselves like civil adults. It's fine to disagree with each other, but please do so respectfully. This goes without saying, since you're all familiar with the forum rules (right?), but apparently some folks could use a refresher: Do not make personal attacks,or speculate about other people's motives. Address the post, not the poster. Don't deliberately try to provoke people. It's against forum rule 2.2.n about flamebaiting. Do not publicly accuse other people of breaking rules. You're not a moderator, it's not your place. If you think someone is breaking rules, do not engage; simply report the post and move on, so that the real moderators can have a look. And finally... c'mon, people, have some perspective. Different people like different things. It's fine to state what you, personally, like or dislike... but other folks don't necessarily have the same priorities as you do, and their viewpoints are just as valid as yours. So arguing about that is silly.

Perhaps, but that would then require using the controller. Don't get me wrong, I love the KAL-1000 like a brother, but it's not needed for this simple scenario and I like the simple "click this one button and everything just magically works" aspect of this mod, not least because it doesn't require adding any extraneous parts.

Yep. Have a look at the source code for AutoAGL, which is my mod where I needed this. Start with the ProjectTimeUntilImpact function and work from there.

Folks, play nice, please. Various content has been removed due to various bickering, petty personal attacks, insults, name-calling, etc. Please review the forum rules, even though you're all already familiar with them (right?) In particular, Do not engage in personal attacks against other forum users. If someone else is doing that, do not engage, please. Simply report the post and let the moderator team deal with anything that may need dealing with. It's what we're for. Please do not publicly comment about past or expected future moderator action. C'mon, gang, you know better than that. Anyway, given the general level of acrimony in this thread, it appears irrecoverable at this point and will stay closed. Thank you for your understanding.

Hello, and welcome to the forums! Moving to Add-on Discussions. FYI, the best place to search for mods is generally in the Add-on Releases subforums.

The math ain't the problem. Math, I can do. No, IK at its simplest really is just about "just get it there somehow", and that's hard, that's what I am attempting to convey to you. Dude. Look. I'm a valedictorian physics major and am very comfortable with complex math. I know how this stuff works. That's not the problem. If it were simply a bit of tricky math, or even merely kinda tedious, I wouldn't have spoken in such absolute not-gonna-happen terms. Getting something to work via programming is not the same thing as simply understanding the principles "on paper". It just isn't. Lengthy spittle-flecked rant in spoiler, mainly because having spent the last few decades of my adult life as a professional software developer, hearing anyone who isn't a professional developer make an innocent, well-meaning comment along the lines of "well, here's <idea>, that should be simple to code" happens to trigger me hard. But it all boils down to "it's harder than you think. Really." And to be clear, I'm not yelling at you, @FleshJeb. Your idea is a good one, I'm glad you suggested it, I like to encourage suggestions, and it's not your fault that it's not obvious to the casual observer that this would be way, way, way more work for me than is apparent to the untrained eye. It's also not your fault that I don't happen to have hundreds of hours to spare on such a problem. Just... when I said "no" rather than "maybe", I really honestly meant "no". Not. Gonna. Happen. (And hey, I could be wrong. It has been known to happen. Maybe I'm really, really wrong and it's only several dozen hours of work instead of the several hundred that I'm pretty sure would be needed. Even in that case the answer would be no, because, first, I don't care enough about such a feature to invest even just a dozen hours into it, and, second, I'm definitely not willing to sink a few dozen hours into it in order to find out whether it's actually several hundred. IK is such a juicy morsel that I'm sure lots of people will want it. And if enough people want it badly enough, eventually someone will step up and do it. But that someone will not be me.)

IK would certainly be super cool... but it would be a great big enormous gnarly hairy piece of work, to the point that I'm not even slightly tempted to take it on. Not only is solving the IK problem for a generalized robotic limb a knotty problem in itself, but allowing the user to set it up how they want would require substantial UI design as well. Seriously never gonna happen, at least not from me. Perhaps, but bear in mind that they have several constraints there that enormously simplify the problem, compared with a general solution for arbitrary limbs. They have a simple arm of fixed physical design, used for solving a specific gameplay scenario.

Moving to Breaking Ground Support.

Moving to Breaking Ground Support. Reporting it to the bug tracker, as you've done, is the right thing to do. However, bear in mind that depending on exactly what's going on, there may not be much that they can do-- for example, it could be a Unity issue. I'm certainly no Unity expert, but my impression is that its physics engine doesn't handle high rotation speeds very gracefully. If it does turn out to be some physics engine issue, then it's conceivable that "fixing" it may be impractical.

Moving to Breaking Ground Support.

Moving to Breaking Ground Discussion

Moving to Breaking Ground Discussion.

No, that's pretty solidly in the "not gonna happen" category. Time sequence editing is complicated, and that's not something I'm prepared to take on. Besides, as far as I'm concerned, that's exactly what the KAL-1000 is for. No point in reinventing that particular wheel. And in fact, I view SlaveDriver as being complementary to the KAL-1000. With SlaveDriver in place, setting up a walk cycle (or whatever) will hopefully become simpler by eliminating the need for redundant "clone" tracks. Even with SlaveDriver along for the ride, I'll confess that I find the KAL-1000 tedious to work with for compound motions, but as far as I'm concerned, the right solution to that problem is to give the track editor a reasonable suite of track-at-a-time editing tools (e.g. invert, reverse, scale, phase shift, etc.) But adding anything like that would be Squad's job, not mine.

Moving to Breaking Ground Discussion.

Moving to Breaking Ground Support. And yes, I've noticed. My SlaveDriver mod is designated "pre-release" primarily because of this bug (the mod tickles the bug pretty hard). It's certainly vexing. Breaking Ground just recently shipped, though, and it's not uncommon to see bugs in a major new release. My observation has been that Squad is usually pretty good about patches after major releases, so I'd be inclined to give them some time to address the problems.

It's still there, for target rendezvous. For maneuver node burns, though, it's not a thing anymore. I removed the feature because KSP now provides a stock burn indicator that does essentially the same thing.

@UnanimousCoward really excellent, thanks for taking one for the team! Unfortunately it'll be a while (probably a few weeks) before I'm in a position to roll this into a new ILCE release, due to IRL stuff, but I'll definitely be looking into it as soon as I can. ReStock compatibility is the most-requested IL feature in recent months, so I'd love to get your work out there where people can use it.

Date of MissingHistory's release: March 13, 2018, i.e. 15 months ago. Today's date: June 5, 2019. Number of new models for Swivel and Reliant that Squad has released during that time: Zero. Number of announcements that Squad has made that they intend to reskin those engines: Zero. The earliest date that Squad would be at all likely to reskin them, even if they did decide to do so: Probably three months or so from now, if Squad sticks to their quarterly release cycle. But bear in mind that there are a lot of other engines crying out for reskins (e.g. Skipper, Mainsail, etc.), so even if Squad continues their gradual reskin, there's no guarantee that the Swivel and Reliant will be in the next one. So it could easily be six months or more from now, if ever. So obviously I made the right choice, by my lights. I've had the last 15 months playing with models that I like better than the stock ones (and, from the majority of feedback I've received about the decisions, most of my users like that, too.) And probably have at least another three months in that state, possibly considerably more. And it was very little effort to add them, since Porkjet did the real work. I would have added it even if I knew it would only last three months. And if anyone doesn't like it, it's two mouse clicks to delete the reskin. And if-and-when Squad ever does reskin those engines, it's trivial for me to remove the reskin at that time. This has, in fact, already happened: the original release of MissingHistory had Porkjet's reskin of the Terrier in it, too. Many months after I did that, Squad came out with a revamp of the Terrier (much to my delight), so I happily removed the Terrier reskin from MissingHistory since it was no longer needed. If that were to happen with the Swivel and Reliant too, I'd be delighted. It's not as though I want to reskin them; I want the stock game to just have models that I like. So I view this as an easy, low-effort band-aid solution to tide me over until such time as Squad gets around to those engines. But all of that is just a bunch of words. What it boils down to is this: It's there because I like it, for a variety of reasons that I've done you the courtesy of explaining here, though naturally I was under no obligation to do so. It's also the case that most of my users like that, too, which tells me that it was the right decision even apart from my own preferences. It's also the case that it's no skin off your nose if you don't like it, because you can just fix the problem with literally two mouse clicks and then it will do exactly what you want. And the fact that you can fix it with just two mouse clicks, without having to do inconvenient things like hacking around in config files, is precisely because I anticipated that there might be users with preferences such as your own, so went ahead and made the effort (way back when I first released) to make sure that it's as easy as possible for you to have what you want. Because you're my user, too, and I care about your game experience.

Well, for the answer to that, you could go read the OP of this thread (the "Why would anyone want this" section), where I made a point of saying exactly what I was doing and why, if you were so inclined. But to elaborate, I did it for a variety of reasons: Because they were part and parcel with the other Porkjet parts (the Valiant and Pug), and it bugged me for them to have a different "look" from those. And because this was happening back when Squad was giving a lot of other parts a visual revamp, and all the Making History engines had a fairly updated look to them, and I thought the Reliant and Swivel looked a bit old and clunky and I liked Porkjet's version better. And because I thought (correctly, as it turns out) that most other folks would like it, too. And because it's completely transparent and harmless because it doesn't affect their stats or their node geometry in any way, so it's a totally "safe" substitution. And because I like it, so since it's my mod, I do what I want. Bear in mind that any time any modder ever releases anything, he has no way of knowing if anyone's actually gonna download it. It turns out that MissingHistory has been a runaway smash hit, but I had no way of knowing that when I wrote it-- for all I knew, maybe two or three people would download it and it would end up being mostly just my private thing. In which case the smart thing to do is obviously to make it the way I, personally, like it. Same as with all of my mods. And because no other mods existed that did this in a way that I liked, without bringing a bunch of other baggage along for the ride. And because I know that not everyone likes the same thing, and (being a considerate, thoughtful person) I like to enable other people's play styles where possible, even when it's different from mine, even though (like any modder) I'm under no obligation to do so. Therefore (as I usually do) I made the effort to factor the config files in the mod so that it's trivially easy (just a couple of mouse clicks to delete a couple of files) to remove the reskin, if anyone happens not to like it. It's literally less than ten seconds of effort. If you don't like 'em, don't use em. So that's why.

Yes, that's unavoidable due to the anisotropic scaling. Yes, but it introduces another problem, which is far worse (for me, and since it's my mod, my tastes are what's relevant here) ... doing that would make it completely visually indistinguishable from the Z-1K battery in the parts list. I hate parts that look identical in the parts list of the VAB. I can never keep straight which is which. I want it to be a slightly different shape than the Z-1K so that they look different. Plus, making it 1.5 times taller would be inconsistent and therefore unambiguously wrong (in my personal OCD universe where consistency is important): the height of the Z200, Z1K and Z4K batteries are all about the same, so clearly that is the correct height for a stack-mounted battery and I am not going to make the Z2K be the "odd man out" there. Yes, it means the texture is a bit stretched, but for me that's a tiny minor wart that is of far less significance than, 1. being consistent height with the others, and 2. being visually distinguishable in the parts tab. If someone would like to step up and supply a non-stretched stockalike texture for the Z2K-- emphasis on "stockalike", I mean really stockalike, not "prettier"-- then I'll happily look at incorporating that. Won't be me, because I've got the artistic talent of a concussed bee. In the meantime, the stretched texture is something I can live with. I considered that option when I was first putting things together, but decided not to, for a couple of reasons. First, it wouldn't solve the stretching problem-- would just flip it around and you'd have it vertically stretched rather than horizontally. Second, that would bring along the Z4K's fancy control-panel-ish looking thing, which I don't want; for me that's a Z4K thing, and I view the Z2K as being more "spiritually akin" to the Z1K. Besides, the extra detail in the "control panel" would call even more attention to the stretched texture. Of course no hate, no worries on that score! Always happy to hear ideas and suggestions, even if they're ones I choose not to adopt. There have been plenty of times when users of my mods have proposed original ideas that are great, and make me smack my forehead and mutter "why the heck didn't I think of that," and which I then choose to incorporate into the mod. So brainstorming is always welcome. In this particular case, though: no, not gonna do that, because (and I mean this is the friendliest, most welcoming way, please don't take this as criticism) it's an absolutely awful, terrible idea from my perspective. Not a dumb idea on its own, it simply would be completely antithetical to what I want for this mod. ReStock is gorgeous, I'm sure... but it is hugely disruptive, it completely "repaves" the game, and I do not want to run it myself. Nor does everyone else, necessarily. Not everyone who's running MissingHistory wants to run ReStock. Some do, sure, but not all. The purpose of MissingHistory is to supply new things, not to tinker with all the existing things (other than a couple of new models from Porkjet that I particularly liked). I like the look of the stock game, and don't want to replace all the stock models. Furthermore, my understanding is that ReStock isn't "simply" a reskin, but it also actually introduces new parts and such, and it does some non-standard patching mechanisms for performance reasons, hand-rolling its own override mechanism for that rather than using the traditional ModuleManager-style approach. None of those are necessarily bad things. It's a major tour de force, and I don't mean to imply any criticism of it, even slightly. But adopting it is a pretty major change to one's game, and is very much a major "lifestyle choice" on the part of the KSP player. I'm sure it's wonderful... but it's not for everyone. And, in particular, it's not for me, just because of my own personal tastes. If these two things were bundled together, it would mean that nobody could get the "missing" stuff (which is what this mod is all about) without bringing along a truckload of other stuff for the ride (ReStock). Which would completely defeat the purpose of this mod. The point of MissingHistory is to be low-key. It adds a few new parts, that's all. It leaves stock parts alone, other than reskinning a couple of stock engines, and it's very scrupulously careful to make sure that it's only a reskin without affecting part geometry or any engine stats, so that it can be cleanly uninstalled if a player changes their minds. TL;DR: ReStock and MissingHistory do completely different things, and serve completely different purposes, and are targeted at users with completely different requirements. So they simply don't belong in the same box. They need to stay packaged separately, and will stay that way.

Moving to Add-on Discussions.

...though if you unbind those from the camera, how will you control your camera? What I did to solve the WASD problem for rovers was to unbind my rover control from those, and assign them to numpad keys. I use numpad 8456 for rover instead of WASD. This lets me leave my arrow keys bound to the camera. Works well for me.

Hi all, I'm pleased to announce the release of IndicatorLights Community Extensions v1.5, with support added to the following mods: Station Science continued (Contributor: @Tonka Crash) K2 Command Pod (Contributor: @VoidSquid) Thanks to our public-spirited contributors! (And many apologies to Tonka Crash, who submitted his patch way back in October and I then somehow managed to lose track of until now, because I suck.)