linuxgurugamer

@Morse suggestion: Create a blacklist.cfg which lists mods to be ignored Also, Ill look into Crew R&R. I think it used to be a custom settings page which i replaced with the stock settings page. If so, ill remove the button

New release, 0.1.11: Changed Base Mount landing leg's category to Ground Added standardized build scripts Added Jenkins config Following changes from github user @taniwha Add a disambiguator for parts with multiple ports Adjust the control node positions. They now match the positions of the docking ports when extended such that docking indicator mods display the correct distance to the target port. They have been moved out 2.72m from the center (the positions of the docking port transforms when the habitat is inflated). Test the correct var for null. Create a module for setting the control reference. This module makes it possible to use any transform of the part to which it is attached as the reference transform ("Control From Here"). If the part has a ModuleCommand module, then the command on the ModuleCommand module is disabled in order to work around a stock bug where ModuleCommand does not ensure the part's reference transform is correct before setting the vessel's reference transform. Fix the loading of the reference transform submodel. Only the first "model =" line in a MODEL node has effect. To load multiple models into a part, multiple MODEL nodes are required. This fixes the problem of "Control from Here" not having the desired effect when used on the docking ports. It does, however, break "Control From Here" for the command module because ModuleCommand does not reset the part's reference transform before setting the vessel's reference transform. Use the correct module for internal flags. Was added for KSP 1.2. If it doesn't work, then there's no such transform in the model (it works for EL's workshop). Rewrite the DeployableHabitat module. it now works with ModuleAnimationGroup via IAnimatedModule. It keeps track of the number of crew members in the part to determine whether the part should be retractable and correctly updates the PAW for both crew transfer and retract-ability Make geeforce public to fix a warning. Quick and dirty makefile to ease building. It's not properly setup for Tokamak, but it works well enough for building in Linux.

got it, thx

Delete the dll files it mentions

The problem is that the picture is almost black

Sounds like the game is making the fuel flow. All perfectly expected. Try turning off the crossflow

Ok. I'm going to wait to see if you get the problem fixed before committing it.

The api available here: https://kerbalspaceprogram.com/api/class_kerbal_f_s_m.html simply documents the methods, but there is no real explanation for this. I've searched the forums, but while it is referenced in many places, it is not explained. Apparently it was written back for 0.16 by @HarvesteR, the earliest mention of this was found in a Devnote Tuesday back in 2014 here: Besides the fact that I may be able to use this for new mods, I'm now trying to understand how it works in a reverse-engineering way on a mod I'm maintaining (NASA Countdown Clock). So, I'm going to attempt to write my own documentation here. I will incorporate any corrections or additions into the OP to try to keep a single point for reference. This will by necessity also include documentation on KFSMState and KFSMEvent. Some will be redundant since I will be copying portions of the public API ================= The state machine available for KSP is called KerbalFSM. Two classes which it needs are KFSMState and KFSMEvent. KerbalFSM is the main class for the state machine, essentially this is the controller KFSMState contains information related to a specific state of the machine, such as what events will activate the state KFSMEvent contains information related to a specific event. The flow of events appears to be: Create state machine (KerbalFSM) Create various states which will be added to the state machine For each state, create events which are added to the state Finally, add the states to the state machine. I've included some code in the spoiler which summarize the above points: Now it gets a bit hazy... The state machine needs to be started using the StartFSM method. There are two ways of calling: public void StartFSM(KFSMState initialState); public void StartFSM(string initialStateName); The first starts the machine by passing in the method of the initial state. The second starts the machine by passing in the name of the initial state. While the state machine defines methods for FixedUpdateFSM, LateUpdateFSM, and UpdateFSM, it doesn't call those itself, so you need to write the code for that, such as the following:

Does the control from here work with the USI tools?

Thx for the ping and the PR

That is expected behaviour

Oh, i just duplicated it. It is when you hit the Ctrl key (ie: throttle down) or Shift (ie: thorttle up), nothing to do with bumping. And, I think I found it New release, 2.0.3: Fixed bug where any and all vessels in Physics range would turn on their engines if the throttle keys were pressed. Most noticed on EVA

Done thanks. I wasn't aware of this review.

Very nice. some details would be nice, such as a log file, craft file, etc Edit: I just tested this, and didn't have a problem. This mod doesn't change the throttle, it just prevents it from going below a certain level.

New release, 2.0.2: Thanks to @eberkain for these: Add Support for RLA Added Puff Engine Missed Huff engine Added support for BDynamics Added HGR and QuizTech support Added USI Support

Some people don't use Blizzy. There are also a lot of moids which don't support blizzy

I added a link to the original thread, but here it is again:

Just curious, how do you deal with the fact that some mods change their icons depending on what they are doing?

I don't see that I replied, sorry. Yes, this is looking wonderful. And, after thinking about it, I probably won't need to rescale it for larger engines, there really wouldn't be any need for that.

Two messages above your post

It sounds like you installed some mods by hand. If not, then a complete list of your mods is needed, so I can find out which other mod has the same file names. It should also say the file name in the error message. CKAN is working fine, it is doing what it is supposed to do. I'm wondering if you installed the BDAnimation Modules for another mod by hand, and then CKAN is trying to overwrite it.

I never use RCS or Vernor for lifters, except when they are in space. I either use the thrust vectoring on the engine, or the fins which would be on it. And, since I play with Mandatory RCS, I don't use reaction wheels either. I've never gotten a true fire'n'forget rocket. It really isn't worth my time, although I applaud those people who can do it

Tired, and too much going on, I should have added this: The mod which was causing the problem was the Adjustable Mod Panel. It wasn't updated, and the original version was not compatible with the Toolbar Controller. The author did make it compatible with my help (ie: I added a method to the Toolbar Controller for him), so the current version works. Compounding this was the fact that the initial release of the AMP didn't have a .version file, so it wasn't obvious that it was out of date. Again, it was added after the first release.

The following files: compatible_ksp_versions.json GUIConfig.xml installed-default.ckan registry

I pointed this out before: The clamps should be in the stage AFTER the engines, not before. Not critical, but makes more sense, and needed if Gravity Turn is doing all the staging, including the initial engine firing You didn't select the clamps to release Think about it like this: the rocket needs to be able to launch without CountDown Clock and Gravity Turn, without a problem. The way you have it, the clamps would fire first, the rocket would fall and explode (if the fall was far enough). You also didn't put the launch clamps into the Countdown Clock, so no wonder they aren't firing. Once the Countdown Clock fires the engines, it will HAVE to fire the clamps, Gravity Turn will not fire the clamps if the engines are firing. So, watch my video again: https://www.dropbox.com/s/3tqr1hm6ftgngb9/TestLaunch.mp4?dl=0 and notice that I select the clamps as the final step in the countdown. Note that the numbers being shown in the Launch Sequence are off by 1 (ie: the top line showing "1 second" should really be saying "0 second")