unregistered_user

Looking into EPL (the real mod, not the "[provided]" from SC) I have found a file that seemed promising (launchpad.dll), so I yoinked it straight out of there and placed it in "SC/Plugins/". Things worked now... except the "Show UI" on dockingports shows a messy thing missing loads of textures and localization strings. Most likely related to the "UI" directory in EPL. Yoinking said UI folder into SC/ solves the texture issues. Sorta. Most of them turn entirely transparent. Better than entirely white bg's with white text, tho. As for the localization, both SC and the EPL version SC installed has a localization file, but lacks the UI strings one can see in EPL's localization file. So yoinking it straight won't work due to namespace collision ("en-us.cfg"), and instead it has to be placed in a custom mod, or files has to be somehow merged. I opted for a combination, making a new directory "SC/Localization/EPL/.", where I yoinked the file to, merging them in File System-style just like if I had made a new mod, avoiding the bother of having to edit a file. Conclusion, there is indeed a missing dependency in CKAN's version of SC. Or missing files. Either way, the user needs to manually stuff from EPL. All this did however not get SC working for my purposes, as I downloaded it after looking for a way to spawn Parts in space. When I open the UI -> select craft -> Parts, all I get is an empty list, with the header "parts".

I am having issues with this SimpleConstruction [SC] mod. I installed through CKAN, so I got all dependencies listed there, and ensured that I didn't install ExtraPlanetaryLaunchpads [EPL] alongside it (particularly as CKAN lists that SC "provides" EPL). Of note, CKAN lists SC as having a conflict with itself, but installed it without issues despite that. For the sake of eliminating confusion, these are the dependencies I it lists and I got: ModuleManager 4.2.2 [required] Community Resource Pack v112.0.1 [required] KAS 1.12 [suggested] (had it beforehand) And looking in my gamedata folder, I see a directory "ExtraplanetaryLaunchpads" dated at the same time as SC (so likely created by CKAN due to the [Provides] relation), with very few files. Most of which are localization- & texture- files. The issue I experience: While I get ore-tanks for metal and rocketparts (I was under the impression that they would let me select what they stored in the VAB? Apparently not, they are all distinct Parts) I do not get the modules for producing metal or rocketparts in the ISRU and Lab respectively. I also do not get the module for showing UI in the docking port. In other words, none of the context-menu functionality is added! Looking through the logs, I get some unrelated spam every now and then from this mod, with a couple duplicate entries each time (let's go on a tangent!). But were unable to spot anything else from this mod (though there were also often errors from MOARdV's AvionicsSystems mod - but again, seem unrelated to the error, and this time also unrelated to this mod): Looking at the files relating to the errors, I see that despite what the msg says the 'effects' do indeed exist in ExperienceTraits.cfg: As for the actual issue I mentioned at start (returning from the above tangent), when I look at the files for the parts, I think I see the issue. They all state a need for a mod named "Launchpad", but I have no such mod, SC lists no such dependency, and doesn't provide any entry for it. Even when searching my entire GameData folder for any entries regarding "Launchpad", the closest I find are either other patches with a dependency ("NEEDS[Launchpad]") for that mod, or lines that merely contain the word in some other identifier (ie. "ELLaunchpad", or "EL_ELLaunchpad_title"). So as far as I can tell, there's some kind of missing dependency? ex. DockingPorts.cfg (make note of line 6 - "NEEDS[Launchpad,SimpleConstruction]"):

Hm, that sounds problematic. iirc you mention that you have the breaking ground DLC, is it possible to try running the game with it disabled? I have the buttons in 1.9.1.2788 (without dlc): https://imgur.com/RS4rITx (in editor, third from left) https://imgur.com/iIc9Gut (in flight, fourth from bottom). Worth mentioning is that the button only shows up if the craft actually has a (IR-next) robotic part in it (And the panel defaults to closed). I assume you did have one, but might be worth mentioning just-in-case.

What control panel? You mean the one on the right here (stole image from google)? https://i.imgur.com/ZfCMjyi.jpg (The button to open it is below a button that is labeled 'SEP', which is below KerbalAlarmClock). If so, then that pretty much makes the mod completely unusuable, does it not? So how did you get some parts to work in (4.)? If that is not what you referred to, and you meant the sequencer tool (the one with graphs and the like) instead, then that is not part of this mod (there exists a mod for that, but I have no idea if it works with '-Next').

If by CKAN version you mean the 'InfernalRoboticsNext' one (there are way too many IR versions there, so important to use the Identifier), I have used it on 1.8, and I think on 1.9 too (don't actually remember, haven't played much 1.9 due to lacking principia)? I don't have the dlc tho. And on the topic of "how big of a bug is 'too big'", imo that would be "crashes the game on startup/load" and "does not do what its description states it does". But yes, it is probably best if ckan doesn't have to be the judge.

No clue. As I said, I have no ability to build stuff for ksp, so all I can do it read the source and make guesses (just like anyone else). But if you ask me what my guess is, then it is that commenting out that line would work to at least some extent, though I dont know what new bugs might pop up, and I strongly suspect at least some of the weird rotations (the ones that rotates the entire part, and not just the hinge) comes from elsewhere and would remain.

How do I clone a Part using Mod manager? The thing that annoyed me wasn't that partslist gets more pods (thats ok to me as I rename them), but that I have to manually copy the model targeted (model.mu, the .dds files, etc.) and edit it to become a new part. Instead of just something like `COPY[Part[partname], newpartname]` in a mm-patch solving it as a one-liner (or two, if new name has to be specified in its own line). Making the IVA's into variants would be really cool. A quick google suggests the variant-themes can't support that though ("can only change texture and hide/show models visually" implies the collision remains, or more importantly in this case, the button-click interaction), so I am guessing the idea is that it would be more like its own theme-system, similar to how procedural parts and/or fuel-changing mods does it?

There seem to be conflicts. I have multiple mods to give nice IVAs that touch the same pods, but instead of resolving nicely by having both versions available, only one ends up existing. My guess is that the mods have conflicts and as such only one can "win" (likely caused by execution-order?) and be available in-game. I think there are more than one pod/mod that conflicts, but the one I noticed was MK1 lander-can conflicting with Moardv's MAS mk1landercan. Aside from this mod making the effort to fix its conflicts, I am more curious if anyone could point me at a mod that solves all such conflicts (preferably letting me specify the name the copies receive, instead of making parts named the same or named with IDs), or if no such mod exists, in the right direction for how to set-up a folder in GameData that points at pods I noticed "lost" the conflict-war, and create a new part based on that with name I specify. edit: I figured out a way to do it, though its not pretty. For each mod conflicting a part, I have to manually make a copy of the squad-part with renamed name= in the cfg. - can't figure out a way for modulemanager to say "I reference the same model-etc. as this part, but with this name edited" manually make a full copy of the IVA-Patch .cfg where I edit the targeted part: @PART[landerCabinSmall] -> @PART[landerCabinSmall_DE] - can't figure out how to use modulemanager to not just target and edit a @Part, but rather instead target another modulemanager patch and edit what is inside the square brackets manually add a line to edit the title (doesn't have to, but its nice to be able to differ between the pods in partslist) And then I have to manually make a mm-patch .cfg to remove the original (cause I couldn't bother to check which mod won the conflict-war, so I did the above for every mod, not just the losers. Meaning the winner would have had a duplicate). Preferably I would have wanted an automatic script that detected a conflict and fixed it all by itself. Possibly letting me map a (part,mod) -> title, for when the generated title is annoying. Preferably preferably, I wouldn't have needed to copy the entire part either, feels like this way will quickly add up to memory-usage when it could have reused the parts model etc.

As Frege didn't have a 1.9 build (released before the new ksp version), I waited for the new moon. But Frenet (released after the new ksp version) never seemed to manage to build for 1.9 either? Or am I somehow not seeing a link in the github README that links to the 1.9 build? Nothing is mentioned anywhere (github readme / forum OP) about skipping 1.9, so I am guessing this is an oversight? ps: this threads title probably need an update. Still only lists up to 1.8.

Another report, albeit rather minor: engaging limits and setting min = max causes spazzing. My guess is either a division by zero, or some conditional logic having issues. Doesn't seem to really cause issues though. Can also report/verify that the prior reported bugs are at the very least not tied to the mod principia. I just tried making a new save with that mod removed as it sometimes cause weird interaction with mods (or even manual editing of save-files. The Orbit of vessels written in the save is unrelated to the actual orbit and position of the vessel, which is why principia breaks hyperedit). Makes sense it was not the cause this time though, as robotics doesn't affect orbit (only affects parts). In short that means I tested (and verified they remain) the bugs: Engaging locks at 90 (spazzes after a few seconds, as if unsure if it is 0 or 90. Or sometimes just directly cuts to a near-0 angle. My guess it is added weight/struts that causes the spaz) while engaging at 0 works fine, and anything inbetween has a response proportional to the magnitude of the delta to 0 setting servos at 90 and going to space-center then back to vessel has the servos returned to 0, except the controller thinking it is at 90 (thus making it possible to go to -90 despite it being a [0,90] servo). While returning to 0 and going back and forth, there is no issue. I mentioned before that it seems to be caused by a line in the code that looks to be an attempt to persist locks. Locking and going back and forth seems to have same issue (cause locks can only be at 0?), except add some weirdness (most likely because the lock isn't exactly at 0). The parts do rotate similar to 3&4 too, but not quite the same. This seems more related to the commandedposition Couldnt reproduce the weird one from edits 3&4, but that is likely because I haven't figured out the trigger, rather than being caused by principia. Overall I get a feeling that one bug was more of a rare thing, but I can't be sure. edit: btw, any reason why "issues" is not enabled on the github repo?

I think I might have found the source of the bug where joints rotate over loads if used (and thus also the deriving bug that lets joints bend outside their constraints after loading vessel). From what I can tell, the issue is line 601 in Module/ModuleIRServo_v3.cs: commandedPosition = -lockPosition; From what I can tell, simply removing this line should fix everything. Though I have no environ setup to build ksp projects, so can't test myself. lockPosition is always 0 (likely because I haven't applied any locks). Commandedposition of the servo - which is always set to 0 on load thanks to that line - along with correction_1 are the two values in save-file that seems to affect servo-position. Say you have a half-hinge (or a hinge constrained to become one), if you activate it and move it to 90 before returning to space-center the save-file reflects this for both commandedposition and correction_1. But on load commandedposition is reset to 0 (and the part and its attached parts are returned to the 0-position), so while correction_1 makes servo unable to rotate in a positive direction and only allows negative (thinks it is fully at 90), if you do rotate it -90 while it will move correction_1 towards 0, it will move Commandedposition from 0->-90. Which is outside constraints, and often means it rotates into and through the ship (luckily there seem to be no collisions enabled). While if Commandedposition remains unchanged on load, this issue should not exist, as the parts would likely remain in the angle and position they were on save, and going negative direction would merely return them to their "home-position". ps: posted a bugreport about the bug a while back, but it was either in another thread, or the moderators failed to approve my post, as I can't seem to find it. edit: tried engaging locks... seems to spaz everything out for some reason? Though it takes a second or two (no need to load crafts, or timewarp). edit2: aha, so for some reason, a locked servo forces itself to be zeroed (after a couple seconds passed)? Causing spazzes if it wasn't when it was locked. edit3: seems to be more issues than that tho. Had forgotten that there is a similarly induced bug that rotates the actual part too, not just zeroing its commandedposition quicksaving doesnt make it known, but going back and forth between space center seems to sometimes? Or is it when closed ksp and relaunched and resuming the save? edit4: nope, seems even more strict in its requirements to reproduce. So I can't force my bugged craft to rotate back/a full rotation I guess it is stuck bouncing over minmus surface using active mining drills as impromptu "landing legs".