mjl1966

Can you attach/detach items from the pallettes (trusses/truckbeds) in situ? i.e. can I drive something somewhere and then unload it with the forklift or some such? If not, no problem, was just wondering if that functionality was in there.

Are the page handlers for MechJeb in a config file or are they embedded in your code? (i.e. - can I tinker with the MechJeb page handlers or are they locked away)

Thanks guys! This gives me something to go look at. Much appreciated.

HI everybody, Having a little trouble getting the parts to show up in the VAB UI. I manually installed 5.2.95 on my 1.0.5 KSP install. Opening sandbox session, I see lots of parts from other devs like Wild Blue and USI that act as "launchpad", "target" and "workshop", but I'm not seeing any EL native parts except for rocket parts cans and survey stake. No orbital workshop, augers, smelters, orbital docks or launchpads. Is this normal or should those things be there? Thanks!

Vanguard iota. It is perfect for landing trucks on the Mun.

MechJeb. Engineer Redux. Docking Alignment.

You're a step ahead of where they are right now, and it's a step they're hoping to avoid. The modders are complaining, but, as a community, they would still like to work out a solution where CKAN co-exists in their universe in such a manner that it doesn't load up their support pages or result in broken installs. Refusing to support it outright and moving on is the next step if negotiations fail. We're not there yet. They're trying to avoid that, as strange as it may seem. (MOST of the dev community, I should say. There are a few that are already at the point you describe and probably aren't coming back.)

out - freaking- standing post. Dead on.

Alrighty. Well, I dare say Sarbian's broomstick is heftier than yours. If that's really the way you want to play this out.

This! I have dabbled in Unity. Written C# scripts. Made a nav ball. (That doesn't use quaternions!) Played with collision physics. All of this was quite difficult - BUT the assumption that "something isn't hard for somebody who can make a mod" is the WRONG approach. After sorting through libraries, scripts, chasing down workarounds around "that one bug", and engaging in other mind-numbing details of coding, the LAST thing a dev wants is another layer of difficulty. I can write C# code. I know squat about JSON, metadata files, netcan files and ckan files. If I had a mod I wanted to publish and came across all that, my first response would be, "screw that, I'll just post it on Curse." (Are you listening @blu3wolf?) To assume that just because people can do hard things means they want to do hard things is a fallacy. Devs are willing to do hard things for their mod to make it cool. They're not that motivated to do hard things for something like CKAN. So, number 9 here is spot on. Make it EASY for devs to "post" their stuff to CKAN. While you're at it, support the users with installs so the devs can take that off their plate. What would "easy" look like to me as somebody who knows zero about CKAN indexing? Web page with boxes where I fill in name, version, url and a blurb. A dropdown box with other mods that may be dependencies. If it was much more complicated than that, I would lose interest fast. Devs like easy, too. They really really do.

This is the result of ... a very long argument. The point being made here is that mod developers have no obligation to support CKAN. Zero. None. And - it really can't work without their support.

So, looking through the IRC log, it seems you fellas have been spending the last day doing what needed to be done: talking about it in committee. So, there you go. I kind of fell silly for going on and on about "hey, you all need to work this out," when that's exactly what you've been doing. Looks like you guys have it in hand and I'm sure you'll get there.

I hear you; but I think the context here is different in that it's a closed loop community with a fairly small distribution network. I may have been overly dismissive of licensing - I just don't think it's central to the real solution here. Thanks for adjusting the rudder, as it were. Good post.

CKAN is not a distribution point. It is a collection utility. If you put your mod on the shelf in the grocery store, CKAN walks in and "buys" it, walks out and hands it to somebody in the parking lot. A seller has no control over that. The websites where the mods are hosted are the distribution points. CKAN is just a "shopper" installed on the end user's computer. It's not different than a web browser in that regard. One more time: "licensing" and other legal remedies are non-starters.

The challenge there is that CKAN can be rightfully called a web browser. It's just downloading using URLs. Then it installs, which is between CKAN and the user at that point. You can't tell people which tool to use to download their software. They can use a web browser, command line ftp or CKAN. They all do the same thing. All it's doing is automating the process of clicking a URL and dragging folders. It's a real loophole situation. There is no elegant legal solution here. This is why many of us keep trying to steer the conversation away from licensing. Licensing will neither help nor hinder - only cooperation will save the day CKAN.

I'd think twice about the whole copyright issue here. Licensing is about copyright holders granting permission, not being forced to allow a free-for-all with their software in ways they did not anticipate. That the CC license is a "promise by the content creator" to do anything, especially in the face of repeated documented requests and demands that somebody stop distributing their copyrighted material, is good fodder for a legal debate, one which would not result in a cut and dried verdict in federal court. Especially since CC is not intended for software. The license could possibly be held null and void on those grounds alone, in which case all that remains are the cease and desist demands. Have a nice day. Debating the issue based on copyright law is foolhardy - it is a complex and difficult domain of law, especially when it comes to derivative works of software, which nobody here is qualified to interpret and understand. Just because we can all read about it at Wikipedia doesn't mean we know what we're doing. We don't. We really really don't. Law is the LAST place anybody should be looking to resolve this issue - as any lawyer will tell you, "It depends." Common sense and common interest are far more appropriate tools here. Continuing to use standardized licensing intended for published works of literature and photography as a primary justification for actions that are contrary to the wishes of developers holding copyright on software is just asking for trouble.

While we're at it, perhaps it's prudent to acknowledge that it *can* be nuked by the people without whom it would not exist: the devs. I have yet to see an acknowledgement that their concerns are at least understood. Without their content, CKAN has no purpose. We should pause for a moment and remember that.

Funny you should mention that. CKAN is itself under an MIT license and the code is readily available. A def-friendly tool could be derived from CKAN itself.

It's blazing terrible .. Oh the humanity!

That breaks a key dependency for many mods, yes?

Would actually like to hear @politas stance This is the heart of the matter: CKAN installed a mod in a way contrary to the dev's technical requirements. What is the generally accepted, promulgated, understood and practiced process for handling this? Answer for most users: either "I don't know" or "post on dev page." (Hey, I installed your mod and it's not werking.) Can that process be improved? How? Can we agree it needs to be improved?

And the community has lost a valuable asset. Your engines are my go-to for just about everything. And I think this is an example of how this problem is contrary to consumer interest, not just producer interest.

Alrighty. So, what would be your position on the following scenario? (This happened last night.) I reverted back to 1.0.5. I used CKAN to install MKS Lite. Although CKAN was able to detect that my version of KSP was 0.5, it downloaded and installed 0.4 version of MKS Lite, which does not work with 1.0.5. I manually donwloaded and installed the correct version (0.3) Would this qualify as a problem caused by CKAN? Although most problems are the other way around (older mods on newer KSP builds), the principle is the same. CKAN installed a mod incorrectly. In such a scenario, who should I, the user, be talking to for support?

Well, there you go. I hope it goes well; this problem is hurting the game. We need happy devs. Yeah, we're the symptom. Trust me, I know exactly how these devs feel when they get by bombarded by a bunch of support questions that are from something totally beyond their control. I know Roverdude is a big ol' softy, but even he's barking. That's bad. For my part, I know how to copy files and have even written some C# scripts in Unity, but I really do like CKAN for organizing things. I think we're better off for it. But we *must* have happy devs. I really hope they can find some common ground on this.

I think the problem is distribution and installation, not licensing. Currently, automated distribution results in a massive increase of erroneous distribution. And it's really liquiding off the devs who have no control over how their mods are handled by that automated distribution. So much so that some of them just want to shut the door and give the world the middle finger. (I can sympathize. Technical support sucks bad enough without automated workload that really could be avoided.) I'm willing to bet that if they can get a hand in controlling what goes into the hopper, this whole thing can get resolved right quick. Roverdude says they're working on just that, so maybe some progress.