linuxgurugamer

Let me know when you submit it

Question: will the reskinning be done for the new parts which are made as KSP moves forward? Also, how does this affect the memory usage of the game?

Apparently that could solve it, but I came across a couple of other situations, unrelated to MechJeb, which could have had the same issue. So now the code is checking all engines 4x a minute to see if there is fuel flow, if there is and the engine gimbaling wasn't manually disabled, it enables the gimbaling

Pinging @cineboxandrew @Beale @riocrokite @passinglurker @blowfish @DMagic (forgot to ping everyone else :-) )

Absolutely amazing. Would you like me to take care of the CKAN stuff for you? Edit: Pinging @Nertea

Yes, it does fix the issue. However, there are other things which cropped up, so for now I'll have to leave it the way I updated it last night. Are you now working on this instead of @sarbian?

New release, 1.3.1 Added code to detect changes in vessel and update accordingly Added code to detect vessel changes Removed check for mainThrottle == 0 (needed to allow MechJeb to work properly) Added events and actions to allow all gimbals to be enabled, disabled, and reset Changed check from 5x a second to 4x a second Changed the OnStart to Start in ModuleEngineGimbal @rebel-1 @Jacke @dlrk This update should fix your problems

@sarbian Have a bit of a mod compatibility problem with Mechjeb. I released a mod, the AECS Motion Suppressor, which, among other things, disables engine gimbaling when the engine(s) aren't running. A problem has cropped up in which if the engines are disabled using: gimbalModule.gimbalLock = true; then Mechjeb won't be able to use the gimbaling, even though as soon as the engines are started, gimbaling is enabled. I'm guessing that this is probably caused by Mechjeb setting it's internal variables at the start of a maneuver, and not seeing the change. Is this true, and if so, is there something I can to to tell Mechjeb that gimbaling is active again? I've traced this to the fact that FlightInputHandler.state.mainThrottle == 0 even when the engines are firing with Mechjeb. I am looking at that to reduce the overhead of checking each engine every time. Is there a way I can tell if MechJeb is executing a maneuver? If so, then I can at least only check all the engines if Mechjeb is active

Ok, I'm trying to understand exactly what you are saying, please tell me if I have it correct (I assume english isn't your first language): When the mod is installed, all gimbaling (ie: thrust vectoring) is disabled when MechJeb is also installed, so that Mechjeb is unable to hold a maneuver node because of the lack of gimbaling. So, I have some questions: Was this during a launch? Before the maneuver, please confirm the engines were turned off And, do the following test, please: Do a quicksave, then activate the engines manually and see if they gimbal when you use manual control

Not sure I understand you. Are you saying that it doesn't work with Mechjeb in space?

Interesting, but I may end up having the science facility mounted on the outside of the shuttle, given that the shuttle is only 2.5m in size

Ok. I'm just exploring possibilities. My problem is that the 2.5m shuttle is so much lighter than the 3.75m shuttle, that the Vector engines throw the whole weight & balance out of kilter. So how about this: I could put the vectors on the external tank, and the normal engines on the shuttle I'm not giving up on having the engines on the shuttle, just exploring the different possibilities before I start doing the design work.

You could have a volume setting for the map view

You could go into the part config and change the max science data, if you want

Up until now I've been launching this shuttle on top of the rocket, but I spent last night while streaming learning how to build and launch it on the side of the stack with an external tank. I'm not too worried about the Mun missions, I've essentially already done them in my career game on Iota (GPP planet pack). But I want to do it better than I did before, so it may be a few weeks while I design the research base and update the shuttle to use much heavier engines at the rear (needed for the launch) Now, this may seem a bit nuts, but am I allowed to drop off the engines once I'm done with them? I'm referring to the engines at the rear of the shuttle

First, I don't mind a fork, but please change the name so people don't get confused I think your changes are great, and actually needed, this isn't a popular mod (based on the avc counts). I don't think it would be a problem to do the PR, but it's up to you. Just let me know how you proceed. Either way, thank you for doing this

The patch was to make the parts compatible with the CTT, so whatever it needs to do that. And yes, I will most likely be doing this sometime in the near future.

New release, 3.7.1.3 Fixed agent in the Contract Group

Hi, I found a problem in the Bases & Stations, the agent was wrong, which may have been causing your issues. I'm pushing a new release, will be 3.7.1.3, please try it when available Release is now available on Github, CKAN will probably take a few hours to get updated

I've adopted this mod, new thread is here: Please move discussion there

A mod written by @KwirkyJ to have RTGs perform more realistically . Original thread is here: https://forum.kerbalspaceprogram.com/index.php?/topic/104415-113-jd A smarter, shinier, better radioisotope module, now with more heat auxiliary title: Quarter Life: Halfway to Dres-truction  An improvement on stock RTG behavior with its eternal power supply. Implements a configurable, robust mechanism for Radioisotope decay and power generation. Parts with ModuleDiminishingRTG will be able to configure their isotope fuel from within the VAB, a single input being reflected across all symmetry companions. Parts should behave consistently between vessel docking/undocking. Decay operates in background (all unfocused vessels). Can be added to any part without interference... probably. Inspired by "Realistic RTGs" plugin by Gribbleschnibit8 http://forum.kerbalspaceprogram.com/threads/96030/ ModuleManager redistributed under CC SA license. Availability Download: https://spacedock.info/mod/2096/JDiminishingRTG Source code: https://github.com/linuxgurugamer/JDiminishingRTG/ License: GPLv3 Dependency Module Manager In the VAB... Extenders/modders:  Look at provided configs for documentation. Plugin and source available under LGPLv3 : You are free to run, modify, recompile, and redistribute with attribution and same license. Assets (cfg files) made available under CC BY NC 4.0 : You may share and modify-and-share so long as credit is given and is not sold. All RTGFUELCONFIG nodes ABSOLUTELY MUST have a resource definition of the same name.  Adding/removing RTGFUELCONFIG nodes may have a deleterious effect to .craft files and persistent saves -- modify with caution. If more than one RTGFUELCONFIG has the same name, only one will be retained and order is undefined.

That's ok. How about a save file, which has the problem evident? Sooner the better, I'd like to work on this on stream right NOW!!!

If possible, can you identify which contract the vessel you are recovering was doing? Basically, this means that there is a problem in one or more contract packs. I'm going to review the Bases & Stations this evening, if I have time I'll look at some of the others as well

make sure you have the absolute latest version of the Toolbar Controller installed. If it is working via the PAW, then it's loaded and not related to anything with the Toolbar controller. Click the yellow wrench to see if the mod's button is hidden