Murdabenne

@bsooner77 (Sic 'em Bears! Heh) Try this message - it gives a good detailed way to make the best possible request for help that will get your bug/question addressed properly, and quicker than any other:

@UomoCapra, I was checking the additional DLC purchases in preparation for a clean 1.11.2 install, and these appear to be the listings: Breaking Ground 1.6.1 "Use this installer if you have a non translated copy of KSP 1.11.2" -> KSP-Breaking_Ground_Expansion-en-us-1.6.1.exe Making History Expansion 1.11.1 "Use this installer if you have a non translated copy of KSP 1.11.2" -> KSP-Making_History_Expansion-en-us-1.11.1.exe These appear to be the same as the previous ones. Is it safe to say I can reuse those or do I need to download what appear to be identical files for a fresh (updated) install to 1.11.2 all around? (A suggestion: sync all the DLC to have the name versioning file name as the base game for which they are intended. It would clear up any possible misunderstanding, even if it is simply a filename change, maybe something like "KSP-Breaking_Ground_Expansion-en-us-1.11.2.exe or even "Breaking_Ground_Expansion-1.6.1-en-us-for-KSP-1.11.2")

I ran into this just now, except that I rechecked what I launched, and NEITHER of the ports were root at launch. So is there any alternative way other than relaunching the entire thing? I made sure I had rerooted the entire ship to the control point (command pod) when I saved just prior to queuing it for launch. ADD: I reloaded to prior to my launch, DELETED the part off the station, re-added them. It still fails after I get into orbit. And now I cannot dock with the one construction port at the aft end. My tug, using a normal port, can dock just fine with another tug, and with a lateral (normal) port on this station, but the Construction Port refuses to dock. I even rebuilt the station using the normal ports, cheated them into orbit, and tried docking, and it worked fine as long as there was not a Construction Port there. I tried changing snap, angle, force, F5-F9, resetting the acquire, and even pushing the ports together and slowly rotating. I've never had these just completely refuse to function. I even tried uninstalling and reinstalling vi CKAN. Is there something I missed? Is there a way to edit the save file to force this functionality to work, some code surgery I can do to fix this? Its getting very frustrating. This has got to be something I missed and not a bug; anyone have any clues or links?

Ugh. Zombie. Why not try and load it yourself and post the results?

OK so what you're saying is the part window menu will have an added "allow weld ON/OFF" toggle per part, but it will still be triggered vessel wide? Or will it be an individual pair basis for welds? Now I think I understand the intent and how it will work. And that is the answer to the parts issue - its simply a module, so that solves the "missing part" problem when someone uninstalls USI (although why would they? LOL ). And if it can be triggered in adjacent pairs ("weld ports" button on t he popup like the staging/activate buttons), then you have all the individual control as a bonus, solving the problems with welding the whole vessel. By focusing on part I missed the entire functionality argument, D'OH! Now that I "get it", the "weld per pair" seems to be the best approach. My improved thinking now: If you have multiple parts that need welding you may need to click a few times more to weld them individually, and code-wise I can see where it simplifies code, and better yet it eliminates the need to walk the entire vessel looking for weldable nodes. That's a lot safer and simpler, although admittedly not as Kerbal as hitting the whole ship and watching it shimmy its way into unity

This is exactly what I was going to ask after getting the answers above - if there was an action group assignment. I'll also add the activate/deactivate for the proper facing thrusters, deactivate the ones going the wrong way, activate the correct RCS, and flip the correct spotlight on and the other off. I assume that having the probe control reoriented by doing this also changes the torque direction for the flywheels in the probe control or capsule as well? And thanks for the heads up about the "forward" direction, I think I'll add a grabber on an arm that goes to the front just below COM on the landercan, the windows will give me a visual in that direction, so it adds another axis to work in and something other than ports to move things (grabber). Maybe have all the RCS active for that (use the RCS addon to balance the induced torque during design), then pivot it all the way "forward" and then switch to the "fwd" orientation. I wonder if anyone has done the work to put together the equivalent of the 2001 A Space Odyssey pods? Maybe something to do once my hospital gets back to "normal". It certainly looks a lot nice than my hacked up junky looking version. But I think mine is more Kerebal.

Basically, I have a 2 ended tug with a Lander Can in the middle, tanks, 2 sets of reaction controls (4 LFO in each for and aft) from one of Nertea's packs, 2 sets of engines (4x Twitch each for and aft), and a docking port at each end (portJr at one end, regular at the other) or alternatively I can stick a grabber on a docking port and put it on either end. In the VAB is easy to see as the "forward" direction (its "up"), and typically I have the full sized port at the "bottom" and the smaller at the "top" (no real reason, just habit of having a lot of ships that use the smaller ports for refueling, etc). Its pretty easy to change "direction" by flipping the part (W key) and then making it root. But is there a way to get this change of orientation outside of the VAB? When flying in VAB orientation, applied torque reacts predictably in a manner we are accustomed to. but if one is flying "backwards", the controls have to be mentally flipped so you don't end up inducing torque that produce rotational forces opposite to what you intended, and docking becomes a bit of a challenge as does pushing an off center load (thats why I have all those RCS units in each direction) What I want to do is fly and swap the "forward" orientation from one end to the one next to whatever I'm moving around as a tug, so that no matter which end (the PortJr or the Regular) I need to hook up, I can always "push" the load. In short, I want to be able to force "forward" to be at the end (longitudinally) of the spacecraft that I want it to be no matter which end and direction i am flying.

Actually I don't see the harm in having them as a separate part, that way it operates the same way it does now (except as a MM copy of the stock port), its not broken so why "fix" it? Is there a reason behind this I am unaware of? I and some others would prefer it the current way to keep things appearing and functioning as they always have, and also to avoid the delay and inevitable complexities that will happen if you have to modify each and every docking port in the game, and also consider them when welding. A common failure would be hitting weld when a supply ship is docked to the current station you are expanding via a Construction Port, because its docking port will disappear and now it becomes a permanent addition to the station - and eliminates the station's primary docking port by welding a ship in its place (and welding all the possible docked parts on that ship as well in a cascading error). I can imagine the error reports and complaints this would generate. I have a feeling individually determining which ports will weld and which do not will add complexity and require some rework of the welding functions with more intrusion into the stock parts and more complex (non-trivial) tree parse of the entire ship structure to see which port is welding and which is not... and by doing so, introduce possible sources for more bugs and possible functionality clash with any other mod that may use/alter docking port functionality. This "separate function for separate parts" method has the advantage of maintaining current stock + USI function, instead of forcing stock ports to behave like a welding port even when you do not want it to. Re-use Squad assets via something like the MM script I posted to eliminate the need to for Konstruction to maintain separate part .dds and .mu assets, and give the user individual Construction Ports the way it functions now as separate parts. I believe the better way is: Adding this functionality to separate parts as done originally, preserving stock as stock, and using a MM +PART script (or the equivalent) thereby reducing the possibility of conflict and error against stock parts expected behavior. Yes, I am asking you and @RoverDudeto reconsider that design decision. Maybe make an option for installing them as individual parts and leaving Stock untouched, versus an "all ports are a Construction Port" approach. This is possible by delivering 2 different .cfg files, and requiring one of the two to be used. CKAN has a pretty straightforward method for setting a dependency that can do that automatically, I think @HebaruSan can explain it better than I can. Thats my soapbox. I simply do not understand why you want to alter the stock parts instead of supplying a MM'd version for Construction. Its a better design. But please reconsider the blanket approach that eliminates pure stock docking ports. I think there is a better way and that the proposed design is defective in several scenarios.

Oh? I thought you were making a MM addition to leverage all the original functionality, artwork and config of the stock part, and then add yours as a clone + functionality. That way the Construction Ports show up different from the stock ports, something like this: +PART[dockingPort3]:Final { @name = KonstructionPort0 @title = #autoLOC_XXXXXXXX //#autoLOC_XXXXXXXX = Clamp-O-Tron Construction Port Jr. (need translation stuff) @description = #autoLOC_XXXXXXXX //#autoLOC_XXXXXXXX = Variants of the popular Clamp-O-Tron Docking Ports that can be compressed for construction, and can angle snap. @manufacturer = #autoLOC_XXXXXXXX //#autoLOC_XXXXXXXX = USI - Construction Division // inherits all the rest of the usual settings these from Clamp-O-Tron Docking Port Jr (dockingport3) // @category = Coupling // @entryCost = 7800 // @cost = 800 ... etc MODULE { name = ModuleWeldablePort portSnap = false } } Are you saying you're simply adding the module to the regular ports, so all stock ports become Konstruction ports? I don't think that is a good move, especially since there are some times where you do not want the ports to ever become welded, meaning you need stock ports, and therefore the Konstruction ones need to be differentiated. Or am I misunderstanding?

OK thanks, I though it might have something to do with the revamp and deprecation. This is not a "hurry up" request, I am just curious how the revamp is going (I hope it goes well), and if you have any horizon in mind for a release. A suggestion - make the new part ConstructionPort_0 vs ConstructionPort0, or even "KonstructionPort0", that way you can leave the old parts in game for a while. I'll watch here for new posts regarding test candidates. I intend to test these parts once you have a beta or RC. It seems like fairly trivial testing scenarios - either they dock+undock+"weld" (and disappear from the craft linking the two parts directly), or they do not. And most of that functionality would come from the stock ports excepting the weld function modules - MM part script should handle it well. Failures would seem to be pretty obvious, but I will also deeper inspect the .sfs file and manually walk the craft parts tree to make sure the proper modules have removed themselves and the linkage references and geometry are correct. Thanks for the response.

@RoverDude just a quick question (is that ever true? LOL) is there a specific reason that the Construction Port[0,1,2] configs have category = instead of category = Coupling If its a bug, I can put it on your bug list if you say to do so, but I am hesitant to clutter things up with a relatively minor issue that I can fix by editing the file myself. Or is it "working as designed"? I know you and @DoktorKrogg coming up with a revamp of the ConstructionPorts that will do away with the part files, which will make these simply MM configs (reuse the Squad base part & art) so in that revamp process maybe you could consider adding that to the config, just a thought.

I checked the save file, and the ship has the module in it. I started by checking the logs, and of course there were no real errors about MJ - mainly warnings about parts and resources that do not exist (for mods I do not have them installed apparently). About the only thing I found in the logs were repeated errors from DeepFreezeContinued and from Background Resources (the latter is an option support add for the former), so I removed them. Still got the missing MJ problem. I may add DeepFreeze back once I go past Duna because I use USI including USI-LS, and if I want to send Kerbals to Plock (I use OPM) , DF becomes nearly mandatory so my Kerbals on board don't die of boredom or starvation. There are a handful of mod authors whose stuff I trust implicitly due to experience, and @sarbian is one of them. Also, MJ is fairly stable and very widely used, so any defect it might have will show up quickly and loudly. There dont appear to be anyone other than me with this issue right now, so I have a feeling that it is something unique to my setup. My thought is that it is another app/mod causing the issue due to something like a memory leak or some other indirect issue. So I started deleting the most recently added mods that might interact peripherally with MJ (stuff that affects nav etc and the display of things), and after I took out Precise Maneuver everything started working again. I have a feeling it is some combination of mods that conflict and mask each other since I have so many (100+) mods running. Therefore I don't believe the solution is as simple as saying Precision Maneuver was the problem. That being said, I can live without it (and there are alternatives if I want them). If it happens again I'll try to figure out how to replicate it and make a full logs+ bug report. Anyway, problem resolved although not exactly solved.

Mechjeb has completely disappeared in my career save. Its not on the screen, its button is gone, not there in flight. However if I load a new (empty) build its not there but when I grab a command pod, it pops up. Same thing if I go to my Station, which has a MechJeb module. But on my currently flying ship, it doesnt show up, although I previously used MJ's Ascent Guidance to launch it up there. I do note that I dont have the option to enable or disable MJ on the Mk1-3, its as if it got ripped out or was never there. I checked the .sfs file and there is a MechJebCore on the command modle. I saw a couple of old messages from November 2018 when I searched this forum thread, and I deleted the .cfg as Sarbian suggested back then, but it didnt work at all. I tried uninstalling, starting the game (even starting a new game), then exiting, the reinstalling and trying again, and its still gone. Has anyone else had this problem, and if so, how did you fix it before I go and do all the bug reporting stuff and bother Sarbian for what looks to be a one-off oddity?

@DoktorKrogg Herr Doktor, that makes imminent sense. So as long as they have already been "welded" this should make no difference to any craft unless they are carrying an "unwelded" port, yes? Out of all of the "I didn't think of that" parts in all of the USI, those construction ports are my functional favorites. I love having them so I can build viable non-slinky weird-angle un-flyable off-centre large vehicles that would never survive a launch in joined fashion - the kind that never see an atmosphere any closer than low orbit. Better yet, when I get a new tech, shoot it into orbit and make it part of my main station (making sure I leave at least one open k-port for the next one). Even better when I can built the new parts in orbit, dock on a transfer stage [engine, tank, probe core, battery, port] and then fling them to another planet, and assemble them on site (hellooooo Laythe Station!)

And there's the most remarkable thing! All those mods and all the requests every time there's an update "when are you going to updat X? I want it now"... And you don't drink yet?!?! LOL! Thanks for what you do - I would not bother playing this game were it not for many of your mods (And Roverdude, Nertea, R-T-B, Poodmund, Sarbian, and several others) I'm sure others feel same the same way. edit: For you millennials and zoomers, thats a reference to Animal House, a movie which GenXers (and boomers) recommend you watch

Caveat: As long as it exists and the metadata is correct. And even then its not guaranteed to work because some ancient mods have "Any" as the maximum version they are compatible with. LGG's games are a notable exception, he keeps them functional, I dont know how he does it with over 200 at last count. Buy the man a beer. Or a good 12 year old single malt Irish Whiskey (or Scotch if that's his tipple)

Works well all the way up to current, anyone available to update the CKAN metadata version info? Looks Like someone already edited it - good all the way to 1.11.9 as of 20-02-2021 in CKAN Maybe just the front page and title of the thread needs an edit.

Thanks. I took a quick look, rebalancing these will not be trivial. I appreciate your efforts.

Any chance this gets moved out of Beta and onto CKAN, or else a release beta build in Github? The only version CKAN lists is 1.26 which is due to it marked as compatible with "any" - all later versions are compat with 1.3 series (ver 1.31 I think) and no further.

I wish I knew more about how to do the artsy stuff, but I realize I simply don't have that as a talent. Thanks for keeping these alive, they really do fill necessary niches (at least for my play style), especially for building space stations and long-haul tankers. Get Davon for resupply and a couple of those huge tanks and round end caps, bolt them together in orbit with a bit of USI magic and some station parts and thats my space depot. I find it fun to put the engines on a seperable stage, a docking port to connect and disconnect them, drop them off in orbit then dock and "weld" the circular tank ends on for aesthetics )and add structure or struts via KAS)... yep.

Bonus for GitHub - if the author build there, then guaranteed you have the latest and greatest.

Fair enough - the root of the suggestion was to merge whats worth it in this mod into the SpaceY mod (mainly the longer versions of the 2.5m and the caps), and basically abandon this one as superfluous, thereby reducing your workload by dropping this one completely after the semi-merge.

"resources emptied before launch, launch+immediate recovery"... I'm curious as to what could possibly cause that odd scenario. Why not simply revert to launch and recover from there?

@linuxgurugamer Ever considered to simply texture swap for different colors/textures for these tanks? There are still some very useful tank sizes, but several are duplicates of stock and possibly SpaceY. Drop the duplicates, make each single size of tank have multiple textures like the orange tanks, white tanks, Saturn V, etc (using stock swap?), then merge this with NecroBones SpaceY, I think you'd end up with fewer tanks in the parts list but more colors and functions (especially if firespitter and something like a cinfigureable container mod can change fuel types). It might be a bit of work to get that done, but it probably would be easier to maintain in the future with fewer individual tanks and only 1 mod instead of 2.

I dont have time at the moment, but it was probably 4 (+/- 1) years ago. Look for whichever updates were the ones where they updated Unity - I think that would be 1.3 and then1.8? Searching the old (original) EVE and Scatterer forum threads is where I think I remember reading it. It still happens (KSC under water) sometimes ans changing scene usually does it, or else an F5-F9 cycle usually fixes it. Advantage of being older = I know stuff happened before, disadvantage = I sometimes can't quickly recall exactly when LOL.