Jump to content

Gotmachine

Members
  • Posts

    377
  • Joined

  • Last visited

Reputation

618 Excellent

1 Follower

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. CC is designed to be extensible. You can create whole new custom parameters, requirements, etc from your own plugin.
  2. CC works just fine. Yes, there are some quirks here and there. And yes, it's definitely far from optimal from a performance standpoint, but this has very little to do with how "old" it is. It's not very optimized because it's a huge codebase and maintainability / ease of programming was prioritized over performance. At this point point, "fixing" it would require a lot of work. But I disagree with you. There are no contract packs because nobody is making them or actively developing the existing ones, not because of CC limitations. RP-1 has a huge and very refined career progression system based on CC. The sad truth is that the KSP modding scene is slowly dying since a few years now. At a few notable exceptions, most KSP plugins are just kept barely afloat and aren't under active sustained development. I can count on my hands the names of the active plugin developers, and large proportion of them are from the RO/RP-1 community.
  3. There is a fix for that (KSP) issue in :
  4. V1.5.0 is out. Available from GitHub and CKAN. New bugfix, KerbalTooltipMaxSustainedG : fix the kerbals tooltip giving wrong "Max sustainable G" information (thanks @NathanKell) Fixed (again...) some patches not being applied
  5. IMO, it's not worth breaking every mod currently using the CLS API. As long as everyone "play by the rules", using a common redistribuable API assembly is fine. I also strongly advise against putting together a reflection based API. Reflection comes with a huge performance penalty. It also becomes a mess to work with when you need to pass custom data around. In any case, the KSP 1.12 assembly loader issue will continue to plague the modding ecosystem, we just need to cooperate and spread the awareness. Also, I've not entirely given up on the possibility that this silly issue get fixed in an hypothetical 1.12.3 update...
  6. May I suggest contributing to KSPCommunityFixes instead of starting a separate but similar mod ? This being said, some of your ideas are already covered by other mods, and some others could be improvements to existing mods. Maybe you should consider contributing to those mods instead : Bring the builtin alarm clock up to par with KAC (add encounter mode, auto select the timer type, better pre-naming of timer) > see https://forum.kerbalspaceprogram.com/index.php?/topic/204404-112x-alarm-enhancements-102-26082021-automatic-alarms-and-better-naming-of-alarms/ More filtering options in the tracking station, such as listing only objects landed at or orbiting a specific body, showing only asteroids of a specific class > see https://forum.kerbalspaceprogram.com/index.php?/topic/172162-19x-dmagics-evolved-mods-tracking-station-evolved-60-5-4-2018/ List of nearby vessels to switch to > see https://forum.kerbalspaceprogram.com/index.php?/topic/141180-minimum-ksp-version-111-easy-vessel-switch-evs-v23/
  7. It is broken, and it is a problem. There is a KSP 1.12 bug in the plugin loader, triggered when two (or more) *.dll with the same name exist in the GameData folder/subfolders (https://bugs.kerbalspaceprogram.com/issues/28036) It cause the plugin loader to either : - outright crash with an ArgumentOutOfRangeException and KSP getting stuck on the "loading part upgrades" loading step - silently remove random assemblies to be loaded - continue without side effects. Which outcome you get depends on the alphabetical loading order of the dlls, and consequently can't be predicted. It also can't be fixed with a plugin, as this happen before any plugin has any chance to execute. LGG implemented that warning in ZeroMiniAVC to detect the second and third cases, but it can't cover the first one. From a mod author POV, there is a workaround : if your redistribute a *.dll that has any chance to also be redistributed by another mod (API, external library...), rename it to something reasonably unique. So in your case, you can rename the "CLSInterfaces.dll" redistributed by Ship Manifest to something like "CLSInterfaces_ShipManifest.dll" Internally, it doesn't matter if those dll have different names. Only one assembly (by assembly internal name as defined in the AssemblyInfo.cs file) will actually be loaded, and all other assemblies will correctly get that common reference. This was actually discussed extensively in the CLS thread recently : https://forum.kerbalspaceprogram.com/index.php?/topic/192130-111-connected-living-spaces-adopted-2006-2020-12-29/&do=findComment&comment=4048902
  8. And more issues... sorry again... V1.4.2 is out. Available from GitHub and CKAN. Fixed ModuleIndexingMismatch patch causing issues with modules dynamically adding/removing resources. Specifically, the patch was causing part resources to be loaded before (instead of after in stock) the PartModule.OnLoad() call when loading a ShipConstruct. This notably fixes RealFuel resources being lost when reloading/launching a craft file, but that mistake likely had consequences for other fuel/resource switchers mods (B9PS, Firespitter...)
  9. Aaah, silly me... Sorry for the borked release, and thanks to @Arrowmaster and @YellowApple for the reports V1.4.1 is out. Available from GitHub and CKAN. - Fixed UIFloatEditNumericInput patch causing various errors and generally not working as intended.
  10. @[email protected] Which KSP version are you using ? Can you upload a full KSP.log (or better, use https://github.com/KSPModdingLibs/KSPBugReport) ? I can't reproduce it, neither in KSP 1.12.2 or 1.10.1 It seems strange that it happen with the Photon Corp SRBs, since they don't use a FloatEdit control. If they have one, it probably was added by another mod. In your working game, do you see such a control (something looking like that : [<<][<][---slider---][>][>>]) on those ? If so, can you identify what it's for / from which mod it comes ?
  11. V1.4.0 is out. Available from GitHub and CKAN. New QoL patch : UIFloatEditNumericInput [KSP 1.8.0 - 1.12.2] Allow numeric input ("#" button) in "float edit" PAW items Fixed some patches not being applied in KSP versions below 1.12 : PAWItemsOrder, TweakableWheelsAutostrut, ModuleIndexingMismatch, FlightSceneLoadKraken. PAWStockGroups patch now applicable to KSP 1.10.1 (min version was 1.11.1 before)
  12. Changing the home system has no effect on how coordinates are computed, what matters is the distance from the original KSP sun. This being said, the real cause of that issue remains a mystery for everyone. All we know is that it happen more frequently the further you are from the original sun, and that preventing some of the MakingHistory DLC functionality to be active seems to further reduce the probability of that issue. Edit : I might be wrong, actually. Does the GU home switch work by replacing the Kerbol system with a custom one ? In which case you are right, distance has nothing to do with it, and the issue is caused by something Kopernicus is doing (or not doing). Which would make at lot of sense. The whole issue seems to be caused by the Unity collision ignore matrix becoming somehow messed up.
  13. V1.3.0 is out. Available from GitHub and CKAN. New bugfix : PAWItemsOrder [KSP 1.8.0 - 1.12.2] Fix PAW items position randomly changing and flickering This should fix the issues @Poodmundand @Dominiquini were taking about in this thread a while ago, although I suspect that there are a few other item ordering related issues lying around in the PAW code.
  14. More or less. However, KIS 2 will override and be mostly incompatible with the stock system, which mean that other mods that want to expand on the stock system will likely be incompatible with KIS 2. I had a lengthy discussion with @IgorZ on the topic, but we more or less agreed that we are disagreeing. The stock system has many shortcomings, but IMO it still is a decent "common base" for mods to work on. IMO, those shortcomings can be fixed without throwing compatibility away like KIS 2 intends to do. I am massively relying on the stock inventory system for some features in another mod, so my intention is to "fix/expand" it from a user facing POV, but also to provide a better modding API for it in the process. This stock inventory "extended modding API" is the reason I would prefer to release it as a part as KSPCommunityFixes, but the KIS 2 plans have made that a bit problematic. In theory, what I'm doing shouldn't cause issues in KIS 2, but having to verify that is a lot of extra work, especially since KIS 2 is a in development moving target... This is a bit messy to implement while keeping compatibility with KSP versions prior to the introduction of the vessel naming feature. This is quite minor in any case...
  15. Yep, that's a good summary. Although it should be noted that the "less/more stability/kraken" bit only apply to a few corner cases. Specifically, it only apply when a part is "instantiated" : flight scene loads, previously unloaded vessel entering physics range, EVA/Boarding, and possibly EVA construction. The current KSPCommunityFix patch only apply to the first case (flight scene load). I have a more "technically sound" fix, but I'm reluctant to release it as it alter the default KSP initialization sequence, and there is a small chance that this have unintended side effects on other KSP stuff/mods.
×
×
  • Create New...