Jump to content

RoverDude

Parts Hero
 View Profile  See their activity

  • Posts

    9,074

  • Joined

  • Last visited

 Content Type 

Everything posted by RoverDude

  1. RoverDude
    There might be a way to sort this - that is, disregard EVA kerbals who have never been in a vessel before.
  2. RoverDude
    I have a plan for this
  3. RoverDude
    Oh no worries at all - that was not meant as a negative, just avoiding a forum equivalent of the telephone game FYI - I've considered MAVC integration (I use the full KSP-AVC myself).
  4. RoverDude
    Can you please make sure you are on the latest version of USI_Tools? You can get it from here: https://github.com/BobPalmer/UmbraSpaceIndustries/releases
  5. RoverDude
    Which I do on occasion Tho I'm hitting the point where all of the bits I had in mind are either stock, or already done. Exceptions being the Malemute (coming soon) and some new base parts.
  6. RoverDude
    While this is not my mod thread, I did want to hop in just because there's a bit of misinformation MKS-L and UKS both have mechanics for increasing supplies in-situ. Tall tippy landers are not required. MKS-L can build everything (including the drills) out of KIS boxes (and come in varying sizes). For UKS, there are some lovely skycrane, stabilizer, and wheel parts (plus nifty inflatable side-mounted fuel tanks to keep the COG low). I can't speak to part count, though MKS-L bases tend to be very light due to the limited number of parts available. Surface attach is just as likely to be kraken'y as landing a base - really depends on luck and the terrain involved. MKS-L supports both (surface attach as well as non-surface attached). Plus, as noted, a lot of what saves MKS-L from the Kraken is the disconnected mechanics (which have been around in one form or another for about two years now). Again, not tossing this out to change people's minds, etc. - just to clear up any misinformation
  7. RoverDude
    Sorry not quite following You're very welcome The best place to get my stuff (in general) is here: http://bobpalmer.github.io/UmbraSpaceIndustries/ Very nice! I think @Mynar Moonshadow might be working on one of those And yep, @goldenpsp is correct - the Karibou was actually designed to be a platform for the MKS stuff
  8. RoverDude
    The copy-paste was kinda the entire point, yes? Especially given how quickly this got spun up
  9. RoverDude
    There's no code in this one, so no hard-coded requirements for Win32 v. Win64 Try on a clean Win32 install.
  10. RoverDude
    FYI, working on infographics for the guide
  11. RoverDude
    How long was this mission? if the hab space has run out, it really depends on how long they have been stuck out there. Generally your best bet is to get a new pilot out there (or a probe core) and bring them home.
  12. RoverDude
    Best way to do that would be something similar to KSP-AVC where it can check an external source for version data (i.e. the raw version file from a github repo).
  13. RoverDude
    You can do that now - just host your own metadata, then there's never a need for SpaceDock to ever send a PR again, or for anyone to ever send a PR to CKAN. Best bit being that when stuff is reorganized, you can publish the modified metadata along with the release.
  14. RoverDude
    1. CKAN is a fantastic idea, with some flaws in execution. I've invested time (and thankfully, had a huge amount of help from my users) to partially mitigate it. Not 100%, because I can't stop CKAN's lag time, but good enough to get through the worst of it. 2. Where did I even mention Curse? I use GitHub. And within this context, my work with Squad has about as much to do with my hosting choices as ham does with hamsters. 3. Regarding discoverability - you might be under the flawed impression that we make mods for other people and care about market share. I make mods for myself, and like that I get a ton of testers, good feedback and ideas, etc. - plus it's a nice thing to do. And tbh, I have never had an issue with discoverability of the stuff I make and choose to share - both before and since CKAN came around. What I have had are more support headaches, and had to take time off making cool stuff to mitigate. 4. Again, No idea why you're even bringing Curse into the equation.... I use GitHub as my primary release mechanism, and the forums as the main place for support/discoverability. That actually is a good idea, since I know some modders explicitly do not want to be listed.
  15. RoverDude
    I believe that horse is not only out the door, it has passed through the next county, led a productive life, and has long since been turned into glue sticks. SpaceDock, which aims to be a replacement, is of course alive and well (and just starting up).
  16. RoverDude
    Well yeah you kinda have that Which is it's own rather delicate topic. But I believe the current context is whether or not CKAN (well, SpaceDock) should also get into the file distribution business using that same model (i.e. distribution without the modder's explicit and direct involvement and opting in)... which is a very bad idea.
  17. RoverDude
    Still have the latency issue. Fine as an option, but not something that should be turned on by default unless a modder decides the latency is worth dealing with vs. a publish script. The only rub is that people don't heed warnings. Hence, opt-in is the far better choice. It would also be a good idea to learn from history... the last time this community had a 'discussion' over opt-in vs opt-out, lots of bad stuff went down, to no benefit.
  18. RoverDude
    The problem with that is the same problem that CKAN has, which is polling cycle. No biggie if it's an option (and by default off of course), but personally I prefer a push API - a lot easier that way, and updates are instantaneous. And since I assume SpaceDock is going to reuse the KS one, that's a solved problem.
  19. RoverDude
    Not sure you even need a frontend to GitHub for that - it's just a release. I'm confused, because the second part of your post sounds more like it references the GitHub Wiki instead? And for that one I doubt there's an API available (and I would expect folks would want to only have documentation in one place - ideally one that has collaboration features ala GitHub, tho any wiki would do).
  20. RoverDude
    Kinda like how SpaceDock would have to be... Given that any info SpaceDock has access to in a situation where the modder has no say-so is the same situation Curse would be in. Works both ways, and both ways stink. (edit) tl;dr: Multiple hosting and discoverability choices are good. Making that choice for people either against their wishes or without their knowledge is bad.
  21. RoverDude
    Oh, the difference (and the slippery slope) is going from 'Here's where to find stuff' to 'Here, let me give you my copy of a file that I grabbed without the modder's knowledge and may very well be out of date'. Or, to bring this more in line with SpaceDock - I would hope (and expect) that they would not include mods on SpaceDock unless a modder explicitly uploaded them to that service. Reason being, that if there's a distro floating around that I'm not aware of, it causes support headaches as I can't guarantee it is 100% in sync. This is why I did not toss mods on KS until I had an automated way of doing this with the same automation tools that I use to publish my GitHub release - which makes my job easier, and guarantees I have no weird versions floating around. So in short, and based on what I've heard since the original post, as long as SpaceDock stays in the 'upload stuff here if you want to share it' vs. the 'let's find everything to share and upload it ourselves' model (even if that latter case respects those of us who host our own CKAN metadata) then we're fine. If on the other hand, we as a community insist on putting tomatoes in our fruit salad, then you're going to see a lot of changed licenses. Or, to spin it around, imagine how folks would feel if Curse started pulling all open-license mods and adding them there without the modder's knowledge just because the license said they (technically) could.
  22. RoverDude
    Nifty work! Just a few things from reading the past pages. This should absolutely be opt-in. In my case, given the velocity of my releases, and the support issues that disparate downloads cause, I'd just as soon have complete control of precisely where my stuff lives. I will of course at some point upload to this new site - but not before I have the process automated, since otherwise I get a ton of unnecessary work. Again, opt-in is the right way to go, for a variety of reasons. Also - RE @Yemo's note: " 4. Spacedock as a frontend for KSP-AVC version checking/updatingMaybe ability to auto-generate .version files and add them to the zip file for the distant future? " This is a very very very bad idea, given KSP-AVC works in precisely the opposite way. I push a version change to GitHub's release branch, and everything else drives off of that. Checking? Fine. Updating? No bueno. I like the idea of having alternate delivery and discoverability mechanisms. I do not like the idea of workflow being dictated, or things being distributed/changed without it being explicitly done by the modder, regardless of whether or not the license technically allows it (again, let's separate 'what we can do' with 'what we should do'). Or, to paraphrase Philosoraptor, just because a tomato is a fruit does not mean we should put it in a fruit salad.
  23. RoverDude
    That would be the system working as designed Think about how we'd do an actual mission to Mars, etc. Yep, slowly working on it
  24. RoverDude
    Good deal - yep it should all be sorted now Replacement Parts should be automatic, but I'll check that. And looks like we're missing a part for MKS-L for fertilizer support (I'm going over all of the docs now, so that should be sorted in an upcoming patch - for now, ship it in). RE Nertea's stuff (which is awesome) I would agree the best place for such a patch is his mod, not this one.
  25. RoverDude
    What I will very likely do is just remove the rear stabilizers then if this is something that only manifests with the command cab. Need to update the model anyway to have some larger ladder/airlock colliders
×
×
  • Create New...