kcs123

I'm not asking anything. I was found it in your log and told you that current available versions of FAR were not compatible. Disapointed that you didn't read last 2-3 pages, otherwise you would find answer and didn't even bothered to ask. Literaly, post above yours info about compatible KSP version and FAR version is provided. You have probably installed trough CKAN with KSP 1.1.3. and then updated whole game. That is bad idea. Leads to many false bug reports and broken games. If you are using steam, install clean game without any mods, copy whole game folder elsewhere and put mods in that copied folder, trough CKAN or manual install, whatever is your preference. That way, your game would not become broken each time steam push update. CKAN would not allow you to install FAR on top of fresh KSP 1.2.2. install. If you want to play RO game, you should stick with older KSP release until major mod dependency is updated. And don't know why that provoked such reactions and posts with insults. I wrote well deserved critics, but at the same time provided answer to question. Where I'm insuled anyone ?

Yes. I didn't tried it in latest KSP 1.2.2. but it should work as it latest is not so mod breaking release as it was in past.

Please, don't pest moders about hosting site they prefer to use. Be grateful that moders created their mods in the first place and are willing to share their creation with the rest of world. Currently available CKAN release have bug that prevents some mods showing up on any list if some of dependency mod is not updated for latest KSP release. I ended myself in combination of CKAN and watching forums, for mods that are not covered by CKAN. Using manual download and install for mods that were not supported by CKAN. Hosting sites for those vary from github,dropbox, spacedock and curse. What is your preference of tracking is up to you, but noone should demand from moders additional workload just that you can track something easier. Tracking 50 mods is not that much, people use 100+ mods and don't complain about it. Despite tracking mods being time consuming, it is still much less time than some moder invested in development of mod. Try to put in consideration how much effort and time is put in creation of some mod, before you ask moders again for additional workload on their side. Such demands only kill some moder desire to develop and share their mod, so please, don't do that.

There is 2-3 pages of debate that reports about developer version of FAR is not supported for KSP 1.2.x because it is pretty much known that issues exist. And yet, you tried to use FAR with latest KSP release and asking for help ? Thiis line is from your log: ******* Log Initiated for Kerbal Space Program - 1.2.2.1622 (OSXPlayer) ******* I haven't searched to see what is version of FAR you try to use. Please be patient and wait for official release, like rest of us. Reports like this does not help until FAR is properly updated, to iron out bugs that were possible not noticed trough development.

Latest stable version of FAR is created for KSP 1.1.3. You will need either, to use older version of KSP or wait until FAR is updated properly for KSP 1.2.x. It is a bit harder to chase down other compatible versions of each mod you want to use for KSP 1.1.3. but it is possible, most mod developers still keeps last known stable version of their mod somewhere.

Just read posts from page #64 to latest one and you will find everything you need.

It will be much easier for developers to help you if you give them log files. Launch KSP, load your save game file, go in flight with craft that gives you issue, click on some Bluedogs antenna function, try to extend it, whatever should trigger animation etc. Then exit game and inspect folders. On windows OS, you should find "output_log.txt" file in folder KSP_x64_Data. Upload that somewhere, like patebin or dropbox or any other cloud service you prefer, so devs can download and help you. Without it, it is pure guess work what is going on. If you are not certain how to find stuff developers need to help you, search for more info in this thread:

You mean about GUI or kOS ? As for GUI, it is not too way complicated, once you start to use it. But perhaps it brings too much info at once when you try to use it for the very first time. Especialy if you are not familiar with ordinary objects in "normal" programing languages, like visual basic, visual C++ or C#, whatever someone prefer. @Waz, alpha10 version fixes that radio button issue, but introduce something new. When you try to enter any number inside TEXTFIELD box it throws NullReferenceException error. TEXTFIELD no longer accept any input. Happens as soon as you press key, not even reaching CONFIRMED event on pressing return key. Here is relevant part of log: Let me know if you need full log or something else.

Take off/landing speeds would be much, much better once ground effect is put in consideration. In stock aero, low speed handling is same on the ground and 1km above ground. It should not be like this, but stock aero does not simulate ground effect either. Once aircraft is in air, it should require much more velocity to be able build up enough preassure under wings for lift, like it is in FAR. On the other hand, while waiting for FAR to update, I tried to recreate craft with variable geometry wings from KSP 1.1.x release created in FAR. Few control surfaces were needed to re-attach due to KSP/mods changes, but on my suprise, craft is handled quite close in stock aero as it was in FAR. Although, take off speed in stock is about 10 to 20 m/s lower than it was in FAR, as much as I recall it. I didn't actualy measure behaviour and making proper comparison.

I have to admit that I didn't carefuly read everything, so it may be a case that I didn't understand it properly. But, is it same thing as with described time warping bug reported in several posts before ? (check last 2-3 pages) Have you try to makearound of time warping bug on flight scene, if that is a case ? Meaning, in flight, instead of time warping, switch to tracking station scene, do timewarp there and just before you need to excecute maneuver node switch back to flight scene. With a bit of luck, it should prevent that joint drifting due to time warp. Or it is entierly new bug, that IR parts swap orientation on SOI change. Have yet to try it in my playtrough to confirm/deny behaviour.

Nope. You have been told wrong in school. It is not Force times Radius. It is Radius times Force. It does not matter in scalar products, but order of parameters matter in equation of vector cross product. You can get totaly oposite direction if you apply right hand rule on cross product.

kOS icon is not shown on stock toolbar at flight scene, but when you add icon on Blizzy's toolbar it opens kOS GUI near stock toolbar. Perhaps those few screenshots will explain behaviour better than I can with words. Availability of icon - appear/disapear between scenes is like I described in previous quoted post. I hope that it help to narrow down issue. @Waz, thanks, and no worries, everything is in alpha stage in development, so changing behaviour back and forth is expected. Just sometimes is done on purpose and sometimes become different when it is not itended. Only using same kind of GUI may help to notice difference in behaviour. I can only help for now with some feedback between updates. I have to check IR again with latest update available. I was playing career game where I didn't unlocked IR techtree nodes having faulty IR sequencer dll between updates and bunch of other things. It is actualy great to know that issue is something on my side, I will be able to do something about it at least. Thanks for that info.

Better wait one day longer for release than patching everything again and reuploading one or two hours after release if something odd is discovered in dependency mods. I was not using RT as it was not everything settled down between SETI/RT and stock comm compatibility. When some other mods update their status I will switch to 1.2.2. and start new career game, just to be on safe side from possible kraken. Meanwhile, I messing more with kOS and alpha release of future kOS GUI: Developed some scripts for launching rocket, hovering, powered landing, executing maneuver node and driving rover to desired direction and chosen speed. Not way too advanced, but serves purpose. Also, didn't using MJ, KER or TCA in that latest playtrough.

Nope. That one is related due to changes in Blizzy's code. Nightingale found it trough KSP 1.2. prerelease that contract configurator triggers bug within Blizzy's Toolbar. He provided PR for toolbar and all other mods that use toolbar need to update wraper to avoid that nasty bug. Issue that I reported first time is on official kOS pre-release. It suppose to be fixed, but later on I was using kOS fork from Waz, so my later reports might not match with latest official releases. I will probably stick with current release until more of mods that I regulary use catch up with latest KSP update. Final frontier, alarm clock, SCANsat seems to work just fine with Blizzy's toolbar. Infernal robotics seems to be broken too. I haven't try MJ in latest moded playtrough and several other mods that I used in past. I having limited free time for KSP lately, so I was unable to find stable set of mods for decent career game.

Just noticed some small issue. 0.625m service bay that comes with SETI parts, should be in Payload editor group instead of utility. All other cargo/service bay are now in that section, including fairings. Not of ultimate importance, some of other mods still use utility section too, but it will be less confusing on the long run if those part types are under payload editor section.

I don't think that it is something easy to do with current RPM. Some of other moders that actualy create parts, more specific, cockpits and IVA for them may provide better info on this topic. But as much I was able to figure it out, you will need to do custom GUI for each specific cockpit. Meaning, you will need to alter cockpit meshes/recompile against RPM each time you want to change something with your own personal GUI. Even advanced moders postpone doing IVAs for cockpits until final release due to amount of re-work IVA require. kOS terminal, on the other hand is much less demanding, it only display data on one of RPM monitors, without or limited interactions. All interactions are mostly done trough AGs. New GUI under development could in theory integrate within RPM monitor in similar way as kOS terminal. I say "in theory". In practice, I don't know how much of this is feasible, as that new GUI is just existing unity game engine GUI. First, it be user responsibility to create GUI small enough that could possible fit within RPM monitor. Second, I don't know if it would be possible to create 3D GUI with built in unity game engine GUI. Meaning, if someone found a way how to display custom GUI on RPM monitor, it also need to take care how it would behave when you turn head around while siting in IVA. How GUI will be drawn on RPM monitor when you look at it from 30 or 60 degree angle instead of looking straight to RPM monitor at 90 degree angle ? Does built in unity game engine GUI is capable doing this ? Quite a lot of question and uncertain answers. Quite a lot effort have to be made to do even most simple RPM integration. All that for most probably limited GUI features. Don't get me wrong, I'm sure that many players would like to see something like this in game, but let @Waz to get current system out of alpha phase first. Once it is at least in beta stage of development and integrated with official kOS release it will be more sense to discuss about RPM integration further. Maybe someone who is more familiar with RPM could possible do something about it in future, who knows. I'm grateful already with overall kOS development how currently it is. Asking more from kOS development team, just not sound right, at least to me.

Actualy, I reported it. @hvacengi have included some fix for it, but it still broken. Just in a few pages back it was stated that Blizzy Toolbar may be considered as unsuported until further notice. At least some progress is made with it. At the time I reported it, it was not possible to use stock toolbar for kOS either. So, for now you can at least use Blizzy Toolbar for other mods and stock toolbar for kOS until proper fix is provided. You may also need to check new options for kOS under difficulty settings screen.

So, what would be recommendation on difficulty settings for new release ? Normal settings with 100% science and some personal preferences, like plasma blackouts, ground stations, G crew/part effects etc. ? Currently I play career game in KSP 1.2.1 with 60% of science. Using Dmagic science parts and scansat. Just a few part pack as some mods were unable to catch up with 1.2.1. release and while waiting for those KSP 1.2.2. popede up, so I'm at point one searching for compatible mods that will work in 1.2.2. That would probably take a while, so I will stick for KSP 1.2.1. at least for a week or so, until I start to go planetary travels. So, yes 60% for science gathering just make a game more grinding, does not create too much of chalange, at least for players familiar with KSP gameplay mechanic. Just made overall progress slower. I also play with only one ground station at KSC and stock comm system because RT is still WIP and updates could possibly be career game breaker, I want to avoid taht since I don't have much time to actualy play the game, so overall career progress is much slower. Despite that, I was able to create more/less stable comm network, at least for Kerbin SOI, landed a rover at Mun and Minimus, done maned landing at Mun, some tourist flybys are in progrees and just unlocked first worthly antenna to deploy comm satellite on orbit around Kerbol. Just when game started to be interesting, I would probably need to abandon everything due to KSP update. Such is a life.

In one of weekly updates, SQUAD mentioned that 1.2.2. will be much less mod breaking update compared to previous releases. In most cases is just recompile and apropriate numbers in version file. In some cases, only version file would need update for AVC and CKAN to be able to understand it.

First, you need to use KSP 1.2.1 or wait for a litle longer for another update. I wrote some quick reminder for myself and other new members of proper install order. Just in few posts above that linked one you will find link for latest plugin release. For other stuff, follow links in Ziws signature. I would recommend to use new rework part pack instead of older legacy parts. Legacy parts might or might not work properly, those were not checked/updated for several KSP releases.

Not exactly easy to understand if you have no background knowlage in math and physic, but wikipedia about couple of forces and about torque is good start. Basicaly, if you put in consideration rotation only on one axis (either of putch,yaw or roll), you can sum up all of forces that act on your craft to only one force vector on some distance from COM. One for each side of distance from COM, actualy. You need to sum up all other forces into other force vector that act on oposite side from COM. So, you can simplify all math to only two forces and two distances from COM. Like on this picture: That is best one I could find in this quick google search that match topic. Try to calculate torque from only one force at time. Let say root of vector P is COM of our craft. Vector P is calculated as cross product of distance between COM and root of F1 and F1 vetor itself. If you use right hand rule as adviced, you need to put facepalm to point from COM to root of F1 vetor, or if applied to your KSP craft towards front. Other fingeres are curled towards F1 point. Thumb of right hand point to direction of vector P. That is your red arrow from question. Now, when you do the same thing for F2 you will also get vector that points UP. That is summed up with vector from F1, meaning, your craft will wildly rotate. That is good if you want to rotate your craft. However, if you want to translate craft on a side, instead of rotate, you want to F2 to point in oposite direction, paralel to F1 vector. When you do cross product of distance from COM and new F2 vector you will get some other momentum vector, let's call it P2 that will point down. You sum up P1 vector from F1 cross product and P2 vector from cross product of F2. Resulting vector is actualy that red arrow you asked what it is. Idealy, for translation, you want it to be zero. However, if it is not, you point thumb of right hand to direction of resulting P vector and curled fingers gives you way of rotation, like it is shown on above picture. So, instead of doing all those calculations by hand each time you design your craft, you can use this awesome mod to just show you result of those scary math. Now, when you know all this trickery magic, you will notice that if you have craft with long tail, you can use smaller sized RCS near tail that also have less weight that can easy counterpart larger and heavier RCS in front that is much closer to COM. How you will use that new knowlage on your crafts is up to you.

@Waz, seems that alpha 7 or alpha 8 broke some of widget features. This kind of GUI no longer works properly: To be more specific, Radio buttons on Picture in horisontal box with labels "Vel.Hover" and "Alt.Hover" no longer can be created like on above picture. Commands for set style no longer works. Here is how it is created previously(only important part for discussion): // Creating GUI set Hover_GUI to GUI(280,400). // (width,height) set Hover_GUI:x to 515. // set GUI window position to X set Hover_GUI:y to 60. // set GUI window position to Y // Elements of GUI set HoveringModeBox to Hover_GUI:ADDVBOX. set HoveringChoiceBox to HoveringModeBox:ADDHBOX. // horizontal box for 2 RB set HoveringChoiceRB_Velocity to HoveringChoiceBox:ADDRADIOBUTTON("Vel.Hover",true). set HoveringChoiceRB_Velocity:STYLE:HMARGIN to 20. // create some space for next RB widget // in alpha8 produce error set HoveringChoiceRB_Altitude to HoveringChoiceBox:ADDRADIOBUTTON("Alt.Hover",false). set HoveringChoiceRB_Altitude:STYLE:HMARGIN to 100. // in alpha8 produce error set HoveringChoiceRB_Altitude:STYLE:ALIGN to "RIGHT". // in alpha8 produce error Previously, before STYLE introduction, I was using directly HMARGIN and ALIGN suffix, but that create error too. Maybe it is still possible to arange two radio buttons horisontaly in one box, but I could not figure out yet. I'm trying to create minimum sized GUI (in width/height used) with all needed commands and needed feedback for user. That I wanted to use one horisontal box with 2 RB instead of same thing with vertical box. I will stick with KSP 1.2.1. for a while until other moders catch up with everything, so no need to rush with next update, just wanted to notify it. Let me know if you need more details about it. It is hard to tell in front what else could possible be needed regarding GUI. That is why I'm trying to bind existing scripts with GUI, to be able to perovide more quality feedback.

I'm not sure, but seems that you are missing Firespitter Resources config. You need that along with firespitter.dll for electric engines and some other too, to work properly.

@Steven Mading, seems that you forgot to update version file that is inside archive. Inside 0.9.3. version file is: { "NAME": "LaserDist", "URL": "https://raw.githubusercontent.com/Dunbaratu/LaserDist/master/LaserDist.version", "DOWNLOAD":"https://github.com/Dunbaratu/LaserDist/releases/download/v0.9/LaserDist.zip", "CHANGE_LOG_URL":"https://raw.githubusercontent.com/Dunbaratu/LaserDist/master/ChangeLog.md", "GITHUB": { "USERNAME":"Dunbaratu", "REPOSITORY":"LaserDist", "ALLOW_PRE_RELEASE":false }, "VERSION": { "MAJOR": 0, "MINOR": 9, "PATCH": 2 }, "KSP_VERSION": { "MAJOR": 1, "MINOR": 1, "PATCH": 2 }, "KSP_VERSION_MIN": { "MAJOR": 1, "MINOR": 1, "PATCH": 0 }, "KSP_VERSION_MAX": { "MAJOR": 99, "MINOR": 99, "PATCH": 99 } } Probably it confuse AVC and CKAN, not knowing that is updated to 0.9.3. regardless of version number in filename.

Previous versions of FAR were including "light" version of real chutes. I can only assume that "llight" version of real chutes is not updated properly in current available development branch. So, you should stick to RealChute parachutes until proper FAR release and stop complaining. If you use development branch, you should know what are you doing.