magico13

Members
  • Content count

    2488
  • Joined

  • Last visited

Community Reputation

1605 Excellent

3 Followers

About magico13

  • Rank
    Capsule Communicator

Contact Methods

  • Website URL http://www.youtube.com/themagico13
  • Twitter @themagico13

Recent Profile Visitors

3357 profile views
  1. There is now. I haven't actually tested if it reads the config correctly, but a config file will generate after the first scene change now (ScrapYard/PluginData/ScrapYard.cfg). That will likely change in the future, but I figured I could at least make that really quick. Also, there's a new dev version of StageRecovery that supports ScrapYard now. Oh, to everyone, if it wasn't obvious, ScrapYard requires ModuleManager but doesn't currently come with it. I'll fix that later, but if things aren't working right and you don't have ModuleManager, that's why
  2. For the first, as of right now ScrapYard doesn't override funds. It's been set up in a way that should let it, but that setting is off right now and the UI wouldn't actually update (yet). For the second, yes I plan on integrating the two but I haven't gotten a chance to yet. I can make that happen pretty quickly, maybe even tonight as a dev build.
  3. Alright. I know there was a build of the dev version that had this problem so make sure you're up to date. Build #15 should have fixed that issue.
  4. Is this with the 1.1.3 version or the 1.2.2 dev version? The only way I can think of that happening is if the persistence data isn't loading correctly, which would be a pretty major bug. Or if the vessel is just not being removed, which is also a fairly big deal. I'd definitely like to see logs if you can provide them, preferably with the "debug logging" setting active in the KCT settings.
  5. Another quick update regarding ScrapYard and KCT. Per the ScrapYard Trello I am a bit behind schedule. Some IRL stuff came up this week so I didn't get to spend as much time on things as I wanted, but it's not a serious set back. I also spent a bunch of time working out some bugs and integrating KCT and SY together. The good news is that KCT and SY are at the point now where they work together, but not every case has been covered (scrapping works and even doesn't count as a "recovery" so it can be used for ordering parts to put in the inventory, but I haven't looked at what happens with recovering a vessel to storage). I'm very happy it's gotten to this point where it's actually almost a functional thing with only final tweaks and improvements needed. One fairly major change is that instead of parts automatically being pulled from the inventory and applied to the vessel on rollout, the inventory is applied within the editor and then the parts are removed upon build (either KCT build or rollout). It may not sound all that different, but it's a decent sized shift from how the inventory worked previously. It also opens up the option to have a UI that lets you grab specific parts out of the inventory and place them on vessels. For now there's just a button that will automatically apply the inventory to the vessel in the editor. There are a few known issues that I'm going to try to fix regarding that change. Symmetry is a problem, since if you pick up a part that's had the inventory applied then all symmetry partners become "fresh" parts and you have to reapply the inventory if you want them to be inventory parts, which makes it harder to manually define which parts should be new and which should be from the inventory. That will still be an issue (potentially worse even) when it moves to the UI that lets you select individual parts. There's also an issue where when you build a vessel in KCT the parts in the editor will still appear as if they're pulled from the inventory, but those parts are already removed from the inventory from the previous build (it makes sense when you see it, basically it's "cache invalidation"). I've got a solution in my head for that, basically to just replace them all with fresh parts whenever the parts are removed. The main other feature I wanted to have at least partially done by now is a way to define which modules are tracked. That's not done yet. At this point I wanted to just have the ability for the user to make a list of modules in a config file. That's ultimately a really crappy way to do it but it's the way it works internally right now. That causes problems with parts before and after installing/removing a mod being treated differently than before (for instance, if you track tweakscale (true by default) and then install it later, suddenly your entire inventory is no longer valid since they don't have the tweakscale module on them). For the tweakscale problem I'd like to just not track the module if the scale is the same as the default scale, but there's not a good general way to do that. Also, it might not be a good idea to track every part of a module, but instead just the relevant ones (the current scale for tweakscale, for instance, but if "staging" is different then that doesn't make it a different part). Also, the PartUpgrades system is defined by a node within every module that is empty by default. ScrapYard needs to track that inner node for every module but is currently not designed to do so. I don't want to hard code any exceptions, instead making the system general enough to handle everything in a user-defined way. As such, I don't think I'm going to even do the basic "here's a list of modules you can change" since that's just going to be rewritten anyway. The proper way of implementing this system is gonna take a while and I have to figure out exactly how to make it work. For instance, how does a user in a config file say to track the TweakScale module only if the default scale on the node is different from the current scale, but in a general way that also works for other modules? I've got ideas for it, but I need to play around with it for a while until I find something that I like that isn't also a pain to use. There's my weekly wall-o-text about progress. TL;DR: Slightly behind on the configuration front because I want to do something better from the start regarding module tracking. KCT and ScrapYard are working together now but it's not finished. Feel free to test that out on a save you don't care about and let me know how broken it is Keep in mind that everything is still Alpha quality and there's a 95% chance it'll break stuff.
  6. Figured it out, it was a really stupid mistake. I started caching the build rates a little while back because of changes to support Custom BarnKit, which resulted in building levels not always reporting correctly and causing the build rates to get messed up when outside of the space center scene. Except I accidentally cached all the SPH rates with the VAB rates because I forgot to change one thing when copying the code over from one to the other. Should be fixed in build 20, and thanks for the report
  7. Finally had a chance to test this with KCT and it was definitely an adventure. A few things: you accidentally shipped a CrewQueue.dll in your release, the files not being renamed to match the classes/namespaces is pretty confusing (and there are files that should be deleted as well), the APIProxy should probably be public and not private since the wrapper is using GetExportedTypes which only shows public types, the wrapper was specifically looking for private Properties and Methods in the getProperty and invokeMethod calls despite all the actual members of APIProxy being public (even with the class itself private), and to top it off the wrapper was trying to get an Instance property that doesn't exist and made all the calls to any of the wrapper properties/methods instantly fail. I'm guessing you mostly just renamed all that stuff, so I am not at all surprised that KCT supposedly wasn't working with CrewQueue, since that wrapper was apparently designed for an entirely different API. The good news is that I managed to fix that in KCT so that the wrapper does hit all the right points and properly filters the list to exclude kerbals who are on vacation. KCT build #19 is tested against CrewRandR and appears to work fine with it Feel free to copy the fixed wrapper back over from KCT, but if you change the APIProxy to be public then switch back to GetExportedTypes from GetTypes (and let me know so I can do it locally)
  8. Alright, no worries. Just wanted to make sure you weren't going to try to do it by hand. Profile links are already a thing in the existing tool. We had considered avatars but decided against it. Hadn't talked about post count at all previously. I look forward to seeing the end result
  9. Are you going to do it by hand or write a program to do it? I really don't recommend doing it by hand since it quickly becomes unmaintainable. Once isn't so hard, but fixing the order later is a pain. That script only requires you to write the descriptions and does everything else for you, including formatting. If you send me the descriptions in any format you'd like I can set them up for the script and send the whole formatted list back with the descriptions file set up correctly.
  10. Here's the program, but without a descriptions file. I posted this a whiles back. It's just a python2 script and I can walk you through it if you'd like (it's been a while so I don't remember all the features and quirks off the top of my head). https://github.com/magico13/LightGreenGroupUpdater
  11. @Endersmens has some pretty serious IRL stuff going on (he updated a few pages back) so it's kind of in hiatus. I've been considering trying to write up a website where descriptions could be crowdsourced by other members and the list would be updated daily (I'd also like to track rep over time, but that approaches a "tracking" line that I'm not sure I want to cross), but that's nothing more than an idea in my head at the moment. That and I'm bad at making websites. I've always thought it was a little silly that the descriptions were made by a single person, crowdsourcing them makes more sense to me.
  12. I gotta say it's weird for someone to call me a "modding celebrity" since I wasn't aware that I was actually known
  13. Not to diminish your efforts, but perhaps to enhance them, but the old software made getting rep easier because you could get up to 5 per "like" instead of the constant 1 you get now. Though the "likes" seem to flow more freely with the new software, so perhaps it is easier now but just requires more people. Personally I got almost all of my rep on the old software (I think I was at 900 or so when the switch happened).
  14. You will be able to add ScrapYard to an existing save and theoretically will be able to remove it later without issue (other than some build times being out of whack, such as when editing a finished vessel). But while ScrapYard is in development the inventory might get broken between builds and have to be cleared out. If you wait until release that shouldn't be an issue and you can drop it into an existing save without any problems. Note that the inventory being broken between builds isn't necessarily save breaking since you can safely delete all that data from the save file manually if need be. It shouldn't cause any permanent breaks as long as you're ok with the occasional editing of the save file to delete a chunk of text. But backup the save often.
  15. Following this and will make KCT work with it. This falls under one of the requirements for the theoretical "Space-Time Continuum" mod set that I've got going in my mind (a set of mods that give time a meaning in this space game ) Edit: KCT dev build 17+ theoretically supports this, but I haven't tested it yet. Edit2: Scratch that. 18+ should work since if there was a manifest already then it wouldn't pull from the modified list. That was fixed in 18. Still haven't gotten a chance to test it yet though.