IgorZ

I'm disappointed too. However, I've seen this before with the other products (not only games). Determining the key aspects of the product and focusing on them during the course of the production is a rare skill. Not many people have it. Hopefully, the devs will make the right conclusions on the community reaction. One reason of KSP1 success was the active devs role.

MechJeb and the other KSP1 mods are all in C#. It's not about converting them into another programming language, it's about using new game's API. KSP1 doesn't provide an API, but people got used to the codebase (but, of course, nobody decompiled it!). Developers of KSP2 claimed there will be some API, but at this point it's nothing but promises. One way or another community will learn how to make mods for KSP2, but the needed time depends on the devs participation (which is zero as of today).

In the countries where "law" is not just a word "the mere accusation" is not enough. An arrest warrant is required. And the arrest warrant is issued by a judge on the basis of the evidence. No evidence, no warrant. But. Anyway.

The rule can be applied, but its not required to be applied. The reason why such rules were included in EULA at all was an attempt to prevent cracking of the software. Of course, it doesn't prevent cracking, but it makes such activity illegal. And saying about how the law works: you cannot be sentenced just because someone said you were decompiling the code, even if that "someone" was yourself. The prosecution must prove the violation, and it's something that requires significant resources. As long as your actions don't harm the product nobody will be wasting time and resources on hunting you.

People overestimate the power of EULA. The KSP one looks to me as a standard end-user agreement used by the software companies. Thus, the rule to not decompile the game does not necessarily reflect the intent of Private Division. However, I'd be surprised if their legal department would give permission to avoid it. If I understand anything about legals (and I dare to believe I do), they will be ignoring any incoming requests for a permission to not follow EULA. The rule of thumb is common sense. As long as you don't commit a crime (and don't promote others to do so), nobody cares if you decompile the program or not. Without a good reason, the legal department won't be hunting people on the forums to prevent games code decompilation. And for those who are still concerned, I'd like to highlight two bullets from EULA: You must be an adult to accept the EULA. If you're not, then you cannot play this game until your guardant accepted the EULA. I have doubts that this requirement is strictly followed by all the players. EULA explicitly states that all disputes are to be resolved in arbitration and not in court. That being said, you won't be dragged into court and put in jail if you decompiled the code just to take a look at it. The very first thing that should happen in this case (according to EULA) is the publisher contacting you and asking to stop. That's how arbitration always starts. So, instead of asking for permission to not follow EULA (which you will never get) just start doing whatever you have in mind and wait for the reaction.

I recall statements early in 2020 declaring that KSP2 will be "modders friendly". Well, we have an early access version came out, which is very unlikely can be named as "modders friendly". No docs on the concept. No API declaration. No easy way to tackle things (everything is in Unity bundles and assets). LUA mystery. As far as I can tell, the current state is even worse than we had with KSP1. I wonder if there are any real plans to make the game moddable. And if the answer is "yes", what's the timeline?

This is one of my favorite mods. However, based on what I've seen in the early access version, we need to be patient until MechJeb is made. And I mean, we need a hell of a lot of patience.

Did you just decompile the code and found the "loader" (which I did found too) or do you know how to use it to make a custom part? Any insight would be appreciated. As of now, the game doesn't seem to be moddable. I recall the early declarations that KSP2 will be modders friendly. Well, the early access version is certainly not friendly. And not only to the modders, if you ask me.

If you are in the rpocess of choosing, I'd ercommend you trying KISv21 Alpha. It's integrating with the stock invwntory. I hope to go into beta in February.

It used to work well... like couple of years ago. Since than many things changed in the game mechanics. The rule of thumb, do not use the attach feature on those parts. It had issues perviously (the Kraken), and it may not work at all today. If you absolutely need to attach something rigidly to the ground, use the stock ground parts (not sure wich mod it is) and attach KAS pylons to it. But honestly, if I were you, I'd avoid to use anything attached to the ground at the all means possible (and that's why in the new KAS there is an RTS part with no rigid connection). You never know how it can hit you, but it will hit you one day. It was happening to me pretty constantly.

Went to check it and figured you own it Great idea btw. In my mods I try to give meaningful names to the parts. Alas, there is no standard on it.

Alpha-5 Changes: Fix "=====" strings in tooltip for some users (a mods conflict issue). Use a specialized KSPDev_Utils version to not collide with the other mods. Some small bug fixes and regressions. @KawaiiLucy @flart Thanks folks for your input! I really value your efforts in helping to make this mod live.

@KawaiiLucy @flart I've figured the reason of "=====" tooltips. It's a broken localization file somewhere in your games. Not happening in the pristine game to me, so I tend to think it's some mod. I know how to workaround it in KIS2, though. Will do in the next alpha. FWIW, here is a config that makes this issue: Localization { en-us { ====== } } Looks like a bad comment in some localization config. I'd love to know a list of mods in your games to verify this theory.

No, RTS part can only work between two separate vessels.

The shortcuts are supposed to be there. What do you see in the tooltip? This is absolutely insane! Could you please share your logs? What if you run a pristine game with only KIS2 installed, will you have the same issue? It used to be in the KSP 1.12.3 and before. I was going to address it one day, but it seems in 1.12.4 it's magically solved. At least for me. I noticed that the surface attach parts go under the surface of the target part. It was an issue in Alpha-3. Are you sure you've updated? The explosion is a result of the new part collision.

Have you installed KIS/KAS manually or via CKAN? One common mistake people do is installing sources archive from GitHub instead of the release package. Verify that you have ModuleManager installed. It's required. Go through https://github.com/ihsoft/KIS/wiki/Troubleshooting, it covers many common problems. Keep in mind that stock inventories and KIS inventories are completely independent things. If you put a part into stock inventory, you won't find it in the KIS inventory, And vise versa. Note, that there is KISv2 "alpha" version. There, the stock and the KIS inventories work together. If nothing from the above helped, please share a log.

I'm glad you've found the answer However, I'd not recommend attaching KIS blocks to the ground (even though there is such an ability). Those parts have issues, but people were ok with them because there were no alternatives. Now, there is a stock anchor, which presumably is much more stable. And in general, if you don't really need to statically attach a vessel to the ground, then don't do it "just in case". For the refueling purpose unattached pylons (like "GP-20 Pylon") are just fine. They will move slightly on the scene load, but with the flexible pipes (like "Hose-70") it's not a problem.

Forgot to mention what to test. The main focus is on to: The clarity of the UI. It should be intuitive. If it's not, let me know your use-case. Basically, the goal is to eliminate the question "what should I do if". You just start doing whatever you want and UI gives the hints. Nothing is expected to explode. There can be glitches, and I want to know about them! The new UI is supposed to be better than the stock (it's the whole purpose of KISv2!). If it's not, then I eager to know why. This is the time to start reporting bugs. If you see something , say something! I never tested this mod in the orbit or on a planet with low gravity. Are there any brave volontiers who can afford losing a base or a station?

Alpha-4 Support drop and attach parts. Stack node / surafce attach mode switch. Press and hold "J" to activate pickup mode in flight. All other keys will be shown in the tooltip hints. The mod is designed so that new people dopn't need to learn "magic keys". All available ekys in any mode are shown either in the tooltop or at the screen top. The "J" key is the only exception, this one you need to remember.

This is interesting. The logs look good, but the result is strange. Could you please send me the save game and the instruction on how to reproduce the issue in PM? I really need such samples (non launchpad or simulated orbit).

Some updates: https://www.patreon.com/posts/kisv2-attach-is-73036232 I'm going to prepare a build soon.

In case of you were following the KISv2 Alpha progress: https://www.patreon.com/posts/kisv2-attach-is-73036232

Can you make an isolated test for this case? The parts hierarchy can sometimes become tricky, and the edge cases are possible. Also, please enable verbose logging in the game and collect logs during the problem reproduction. It may give me a clue.

I'm not sure how is this situation related to KIS/KAS (my field of responsibility), but I know when this kind of things happen. I saw a lot of this stuff in my KIS developer carrier. It happens when the part object got detached with no `Vessel` module on it. The most common case is an exception in the middle of the part attach/detach process. Such cases can easily happen due to a mod conflict issue. No way it can be worked out with no detailed logs. Enable verbose logging in the game, reproduce the case, then share => chances to find the reason. However, a better approach is removing the mods one by one until the problem is gone. Knowing the name of the "offender" reduces the amount of work by an order of magnitude.

And I forgot to mention that the latest fix was made not by me, but by @Rodger. Sorry, didn't mean take it as my own achievement My skills with textures and normals are very humble.