• Content Count

  • Joined

  • Last visited

Community Reputation

74 Excellent

About TeddyDD

  • Rank
    Spacecraft Engineer

Contact Methods

  • Twitter Array

Profile Information

  • Location Array

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. I'm surprised @SQUAD released such unfinished, buggy mess... wait, no I'm not surprised. I'm disappointed. Parts are nice though.
  2. 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.
  3. KSP TOT is amazing tool, especially when you planing slingshots Pitty I can't use it anymore (Linux ftw)
  4. @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.
  5. @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?
  6. 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
  7. 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.
  8. 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.
  9. 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.
  10. 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?
  11. You can also grab ModuleManager.fozen and use netkan.exe to genrate ckan package (Like in Arch AUR). That is what I'm going to do.
  12. Install is quiet easy. Update 60 mod install is pretty hard. And time consuming. Maybe moderators should ban users who don't read first post in a thread? They are source of issue, not CKAN and mod devs don't care about them anyway.
  13. @Umlüx Yeah, I wouldn't count on Squad. If I recall correctly CKAN guys can mirror mods on S3. I suppose this feature will be priority now.
  14. Is even worse. Thanks to KerbalStuff api ckan files were generated mostly automatically. It's still possible if authors will host their mods via Github releases but Curse only mods have to be updated manually. Edit: There is torrent at Kerbalstuff site with all mods. Who wants 60gb of mods?