Gotmachine

Members
  • Content count

    118
  • Joined

  • Last visited

Community Reputation

140 Excellent

About Gotmachine

  • Rank
    Spacecraft Engineer
  1. Interesting. I gave up on updating UpgradesGUI after 1.3 because I couldn't get a reliable way to manage the per-part status of upgrades. It's a big mess. Doing it with a partmodule is a good idea and may work in the end, but you haven't overcome what made me give up : they added some custom logic in the editor, upgrades are always reapplied to parts that gets loaded in the editor based on the current enabled/disabled status in the PartUpgradeHandler, regardless of what was saved. Try this : create a new sandbox game, set the difficulty settings to have all upgrades enabled (the effect would be the same in career mode with unlocked upgrades) go to the editor, add a part edit the upgrades save the craft open the craft all stats are reverted to non-upgraded state. I think this is because your plugin is setting AllEnabled to false in Start(). If AllEnabled was set to the default (true), all existing upgrades would be applied to all partmodules on the craft. This mean that when loading an existing craft in the editor, you need to iterate trough each module of each part, enable/disable upgrades in the PartUpgradeHandler according to the craft saved Upgrade confignode and apply them. Since you have gone the partmodule way, it shouldn't be too difficult. As for reverting to base stats when no upgrades are applied, it is indeed messy. Here is how I'm doing it. It won't handle sub-nodes but in my tests for a 1.3 version, I found a workaround : instead of copying the field values from the prefab partinfo confignodes, I instantiate the part, get the field values from it and then destroy it. A bit hacky but it works and will support every possible partmodule. License note : you can re-license my code under GPL, no need to release some part under the unlicense (it's an unrestricted public domain license). This said, I encourage you to release your work in the public domain too so others can freely reuse your code, in my humble opinion the license hell around here is getting awful.
  2. Hi guys, I would like to have some feedback and opinions on a few new features I'm currently trying to implement. Picture first : This is a replacement for the stock SAS. It's build on top of MechJeb and will probably require MechJeb to be installed (the other option being repackaging MechJeb as a library and distribute it with the plugin, which I want to avoid). But this SAS (and possibly other features built on top of MechJeb) will be independent from the MechJeb parts and GUI. The MechJeb GUI and parts will still be available, but not visible if you don't use them. I'm doing this because : The stock SAS is struggling with large and heavy vessels, to the point it is impossible to stabilize them. The stock SAS is atrociously inefficient and imprecise, leading to astronomical RCS fuel consumption The stock SAS lack some very useful features. I did a lot of tests to compare the MechJeb SAS to the stock SAS, in various situation and with various vessel sizes. For the same sequence of events, the MechJeb SAS is between 25 % and 200 % more efficient with RCS fuel, especially with large vessels. I also did test using the TCA SAS, which is even better but unfortunately TCA is build in a way that make it very hard for me to use it as a dependency, plus it is missing a few features that MechJeb have and that I want to use. Now back to the screenshot. The new SAS modes are : Hold : Used to precisely hold an orientation, this is the default MechJeb Hold. The orientation is defined in two possible ways: - When hold mode activated, hold the current vessel orientation at time of activation - On pilot input key release, register the current orientation and then hold it HoldSmooth (Default mode): Same as Hold, but on input key release angular velocity is killed and once the vessel has stabilized, the reached orientation is registered. The stock SAS Hold mode behave a bit like this. KillRot : Don't hold any orientation, just keep angular velocity to zero. Great for consuming less RCS fuel. ForceRoll (3 horizontal markers) : - center marker : toggle that activate/deactivate force roll. Icon change to reflect the current selected roll angle - right / left markers : buttons with arrows icons, add / remove roll angle by 45° increments Roll angle is relative to the current reference (ORBIT, SURFACE OR TARGET) PitchOffset (3 horizontal markers + value) : Add a pitch offset to the current selected orientation. Disabled if Hold, HoldSmooth, KillRot or Maneuver mode is active. Useful for managing attitude in atmosphere, especially for reentry - center marker : reset pitch offset and set mode to HoldSmooth - right / left markers : increase / decrease pitch offset (2.5° increments) ProgradeCorrected (target mode marker) To target, correcting lateral velocity This is the orientation you need to burn to so Prograde become aligned with Target RetrogradeCorrected(target mode marker) Against target, correcting lateral velocity This is the orientation you need to burn to so Retrograde become aligned with AntiTarget Parallel + & Parallel - (target mode marker) Keep the vessel parallel to the target, great for docking using lateral RCS movement There are some other features I want to add, but maybe not in next release because it will involve a lot of navball GUI hacking and this is the most horrible task I've done since I begun modding for KSP. SAS aggressively slider : basically how hard the SAS try to turn, less aggressive = less RCS fuel consumption (MechJeb functionality integration) RCS auto mode switch : automatically disable the RCS toggle when reaction wheels are enough to do the job Global RCS throttle slider Maneuver autopilot : a basic autopilot that will execute the next maneuver node (Mechjeb functionality integration), to be used in conjunction with commnet Navball markers for the new SAS modes All these thing would be available from a nice stockalike popup menu accessed by right-clicking the SAS and RCS toggles on the navball. Also, I'm thinking about redoing how the reaction wheels nerf is working. This could involve : A "realistic torque output", available all the time for the pilot or SAS to use. This realistic torque output would involve realistic reaction wheels saturation, meaning fully saturated wheel = no torque available. A on request auto-desaturate function, that would involve automatically firing RCS thrusters to desaturate the wheels. A "magical torque output", saturation free, available only for stabilization when the SAS is used.
  3. There are two things that can (and most likely will) go wrong when MechJeb is engaged : MechJeb seems to expect the stock behaviour of "timewarping kill rotation" in some cases. MandatoryRCS "fixes" that behaviour. This can cause MechJeb entering in an infinite loop of timewarping and correcting attitude. In my quick tests, this does happen sometimes, and can be avoided by unchecking the MechJeb auto-warp feature while a maneuver is being performed. MandatoryRCS reaction wheels "balance system" is dependant on the state of the stock SAS. If the SAS is off, reaction wheels are always in the "nerfed realistic torque output" mode. Since MechJeb force the SAS to the off state, reaction wheels are in this weak mode when MechJeb is engaged. This mean that every small attitude correction will be done by the RCS thrusters, causing huge RCS fuel consumption. For large vessels, this mean that they will be impossible to stabilize. A few recommendations to keep your RCS fuel consumption under control when using MandatoryRCS, and other playing tips : Have a good RCS thruster setup : Use the RCS build Aid plugin and pay attention to the yaw/pitch/roll "torque output" of your RCS setup. This will help you to learn how to do an efficient setup. Have your RCS trusters as far as possible from your vessel center of mass. Further away = exponentially more torque = exponentially lower RCS fuel consumption. If you have some thruster nozzles that can't follow this rule, use the advanced tweakables to disable Roll / Pitch / Yaw on the part. A RCS nozzle with its thrust vector aligned with the center of mass will consume RCS fuel for zero effect in attitude control. For in-space situations, don't have too many and too powerful RCS thrusters. A powerful RCS setup will allow you to rotate faster but at the cost of an exponential RCS fuel consumption. Tweak the RCS thrust limiter on small vessels. Have a balanced RCS setup : put an even number of RCS thrusters in symmetry around your vessel center of mass. Don't have RCS nozzles facing random directions, always have them aligned with vessel X, Y and Z axis. Add/keep a good ratio of reaction wheels, especially on large spacecraft. Micromanage the RCS on/off toggle ("R" key). Even when the vessel seems stable, keeping the RCS toggle ON will cause a rapid depletion of your RCS fuel. When maneuvering, engage RCS and as soon as you have reached the SAS target marker (or if you are in stability assist mode), reaction wheels will stabilize you vessel for free. Turn the RCS toggle off as soon as possible. If you have the patience, do your manoeuvring in fine controls mode ("Lock Caps" key). When in atmosphere or if landed, remember that reactions wheels will help you only in "stability assist" mode OR if you are already/still oriented toward the selected marker.
  4. @Barcel@Wardstone111 Now updated for 1.3.1, and released the part pack as a separate download, should be available on CKAN soon.
  5. @Barcel Probably, but not tested. I will do a proper release for 1.3.1 soon.
  6. [1.3.0] Kerbalism v1.2.9

    @vladutz26 Try this : open the Kerbalism/System/Misc.cfg file and comment the following : @PART[*]:HAS[@MODULE[ModuleDeployableSolarPanel]]:FOR[Kerbalism] { MODULE { name = WarpFixer } } by changing it to : //@PART[*]:HAS[@MODULE[ModuleDeployableSolarPanel]]:FOR[Kerbalism] //{ // MODULE // { // name = WarpFixer // } //} And restart a fresh game Also, delete the "ModuleManager.ConfigCache" file in GameData when you do some modifications to your mod setup. You can also try to search inside the "ModuleManager.ConfigCache". It is generated every time you launch KSP and have changed the mod setup. It contains the configs of all part with all the patch from all your mods applied. Launch the game with kerbalism then quit, backup this file somewhere. Relaunch the game without kerbalism and do the same. Do it one more time with no mods other than modulemanager. Open the three files, search for PART configs that have a "ModuleDeployableSolarPanel" and check if there are some differences. Kerbalism should add a module named "WarpFixer". If another mod is modifying the solar panels, they may add another module to the part. Edit : also, looking at your log, you have a copy of ModuleManager.2.6.25 (KSP 1.1 !!!) hidden somewhere causing a big mess, this is very likely to be the source of many problems. I'm pretty sure that ContractConfigurator is partially broken by this.
  7. [1.3.0] Kerbalism v1.2.9

    Kopernicus should work as long as you only use it to add planets (OPM is fine for example) and not to modify Kerbin or have multiple stars. Dynamic battery storage; AmpYear; Background resources generation are likely to cause issues Did you try to create a new game before testing without those? Adding / removing plugins on an existing save can break things badly. Also, the power consumption will fluctuate (but not like that) between day and night due to the climatization needs. In the VAB, you can see the nighttime estimated consumption by clicking on the sun icon at the top of the planner.
  8. [1.3.0] Kerbalism v1.2.9

    @Vila Restal@Magzimum Seems the custom category code is broken by the 1.3.1 update. Copypaste the following in a *.cfg file, and drop the file anywhere in your gamedata folder : @PART[kerbalism-activeshield]:NEEDS[FeatureRadiation]:FINAL { @category = Utility } @PART[kerbalism-gravityring]:NEEDS[FeatureComfort]:FINAL { @category = Utility } @PART[kerbalism-greenhouse]:HAS[@MODULE[*]]:FINAL { @category = Utility } @PART[kerbalism-chemicalplant]:HAS[@MODULE[*]]:FINAL { @category = Utility } @PART[kerbalism-container-*]:HAS[@RESOURCE[*]]:FINAL { @category = Utility } @PART[kerbalism-container-*]:HAS[@MODULE[*]]:FINAL { @category = Utility } I didn't test this (I'm still on 1.3) but his should add the missing parts to the stock "Utility" category. There may be other things that are broken by the 1.3.1 update, you should enable the debug info to see if there is any exception spam going on. I hope @ShotgunNinja is still around to update the mod but according to his profile he hasn't been on the forums since august 7 and has shown no signs of activity on github since that time either.
  9. [1.3.0] Kerbalism v1.2.9

    @goldenpsp But in this case, Kerbalism use the CRP definitions to avoid the issue, and I totally understand @ShotgunNinja not wanting to add CRP as a dependency. The difference I pointed out is due to CRP being updated with custom HSP values but Kerbalism defintions weren't updated to reflect these changes. This is a problem and must be fixed (Kerbalism definitions should match CRP ones), but from a quick testing the "duplicate resource" issue isn't happening anymore, looks like something changed in how KSP handle duplicated resource definition since the early days of CRP.
  10. [1.3.0] Kerbalism v1.2.9

    Seems my intervention caused a bit of confusion. What I know for sure is this : Kerbalism is designed to be compatible with CRP, no need to do anything for the two to work together. Kerbalism use some resources that are defined in CRP, but those resource are also defined in the Kerbalism files to avoid CRP being required for Kerbalism to work. I suspected this system could have been the cause of @Andrea Galimberti issue but it turned out that I was wrong.
  11. Whoops... English isn't my native language so thanks for the corrections. I will fix this for next update.
  12. [1.3.0] Kerbalism v1.2.9

    @baldamundo For station building you can get Nertea Stockalike Station Parts Expansion. Note that MKS+USI-LS are incompatible for a good reason. The two mods are doing the same things with different goals : Kerbalism is aimed at providing a somewhat realistic (and hard) set of rules for life support, ISRU and self-sustainability while MKS+USI-LS is offering a "Kerbalized", relatively easy and unrealistic but complex self-sustainability system. What could eventually happen is a MM patch that alter MKS/USI-LS parts by removing USI specific modules to replace them with kerbalism modules. A small plugin could take care of hiding the MKS/USI-LS GUI. But as far as I know, nobody has tried that.
  13. Let's talk about part/modules upgrades

    Indeed, the module name is "ModuleEnabler". I understand your point of view but as you said, proper add/removal of module instances at runtime is near impossible. On the other hand, we have a more or less clean way of enabling/disabling them. From a functional point of view this achieve the same thing. As for the potential issues : I'm pretty sure that the "overhead" (I assume you mean memory footprint) would be very low if measurable at all. Since disabled modules don't call Update/FixedUpdate/OnGui, there is no performance difference. On your compatibility example, I'm not sure I follow you. Are you talking about code compatibility or MM patching ? In any case, having a module switching system will induce complexity for mods that want to interact with a switchable module, no matter how its done. Maybe the specific code issues/features, when identified, could be dealt with in an interface that other plugins could implement in their custom modules. Unless there is something I missed, the proposed modules are fully compatible with MM. But I agree that the upgrade configs are a bit tedious to write (compared to what we are used to with IFS/B9/Firespitter). My point is : since 1.2, we have a stock upgrade system that is able to track what is essentially "part variations". On the other hand, this is is something that the modding community need and already do heavily. Count the number of plugins that provide resource/texture/mesh/module switching : B9, Firespitter, IFS, Kerbalism, BDB, and so on... Don't you think it make sense to try to link those features to the stock upgrade system ? My idea is to do this in incremental steps and see what are the issues one at a time. For two reasons : I'm not a super skilled programmer, and I don't have a lot of free time. Also, I was thinking about what you said about mesh switching. I looked into the firespitter code and it doesn't add/remove components/objects, it only enable/disable them. Since they exist, why would referencing them cause nullrefs ?
  14. [WIP] Vaguely Realistic

    May I suggest the bundling of my MandatoryRCS plugin ?
  15. Let's talk about part/modules upgrades

    I need to verify, but seems to me that setting the "enabled" MonoBehaviour property to false lead to Update/FixedUpdate/OnGui not being called. Isn't that enough to prevent all interactions ? Then the only thing that would need to be dealt with are KSPField, KSPEvent and KSPAction, to toggle their UI visibility (but I was under the impression that they don't show up if enabled = false, since OnGui isn't called). Of course this wouldn't support modules that do mesh switching, everything needed for the module to work should be present in the part. The idea is to only prevent them to Update/FixedUpdate/OnGui, not to prevent Awake/Load/Onload/Start/OnStart. By setting enabled = false in the ModuleEnabler own Update/fixedUpdate, so after everything is initialized. The ModuleEnabler will disable the target module only in the editor (not in flight), wouldn't this will narrow down these issues ?