erendrake

No other fork of kOS has ever had a release since Kevin's last release in 2013, and his mod release thread OP points to the new kOS. RemoteTech doesnt integrate with kOS. It is the other way around. The nature of RT is a command blocker so when other mods issue commands RT intercedes unless it is called off through RTs API. That API needs some love before it will be friendly to use by anyone.

Of course not everyone wants to use kOS. The reason i bring it up is because kOS has some kind of integration with RemoteTech that works. Mechjeb does not and shows no signs of adding one.

I believe the idea was not to have an autopilot like mechjeb do the work for you when out of communication range. Cliph and I talked a lot about interop between kOS and RemoteTech and I believe using kOS would be more in keeping with the idea of RemoteTech making the game more realistic.

https://github.com/KSP-KOS/KOS/releases/tag/v12.1 download this version and install it. Let us know if you still have the trouble

which version are you using? I have not seen any revert to launch issues with the new version.

The current RemoteTech/kOS integration is very beta right now. you can turn it on in the kOS config file and try it out. It should allow you to issue a command and the script will continue to run and function while you are out of range. known issues include only having access to steering and throttle. No action groups or sas rcs toggles. I have been holding off a bit to see where RT development goes and we have a lot on our plate already. That being said i see RT and kOS as the peanut butter and jelly of mods and i want them to work very well together

Well then this would likely help. Please let us know if it doesnt and we will get it on the list of fixes! EDIT: Mariano knew the truth

I imagine it will make it easier conceptually but was there something that blocked you before?

I would say that there are many more examples of Engineering projects that are total rewrites and never see the light of day, I know I have been part of my fair share of these We do not strictly adhere to anything if we think we can improve it. Truly very little code remains of the addon that Nivekk left us. If you had used it in the last month you would notice that the new kOS is considerably faster than the old one. Scripts run with kOS today are compiled and run much faster than before thanks to a lot of hard work by our small team. we are adding new features almost every day such as a vector drawing tool and an improved file editor that we just issued a pre-release for. I welcome anyone who wants to develop a mod with their own time. Someone bringing new ideas to the table is exciting for everyone in the modding community. I wish woodywood245 the best of luck with his project.

New pre-release https://github.com/KSP-KOS/KOS/releases/tag/v12.2P1 * BREAKING: All direction references are now relative to the controlling part, not the vessel, this will only break on vessels there these two directions are not the same. * Added a 3d Drawing tool for letting you draw https://www.youtube.com/watch?v=Vn6lUozVUHA * Added a new and improved file editor so the edit command actually works again in game! * Added the ability to switch to MapView and back in code * Other bug fixes

Beat me to it I was going to start using Universal Storage but didnt want to mess with ECLSS if it was abandoned. Its good to know that is still works fine. Maybe someone will pick it up.

I have been trying to bring MM into kOS and i have a syntax problem that im sure is simple I would like to add a kOSProcessor module to all parts that: 1. Have ModuleCommand 2. Dont already have a kOSProcessor The tricky part is that i want to give a varying amount of diskspace to parts based on their tech level. The example i have for the first two tiers of control follow. @PART[*]:HAS[TechRequired[start]]:HAS[@MODULE[ModuleCommand],!MODULE[kOSProcessor]] { MODULE { name = kOSProcessor diskSpace = 1000 } } @PART[*]:HAS[TechRequired[flightControl]]:HAS[@MODULE[ModuleCommand],!MODULE[kOSProcessor]] { MODULE { name = kOSProcessor diskSpace = 3000 } } pretty sure its something simple i dont understand about the syntax.

1. there are already a few of these controls available, but there is no way to "break" parts 2. we already have a Random number generator

New version v0.12.1 is up BREAKING: DOCKINGPORT:ORIENTATION is now DOCKINGPORT:FACING * Fixed Terminal linewrap @ the bottom of the terminal * Fixed "Revert to Launch" button, it was blowing up the world and not allowing control before * Fixed LOCK s in subprograms * Fixed RemoteTech integration blowing up everything * Fixed flight controls not releasing when they should * Disabled RemoteTech Integration while RT development is stalled * Fix exception when trying to type a multiline instruction in the interpreter * srfprograde is available as a new shortcut * BODY now has an OBT suffix * Parts now have a SHIP suffix * You can now work with your target if that target is a docking port * Added a new PRESERVE keyword for repeating a trigger. * all active triggers are removed when a script is finished.

Yep! you can lock "wheelsteering" and "wheelthrottle" using kOS to drive rovers.

I would be happy to help you both get to executing code. We dont have the features now but lets figure out what the smallest bit is and we will get it in for 12.2 Would you both like to talk about this feature over in the github tracker? https://github.com/KSP-KOS/KOS/issues/103

He is talking about kRPC, another project that is pretty neat. Honestly the concept of kRPC is pretty compelling and before our parser rewrite i had considered doing something like that and we still might. I have been focused on enabling more mission types and integrating with other addons. Im pretty sure we will come back around to something like this. This would be a very long ball.

This is something i have been noodling on for a few weeks on. once you have a target there are quite a few important bits of info we should add. For this example you could work it out if we added the "Longitude of AN" for the craft and minimus. However this might be a pretty big barrier to calculate that for a lot of younger scripters. What does everyone think about this? This would be additional data exposing more of the numbers that the KSP interface gives us * ETA to and/or Longitude of AN/DN * Rotational delta * translational delta * rotational rate of change * translational rate of change * Closest approach distance and ETA * Relative motion vector Any or all of these or others could be good. Sound off, tell us what you think.

When we rewrote the parser, the editor was removed to help get an update out sooner (still took awhile). Once 12.1 is out for real we have a list of stuff to bring back. I personally would rather use the excellent Saturn IDE

Sweet! I cant wait to see what you come up with.

the algorithm for LOCK STEERING is pretty rough and yes it does not count engine torque when determining steering. Luckily you can take direct control of all of the flight controls and steer yourself. Info on how to do so is here: http://ksp-kos.github.io/KOS_DOC/summary_topics/ship_control/ EDIT: If you have engine torque it will use it the same as normal steering, but if all you have is engine torque it doesnt think you can steer so it doesnt bother.

So far i am unable to reproduce this. If you shoot me a craft and kOSscript file that shows the error it will help a lot.

NEW PRE-RELEASE Up on Github After v12.0 we started finding a lot of bugs with steering and the "revert to launch" button. This is the first pre-release of v12.1 On Github

NEW PRE-RELEASE Up on Github After v12.0 we started finding a lot of bugs with steering and the "revert to launch" button. This is the first pre-release of v12.1 On Github

A bootstrapper is part of the roadmap and im going to try to get it in to v13.0