steddyj

Hey guys, I use Custom Barn Kit to make a few changes to the KSC, including allowing a much higher contract limit. It's actually unlimited at L3, which I currently have the upgrade for. However I'm still artificially limited to just a few depending on the difficulty level. I'm pretty sure it's Contract Configurator which is adding this limit. I saw some posts back in 2016 for this feature to be configurable and/or disabled in settings, however I don't see any way to do that. The only thing I've found so far is that the limits were raised. I just don't want to have a limit on the number of open contracts I keep. Just not the way I want to play my game. Is there a way to change this that I haven't found, or is this a brick wall?

@Tyko (and everyone): @Tidal Stream is not expected to make any permanent fix for this or any other issues. He mentioned a few weeks ago that he is no longer playing KSP nor is he actively maintaining this mod. He might push a new release if someone submits a pull request, but he's either not chiming in here because either this isn't (as of yet) a permanent fix or he's no longer following the forum. All in all, this mod needs a new maintainer. @ozraven - I would venture that the new bug may be caused by the chunk of code you removed earlier to fix the issue with the tanks remaining in the menu. I frankly didn't look that closely at that part as I was focused more on the node issue, is that what you've added back (in whole or part) in this new patch? As to your earlier comment I do understand the tolerance, just not why it's looking at that coordinate at all. Why would a top/bottom node be +/-.5 on Y, and apparently ONLY on Y because the actions taken if true is to offset X and Z by the same? Also, why is it important to have all of those coordinates offset?

Yeah.... I looked at your diff file and... yes. This is a hack. I mean this with no disrespect, just a caution to anyone who may not be willing or able to look at the diff file to see what you did. For the layman, there's a seatbelt in the Procedural Parts car that was getting stuck. So Ozraven took it out. 100% guarantee of no problem. (100% guarantee is void if vehicle is involved in an accident.) In fairness this is exactly what he said he did, but I'm fond of colorful metaphors that people seem to find relatable. Also in fairness, this seatbelt may do nothing more than keep your big gulp firmly in the cupholder, I don't know. To get a bit more nerdy about the issue if (Mathf.Abs(Mathf.Abs(position.y) - 0.5f) < 1e-5f) So my C# is very rusty and I haven't done any Unity programming at all. If I'm reading this correctly : We're working on an attachment node (if I understand correctly what an Attachment object is) This returns true of the Absolute value of (The absolute value of ( attachment node's position on the y axis) - .5 ) is less than .00005). the only way for this to return true is if position.y = [+/-.49995-.50005]. This jives with the preceding comment, "This is easy, just get the UV and location correctly and force an update. as the position might be after some rotation and translation, it might not be exactly +/- 0.5" So the math is just to give some wiggle room, we're looking to see if the y offset of the attachment node is pretty close to .5 or -.5. I just don't understand why this position needs to be close to +/-.5. It looks like if the condition is true it positions the node to the top or bottom, otherwise it's attached to the side. I *think* the intention here is to sort between a node on the top/bottom versus a node on the side of a part. However, I don't know of any procedural parts that have side nodes, nor do I understand why this breaks after 1.7.0. Were nodes changed in 1.7.1? Why is this looking at the y offset of the node, and then adjusting the X and Z offsets by .5? When and why is AddAttachmentNormalized called?

Rightclick somewhere out of the display to close the menu, then open it again. You should find just the last tank set on it. This is not an issue with PP as far as I can tell, it's a graphical glitch with the tank switch module. It updates the menu with the new tank set but doesn't clear off the old one.

Honestly the bug is so prolific that it would take longer to create and upload a craft file than to just type out the replication steps. Launch game in 1.7.1+. Open Sandbox, VAB. Select HECS as root probe. Add procedural liquid tank. Adjust length (diam does not always cause the issue). Exit VAB, save changes. Open VAB. Lift procedural tank off probe core, note the misposition of nodes, and how it will only seem to surface attach now. There may or may not be a visible gap when the craft reloads. Sometimes it seems the node is placed outside of the part's mesh, but most often (at least when following the above) it was shooting the nodes out to the edge of the top/bottom faces. If you have Node Helper installed on your game (https://github.com/linuxgurugamer/NodeHelper) you can look at the nodes and see the reason that you can't connect to them is that they've rotated their orientation as well as shifting to the edge of the part. They point towards the center of the face, so it surface attaches before you can connect to another node.

Yup, this appears to work when resizing. The misplaced node issue on reload is still there in 1.7.2, but again that existed before you did anything. I did notice that it did change the behavior of that issue slightly, however. Previously when you reloaded the craft and the nodes were shifted, both went to the same side of the part. With your latest update they go to opposite ends. Likely nothing, but curious. I should probably also mention that I hadn't purposely replicated the re-root issue that you were attempting to fix. However it does occur to me that this is exactly the cause of the crash I had a few days ago which led me to a complete redesign of some small comms probes I was building. That said I did just test re-rooting to a part surface attached to a procedural tank and can confirm that works correctly as well.

My apologies if this has been mentioned before, but I couldn't find any reference by searching any way I could find to reference this with the existing forum tools. Am I going crazy or is the % key missing from the keycodes list? This key may be referred to as percent, mod, modulus, grapes, or sometimes double-oh-seven, and yes I'm trying to index some search terms here, especially since you cannot search for '%' Oh, someone might refer to it as shift-5 or shift-five. So yeah, am I blind or crazy? I mean, AltGr is there. Raise your hand if you have AltGr on your keyboard. I'm blind, right? Someones going to post a screenshot with the very obvious key highlighted, and I'm gonna feel pretty dumb.

If you're testing in 1.6.1, that may be why you don't see either issue. The Node issue appears in 1.7.1 and 1.7.2, but rarely if ever in 1.7.0 and earlier. I've not personally tested earlier versions, but I've heard mentions that it has come up in previous versions, but 1.7.1 broke it entirely. I listed replication steps in this post above. The issue I reported to you was also tested in 1.7.2, I did not try any earlier versions so it may not appear in 1.6.1. To reiterate, what I'm seeing is if you attach a procedural part - a liquid tank, for instance - to any other part. Then change the dimensions of that part. The part stays physically in the same position, its center of mass relative to its parent part. If you reduce the length, you will see a gap form between it and its parent. If you increase the length, it swallows the parent. This can be fixed if you detach the part and reattach, however the normal and expected behavior is that the part updates and moves its attached points as necessary.

@whale_2 I checked to see if your update would fix the node issue that myself and several others reported. Unfortunately it does not. In my testing I also found an additional bug that your version seems to introduce. If you modify the dimensions of a part, the position of the part remains the same relative to its center point. The nodes do update, if you detach and reattach the part it snaps to the right position. But if you'll need to do this any time you change any of the values. Any chance you could take a poke at this, and perhaps the other node issue? @russ0133 that looks like the same issue the rest of us are experiencing. If you detach that floating tank you will likely find the attachment node is on the edge of the tank rather than in the center, and that it wont connect to anything. The node is actually pointed in the wrong direction. Roll back to 1.7.0 or stop using procedural parts until a fix is posted.

Gotcha. I thought that might be the case, which is why I tagged you in my comment. Thanks for taking the time to reply.

Hey @Tidal Stream have you looked at all into the issue of attach nodes moving on reload? I've seen several people mention it over the last couple of pages but I haven't seen any response to it yet. It's been itching my brain for a while and didn't seem to be bothering me too much for a bit, but now it seems I can hardly make any procedural part without it getting wrecked the next time it loads in the editor. Reverting back to 1.7.0 does seem to calm it a bit, but 1.7.2 is unusable in the current state. I think I was running 1.7.1 with mixed results for a while. I picked at this a little tonight to try and see if recompiling the dll against the assemblies in 1.7.2 would help, but it didn't seem to make a difference at all. I can reliably replicate the issue by loading up a sandbox game, selecting a Hecs probe core as my root part, slapping a proc liquid tank on top, and adjusting the length of the tank. Save, leave the VAB, re-enter VAB, and lift the proc tank off. The nodes will either be on the rim or on the side, and inspecting the nodes with Node Helper shows the orientation is wonky. While I mention Node Helper, that is by no means a required mod to see the error here. I'm testing right now in a clean install with only Proc Parts installed, and still get the issue. This is also by no means the ONLY way to replicate it, but I've been able to replicate it on every attempt. Changing the diameter by itself does not always trigger the issue, but moving the length up or down does every time.

@MOARdV I actually looked into the IACBM, as I used to use Sumghai's station parts extensively. I poked around git and found his old repository and downloaded it and put it in a test install. It did work well enough to load into the VAB in sandbox, although I didn't test enough to see if it would fly without summoning the kraken. I don't believe it's the one that I'm looking for, though. The model was significantly thicker than what I'm thinking of. You did remind me of the original Fustek CBM. After a little googling I think you're right, that's the one. It had gendered models but they were universally compatible. I think I just used one or the other as they worked and meshed well enough for my needs at the time. I know Fusty handed off his stuff to Sumghai, I can't recall if he ever released the original CBM or if someone had updated it, or if it just still worked well at the time. I don't suppose @sumghai is still around these days...

I hope this is the right place to post this. I've been fiddling with a new game after several years away. I think I last played around 1.1/1.2, but first played long before that. I've been starting to piece together some of the mods I used to use, some new ones, and trying to come up with a strategy for a long-term career playthrough. I started playing when sandbox was all there was, so I have a habit of setting a goal for what I want an install to be, and trying to mod around to get the ruleset I want to play in, so I tend to be pretty heavily modded. Anyway There was a mod I used to use that provided an alternate docking port model that I much preferred. It was significantly lower-profile than stock, and most important it wasn't nearly as wobbly. I honestly don't know if the wobble problem is still around as I haven't put a docking port on anything in my fiddling just yet, but I know that the model is still the same. I can't for the life of me figure out what mod pack included this docking port. I thought it was KW, but it's not. I remember it was white with some grey and red details on it. It was low profile, about the same thickness as the KW stack separators (part of why I thought it was part of the KW set) and if I recall correctly when docked the mating portion of each port clipped into each other. I think early versions even had a male/female version which was eventually canned for the universal format like the stock adapters. The face of the port model showed a square hatch with rounded corners when nothing was docked to it. and I think it may have been lit. If anyone knows what I'm talking about and can point me towards my long lost mod, or something like it, I would be very grateful. Thanks!

It sounds like this should work as is. I'll do a little testing when I get a chance, likely tomorrow night, and let you both know how it shakes out. Thank you both.

Yeah, I had noticed that. Unfortunately that locks me into unmodifiable tanks. I tend to like to reduce part counts by using a larger than needed tank and modifying it (usually with Modular Fuel Tanks) with additional resources as needed, sort of creating service modules. That is a better question for @FreeThinker but as of what I can see now on CKAN the full IFS mod is required. Whether or not that could be pared down to just the core I can't say.

Hi @allista I have a quick question about compatibility with this mod. I've been away from KSP for a while and last played shortly after the first version of this mod came out. I tried it briefly but wanted to get into KSPI and this had a conflict with InterstellarFuelSwitch. Fast forward some (many) years later and I'm starting to play KSP again. I really want to use KSPI-E and I'm leaning towards using your Global Construction mod over EPL. That said, ckan still lists this mod as conflicting with IntersetllarFuelSwitch, so I had assumed that it was still a no go for me. But I just noticed you list KSPI-E on your compatible mods list in the first post here. In short, I'm confused. I'm looking at ckan now and InterstellarFuelSwitch is still listed as a conflict, but that is also a requirement for KSPI-E. Is this an error in the ckan metadata, or is there something else I'm missing here?

@Jim DiGriz Ah, gotcha. I'm aware of RP-0 and RSS but don't use them, so I wasn't aware that they unlocked MJ from the start. The procedural avionics stuff seems interesting. I can confirm that build 886 lets me cheat to my heart's content. Thanks!

/facepalm I just understood why this config file exists, and why it broke the old MechJebForEverything file I had been using since forever. Although now that I understand the conditions you're trying to create, shouldn't the second block NOT include !MechJebUseCommandPod if you want it to trigger if both are flagged? For that matter, shouldn't the only NEEDS there be MechJebUnlocked? As written it will explicitly ban anyone from using this method to unlock MechJeb in an RSS/RP-0 environment, which is fair enough, but since this already requires some minor acrobatics to accomplish and won't provide any feedback as to why it doesn't work in those use cases, couldn't it be assumed that someone who wants to use this option understands that it bypasses the spirit of RP-0? This is mostly my opinion as an admitted cheater. But also, I spend a lot of my life working out ways to not have users contacting me for support.

@Jim DiGriz The first block has the following conditional: @PART[*]:HAS[@MODULE[ModuleCommand],!MODULE[KerbalEVA]]:NEEDS[!MechJebUseCommandPod,!RP-0,!RealismOverhaul,!MechJebUnlocked] It won't run if MechJebUnlocked is detected, so that's preventing your second block from running. Well, it runs, but MechJeb is never added to the rest of the parts with ModuleCommand. It works just fine for MJ parts or if you have something else adding MJ to command pods. You can remove the reference to MechJebUnlocked and it should work as you intend, or make the change I propose. Either solution should work, although I've only tested the solution I proposed.

I must admit, I'm one of those sad sad cheaters. I was having the same problem getting my cheater MM config to work, and found that MechJebNoCommandPod.cfg was interfering with my own, but I was lazy and just changed it. Yesterday I went and ran a CKAN update and loaded the game (I'm still stabilizing a modlist for a new game after a while away) and found that my hack stopped working. Of course, I had barely noticed that it was a new MJ dev build that got updated. I opened up the file and found the new settings... curious, I didn't think those were there before. That brought me here and to your post. Cool idea, I made the changes but didn't bother reloading my game at the time and just beat on the controls like a cavekerbal. This morning I went to try and do one more science run before being productive, and as I was designing my new craft I found all of my MJ functionality was missing. And that leads me to this rambling post. You made an oops in the new config. The cheater block opens with this conditional: @PART[*]:HAS[@MODULE[MechJebCore],!MODULE[KerbalEVA]]:NEEDS[!RP-0,!RealismOverhaul,MechJebUnlocked] it should rather have this conditional, to similarly apply add MechJebCore to all command pods, rather than just apply cheater settings to all MechJebCore modules @PART[*]:HAS[@MODULE[ModuleCommand],!MODULE[KerbalEVA]]:NEEDS[!RP-0,!RealismOverhaul,MechJebUnlocked] Thank you for indulging my rambling, and for making this handy hack.

Eh, this started itching in my brain again this afternoon. I posted in the Procedural Parts thread to see if my assumption that costMultiplier cannot be defined outside of the TankContentSwitcher module is correct. If that holds true, then I see two options for providing some level of balance Remove the MFT config for procedural parts in SETI, and meaning the cost for having procedural size is a bit less freedom in the contents (but this provides less support for other fuel mods, unless otherwise also defined in config for additional tank content modes) Allow the use of MFT for procedural parts, but accept that they will cost more than other parts in the mod

Hey guys, I was hoping someone here might be able to point me in the right direction of a solution (or confirm my suspicion that this cannot currently be resolved) of an issue I've been working on regarding Procedural Parts, Modular Fuel Tanks, and the SETI Rebalance mod. I first noticed that the three didn't play nice together when I was creating negative weight liquid fuel tanks, which is cool, but at the time I was not trying to create a TARDIS. I was able to trace this down to the fact that SETI makes some MM config changes to Procedural Parts, and this was not properly removing the TankContentSwitcher module from the parts when MFT was installed, causing a conflict resulting in bigger-on-the-inside-edness. Again cool, if you're a time lord. The easy fix is to modify the SETI config to either ignore the included new config or remove TankContentSwitcher if MFT is installed, which I started to work on but either would negate what the SETI config is doing, which is really just to modify the cost to be in line with the changes the mod makes across the core of the game. Which leads me to my question: Is it possible to define the costMultiplier variable outside of the TankContentSwitcher module? Obviously this cost equation is done outside of the module itself, but I've been unable to find anywhere else that references it. I'm assuming the calculation occurs within a function in the dll, and it defaults to 1 if not passed an argument to otherwise define it, but I was hoping there may be some other way to set this. Otherwise, it appears that the three mods are not fully compatible in combination, or for that matter any other use case that involves modifying the costMultiplier as well as providing alternate options for defining tank contents.

Well, honestly I stopped looking into this because I decided to try out Configurable Containers instead, and it doesn't cause the same issues, although I think that's just by chance. That said, I had hit a brick wall before deciding to switch mods. The balance changes you are trying to make are to reduce the cost structure of Procedural Parts, but from what I can tell that variable can only be defined within the TankContentSwitcher module, although the cost calculation obviously happens elsewhere. If you're using either Modular Fuel Tanks or Configurable Containers, the trade off is that you're going to have to pay full price for your procedural tanks. I resigned myself to this issue, so I stopped digging into it further in order to get back to playing and it seems a little unclear who is currently maintaining Procedural Parts, other than just getting it pushed to new versions.

So I've figured out the problem, but I'll probably work on the actual solution tomorrow. Short version, the TankContentSwitcher component of Procedural Parts does not directly play nice with ModuleFuelTanks. The MFT config included with Procedural parts actually disables the TankContentSwitcher module, then adds ModuleFuelTanks in to replace it. The SETI Rebalance config then adds the TankContentSwitcher module back in. So, at face value the fix is to remove the rebalance config.... except that it seems to make some cost adjustments. I'm pretty sure that ModuleManager has syntax to allow you to only make changes if a particular mod is or isn't installed. Actually, I know it can account for requiring a mod, I'm not sure if it can say "only do this if this mod ISN'T installed" (but I think that it does.) I'm going to dig through the documentation later and see if I can't re-adjust the procedural parts rebalance config to make sure this won't be an issue for anyone else, as well as making an MFT-compatible rebalance config that will still provide the same benefits.

I'm running into a bit of an issue and I'm hoping someone might be able to help me solve it. I started a new playthrough for 1.2 using a variety of mods, the most important for this conversation being SETI, Modular Fuel Tanks and Procedural parts. I've also used the Janitors Closet mod to prune out all parts that can be replaced by a procedural to keep my part counts down. I just unlocked some LFO tanks and engines, which means my only tank option is the procedural tank, and I was very surprised when I found my simple rocket hat a 19 TWR. I was more surprised when that TWR went *UP* when I added another tank. Looking at the tank stats, I found that there are two weight displays on the tank, and one of them shows a negative value. I've been picking this apart for the past several hours. Removing MFT solves the issue, so it's some interaction with that mod. I've been reviewing both the stock PP configs and the MFT, and everything looks good there. So I searched my install for any other configs that alter the proceduralTankLiquid part, which led me to the configs in SETI-Rebalance. Removing/renaming that config file also fixes the issue, and I notice that the tank actually shows as a very different part with and without this config. I want to keep as much of the SETI functionality in place for this playthrough, and the config seems to add some config I like to the tank, so I don't want to just leave it out. I can't see anything obviously wrong with the config file, though. I've installed SETI via CKAN, if anyone was wondering. EDIT: I noticed that there were also two type selectors, as you can see in the image above. I went back and pruned out the MFT config file in the procedural parts directory, and this has the tank working properly. The two must not be playing nice together, although I'm still not sure why. There were no other issues with any of the other procedural parts. Second EDIT: Belay that, now I can select a tank type as usual, but not use MFT. Seems I still need to figure out a MFT-friendly config for this tank if I want it to work 'right'