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.