kcs123

Well, no need to repeat same thing again to that thread, when you got time, willpower and access to unity files you can investigate this. It is either something with B9PartSwitch plugin or something with meshes that require SDK, unity or whatever is used in creation of models. I understand that you don't have willpower to investigate it further, it is not big deal. Anyhow, I have found some other inconveniences. It include several fuselages. Some of them weight too much and can hold too much volume compared to stock parts. For example, Mk2b 2m fuselage (structural) is heavier than short Mk2 stock liquid fuel tank when it is empty. Furthermore, stock part can hold 400 units of fuel while Mk2b of same size can hold 800 units. I have no objections for different dry mass, B9 can be heavier, but have higher crash resistance or temperature tolerance, so it can be pros/cons when someone use B9 part over stock part of same type. I don't have nothing against to have different fuel amount either, but double size difference for the same volume does not seems right. Similar thing is with 0.5m Mk1 part when you compare it to stock FS100 tank. There is probably some other similar issues, I didn't noted all of them. I don't know how much time I will have for KSP to track down everything, I just bringed it to attention, so other players may also pay attention for it and report if there is such things with other parts. Neither of those things are gamebreaking or urgent to fix, I just reported it to be aware of it.

Yes, that one. I didn't noticed this in previous album. That was one of biggest issue to learn when I was started to use SCANsat mod. Glad to see that is included in KSPedia.

Maybe to add smal bit of info how small change in dV can influence coverage (previous orbit/ new orbit). In other words, how player can adjust orbit to scan planet faster, to map planet in least amount of orbit as possible. Not a big deal for me, but can be valuable info for new players. Other than that, KSPedia entry is nice touch to already great mod.

Yep, figured out root of problem. As soon as you touch slider to limit deployment, stock cargo bay change it's state from Closed to Open, while Mk1 does not. Mesh need some trigger or event to be properly configured somewhere. Can't help you more than that, I'm not mesh expert, don't know where you need to put this missing piece of code. Probably just few lines of code and after that config files should work properly. I hope that this helps to narrow down problem and possible to solve it when you got time for this. Thanks for great work on maintenance of this mod and AJE too.

So, only messing with part config file should be sufficient (in theory) to work ? I assume those two modules are responsible for that. This is from squad config file for Mk2 large cargo bay MODULE { name = ModuleAnimateGeneric animationName = Mk2BayL startEventGUIName = Close endEventGUIName = Open actionGUIName = Toggle Bay Doors allowDeployLimit = true revClampDirection = false revClampSpeed = true revClampPercent = true } MODULE { name = ModuleCargoBay DeployModuleIndex = 1 closedPosition = 1 lookupRadius = 1.8 nodeOuterForeID = top nodeOuterAftID = bottom nodeInnerForeID = top2 nodeInnerAftID = bottom2 } I can only speculate for now, but from short look at config file, problem might be in proper animation name. It should match with animation name configured in mesh file somewhere. Not that I'm expert in mesh modeling field, but I will try to mess with it.

Probably not possible, but it does not hurt to ask. One new feature from stock game - how much in percentage will cargo bay doors open. I assume it is not possible in B9 mod due to differnt animation plugin used to open/close cargo bay doors, but can that be added some day in future when you take a bit rest from moding and actualy enjoy playing game for a while? Those new Mk1 cargo bays are nice for some small stuff. Much more usefull than stock game Mk1 service bays.

Just added few WIP craft files for KSP 1.1.2. Link for downlaod is in OP. Here is some screenshots from test flights.

Missing those landing gear too. I wasn't being able to play KSP for a long time. Decent number of my favorite mods are still not updated for 1.1.2. I was inspired by the look of Gripen. I didn't created exact replica, but interesting thing that I noticed on Gripen is lack of tail elevators. It uses elevators on wings and canards in fronts. Engine and vertical tail surface is much further back. I tried something similar and it turned out pretty well. Please note that it is rough example because I didn't have much time to fine tune everything. Don't know when I will be able to grab some free time for KSP, so I deceided to upload craft files regardless, in this unfinished state. There was demand for examples of flap usage and stable but maneuverable crafts, so there it is my attempt to create such. Here are some screenshots from test flights. Video might be more interesting, but I can't create one properly. You can download craft files and try for yourself, though. Mod required is B9 Aerospace, B9 PW, FAR , KJR and dependencies. Everything else is stock.

I didn't checked RT for a while, didn't even notice that it writes something in save folder. Anyway, this config file should not be in conflict with anything. Beacuse MM looks only in gamedata folder and it will ignore that config file in savegame folder. Also if, RT is installed with CKAN, it will be properly uninstalled by CKAN when you update RT or deceide not to use it anymore. You will probably still have config in savegame folder that contains info about your personal settings for RT but not MM patch configs.

I use MechJeb in combination with MechJeb embeded that add MJ module in every probe core/cockpit. That gives same info as KE regarding TWR. Any TWR above 1 for chosen celestial body is capabale to lift off your craft even without atmosphere and wings. It is up to you if you want to use other MJ features or not. For me, information about craft in editor and flight is enough, autopilot didn't work well when it is combined with FAR, so, I rarely use it. Sometimes in space if craft is not balanced, MJ tend to use full throtle and spin off craft instead to execute maneuver node properly, etc. But for info purposes is just fine, like KE.

KAX is tagged as 1.1.2 compatible too, require latest firespitter plugin for KSP 1.1.2. and comes without landing gears. For known reasons.

Like Vrana said, you don't until you install some mod and try it in game. In other games,for example, Stalker, X3 serial, Silent Hunter, Fallout, etc. if you want to modify game to personal liking, you must overwrite all files that game engine read for ingame asset properties. If you want to merge two differnt mod that change the same object in game, you have to combine changes made by bothj mods by yourself in some editor (either something from SDK or just simple notepad). That way you have actualy made some new mod that combines previous two. That is not something for ordinary player, only for some that have experience with moding and bit of coding. Because of MM, you don't have to do such thing in KSP. MM does not alter original files, from either, stock or modified game. Instead of that, MM search for possible config files and do altering of some part properties as it is specified in that config file. Those changes exist only in memory while you run game, it does not change original files. That is why it is possible to just simply delete mod folder and all changes on parts that comes from that mod no longer exist when you next time run game. This is also reason why literally hundreds of mods that alter same parts can work together in KSP. Without MM such thing will consume too much time to be feasible by merging each mod "by hand". Of course, not all MM configs on each mod is "friendly" with some other mod. There always be situations when some mod simply does not work properly with other mod. Such things were reported from users to mod authors, if possible that is solved in future versions of mod. If not, at least you community will know what mod conflict with each other and you should avoid such combo. Due to way how MM work(it think that some mod is installed only if folder for that mod exist in "gamedata" folder) it is possible to create faulty installs. CKAN, for example don't delete whole folder if some other file is created there after mod install. You may think that you have uninstalled some mod, but if main mod folder is still present, MM can consider as whole mod is installed and do some patches/changes to parts, while it should not do any changes at all. And last piece of advice - if you are afraid to loose gameplay progress, backup your save game files before you do any changes with mods - either, install or uninstall. If you are steam user, you can sonsider to copy whole KSP folder elsewhere and mod that copy, leaving original game intact.

FAR put @dragCoeff = 0 and @deflectionLiftCoeff = 0 for a reason - those are meaningless when you have FAR installed. FAR use voxelization feature and calculate lift and drag on all parts at the same time. Very rude simplification of this is that FAR use all parts from craft and trough voxelization "change" it to looks like only one part. Then lift and drag is calculated on craft as a whole, not part by part as stock physic does. Your custom MM config only breaks both - stock physics and FAR - neither will work properly. I didn't get deep enough with kOS, but based on experience with both, it worked much better for me with custom PID (search for PID library trough kOS documentation) and use raw pilot input control instaed of lock steering command. I wanted to create pilot assistance instead of full autopilot with kOS in previous version of KSP and kOS with trim controls. Unfortunately due to bugs in kOS or KSP, raw input command does not work. @Steven Mading have raised issue on github about it, I forget to check current state of it. Probably there is bigger issues to solve first. I'm still in phase of learning how everything is handled trough kOS, so I can't help you much, but there is video creted in previous releases where someone created nice autopilot with kOS and FAR, following terrain altitude pretty nice. Flying over mountains, hills and valleys. Nice video, btw. So, it is possible to create kOS scripts that handle FAR crafts in friendly way, but you should know how to create stable crafts/rockets in the first place. Or have to know craft limitations, so you don't exceed control input over craft limits.

One page back there is already answer regarding CKAN issues. Until everything is settled down from SQUAD side (fixing remaining bugs after vacation) and probably other mods that were dependency for SETI properly work on CKAN too, we all have to mix manual and automatic installs trough CKAN. Or just install everything by hand and don't forget to double check if some dependency mod is packed with your favorite mod but with older version. Also check that you don't have multiple versions of MM plugin. Firespitter is prone to be shiped with older version too as lot of mods depend on it.

Is it linux or MAC ? Have you hidden KSP folder by accident ? On linux machines it could be if you have installed in ".ksp" instead of "ksp" folder. I'm not familiar with all of linux distributions and have no experience with MAC at all if you use it. A bit of more details of your hardware/OS KSP version might help to provide support sooner and better.

Take your time with this, I know that it won't be easy to properly fit such idea in stock game and keep gamebalance. kOS mod itself for people who know how to use it is great balance breaker already. On the other hand, kOS brings a lot to this game, make people more interested to do some math, improve programming skills, introduction to robotics when combined with IR mod and so on. Liminting it too much might kill peoples interest to use kOS in the first place. Blocking availability of some commands in kOS language, based on unlocked tech tree level is another idea for gamebalance purpose, but it can also bring more issues than it is worth to go in such aproach. That brings back idea to go with energy consumption based on tech level and storage space for kOS scripts. On higher tech level you can have more storage space and/or less energy consuption to keep gamebalance. Although, if you run scripts from archive drives you don't need storage space at all. It all comes to personal preference, how someone want to customize KSP with mods, what kind of experience someone expect from this game. If someone want to use kOS integrated in probe cores, he will do it, regardless if it is officialy suported or not from kOS dev team. On the other hand, having it integrated with probes though, could make it easier in further development, less thing to worry about whenever SQUAD change something regarding part physic (mass/heating/drag etc.) I just throwing ideas here, to recall it when time comes to discuss about it in development. I already appreciate what you have done with kOS so far, probably many other users too.

SETI adds antenna to each probe. It works nice with stock behaviour. However, when you have installed RT or antenna range mod, you need MM configs written in different way that does not break intended RT or antenna range behaviour. If you have installed RT after you have installed SETI than you will not get any probe with built in antenna. Correct way should be to install SETI, rename mentioned config file, then install RT. Be creful though, when SETI update it might overwrite config again unless you rename it first or @Yemo rename it when update SETI.

Second this. I mostly use MJ for info purposes (dV, craft mass, current thrust etc.) and to create maneuver node, less often than before, but still it is essential when you overestimate self pilot skills and become short on dV when you neet to get back home. That become handy when you build some craft and want to share with others that don't use MJ. Behaviour of craft is the same regardless if you have MJ ort not. Similar thing is with kOS. It will be nice to include it in probe cores, less parts to worry about trough design. While we already speaking of MJ, it is integrated quite well in career too. You can't use some MJ modules (rover controls, docking for example) until you unlock it trough tech tree. It would not be too hard to do same with kOS. Such MM patch could be shiped separately from kOS main mod for people who will use it. Also it will be better idea to have different price for storage space, different EC drain rates and similar, rather than changing part mass as you unlock certain kOS part in tech tree. Again, to avoid different craft behaviour if you want to share craft with someone that does not use kOS at all. Increased EC drain will result in need for additional battery and solar panels that will increase overall craft weight, so result will be the same as you have increased part mass, but craft will behave the same with and without kOS installed.

Almost all of mods have dependency on module manager. MM is not the one that breaks your game, most probably you have wierd situations where some other mods are in conflict with each other. Or you didn't install something properly in the first place.

Sounds more like issue with wheel autostrut "feature" in KSP 1.1.2. Wheels will put autostrut on nearest heaviest part. In some cases that produce strange result, similar with IR parts where you can't rotate/move due to force from autostruts. Try to put wheels on different craft parts to see if that is a case or not. Don't have idea how to properly solve this though.

Due to way how game choose what is master vesel and what is chield when you dock, what part is "root" part of new mergerd craft and few other reasons. Someone asked same question recently, search couple of pages back to see better answer than I can provide.

Well, I'm sure that Inigma will add firespitter parts along with KAX parts for some barnstorming contracts, once firespitter is updated. That is reason for invitation to thread. Nice to see that whole mod is updated after long time.

I think that @inigma will like it for GAP Missing another seat for true rescue craft though. I'm sure that some other craft designer will come out with some fancy solutions once all parts were reworked and usable again.

Have you tried link for documentation in OP ? Or you need more info than provided there ?

I didn't checked everything in 1.1.x releases, but I have used both, FAR and stock fixes without issues. FAR add one set of things on control surfaces while stock fixex gives you another set of tweakables on top of that. It worked nice in combination to allow fine tuning your craft, in a way how you want to control surfaces response to input. BodyLiftFix is not needed at all with FAR because FAR calculate lift in compleatly different way. Trough voxelization process any part can provide lift, even if that part does not have config for lift in stock game at all. You may encounter problems with some mods though, if those moded parts don't have collision boxes set in proper way to allow voxelization for FAR.