JH4C

Members
  • Content Count

    416
  • Joined

  • Last visited

Everything posted by JH4C

  1. Hm. I've just been trying the last release in my 1.5.1 install for compatibility purposes, and any ship which has been named using localized strings (pretty much all stock craft as well as ChopShop's provided examples the ones I've found so far) aren't pulling the localized names out of the dictionary files. Not sure why, it obviously used to do this in 1.4.5 (and still does when I boot that version for comparison.) Weird.
  2. I don't think the Dev side's been updated to 1.5.x yet; @Jim DiGriz has been working on the orbital transfer stuff in the older codebase, hopefully it'll pop up in the release version too.
  3. Try to launch the craft and it'll tell you, if memory serves; it's handled by the base game as it's a stock part of the system. Locked means you've not opened their tech nodes (or bought them after unlocking it if you're playing that rule.)
  4. But the latest version built for 1.5.x has been 2.8.1 since mid-week. That would be why you're getting an error message. https://ksp.sarbian.com/jenkins/job/MechJeb2-Release/
  5. There's usually very few issues with parts when patches are issued, so this is a puzzler. Have you made any wild changes to the part.cfg?
  6. Huh. "Expected part not found." You don't consider that a problem? But as I said, it's fine here: Not deleted, sitting in the folder exactly the same place as before, .cfg file is identical to previous release.
  7. Seems fine here, what problem are you having?
  8. @Beale, it's no big thing but I just realised there's a duplication of part designations between this mod and PorkJet's Parts Overhaul. One of the engines PorkJet built is designated LV-T15, a name which is also used by your Blok-D LFO engine. The number is embedded in the texture of PorkJet's model, so there's not really any way to adjust things on that end. I'm not saying anything need be done about it, there's no other conflict and the game cannot confuse them; I just found it interesting & thought I'd share.
  9. With the newly upgraded mk1 Pod and FL-T100/200/400/800 parts in the latest patch, a lot of the parts in this are now obsolete; the engines however are still significant visual improvements over stock. I've edited @Jognt's MM patch to only apply the engine replacements, as well as fix a side-effect of the "brute force" method of replacement being used, where the "IdenticalPart" setting in the paired engines looks like it's being ignored due to one of each pair ending up with a different part identity (I'm not sure if it does anything anyway, but as things were I'm pretty sure it couldn't even hope to.) Copy/paste the following into your .cfg file, as described elsewhere in this thread: //Implement missing thrust upgrade for Heavy Rocketry node PARTUPGRADE { name = LVT-Turbopump-heavyR partIcon = liquidEngineT15 techRequired = heavyRocketry entryCost = 7500 cost = 0 // for display only; all parts implementing this will need a PartStatsUpgradeModule with cost = this. title = LV Series Thrust Upgrade //basicInfo = Whatever\nblah manufacturer = Jebediah Kerman's Junkyard and Spacecraft Parts Co description = Turbopump enhancements and other detail improvements lead to higher flow rates and thus higher thrust. } //Match thrust on Terrier boattail to standard version @PART[liquidEngine909_Boattail]:FIRST { @ @MODULE[ModuleEngines] { @maxThrust = 75 //was 80 } } //Correct description of Swivel Isp in Precision Propulsion upgrade @PART[liquidEngineT45,liquidEngineT45_Boat]:FIRST { @MODULE[ModuleEngines] { @UPGRADES { @UPGRADE:HAS[#name__[LVT-GasGen-precProp]] { @description__ = Isp now 325/265. } } } } //Correct description of Pug thrust in Heavier Rocketry upgrade @PART[liquidEngine303_Boattail,liquidEngine303]:FIRST { @MODULE[ModuleEngines] { @UPGRADES { @UPGRADE:HAS[#name__[LVT-Turbopump-heavierR]] { @description__ = Thrust now 33kN. } } } } //Correct part pairing for stock engines being replaced; no idea if this actually affects anything! @PART[liquidEngineT30_Boattail] { @identicalParts = liquidEngine } @PART[liquidEngineT45_Boat] { @identicalParts = liquidEngine2 } @PART[liquidEngineT909_Boattail] { @identicalParts = liquidEngine3 } //Brute-force swap PorkJet parts in preference to stock parts -PART[liquidEngine]:FIRST {} -PART[liquidEngine2]:FIRST {} -PART[liquidEngine3]:FIRST {} +PART[liquidEngineT30]:FIRST { @name = liquidEngine } +PART[liquidEngineT45]:FIRST { @name = liquidEngine2 } +PART[liquidEngine909]:FIRST { @name = liquidEngine3 } -PART[liquidEngineT45]:FIRST {} -PART[liquidEngineT30]:FIRST {} -PART[liquidEngine909]:FIRST {} You'll also need to delete both of the PartsOverhaul\Parts\Command and PartsOverhaul\Parts\FuelTank folders, unless you want to keep those parts alongside the new models; either way, they will no longer replace stock. This shouldn't break any ships but there may be minor alignment issues, especially with the command pod - you have been warned! I take no responsibility for lost ships! Also note that an engine in Tantares uses the same technical name as one of the new engines, the LV-T15. Due to this being baked into the texture, the name cannot be changed on this model; you should be able to tell the difference in the editor though, as they're very distinct in style.
  10. Thanks @Beetlecat; I still have my 1.4.5 install, I'll just drag it over.
  11. Thread title implies this has been recompiled for 1.5.x but neither of the provided "active" download links work; Curse denies the page exists, and GitHub hasn't been updated in a couple of years. @pizzaoverhead you may need to update the OP with new links.
  12. Just tried a couple different SPH creations, they all eased in nicely and no springiness. Seems to work well. Thanks @whale_2
  13. 1: it's only been 3 years, not 5. 2: You've looked at the wrong thread:
  14. Hah, fancy that... And I only left it at 0.075 because I felt the thicker part would weigh more; I'd totally missed the mass was being adjusted in the variants. Three cheers for blind **** luck! Glad I could help.
  15. CKAN won't have been told otherwise, but it was working fine in 1.4.5 for me and many others. Just make sure you've told CKAN it's allowed to install anything related to 1.4.x and you should be good to go.
  16. An hour is a smidge on the high side, but it depends on how much physical RAM you have and how much the game's having to rely on a swapfile. The less RAM, the longer it's gonna be as it'll have to keep swapping stuff in and out. LGG has as many or maybe more mods than you, and on his streams it can take ten minutes or so to load...
  17. Maybe include it as an optional install? Some people may be used to it and miss it if it went, while others may be happy to use the new system.
  18. Lucky for you, I was in need of a distraction this afternoon... I've got it working! You may not like it, it may not be as pretty as you'd hoped for, but I can restore it to functionality so you can resume using it in your designs. The problem appears to lie in locating the bottom attachment node. If you check the originals (which i'm sure you did multiple times) you'll see that, although sizes 2, 3, and 4 all grow and move their nodes proportionally in relation to each other, the size 1.5 plate shares the exact node positioning as the size 2. While testing another theory, I accidentally built a size 1 plate that used the longer dimensions, and it worked - it dropped like a stone when the clamp was released, and flew if I remembered to turn the engines on. I also noticed that each size of plate has its own unique build of shrouds, and there's another set in the same folder for size 1; sadly they don't appear to work properly at all, as when I tried swapping them in only the long or short fairings displayed and not in a manner consistent with the user's choices. So to make everything fit without shims or cludges, what I've done is I've tweaked your EnginePlate_1.cfg into this: // A 1.25m engine plate. Would love to eliminate every node combination // except the "single" and "double"... except it looks as though the // ModulePartVariants class is coded in a brittle way that makes it // impossible to "hide" any node set via config. If nodes are baked into // the .mu, then they *have* to be a config option. Oh well. +PART[EnginePlate2]:NEEDS[SquadExpansion/MakingHistory] { @name = EnginePlate1 @author = Snark @MODEL,* { %scale = 0.5, 1, 0.5 } @NODE,* { @size=0 } @title = #MissingHistory_EnginePlate1_title @description = #MissingHistory_EnginePlate1_desc @mass = 0.075 @bulkheadProfiles = size1 @MODULE[ModuleDecouple] { @ejectionForce = 100 } } The models are being resized in two dimensions only, so that the shrouds remain the correct length as well as the correct width. This does mean that the lower attachment node is a lot further away from the plate than is pleasing to the eye, but it flies so the trade-off's probably worth it. There may be some wiggle room, you might be able to shrink it a little further, but this works. Oh, for some reason the main top/bottom attachment nodes still look huge even though they're supposed to be getting changed to size 0. Again, it doesn't affect function. HTH.
  19. I didn't test it but see no reason why not. @gamerscircle you only needed to look 3 posts up.
  20. Craft Manager lets you tag your craft which allows you to sort them into multiple categories, as well as load craft created in different saves. That'll accomplish what you're after.
  21. There's at least two people working on the project right now, with multiple updates during the last week or two... I'd love to know how that gives the impression it's abandoned?!
  22. Thanks for the quick fixes. I'm really liking all these parts, and I'm especially fond of how you've given each loading ramp its own niche - they all work slightly differently, and I just wish I could find an excuse to use more than two per plane!
  23. @Kaleu, there seems to be a minor error with the ConeComando decoupler, but I'm not sure exactly what; certainly it doesn't appear to be serious enough to prevent the parts from working as anticipated, it's probably just some internal weirdness: [LOG 14:40:44.593] PartLoader: Compiling Part 'SCA/Parts/VLS/ConeComando/ConeComando' [ERR 14:40:44.601] Cannot find fx group of that name for decoupler [ERR 14:40:44.634] Cannot find fx group of that name for decoupler [LOG 14:40:44.639] PartLoader: Part 'SCA/Parts/VLS/ConeComando/ConeComando' has no database record. Creating. [ERR 14:40:44.641] Cannot find fx group of that name for decoupler [LOG 14:40:44.643] DragCubeSystem: Creating drag cubes for part 'ConeComando' Casual inspection doesn't reveal anything obviously wrong with the decoupler fx names used in the part's .cfg file; it's spelled and capitalised properly when compared to stock parts. I'm also seeing the same error occur on Tantares' decouplers, but not on other the parts pack I currently have installed (Mk 3 Expansion). As I said, weird. Still, thought you might like to know.