kcs123

If you have to ask if it is hard to mod, then answer is: Yes, it is hard. However, don't let that answer discourage you. Try with small thing at first. MM for KSP is good start, to figure out how to make small tweaks for existing stuff in stock game and other mods around. If you want to crate new parts - meshes, animations, textures and such you need to learn how to use applications for that type of work, like 3d studio max, blender or similar tools. Blender is freeware software, start with that first to find out is that kind of work is appropriate/fun for you before you go to buy something more powerfull. If you want to do some awesome mods like TCA, you will probably need to learn a bit more of coding, mostly with C#, learn how to create plugin dlls, follow specific rules, so KSP can properly recognize them, so features from it can be used to tweak stok game in a way you want to do it. That is just basic, essential knowlage about tools and means of usage. While I was writting this @Denko666 have already provided shorter summary. What is more important is to know in real life, how stuff works and you want to accomplish. Knowlage how to recognise problems(goals), disect big problem(goal) in smaller chunk, solve smaller issues one at a time. Once you figure out how to deal with small stuff it is easier to put everything together in one more meaningfull application. Now, for your question, to figure out how to create autopilot that is capable to land a craft somewhere, there is already quite nice mod for this in KSP. Look at kOS autopilot mod. I assume you are beginer with coding. Such mod is quite good to start learning about programming. It is simple enough to get started and learn how to do stuff with kOS and yet quite powerful programming language that share some similarities with more powerful programming languages like C#, visual basic, LUA, phyton and such. Similarities are in terms that it have triggers/events, more complex structures for objects, functions for subroutines and such. All that packed for stuff you want to do in game. Possible things you learn playing with it can be easy applied later on in real life with more powerful languages. And if you don't, at least you will have some fun with it. Anyone can learn commands/keywords for any programming language. Thing that is more difficult to learn is to observe things and figure out how to write code for it, so machine can replicate desired steps. Bolded part of this post. kOS can also be too much if you never do coding, so you would also need to start with some small stuff before going to write full autopilot capable of landing on it's own. Before you are able to land, you need to figure out how to hold steady altitude, velocity and heading. Once you figure out that, solve thing how to steer your craft to different direction without crashing and holding same velocity and altitude at same time. When you solve this, you need to figure out how to gently lower altitude and velocity while still having steady craft heading, so you can actualy land on runway and not on some random spot. Although, you will probably need to learn how to land safely on some random spot first and when you figure out that, next step is how to land on exact desired spot with controled exact velocity and slope. Final thing for your desired autopilot is to put everything together and create several waypoints to follow, so your craft have proper heading when descend for final land spot on runway and it will touch down at desired safe speed. Once you find out how to do it with kOS, you will be more ready to create full pledged plugin in C# for it. Now you get some idea what is needed, I will let you to figure out for yorself is it easy or hard to do it. EDIT: You may also llok at this thread, it is similar topic as your own question:

Thanks to @sdfghdfgjd for that info. It is just few pages back.

Regarding AssetBundles subfolder, it comes packed with both, IR core files and also with IRSequencer. Currently it is no issue as sequencer have same file "ir_ui_objects.bundle" as in core archive, but also have another file "ir_ui_objects.ksp" that is not included in main archive. Just something you should be aware of when new version is released, you need to have proper order of deleting and istalling IR archives in case that core pack is updated but IRSequencer is not against same beta release. It would be better if both files are in core pack and left out completely, to avoid possible fault installs. If it is possible at all. If not, users should be informed about proper order of install, at least. Anyhow, thanks for keeping IR alive, KSP is just not same game without it.

Then it is just about not using control surface for pitch pilot input. With shown settings on picture above, all you need to do is to set pitch slider to "0" for pilot control, put spoiler to active and flap to inactive. Give it desired deflection and that's it. For elevation control, you should use other control surfaces, not same one that is used for spoiler. All other things is, like Darael said is just abusing FAR. It is either, some nasty part cliping or other mods involved.

Something just poped up, but I don't know if it feasible with MM only in KSP. Let say we have some part defined like this: StockPartPrice = 5000 StockPartNodeScience = 300 Part in question is moved to different node, could be higher or lower in tech tree. For this example I will assume that part is moved in lower tech node, but should work in both ways. NewPartNodeScience = 90 We should calculate new part price like this: NewPartPrice = (NewPartNodeScience / StockPartNodeScience) * StockPartPrice NewPartPrice = (90/300) * 5000 = 1500 So, basicaly, entry price will be changed based on percentage, how much is science purchase is changed by moving part into different tech tree node.

This picture is from KSP 1.0.5. I deleted recently KSP 1.1.x installs, so I no longer can check, but I belive it is this what you have asked for: Control surface defined as spoiler and positive deflection - it deflect up. On this crafti it is also used as elevator along with ones from tail, therefore it have pitch control to 100%, but it is not always recommanded such combo. I opened stability derivates with spoilers deployed so it can show behaviour in flight. Spoiler is also tied with brakes, it is always 100% or nothing, while for flaps you can choose 3 different steps of deflection in flight. Please, note separate values for deflection when used for picth control and different values for spoiler / flap. It is also possible to have negative deflection on spoiler as you can see on another picture, although as I said, I no longer recall is that feature from FAR or stock bug fixes mod from Claw.

Thanks @hvacengi, that is exactly what I hoped it is possible. I know that I read about delegates in documentation, but I forgot that term "delegate" is related with that stuff I wanted to accomplish. Switching between several programming languages on daily basis and english not being native language does not help much. Still need to diggest large part of kOS syntax and quite nice set of "hidden" features that I didn't even know it is already included in kOS until I stumbled upon something that I need it.

Looked at that page, but missed info about bolded part and how TOPATH is interpreted by kOS. Thanks for pointing in right direction. Anyhow, tried this in game: copypath("0:/mun_land",""). And does exectly what I was asked for. Btw. speaking of documentation I found small error, regarding nodes. On page http://ksp-kos.github.io/KOS_DOC/tutorials/exenode.html is stated that command for picking up next maneuver node is this: set nd to nextnode(). however that gives error. Proper command should be this: SET MyNode to NEXTNODE. Last one is from this page http://ksp-kos.github.io/KOS_DOC/structures/vessels/node.html#global:NEXTNODE Probably lot's of changes were made within kOS, but tutorial examples were not updated. That was not stoped me to create more/less multipurpose function to excecute maneuver node. This one should be in library file and executed from main script. Throtlle PID could have some more optimization, timewarp stop command should be added before trottle up/turning ship and other small stuff. Example of usage could be something like this: set MyNode to nextnode. set Moutput to "". ManeuverBurn(MyNode,0.1,Moutput). print Moutput. Function does it's job, but feedback on terminal is not written as variable for output is primitive one, it is not of complex class with suffix. So that print command write only blank as it was set outside of funtction block. That behaviour is expected as described on this page: http://ksp-kos.github.io/KOS_DOC/language/user_functions.html#passing-by-value I want to provide better feedback to user what is happening, to not get a feeling that script is stuck with something. Currently I put text message on screen, but it is not so good if someone plan to use it trough telnet terminal, or trough kOS terminal in IVA, for example. So instead of returning primitive, could be better that inside of ManeuverBurn function I add a call for some other function. for example something like this: I know that instead of passing function as parameter, I could just simply create global function call for "display_block", but I want ManeuverBurn function to be in library, providing maximum reusage from various other scripts, as most probably display block will be different for various craft. Somehow, I feel that is possible to do in kOS, but I can't find reliable example in documentation. Is it something like that even possible in kOS ?

I usualy set control surfaces for flaps to be "flaps only" - give it properties that actualy is flap, choose flap deflection, but also pitch/yaw/roll to zero, so it does not move from pilot direct input. Level of flap deflection in flight is set trough action groups. For pitch control it is better to use surfaces on tail than same one as flaps. I used stock bug fixes from Claw in past, so I no longer recall what flap feature comes from FAR and what was addition from stock bug fixes.

Thanks for info. When you update mod properly for KSP 1.2.1., is it OK from your side to notify CKAN staff members for proper metadata file updates ? If you don't have time and willpower to maintain metadata files for CKAN.

I created small boot script that copy necessary files to kOS CPU on craft launch and start main program. Works as intended, look like this: set TERMINAL:CHARHEIGHT to 10. if not exists("1:/lib_navball") { copypath("0:/lib_navball","1:/lib_navball"). }. if not exists("1:/mun_land") { copypath("0:/mun_land","1:/mun_land"). }. runpath("1:/mun_land"). I would like to change it to be more universal, if I add more than one CPU on craft, for example. My question is: What is starting directory when boot script is started on craft launch, assuming that I don't start from archive ? Would command: copypath("0:/mun_land","1:/mun_land"). have same effect as this one: copypath("0:/mun_land",""). // or this one: copypath("0:/mun_land","/"). Thing that I would like to avoid is to explicitly use volume label in path, but I want to files be copied in CPU that started boot script, not some random CPU that could also be on craft. And also, do I need to create directory on destination CPU before going to copy files, or kOS is capable to recreate whole source path ? I could not figure out this in kOS documentation, have yet to figure it out trough old fashion method of futile attempt.

Most of those fixes are included in stock game at time while @Claw was under SQUAD payroll trough KSP 1.2. development. Can't tell how many of fixes from this mod were not included in stock release. Even less is known if Claw have desire to continue this mod or not. There was a lot of speculations what was happened between SQUAD and former developers, without true reliable info from both sides to get proper conclusion.

Thanks. It is not only for me, I thought it will be more helpful for @Yemo for gamebalance. Antenna mass is not so much important for large crafts, but is of high importance if you build tiny probes early in career for DNS relays. Thanks again for all effort taken in creating and keeping alive this mod.

Thanks for info, somehow, I didn't noticed such behaviour until now.

Don't know if it is already mentioned or is known issue, but I noticed small glitch with big map. Probe with altimetry scaner is in optimal orbit, have enough EC, but data is not updated on map. At the same time, small map works as intended - properly update altimetry data. Sometimes showing small map trigger proper update of big map. Last time it didn't helped, but switching to different celestial body on big map back and forth have triggered update of data. I still observe behaviour, so I can give you proper reliable reproducing steps. I got only 2-3 screenshot of behaviour if description is not enough.

Nice. Only thing missing in tables is antenna mass(important info for space craft and dV) for better comparison which one is better(more effective) for given task. Mass still can be found down in page along with picture and full description of antenna, but it is hard to list page back and forth if you want to make some comparison. Just a suggestion, looks nice otherwise.

@TheReadPanda, does you maintain your own metadata files for CKAN, or it is handled by CKAN staff members ? Somehow, it is equaly bad to ask in CKAN thread as they already working hard to put everything in order with other mods. On CKAN mod list there is listed former mod name "Kerbal Science Institute Hiring" with max KSP version 1.0.9. Perhaps all that mod name change and version numbers confuses CKAN bot, so it can't pick up changes. I appologize if you don't maintain files needed for AVC and CKAN.

Pre-release is already available to test. Although it could still have issues. So, use it at your own risk, have some fun, report any issue found or just wait a bit longer until proper release. https://github.com/MagicSmokeIndustries/IR-Sequencer/releases

KJR and wheel/landing gear autostrut feature is your enemy with IR parts. There is info about KJR, to edit xml config file for it and disable autostruting on all parts. Search for posts few pages back. (It might also be in WIP IR part rework thread, I no longer recall, sorry). Wheel autostruting is more tricky. You have to design your craft carefuly, placing some other (more heavy part) between wheel and IR part. It might work on some design, while still having issues on other designs.

Got a bunch of other mods, including beta(pre-release) version of IR and kOS. Not having described issue. I'm afraid that your best bet is painstakingly removing mods one by one, or uploading output log that could give some clue what could caused it. Probably both.

Noticed similar issue with toolbar. Fresh KSP install and just started to hunt down working mods and install them. Fresh install, blizzy toolbar is empty, but shown on UI, so you can choose size/positon and icons you want to be there. If I add only IR icon on it, toolbar itself become invisible. If you leave it like that, there is no chance to configure it properly again except by deleting toolbar-settings.dat file located in "GameData" root folder. Workaround from this, at least in my case is to put final frontier icon, so it can stay visible even when you click on "broken" icon from other mods like IR. Hhave yet to try to edit IR xml config file to suport toolbar, as V8jester suggested.

No worries, I will make some workaround with this. Take you time and schedule fix along with other bugs, no special need to make another pre-release for it. Some other player could read about it here and avoid issue. Not a big deal, clicking on part and on button to show terminal still works properly.

Don't know if it is of any help, but kOS icon also missing in main game toolbar. Another odd thing is in SPH/VAB. That one is be related with beta IR mod. Migth be strange interaction between toolbar-kOS-IR mod. Fresh install, blizzy toolbar is empty, but shown on UI, so you can choose size/positon and icons you want to be there. If I add only IR icon on it, toolbar itself become invisible. If you leave it like that, there is no chance to configure it properly again except by deleting toolbar-settings.dat file located in "GameData" root folder. Workaround from this, at least in my case is to put final frontier icon, so it can stay visible even when you click on "broken" icon from other mods like IR. Someone mentioned that I need to edit IR xml config file to suport toolbar, have yet to investigate that option. Somehow I missed info about kOS options being in difficulty settings UI. Have to check those if I can make kOS UI apear on regular toolbar at least.

Those S2 parts were creatred long before B9PW, therefore is mismatch with textures. Also KSP itself have changes along way with shaders and what not. To me it looks like bumbmaps are off, but I don't have much knowlage how that is handled in unity game engine. Anyhow, upper section of S2 parts looks much better after alteration.

Yep. Everyone else who place landing gears or wheels too close to IR parts. KJR if used could also be issue. Mentioned few pages back. It is due to stock wheel/landing gear autostrut feature that can't be disabled. Wheels/landing gears aims to closest heaviest part to autostrut with. That cause issues with IR moving parts. You can try to put some other parts between IR parts and landing gears, but it not work in every situation. Trial and error mostly, until you figure out what you can do and what you need to avoid when building craft.