Jump to content


  • Posts

  • Joined

  • Last visited

Everything posted by JonnyOThan

  1. KOS-Scansat doesn't have anything to do with that RPM page. It's a binding layer between KOS and Scansat. And all these mods *are* compatible with the latest version of KSP - you may want to check versions 1.8-1.12 as compatible in CKAN. But thanks for the heads up, I'll make sure the compatibility is updated.
  2. Would you mind checking the "add to ckan" box on spacedock? That will automate a lot of the process.
  3. Huh. The tantares_v2_orbital_module_s1_2 part references an internal space (tantares_v2_orbital_module_s1_2_interior) that doesn't exist. Looks like this is a new issue introduced in tantares here: https://github.com/Tantares/Tantares/commit/bc94ae338c5bfb4933624fcbe1a96a4725774da8 You can *probably* edit those files or write a patch to make them point at the correct internals (tantares_orbital_module_s1_2_interior etc) (the ksp.log file would have made this obvious in less time btw)
  4. Can you give the specific attachment ordering and names of parts, or better yet a craft file? I loaded the provided [Soyuz] LOK craft file, and this setup works for me. If it doesn't work for you, please post your ksp.log file.
  5. Nearly all mods that work in 1.8 or later will work in 1.12.3, but the reverse is not true. You need to find your log file in any case.
  6. Thanks for the report and logs. This is caused by incorrectly configured parts in Netherdyne: https://github.com/linuxgurugamer/NeatherdyneMassDriver/issues/1 I believe you should be fine to just ignore that error.
  7. Several parts have MODULE nodes with no name specified: https://github.com/linuxgurugamer/NeatherdyneMassDriver/issues/1
  8. I’d suggest playing on 1.12.3 or later, but without log files I really can’t help much.
  9. PCR 1.4.0 is now available! Changes Adds support for Reviva (requires Reviva 1.0.0 or later) Respects input locks from KOS terminal Fix a bug with crewed parts being incorrectly set up as probe cores
  10. Version 1.0.0 is now available! Changes from previous version Giant refactoring of patches to make it easier to add support for mods and parts Fixed bugs regarding RPM variable persistence and action group memos being lost Fixed bugs that prevented ProbeControlRoom from working properly with Reviva Added Apex and Kermantech options for mk3 cockpit Fixed some configuration bugs
  11. Would you be OK with someone else adopting it? The license is very permissive so someone *could* do that without asking, but usually it's nice to get the blessing of the original author.
  12. Heads up, this is pretty broken: https://github.com/JonnyOThan/KSP-ProbeControlRoom/issues/30
  13. TweakScaleRescaled has now officially been released: This thread can be closed. Thanks!
  14. Support You MUST include your ksp.log file with all support requests. These links are for TweakScaleRescaled. DO NOT ask for support on other TweakScale threads. KSP Forum: https://forum.kerbalspaceprogram.com/topic/223692-1125-tweakscalerescaled-scale-your-parts-in-the-editor/ Discord: https://discord.gg/tTWcqrBB3t Github: https://github.com/JonnyOThan/TweakScale/issues New Feature Demos What is this? TweakScale is a mod that allows you to rescale parts in the vessel editor. All of their stats and properties are affected realistically - tanks contain more fuel, engines get stronger, solar panels produce more power, etc. It's one of KSP's oldest mods and has been maintained by many different people over the years. I've forked pellinor's version of TweakScale and updated it for modern KSP to provide a simpler and streamlined version. I've paid special attention to the following areas: User experience Improvements to part action window in the editor clicking interval buttons at the ends of the ranges works better can now drag the slider smoothly Toggle for scaling changes to affect the entire subtree Toggle for matching node sizes when attaching parts Numeric entry (click #) is now supported Option to display the effects of scaling on the part's stats Scaling construction mode gizmo akin to offset and rotate (press 5 in the editor) New "match node size" feature to auto-scale parts when attaching nodes to each other All parts are supported with reasonable defaults unless they opt-out or match certain filters to trap known issues (AllTweak will still override this and enable everything) Scaling docking ports is supported Reduced dependencies to only ModuleManager and Harmony Optimized for better performance better loading time to main menu better switch-to-editor time scaling a part is more responsive less performance impact in flight scene better save/load performance Less intrusive and more targeted validation system (TweakScaleSafetyNet) Robustness fixed part attachments and mass/cost scaling when variants or B9PartSwitch are involved scaling engine effects (stock, waterfall, realplume, smokescreen, etc) works correctly Craft files and saved games no longer break from changes in TweakScale configs More resilient to problems caused by missing dependencies, problems with other mods, and incorrect installations Copying part subtrees, subassemblies, load-merging all work properly Made it easier to add or customize TweakScale support for other mods Scaled parts work correctly with EVA construction Compatible with many fuel-switching mods: B9PartSwitch ModularFuelTanks InterstellarFuelSwitch SimpleFuelSwitch Firespitter Universal Storage 2 Configurable Containers Why not work to improve the current TweakScale? The gist of it is: it would take far more energy than I have. If I believed this option was possible, I would do it (because usually, this is the best option). However, TweakScaleRescaled (this fork) is licensed CC-BY-NC-SA. Its code may be used by anyone else provided they abide by the license terms. Pull requests are also welcome from anyone who wants to contribute. Compatibilty Backwards compatibility is a core goal of TweakScaleRescaled. Existing craft files, saved games, configs, and mods that depend on Scale_Redist should work seamlessly if you change to TweakScaleRescaled. However, ongoing interoperability with other versions of TweakScale is not a goal. I will make a reasonable effort to support it where it's easy. In order to make the improvements necessary, data structures and assumptions have to be altered in ways that are difficult to reverse. TweakScaleRescaled should just work with almost all stock or modded parts. It includes the stock and mod-support patches that were written by the previous authors (updated as necessary). There's also a new patching system based on heuristics that will apply to all other parts unless they opt out or are blocked by filters for things that are known to break. Only KSP 1.12 is supported. Other versions 1.8-1.11 may work but have not been tested and are not a priority. Dependencies ModuleManager Harmony KSP Community Fixes is recommended to address stock bugs that become more apparent when using TweakScale License Info TweakScaleRescaled is licensed CC-BY-NC-SA-4.0. © 2023 JonnyOThan © 2015-2018 pellinor © 2014 Gaius Godspeed and Biotronic Source code: https://github.com/JonnyOThan/TweakScale History TweakScale was originally created by Gaius Goodspeed under CC-BY-NC-SA. Biotronic took over and relicensed it as WTFPL pellinor adopted it and kept the WTFPL license. TweakScaleRescaled is based off of pellinor's version, and is once again licensed as CC-BY-NC-SA. Download CKAN is recommended (NOTE: if you previously had TweakScale-Redist installed, you may need to deselect it and select TweakScaleRescaled-Redist instead) Github: https://github.com/JonnyOThan/TweakScale/releases Spacedock: https://spacedock.info/mod/3514/TweakScale%20Rescaled Installation Instructions Remove any previous version of TweakScale and KSP Recall. Install the contents of the GameData folder in the zip file into your GameData folder. Install Harmony and ModuleManger - CKAN is recommended for those.
  15. There was a bug a while ago in FreeIVA that would cause that, but it absolutely should not be happening any longer. Unless….freeIVA uses some heuristics to figure out which parts are probe cores (it’s harder than you’d think). If it guesses wrong I could see that happening. In any case it’s likely a bug in FreeIVA and you should report it over there (ideally on github) and be sure to include your KSP.log file and the part names you’re having issues with.
  16. Can you clarify what this means? This mod is up on SpaceDock and they requested addition to CKAN: https://spacedock.info/mod/3557/Arktus As part of the CKAN approval process we check on licenses; this mod appears to have copied the cloud maps from Infinite Discoveries. I don't really know that much about planet modding so it's hard for me to say whether this is in violation. Also the language is not super clear - what does "as part of something else" mean? They're part of another mod, is that enough? Or do you require that they're modified in some way? Thanks!
  17. This design sounds good. But there is a 4th phase, which is where PCR adds reviva support for all the mods that it knows about. Ideally it does this in a way that makes it easy for other mods to remove it or customize it. FOR[ProbeControlRoom] seems like the right place. Another way to do that would be to prevent adding the support subtype if it’s already been added, but that requires guessing what the other mod is going to add. If we plant a stake in the ground and say “here’s the subtype we made for you, and it will never change” then the other mods have something fixed in place they can work with.
  18. in which pass though? They have no good way to control when they run compared to that patch. Unless they just use AFTER[ProbeControlRoom] - but at that point you might as well have used FOR[ProbeControlRoom].
  19. Im not sure but I think you might be misunderstanding how the patch ordering works. BEFORE[ProbeControlRoom] runs immediately before FOR[ProbeControlRoom]. It’s a bit of a code smell for a mod to be using BEFORE or AFTER for its own identifiers. Those specifiers are most useful for *other* mods to insert patches immediately before or after some other mod that they interact with. If the mod itself uses them, then it limits the ability for other patches to position themselves correctly.
  20. Yeah, I'm basically proposing we invert that - at least as long as Reviva is installed, because the whole point of the ordering here is to not step on the toes of other mods that might want to be adding their custom control rooms. And really it's probably better if PCR didn't use FINAL...I'm not sure if there was some good reason it's set up like that rather than setting up defaults early and expecting other mods to overwrite it. Why BEFORE and not FOR?
  21. You're welcome! However....I'll have to say that I did not do extensive testing with lots of other mods (other than fuel switching. What a pain). But the heuristic system should mean that anything that is set up similarly to stock parts should just work. If you come across things that are broken, please let me know (see the support section at the top) and I'll get em fixed.
  22. Yes please! I think the best way to do this would be to add the reviva and b9ps modules alongside where it adds the INTERNAL node. And ideally that would be in a pretty early pass. We could populate it with all the mods that we know about. The subtypes should have a name that makes it clear the config is coming from PCR, so that the other mods can delete it or tweak it and provide their own.
  • Create New...