TBenz

I've been having some difficulty with the octo-girder octagonal docking connector myself. After playing with the config for a bit, and doing some extensive ingame testing, I've come to the conclusion that the issue stems from the positioning of the attachment nodes and the collider dimensions. With stock docking ports the docking nodes seem to be essentially flush with the surface of the collider, and so when the stock docking ports are properly centered and the colliders are physically touching, the docking nodes are aligned just about perfectly. The octagonal docking ports, on the other hand, have docking nodes that seem to be a fair distance away from the collider. This results in the parts not actually making physical contact when the docking nodes are aligned. That becomes a problem because, from what I can tell, the docking ports need to be moving very slowly relative to eachother for docking to occur. The magnetic docking attractor can get the docking ports moving quite quickly, and the game seems to rely on the physical collision of docking ports to slow them down to a proper docking speed. But that doesn't happen at the right position with the octogonal docking ports. So instead of being physically stopped by the collider and properly docking, the docking nodes speed past eachother and the colliders make contact with the nodes misaligned. Then the magnetic docking force ends up pulling the docking ports apart, as it's trying to bring the overshot nodes back into alignment, and the docking ports bounce apart. This happens back and forth in an oscillation that can last a significantly long time, if not forever, without any outside intervention. If that doesn't make any dang sense, I put together a diagram illustrating what I was observing: As well as some pictures illustrating the differences between docking node distance and collider distance ingame: I don't really know how to fix this alignment issue myself, unfortunately, I'm not familiar with node manipulation, and I certainly don't know how to fix the physical colliders for parts. I attempted to change the position of node_stack_top in the CFG file, and while I could tell that it was changing where the attachment node was in the editor, it didn't seem to have any effect on the distance at which the docking occurred. A quick fix solution I managed to put together is to decrease the attractive force between the docking ports. Adding: acquireForce = 0.05 to the ModuleDockingMode module made the attraction force small enough that the docking ports pull together, and drift apart more slowly, and are more likely to actually be going slow enough for docking to engage. It still doesn't guarantee that things will go right, it may be necessary to further decrease the relative velocity of the two docking ports using a well timed burst from the RCS. And it has the obvious downside of not providing nearly as powerful of a docking assistance magnet as most other docking ports do. A proper fix for this will either have to come from you, @Nertea, or someone else familiar enough with modifying docking nodes or part colliders. Wish I could be of more help here. Also, I hope that this rather lengthy post is actually helpful, and not just an annoying waste of time. Edit: Also, if it would be useful, I can open up an issue on the Near Future Construction github. I probably should have gone there first, but I'm still not fully used to using github and it didn't really occur to me that it would be the proper place for something like this until after I posted.

1. LOCK STEERING TO PROGRADE. 2. Stock Action Groups Just to verify, the goalPitch is being printed to the terminal every time? As far as I'm aware, locking steering to a variable should work with updates to the variable (but I only really started using kOS yesterday...) It may be a bit of a brain dead fix, but you could see if adding another "LOCK STEERING TO HEADING(90, goalPitch)." to the end of the main IF statement forces the steering to update properly.

I've been using both together with no issues. You might want to check to make sure that both have been installed properly. Otherwise, we'll need to know a little bit more if we want to help you. "Having trouble" isn't very specific, and doesn't give us any information on what the problem might be or how to fix it.

The hatches on the Pilgrim are not meant to function as docking ports. It might technically be possible to make the Pilgrim function as a rotating hub that you can build off of, now that we have the Breaking Grounds DLC, but it would probably be a royal pain to do. Moreover, if I had to guess, I would say that using the Pilgrim (or any of the other SSPX centrifuges) as a rotating hub for constructing larger rotating sections is completely outside the scope of their design and intended functionality. You would be better served creating your own rotating hub with the Breaking Grounds parts.

Downloaded it off SpaceDock and copied them into the GameData folder, replacing the old files. It wasn't CKAN, if that's what you are asking, but I also didn't do a clean wipe of the old install of KEI first... If that matters, I can test again tomorrow, but I figure you'll have it sorted one way or anther before I get to that.

Just updated to 1.2.9.6, KEI is still throwing an exception, although as far as I can tell it's harmless. Having the surface experiments unlocked didn't cause the exception though (so if there was one related to them, it seems you fixed it), I only started seeing it when I unlocked a scanning arm. The log file indicates that they are the problem, as the exception is always preceded with the line "[R&D]: No Experiment definition found with id ROCScience", and ROCScience is the id of ModuleScienceExperiment for all 3 of the scanning arms. Adding ROCScience to the ExcluldedExperiments.cfg file made the exception go away, although I don't know if that's how you want to fix that or if there's a better way. Here's my output log, if you'd like to look at it yourself. I hope google drive is acceptable for sharing it? https://drive.google.com/open?id=10dkWhAt0Mu8DFy7TW5gmziM31NuIeSPQ

Yeah, I've only ever seriously used it with a lab either. It's such a bulky part, and less functional than a lab, so if I'm ever using it I'm sure to already have a lab on my craft also. As to the interaction range, I didn't test it too thoroughly, and I've got some 60 mods installed, so something else could have done something strange to it. I'll give it a more rigorous test right now. Edit: Yeah, no joy. I can take the data out of it properly (so the interaction range is correct), but the reset is not available on EVA. I think it has to do with this line in the config: If that's the case, it seem to be intentionally not-reset-able without a lab. I guess you could argue that it would take a proper set of laboratory equipment to perform a full reset of the scientific studies in such a part.

You can clean it (you have to to re-use it) but today I was messing with it and couldn't actually get it to reset on EVA. The option wasn't appearing in the PAW (and my scientist was as close as I could get him without clipping into the part). It looks like you need to have at least some other part that can clean other science experiments. I think the Experiment Storage Unit part is capable of that (it seems to be when I play, but I've got such a heavily modded save that I don't know if that is stock or not...). Otherwise, you need one of the science labs.

I have to ask, is it intentional that the LF/Ox wedge tanks have an ever-so-slightly incorrect ratio of LF to Ox? They hold multiples of 11 LF to 14 Ox (8.8/11.2) when engines burn using 11.25 LF to 13.75 Ox (9/11). What you have now are cleaner, whole numbers, and the total volume does match the stock tank volume, but it will forever bother me that I have slightly too much oxidizer left over. This only affects the wedge tanks (in all sizes), the radial tank has the correct ratio. Apologies if this has already been covered elsewhere.

IMHO, the best counter to "moar parts" is "moar challenging mechanics". Life support, distant planet packs, that sort of stuff. That way, even though you have more tools for solving problems, you also have more problems you need to solve. It ups the complexity though, so you need to be willing to think harder and plan more carefully for your missions.

A quick peek in the GameData folder shows why. Looks like Squad "recently" changed the position of the Vernor and Linear RCS parts in the file structure. The CFG files for both are now located at "Squad/Parts/Utility/linearVernorRCS/" and the textures and models are at "Squad/Parts/Utility/linearVernorRCS/Assets/". I'm assuming that this is part of the blacklisting system, and the paths for the parts just need to be updated, wherever they are defined. If that's the case, then the only problem this should really cause is the unused models and textures still being loaded. I'm feeling.. brave, so I'll see about putting together a pull request to fix this. Looks to be trivially simple, but I've never actually done this before and I wouldn't want to underestimate my capacity to mess things up. Update: It appears I did everything with the pull request right, except for the tiny little issue of not actually testing anything before putting it up. I'll go check that this doesn't actually break anything ingame, but I think it's ok... Update II: Ok, tested, not throwing any warnings, looks like I knew what the heck I was doing. The pull request should be all good then.

@RizzoTheRat I'd recommend looking at the cfg file if you want the full story on part modules. A quick glance at the file and I notice this module here. It looks like ModuleAnimateGeneric is what manages the actual arming and disarming of the Grapple Node. I haven't actually used KOS (stumbled into this thread to check it out), but I'm assuming that the proper way to arm and disarm the AGU is through calling the respective arm (start) and disarm (end) events, or the toggle action.

I don't know how to break this to you, but they wouldn't need to "relocate" Dres very far, seeing as how it's already right between Duna and Jool anyway. Also, my gut feeling is telling me that the Outer Planets Mod probably doesn't want to do much changing to any of the inner planets. You may need to look elsewhere (or try your own hand at modding) if you want to change Duna's satellites.

The "action sets" sounds like it will fix that problem. I believe that means that you will be able to set up multiple different control setups with their own action groups through "action sets", and even disable the functionality of controls like Shift and Ctrl. And for anyone who hasn't read the Breaking Grounds KSP Loading... article yet, the action sets will be part of the base game and not the DLC, so everyone is going to be getting that. (Well, everyone but console players, sorry guys).

From what I have heard, unused attachment nodes contribute to drag. Try putting nosecones on the top and bottom attachment nodes inside the payload bay, to see if that helps for that. You could feasibly have the same problem on the heat shield, as it has two different attachment nodes (one with the shroud, one without). As far as the reaction wheel, that probably just comes down to it being larger than the other parts. You probably don't need that large a reaction wheel on such a small craft, you might be better served putting some smaller reaction wheels inside your craft.

We do know there is a sequencer: However, Squad is adding some new features to the action groups, and from what they have said this was primarily driven to better support the robotics: It sounds to me like the sequencer will be able to run one or more preset series of commands, but you will need to use the action and axis groups (or perhaps the PAW) if you want to exert manual control over which sequence(s) to run.

Action Groups Extended managed to pull it off, but the interface is a little messy (which is understandable, given the limited resources that mods have to work with). I'm fairly certain that Squad could do this and integrate it into the UI in a much cleaner way. Would be very nice to have, in my opinion. Edit: Correction. AGE works, but I've been using Action Group Manager, which has the interaction through the PAW that I'm not a fan of. However, it looks like there is a dedicated window for it to, so I guess I just need to look deeper into how to properly use it.

It looks like NF Aero is using KerbalActuators for the VTOL control. Parts from other mods should be able to use it through the WBIHoverController module, but I have no idea what all is required to properly add that module to a part. If you are familiar with modding KSP, or just feeling brave, you might try looking at the cfg files and creating your own MM patch. Otherwise, you might want to ask the owners of other mods if they would consider adding KerbalActuator support, or ask @Angel-125 if they can help you. There's no promises there though, these are people that likely have their own stuff going on too, and may not have the time to provide in depth help, depending on the situation.

Last this was asked, NF Aero had a dependency whose author did not want it being distributed on CKAN, which means that NF Aero can't be distributed on CKAN either. I'm assuming that hasn't changed.

Does that mean that you believe that KSP has been dying for the last 6 years? Because, if so, your definition of "dying" is completely worthless, as it says nothing about what will happen in the near future. Generally "dying" is used to state that something will be dead "soon". If someone claims something has been "dying" for 6 years straight, they are either wrong or not saying anything insightful, depending on how liberal you want to be with the interpretation of the definition.

I don't see any particular reason why it wouldn't. That seems like very basic functionality for squad to leave out. I could see it being the case in a mod that has to hack functionality together based on what Squad has provided, but an official DLC should have full and proper integration with all the features of the base game.

I'd say the problem is less about "why can't I open a locked door?" and more "why can't I unlock a locked door?". I learned what locking the bay doors does the hard way too. And yes, I do get that having the "lock/unlock" options accessible in flight would be redundant. I frankly had no idea what those options were there for, and ended up doing a bit of science to try and find out. FWIW, it might be useful to allow for a Kerbal on EVA to lock and unlock the payload doors in flight, depending mainly if it's as easy to do on your guys' end as I'm hoping it is.

I've got an unnecessary amount of mods installed, and I have to say, it gets prettying annoying having to dig through the 100 some parts in my science tab (don't even ask what my fuel tank section looks like). I welcome more specific tab organization. And honestly, I need to sit myself down and write some custom patches to better organize all these mod parts sometime.

Well then it's a good thing we don't have any of those here. This is the perfect suit for when you want to strap 3 SLS's together, launch them using an oversized stratolaunch replica that can reach a suborbital trajectory, and fly the whole thing out to Jool and back.

Mission editor? Different launch sites? Making History wasn't exactly "only added varied parts". That comes down to the modders. I doubt any of the existing mods will convert to the DLC systems. A full refactor is never the most fun thing to do, and if the stock system works differently than that turns into an outright ground up rework. And even if they do, I think it's a safe bet that someone will maintain a non-DLC fork. While mod support is a great thing, it's hardly Squad's job to make sure that all of their paid DLC is designed in such a way that no mods would ever want to be dependent on them. You're essentially asking Squad to make sure their DLC isn't good enough to encourage people to buy and use it.