• Content count

  • Joined

  • Last visited

Community Reputation

1856 Excellent


About magico13

  • Rank
    Capsule Communicator

Contact Methods

  • Website URL
  • Twitter @themagico13

Recent Profile Visitors

3854 profile views
  1. Alright, thanks! A lot of people have had that issue since the install directory for it changed halfway through 1.2.2 per the request of the CKAN folks.
  2. In the future, the log files are also recommended (posted to dropbox or other similar sites). Without the log I can only make general guesses. My guess is that you've got an older build of MagiCore sitting at GameData/MagiCore.dll, which you have to remove and make sure you only have the latest one at GameData/MagiCore/MagiCore.dll. That would potentially exhibit those symptoms, but the log would confirm it.
  3. Fixed, and then some It should now populate the list correctly, should wrap the list in a ScrollView so that if it's really long it won't go off the screen, and you should be able to launch at any open site without having to go into the editor and do any funky workarounds. It should just be that you set the site with KCT and can launch right away. Let me know how it works (and also that stock isn't broken...)
  4. This should be fixed now in the latest build on SpaceDock and at the new automated build site for the 1.2.2 backports (and also fixed in the 1.3 builds). Let me know if you're still seeing issues, thanks!
  5. Yeah, doesn't sound unreasonable. I test that code with really small ships and use less fuel than that. A mostly empty stage won't require too much, especially because its terminal velocity (assuming that calculation is working even remotely correctly) shouldn't be too high. Like, less than 200 m/s of dV probably was required. Powered landings are remarkably cheap in requirements.
  6. @Kerbas_ad_astra I'll try to take a look at that soon. Hopefully is as simple as changing a few strings in a few places. Hopefully I can also fix the issue with having to manually load sites before going to them to avoid crashes. Just a heads up, since 1.2.2 is still fairly popular I've started up a new automated build process for the 1.2.2 backports branch. I'm still preferring active development in the 1.3 development branch, but the 1.2.2 backports branch will include any changes I think are important enough to backport (mostly bug fixes, maybe some new stuff). I have to manually cherry-pick the commits from the 1.3 build into that branch as of right now, but I've at least got them automatically building whenever I do that. You can access the builds for 1.2.2 from here: Construction Time 1.2.2 Backports/
  7. How many completed vessels do you have? I'm betting it's the log spam due to calculating rollout non-stop. Try the latest version from SpaceDock since it removed that log spam.
  8. I mean, if you think it's harsh that you have more options than other people (assuming you're playing with the option where each site gets full access to the pool) then I can't stop you. With KSC Switcher you've got the option to make one KSC specialize in one type of construction and another specializes in another. Stock KSP doesn't have separate sites, that's only with KSC Switcher, and I've already added more support and options for KSC Switcher (a mod I don't use btw) than I need to. If you have a balance problem with RP-0, bring it up with the RP-0 folks or edit the Preset yourself. Or use a single KSC. I could have just made it so there was only a single KSC you could do anything with, even with KSC Switcher, which is essentially what it was before I spent a bunch of time adding support for mods I don't use.
  9. Because the VAB is the closest approximation to a construction facility we have in KSP and it allows for natural progression since the player would be upgrading that anyway. Default KCT only uses the VAB level to restrict the number of build rates you can have (2 per level). I don't know what RP-0 decided to do with that, so if you've got a question about the RP-0 Preset you'll have to ask them about it. You are more than welcome to change an existing Preset or create a new one, if you're interested in that then check out the wiki as there are several pages talking about it. You can completely redefine the formulas that are used for everything through the Preset system.
  10. I'm not sure what the problem you're having with ScrapYard is, so feel free to send a log my way (.zip it if it's big). A few people have mentioned still being on 1.2.2 and having issues with that logging, so I'll see if I can backport that change without it being a huge pain. Edit: There you go. Backported that change and at least one other one to 1.2.2, then uploaded it to SpaceDock (and thus also CKAN). Have fun.
  11. 1. This is true, but isn't important for the tracker. 2. Every instance of every part has a unique ID. The tracker is indexed by a full InventoryPart and so all of the InventoryPart's fields are required or else it will break the game while loading, _id is one of those fields. Those specific examples are actually individualized by their stored MODULEs. 3. No, every part can be turned into an InventoryPart, even if it hasn't ever been part of an Inventory. That's actually how comparisons are made, by turning every part on a vessel into an InventoryPart and then calling IsSameAs. The extra fun that resulted in Inventoried having to exist is that you can put a part in the inventory without recovering it. For example, KCT does this if you build a vessel and then scrap it without ever launching it. Other mods (or ScrapYard itself) may come out that allow you to purchase parts ahead of time in bulk for reduced per-unit costs, without counting as a recovery. I only need the tracker section from KCT_Data to convert things, but you're free to attempt it as well. You'd have to take the count from the old save and put it minimally into buildsTotal and usesTotal. You can split the usesTotal into usesNew and usesInventoried however you like (those must add up to usesTotal). Splitting buildTotal into buildsNew and buildsInventoried is fun because those don't have to add to buildsTotal (they just can't exceed it), since a build could have used a new instance of a part and an inventoried one. The actual counts don't ultimately matter that much. As for the ScrapYard.InventoryPart, copy an existing one but change the _dryCost to 0, keep the _id the same, _timesRecovered as 0 and _inventoried as False. Only the _name matters and it just has to be the actual name of the part (if the name in the tracker section of KCT_Data mentions anything about size,like "liquidEngine2,2.5" then don't keep the size part, just the base name). The reason the rest of the stuff doesn't matter is that the tracker is (by default) only set to compare by name, but it is capable of comparing by any amount of strictness (including all the way up to ID) if desired (by the modder using it).
  12. You can migrate the tracker, but not the inventory. It might be easiest if you just send me your save file from 1.1.3. The tracker really just uses the name like KCT's tracker did, but the inventory is way different.
  13. It's due to some logging I added to diagnose a bug someone was having that I've since removed from the 1.3 builds. I'm not officially supporting 1.2.2 anymore, but may make a build with that logging disabled.
  14. Shoot. I thought it was packaging them correctly but I clearly messed that up. It should be in its own folder. I'll manually fix that today and will have to adjust my build script again. Edit: Alright, I think I fixed that and I updated the build script so it shouldn't happen again.
  15. Build #26, link here.