TeddyDD

I took a F16ish jet to a ride in the storm to test the new version of Blackrack's clouds. They are stunning.

Might be related issue: https://github.com/Gameslinx/Tessellation/issues/127

Same here but on reverts [LOG 15:15:17.481] [HighLogic]: =========================== Scene Change : From FLIGHT to FLIGHT ===================== [EXC 15:15:17.483] NullReferenceException: Object reference not set to an instance of an object Parallax.ParallaxInFlightOperations.Update () (at <40e34d3c09734e828597afb2f90e2e92>:0) UnityEngine.DebugLogHandler:LogException(Exception, Object) ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object) UnityEngine.Debug:CallOverridenDebugHandler(Exception, Object) Have you, perhaps, found a solution?

The game on ESA presentation looks like an unoptimized, buggy mess. Physics seems to be exact same engine from KSP1 (laggy noodle rockets again ). Before ESA presentation, I was set on buying it on day one. Now I'm not sure anymore. I can wait for colonies, multiplayer, interstellar and even for features from KSP1 to be ported, but I expected rock solid foundation.

I'm excited to see what modders will do with KSP 2.

I'm surprised @SQUAD released such unfinished, buggy mess... wait, no I'm not surprised. I'm disappointed. Parts are nice though.

Not true at least in my case. I'm playing since 0.13 I can plan and conduct interplanetary mission including slingshot with pretty good precision (KSP TOT is amazing tool). But usually I stay in Kerbin SOI. Why? I'm playing in semi-realistic roleplay style. I wont put three Kerbals in tiny capsule and send them in three years long flight. Interplanetary takes lot of time and effort to plan. I don't have much time to spend on KSP. Unmanned are easier, but they usually are satellites (rovers and driving sucks in KSP so much...) And planets are pretty boring in KSP. Nothing to do, flat surface, flat, blurry textures. Thankfully Mun have quiet interesting terrain. When I want to play game about planet exploration I play Take on Mars.

KSP TOT is amazing tool, especially when you planing slingshots Pitty I can't use it anymore (Linux ftw)

@Malah Nah, don't worry, with all policy changes and proposal to split the repo into stable/stagin some downtime is inevitable. Only thing that really made me angry is this thread: I'm not sure if @passinglurker tried force CKAN to change policy this way or this is supposed to be way to kill CKAN by unjustified censorship and blocking any possibility to talk about issue. Either way this is pathetic.

@RoverDude Well ok. I agree. Lets focus on official, op-out repos now. We can think how improve user experience for advanced users later. Edit: Gods, this forum hates me. I want everything to be markdown ;=; How to reference user?

It seems there is wip project like that here "We will encourage you to develop the three great virtues of a programmer: laziness, impatience, and hubris." -- LarryWall My favourite quote

That's your opinion. My opinion is that nothing justifies user that don't read frigging notices in authors thread and ask for CKAN support when author clearly say "NO CKAN SUPPORT HERE". De-listing, staging repos and everything else is just workaround to people stupidity ¯\_(ツ)_/¯ for me its EOT Thats why me and @blu3wolf are insisting on creating unsupported, wild repo that would contain anything. (btw I'm interested in your idea to rewrite CKAN. What would you change? What kind of metadata would you use? What language? Could you drop me pm about details? ) Sure, you can be against this, you and other moders can force CKAN to not create that kind of repo. But someone outside of CKAN will create it sooner or later. Neither the modders nor CKAN will be able to stop this. So it would be better for everyone if that kind of repo would exist as part of CKAN, assuming it would be available for people who know what they doing. But this is not priority now IMHO. Advanced user still can generate ckans from frozen netkans. And there will be plenty of more important work now. Edit: I have no idea how to reference users on this forum software, sorry.

From what i learn in this drama - users are idiots that can't understand this simple sentence. This. Generally I love idea of unsupported repo as long as that stupid users won't use it.

I'd like to have unsupported repo for advanced users but I this one must not be opt-out to make sense. Therefore it should not be part of offical CKAN to not cause controversy. I wouldn't call it done since many modders passionately hate CKAN, and most don't care about it. I agree that manual edition of JSON file is not something that average mod autor cant handle. But for example, looking for deps is tedious since you have to use identifier instead of name. This could be streamlined a bit. Also I know CKAN metadata quiet well but I'd like to have tool that visualize package relationships including provides/conflicts trick and virtual packages. License don't apply to metadata but I'm not going to suggest that we should force this mod into official repo. I'd rather work closely with authors of such mods to ensure metadata is rock solid.

I'v gone through the thread and I'd like to sum up things that could be done to increase CKAN metadata quality (before I open an issue at CKAN) 1. Add "maintainer" field to metadata. This could work similar to maintainers in AUR 2. Split CKAN-meta into two repositories: CKAN-meta and CKAN-testing (or staging, whatever). Those repositories would be opt-out for mod authors of course. 3. Don't accept .netkan without a maintainer. Automatically inflate .netkans provided by mod author to testing repo. Inflate .netkan to staging that is provided by third-party maintainer only after manually checking generated .ckan by human. Eventually create new repo for unsupported netkans that advance users can download and inflate manually. 4. CKAN-meta: only packages with maintainer move packages from testing here after checking they are correct If package lost maintainer then move it back to testing. 5. Point users looking for help to maintainers. This could be by adding "repot a bug" button to CKAN gui. 6.? Create separate bug tracker for communication between users and maintainers. CKAN-meta issues would be used to communication between CKAN maintainers, developers and mod authors. 7. Add fast and reliable mechanism that would allow mod author to nuke specific .ckan (move it back to testing) probably using bot. This is must in case one specific release of mod would cause trouble. 8.? Setup special policy about "core" mods. By core I mean packages which many other packages depend upon (like ModuleManager etc.) This mods should not be pushed back to staging without warning. 9. Encourage authors to manage metadata about their mods. Who knows better how mod should be installed that the author? Write tutorials how to package mod. Show modders what advantages CKAN gives as package manager. Create easy to use .ckan/.netkan editor that don't require messing with JSON. Provide any help they need to understand how CKAN works and how to package a mod without hassle. This is critically important point! Mod authors providing metadata means that CKAN maintainers could spend more time on testing packages than packaging mods. It would also decrease importance of Netkan witch is good! Netkan as automatic tool is error prone and should be used as helper not as main tool to create metadata. Imagine this workflow: Author wants to release new version of mod Author have a .netkan file for his mod he/she upload the mod to Spacedock and generate .ckan file using netkan. If file is correct, author is pushing it to testing repo (or even directly to main repo) If generated ckan package is broken is pretty easy to fix it manually since author knows how CKAN works Author edits generated ckan file (5 minutes of work) and sends it to testing repo In this example .netkan is just a helper. I best case it generates end-user metadata, in the worst case it helps in writing metadata by hand. Any suggestions?