Jump to content

Gotmachine

Members
  • Posts

    690
  • Joined

Everything posted by Gotmachine

  1. 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...
  2. 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.
  3. "Part" group : sameVesselCollision, AimCamera, ResetCamera, ToggleAutoStrut, ToggleRigidAttachment, ShowUpgradeStats, SetVesselNaming "Comms" group : ModuleDataTransmitter PAW items "Command" group : ModuleCommand PAW items "Control" group : reaction wheels, RCS, gimbals, control surfaces PAW items I guess I should make a screenshot and add it to the OP. Yeah, it also doesn't always properly update when you manipulate stuff in the PAW. I have a much more refined stock inventory overhaul in preparation, but at this point it probably belong to a separate mod, as it somewhat goes quite beyond the simple "Bugfix/QoL" category. In a nutshell, what it does is : - Automatically compute cargo parts volume instead of requiring config definitions - Properly handle volume for part variants - Remove the inventory slot count limit (only mass/volume limits matter) - Always allow stacking up to 10 items, as long as cargo parts are technically identical, don't contain resources and aren't specifically excluded from being stackable in the configs. - Overhaul the stock inventory UI with a "pages" system, and make the grid user-resizable so it doesn't take so many space in the PAW While this is technically entirely compatible with the stock system, it is nevertheless a deep modification and can potentially cause compatibility issues with other mods relying on the stock behavior (especially the in-progress KIS 2 mod). So I'm not sure what to do with it yet.
  4. Likely not so easy to do. The crew assignment stuff is quite messy, and messing with it might have unintended side issues with other mods... I will try to look into it.
  5. V1.2.0 is out. Available from GitHub and CKAN. New QoL tweak, TweakableWheelsAutostrut [KSP 1.8.0 - 1.12.2] : Allow tweaking the autostrut mode of wheels/landing legs. Still default to "heaviest part".
  6. I'm not pessimistic, I'm just saying that what KSP 2 is focused on isn't what I personally want to do in a KSP game. They obviously are making the "lets assure a commercial success" choices, I'm fine with that, but it isn't the "rocket game" I personally would like to play. I don't want things to be simple. I want game that I can play for hundreds of hours, with complex gameplay elements, and a less emphasis on the "derpy toy/scifi world" aspect, and more emphasis on the "real world rocket/space program simulation" aspect. Which is a much more niche genre. It isn't. If there aren't any branches, it isn't a tree. If you want a comparison with a commonly used game mechanic, it's like a "Level up ! Choose a new ability to unlock" thing.
  7. Problem is, there isn't much choice to give. Every "technology" is mandatory at some point. You need parachutes, landing legs, heat shields, fuel tanks, RCS, reaction wheels, thermal control, solar power, batteries, etc... The only potential strategic choices are choosing between a handful of advanced propulsion systems, plus maybe the "nuclear power or not" choice. If they really want to give those choices, that would still work with a "single line" progression : when you reach X progression points, you can choose one tech between the 5-6 "advanced techs", and at the next "progression threshold", you can choose another, etc. But I don't see the need for a "tree" of any kind. You're missing the point of the "very few tech nodes". Those situations wouldn't happen because there is no such granularity, and because there are very few milestones before unlocking the vast majority of parts and functionalities. The progression revolving around what the player accomplishes (base/station construction, supply runs, etc) is enough, no need to create arbitrary and hard to balance low granularity "tech gating" on top of that. What I describe isn't what I would like. It is what I think we will get. Personally, I would definitely prefer an in-depth "space program management" sub-game complete with funding, a proper contracts system, time based rocket construction, time base science, individual part unlocks based on time based research, a proper life support system... But that's definitely not what we are gonna get. We are gonna get a "guided sandbox" with interstellar fluff, scifi propulsion, colonies, and multiplayer. All things that I absolutely don't care for.
  8. We can't do much but speculate. But based on what they said and what I think would make sense, this is what I mean by a "slightly part availability gated sandbox" : A single "progression point" variable, where those points are acquired : Passively, on reaching various milestone (like the "world firsts" KSP 1 system) : distance traveled, speed attained, reaching a body SOI/orbit/landed/biome, using a mechanic (ISRU/in situ construction...) for the first time, colony achievements/bloom events, finding special places/easter eggs, stuff like that. Actively, by transmitting or retrieving part experiment results (same mechanics as for KSP 1 science points). Very few different experiments (~5-6), available from the start. A single branch, linear "technology" progression, with maybe ~20 "nodes", each unlocking a large batch of rocket/colony parts. Basically, one node for every major technological milestone : one for each propulsion technology, one for each major colony/station capability, a bunch of extra nodes at the start for not overwhelming new players with tons of options. They unlock passively, when the total acquired "progression points" reach a given amount. To spice it up a bit, that system could also have an "actively spend progression points" mechanic for : Launching rockets from KSC, with the progression point cost based on the rocket mass. Launching the special colony/station "core" parts. Hiring new kerbals. KSC upgrades, for example to increase launch mass limits or DSN range. Spending points wouldn't change how the "tech progression" works, it would be purely based on the total points ever acquired. This avoid the "part availability mismatch" issue of the KSP 1 tech tree where you inevitable end up doing silly designs due to parts being both categorized by size and function. This also avoid having to balance a per part "tech cost". The only limiting factor is vehicle launch mass, all part sizes are available once the corresponding technology node is unlocked. In that system, the vast majority of parts would be made available in the first ~5-10 tech nodes, designed to be achieved quite quickly, including all structural/utility/control/aero parts.
  9. It is fundamentally linear. Launch a basic rocket, reach orbit, go to the moons, go interplanetary, go interstellar. Arguably, the 4-5 "technological steps" for doing so are quite linear : first chemical, then chemical++, nuclear fission, nuclear fusion and finally sci-fi exotic stuff. There isn't really enough there to build a meaningful "tech tree choice" gameplay around that, unless they actually develop a whole in-depth "space program tycoon" sub-game, which at this point we know won't happen. This is why I doubt there will be any significant depth to the "adventure mode" mechanics. They gave strong hints that they won't repeat the same mistake as KSP career mode : introducing "tycoon/strategy" like mechanics without having any significant gameplay elements to back them. Moreover, a "player decisions" gameplay will already exist through colonies/stations building/growth and associated gameplay elements : ISRU, colony growth, offworld vessel construction, resupply lines... Arguably, this is the progression gameplay, directly involving the core "lego building / piloting vehicules around" element. Why would they need to add complex abstracted progression concepts on top of that ? To satisfy the 0.1 % of players that will play the game more than 100 hours ? The fundamentals of KSP are about building rockets, flying them and reaching space and distant worlds in a somewhat physically accurate way. This is the fun part. They will succeed if they get that right, and this in itself is a huge task. At some point, some of the KSP 1 devs commented that when analyzing the collected statistics, they discovered that vast majority of people that bought the game didn't ever get past Kerbin orbit. The "forum population" is NOT representative of the player base. They are the 1% advanced, noisy, nerdy players. If the KSP 2 devs are doing their job right, focus will be accessibility of the core gameplay elements : building rockets that work and piloting them to their destination so Kerbals can go interplanetary/interstellar and build distant colonies, and making exploration interesting by making beautiful worlds, with more variety and unique features. It would be a much higher payoff to introduce "lore" stuff (kerbal artifacts, alien/kraken stuff...), then create some sort of "quest/story" gameplay element than building a pointless progression system. They have given a lot of information on the accessibility/core physics/stuff to explore topics, but they have been quite silent on the "adventure mode" mechanics. Likely because there isn't much to it, and the "KSP 1 nerds community" has huge misplaced expectations on that front. But I wouldn't be surprised if that is because they have a "lore/story" progression element they want to keep secret until launch. Advanced progression mechanics are the realm of mods, or DLCs / extensions. Which are an essential part of the economical model of a game like KSP. But it certainly won't be a launch-day feature.
  10. You (and a lot of people in this thread) are assuming that there still will be a KSP1-like tech tree, KSP1-like science points, KSP1-like experiment parts... All we know is that the whole progression system is completely different, and somehow based on "achievements", which can come from doing science, going places, reaching specific milestones... There was a few hints that concepts like funds or a tech tree tied to science points acquired by performing experiments don't exist anymore. This leave a lot of room for interpretation on the actual gameplay mechanics involved, but thinking about it by taking KSP 1 mechanics as point of reference is a bit pointless. Personally, I expect things to be a lot more basic than in KSP 1. From the developer POV, the progression system is the least important aspect of KSP. Nobody is gonna buy that game for its progression gameplay mechanics. They are clearly counting on the interstellar/colonies stuff wow factor, as well as graphics and multiplayer. So this is where the development resources are. The likely only design goal of the progression system is to give new players directions, and to cost the least possible to develop. Likely a single "progression points" variable that increase passively when you go somewhere new, or perform something for the first time, and probably a single "technology tier" system that passively unlock new parts when you you have accumulated X progression points. I doubt we will have any significant "experiment system". I would be very surprised if its anything more complicated than "be somewhere" > "click on a perform experiment button" > "have an antenna or return the data" > "get progression points". Arguably, the only real KSP 1 issue with that system is a UI one. Frankly, I expect the so called "Adventure Mode" to be a slightly "part availability gated" sandbox. I doubt there will even be any form of "costs" for doing stuff like launching a new vessel or hiring kerbals for example.
  11. V1.1 pre-release is out. A lot of new stuff in there, so I will wait a bit before pushing the update to CKAN and updating the OP. Meanwhile, you can get it from GitHub Please report any issue, and please use KSPBugReport to do so. Required and must be downloaded separately : HarmonyKSP : Download - Homepage - Available on [CKAN] ModuleManager : Download - Forum post - Available on [CKAN] Installation Download the file named KSPCommunityFixes_x.x.x.zip Open the downloaded *.zip archive Open the GameData folder of your KSP installation Delete any existing KSPCommunityFixes folder in your GameData folder Copy the KSPCommunityFixes folder found in the archive into your GameData folder Changes in 1.1.0 KSP Bugfixes ModuleIndexingMismatch [KSP 1.8.0 - 1.12.2] : Prevent modules persisted state from being lost in existing saves/ships following a mod installation/uninstallation/update. Note that this won't handle all cases, but it massively reduce occurrences of that issue. StockAlarmCustomFormatterDate [KSP 1.12.0 - 1.12.2] : Make the stock alarm respect the day/year length defined by mods like Kronometer. Fix the underlying AppUIMemberDateTime UI widget API to use the mod-provided IDateTimeFormatter if present. PAWGroupMemory [KSP 1.8.0 - 1.12.2] : Fix the expanded/retracted state of Part Action Window groups being reset when the PAW is closed or internally rebuilt (especially frequent in the editor). KerbalInventoryPersistence [KSP 1.12.2] : Fix the whole kerbal inventory persistence system being inactive in KSP 1.12.2. This cause multiple issues, like being able to bypass kerbal inventories mass/volume limits, and various cargo part duplication / disappearance issues when EVAing / boarding. FlightSceneLoadKraken [KSP 1.8.0 - 1.12.2] : Prevent kraken events on flight scene load in laggy situations Quality of Life tweaks PAWStockGroups [KSP 1.11.1 - 1.12.2] : Part Action Window groups for a selection of stock modules Mod API MultipleModuleInPartAPI : This API allow other plugins to implement PartModules that can exist in multiple occurrence in a single part and won't suffer "module indexing mismatch" persistent data losses following part configuration changes. See documentation on the wiki.
  12. *sigh*... No, the dll isn't there. Should I really explain it a third time, or are you gonna read the post just above yours ?
  13. No. The CLS core functionality is in "ConnectedLivingSpace.dll", which is only distributed with CLS. That one will cause the "ConnectedLivingSpace" keyword to be added by MM (as well as the fact that a "ConnectedLivingSpace" folder exists in GameData). "CLSInterfaces.dll" is an additional assembly distributed by both CLS and other mods using it, for the purpose of plugin interoperability. It will indeed cause a "CLSInterfaces" keyword to be added to MM, but nobody should ever be checking that in a MM NEEDS.
  14. No. MM will only register a CLSInterfaces keyword if the interface dll is present. MM adds NEEDS keyword by looking for *.dll names and gamedata root folders names. As long as no ConnectedLivingSpace.dll exists, and that no ConnectedLivingSpace gamedata root folder exists, a NEEDS[ConnectedLivingSpace] patch won't be applied. The best solution to work around that KSP bug is having mods using CLSInterfaces.dll redistributing it from within their own mod folder, but renaming it with an unique name like "CLSInterfaces_MyMod.dll" I confirm that this work without side issues, both in 1.12.2 and 1.11.1 (so before and after Squad modified the assembly loader). The assembly loader will have two separate wrapper entries, but only one common interface assembly will actually be loaded : This solution is the one that will have the least impact and require the least work from everyone's POV. It doesn't require any change on CKAN and neither on the CLS side and won't break any player install that isn't already broken by the KSP bug. It only require updating mods using the CLS interface.
  15. It will cause any mod having a MM patch relying on a NEEDS[ConnectedLivingSpace] to have that patch wrongly applied when CLS isn't actually installed.
  16. I guess @Tacombelidea of just using an unique name for dll when redistributing it might work. Unfortunately, there is no way to fix that KSP bug through a plugin, as the presence of duplicated dll will either : - Causes the plugin loader to crash with an ArgumentOutOfRangeException - Silently delete random plugins from the list of plugins to be loaded. At best, in the former case, the issue can be detected (but not avoided, since in any case, it's already too late). My fix (the one I linked a few post above) rely on using an external Unity mod loader, so I'm able to run some code before the KSP plugin loader execution.
  17. I think that may work. At the runtime level, if I remember correctly, only the "first found" one will be loaded. However, this will definitely have some side effects on the plugin loader. How problematic that will be, I don't know. Probably not much in that case.
  18. This has drawbacks and would be a breaking change. Standardizing CLSInterface to be a separate mod is a better solution. If CLSInterface is distributed by everyone as "GameData\CLSInterface\CLSInterface.dll", the likeliness of end users having duplicates becomes quite low.
  19. The plugin loader in 1.12 is broken and will crash when multiple *.dll files with the same name exists in GameData. Details here : https://github.com/gotmachine/StuckOnLoadingPartUpgradesFix
  20. They are indeed extremely cheaty. Not because they don't have saturation mechanics, but because compared to real world reaction wheels, for an equal mass, the torque they provide is about 100 times higher. For example, you can compare the KSP 0.625m small reaction wheel that weight 50 kg and provide 5 kNm of torque to that real CMG assembly that provide only 0.075 kNm of torque, weight 70 kg and is roughly a 0.6m cube. The figures for the much larger ISS CMG assembly are identical : 280 kg, 1.2m, only 0.26 kNm. Said otherwise, to be realistic from a mass POV, the KSP 0.625m reaction wheel should be weighting about 5 tons. If you want a quick and dirty fix, you can use the following ModuleManager patch (put that in a *.cfg file anywhere in your gamedata folder) @PART[*]:HAS[@MODULE[ModuleReactionWheel]]:FINAL { @MODULE[ModuleReactionWheel] { @PitchTorque *= 0.01 @YawTorque *= 0.01 @RollTorque *= 0.01 } }
  21. The loading times on scene switch is due to a bad design decision to have the core game database belonging to scene objects instead of being DontDestroyOnLoad root objects, which cause KSP to make almost the whole game to go through an useless full serialization/deserialization cycle. To their discharge, managing that pattern is quite a lot easier in recent Unity versions and the "additive scenes" feature. KSP doesn't use the ECS system. It's entirely built on the GameObject system. And BTW, Unity's ECS implementation is merely a few years old, and has been out of "experimental" only since last year. This is a (common) urban legend. There is zero threading involved in any part of KSP, at the notable exception of the stock delta-v calcs. The only threading happening is on the Unity renderer side and on the PhysX engine side.
  22. How "exposed" something is doesn't matter as far as the EULA is concerned. The EULA forbid an act, it doesn't care about the tools you use. The only thing that the EULA doesn't explicitly forbid is purely "additive" modifications. For example a new part. But even in that case, the "red line" can be quite blurry. For example, in intent, a combination of Kopernicus + OPM doesn't end in a modification, the stock system remains as originally provided. But under the hood, there are still significant alterations being performed, and those still are a "reverse engineering/decompile/dissemble" act. In the end, the issue is that the EULA is completely disconnected from the existence of modding. It's a copypasted standard end user software contract. From there, any attempt at rationally determine how it apply to modding is an exercise in futility. Which is why the so-called "addon posting rules" with the "follow the EULA" statement doesn't make much sense. To take a step back on the situation, it should be noted that at the notable exception of Minecraft, as far as I know, all games in existence having a "recognized" modding community are in the same situation with their EULA. At best, the developer/publisher has made a public statement, or has a separate contract for using the official mod sharing services (that's what the KSP addon posting rules are), saying that modding is tolerated, sometimes with some additional details. The KSP addon posting rules are a relic of a 9 years old forum post, written by a modder with a quite aggressive and restrictive policy in mind at the time. But since then, the modding scene has been blooming in size and technical ability, resulting in daily infringements on both the EULA and those rules, all that while Squad was praising said mods in "thread of the month" posts and saying how proud it is of the modding community. For example, at the time, there was a hardcoded ban in the plugin loader on the System.IO and System.XML namespaces, something that was reverted latter without any explanation (as far as I know, but I bet there is a juicy story behind that). Somehow, what this guy said 9 years ago and that long gone forum post has become the "source of truth" over the years. My bet is that neither Private Division, Intercept games, or what now remains of Squad has an actual "modding policy", beside interpretations and opinions of individual employees or of the forum moderation team members. An example how this is completely arbitrary : the forum moderation is aggressively removing any discussion containing technical details obtained trough KSP assembly reverse-engineering, but has no problem with technical details obtained by reverse engineering the KSP assets. All this to say I wholly support and understand your position, and would very much like to see the "officials" taking a stance that acknowledge the reality of KSP modding : modders need to break the EULA and they need to reverse-engineer the game. You can't mod what you don't understand. It would be wonderful if the KSP forums actually allowed the exchange of all technical information between modders, instead of us having to hide on unofficial channels. Due to KSP being a tiny game now belonging to a AAA publisher, I doubt we will ever see a custom modding-friendly EULA. But maybe they could release an actual "modding policy" that doesn't try to supersede the EULA while not doing it at the same time like the current addon posting rules, and just acknowledge that they are wishing to "look the other way" on EULA infringements in the context of modding. If you think this is a silly idea, this exactly what Rockstar (a T2 subsidiary, like Private Division) has for GTA games : https://support.rockstargames.com/articles/115009494848/PC-Single-Player-Mods
  23. If I may, Kopernicus has always violated the EULA in its intent, and in practice by replacing the PSystem prefab. There is no legal or technical difference in the act of replacing a game asset by using the tools provided by the underlying Unity engine API or replacing a portion of the game code using the tools provided by the underlying CLR and .NET framework through the Harmony library. In both cases, this is a reverse engineering act performing a modification of the provided software, which is a double violation of the EULA.
×
×
  • Create New...