erendrake

I'll skip it then How would you feel about making a Tutorial on it, we can add it to the wiki I haven't had trouble with it. Do you have a craft/script that i could try that expresses it?

I have a new prerelease available for testing! this one takes care of most of the reported bugs and I would really appreciate feedback. Download: https://github.com/erendrake/KOS/releases/tag/v0.11.0RC Documentation: https://github.com/erendrake/KOS/tree/develop ## This is a prerelease, expect some bugs - CHANGELOG - Thanks to enkido and jwvanderbeck for your help. Basic RemoveTech Intergration Added VOLUME:NAME for getting the current volume Lists can now be populated with basic data that you can loop over or index [Full Info](/wiki/List/) A Lot of bug fixes and refactoring Constants (eg G, E, PI) are now retrieved using CONSTANT(). Commands resolve in order of descending specificity, rather than in the pseudorandom order they were in before Added Math operators LN, LOG10, MIN, MAX. Removed NODE:APOAPSIS and NODE:PERIAPSIS. They are now available in NODE:ORBIT:APOAPSIS Basic list types: Bodies (eg Kerbin, Mun, Duna) Targets - All Vessels other than current Engines - Active engines on the craft Resources - All Ship Resources Parts - All Ship Parts (slow) Sensors - (eg Pres, Grav, Accel) Elements - All flights connected to the active vessel

First off you're welcome * Direct control of rotation and translation are definitely on their way, maybe even in v0.12. * thats a great idea that i hadn't thought about, I think you are right though, unless i have some kind of event structure (eg KeyUp, KeyDown) it will be a hack. we should also allow for joystick control! * What i am thinking about is making the limit higher in sandbox mode and then tying a bunch of feature unlocks into the tech tree for career. I think it would be against Kevin's vision for the mod to make it simple to turn off. * For the pid, I was thinking about letting the scripters make a new one (eg "PID(1,0.5,0.7)" then feed it settings and input or maybe even lock it to an expression. Then they would get an output value. just to make the guts a little easier to deal with. Is that what you are thinking? or would you like to keep it like it is where scripters make their own from scratch?

Its still there if you toggle power off and on again. We should restore it on launch

Sorry, i actually looked in the code, typed out the full line, and then mangled the text i just typed and it is not 10000kB. It is 10000B.

10000 Bytes LIST FILES. If you look at Steven's Duna mission. he has quite a few methods for dealing with this problem. I am ready to make many changes to this mod to add access to data and features, we might even add the ability to slave multiple parts together to form one "volume" but some limit stays as long as i am maintaining the releases. Kevin was always emphatic that it would stay and i see no reason to change it.

You are welcome, this has been a fun project. Documentating these changes is my last step to getting the next release up and i am avoiding it by playing...wait for it....KSP

I agree, they should not be hard.

in v0.11 We will have the following values in ORBIT APOAPSIS - Altitude PERIAPSIS - Altitude BODY - Reference Body, has a bunch of its own data. PERIOD - in seconds INCLINATION ECCENTRICITY SEMIMAJORAXIS SEMIMINORAXIS TRANSITION - How the current orbit patch will end INITIAL, FINAL, ENCOUNTER, ESCAPE, MANEUVER, PATCHES - all of the proceeding orbit patches. which have all of these same values. we have an open issue for adding more to orbit. feel free to add your thoughts https://github.com/erendrake/KOS/issues/18

I wish you well on your mod and we will do what we can to help you out. if you want all of these soon, please consider issuing some pull requests for us to review.

@Luis It would be helpful if you would add a feature request to the github issue tracker. If they are only on the forum they are likely to be lost in the shuffle.

If what we have will make steering work, im happy with not getting roll and getting v0.11 out. v0.12 will have all kinds of goodies like gimbaled roll steering if we want it

I Concur with your current thrust argument. max is not the correct value to use. I actually like your OfType syntax better than my foreach loop.

Ill bet that you could achieve docking if both ports where near the center of mass and you were careful with your alignment script. However, I dont want people designing their crafts around the capabilities of kOS, where possible. Now that we have Lists and the LIST IN command it opens up the possibility for "control from here" part lists as well as a list of docking ports on the current vessel along with their status. I think we might need something better thought out to let you do the current vessel easily while also allowing for any target vessel to have the same access. Feel free to add issues to the tracker on github, Ill get them into a milestone and we will keep plugging away, we are currently feature locked trying to get v0.11 documentation and bug fixes done.

public static double GetThrustTorque(Part p, Vessel vessel) { if (p.State == PartStates.ACTIVE) { ModuleEngines moduleEngine = null; ModuleGimbal moduleGimbal = null; foreach (PartModule partModule in p.Modules) { var foundModuleEngine = partModule as ModuleEngines; var foundModuleGimbal = partModule as ModuleGimbal; if (foundModuleEngine != null) { moduleEngine = foundModuleEngine; } else if (foundModuleGimbal != null) { moduleGimbal = foundModuleGimbal; } } if (moduleGimbal == null || moduleEngine == null) { return 0; } var gimbalRange = Math.Sin(Math.Abs(moduleGimbal.gimbalRange)); var maxTrust = moduleEngine.maxThrust; var magnitude = (p.Rigidbody.worldCenterOfMass - vessel.CoM).magnitude; var output = gimbalRange*maxTrust*magnitude; UnityEngine.Debug.Log("EngineTorque Found: " + output); return output; } return 0; } This was my effort before work this morning i think we might have come to a very similar place. I know it might seem silly but i really like having each term of these equations broken out and labeled.

ever since i saw the old buran concepts i have wanted KOS to be able to accomplish this mission profile. https://plus.google.com/104283767066622569016/posts/62Si9EEy6gg

There are so many of these properties that i have been mostly waiting for people to ask. If you think it could be useful, We can get it in for v0.12 There are a few reasons I have for not making this change * I am extremely leery of the Dynamic keyword. IMO it is only useful when you can't know ahead of time what properties you will have available. In this case, we can know this from the api. * we would have to inherit the names of the fields and the class structure in the KSP api directly, many of these are unhelpful. * when Squad changes any of these apis, I would rather it break my addon and i can fix it rather than making every scripter run into the same problem, get frustrated and have to search on the forums. * Im guessing it would break almost 100% of scripts written in kOS

you might want to pull my latest change, a lot of direction based math was not working because i forgot to include an interface on the Direction class. https://github.com/erendrake/KOS/issues/15

Are you comfortable merging this into the main trunk then? if so lets get it into v0.11 I still have so much documentation work to do that there doesnt seem to be much sense in waiting.

Does kos throw any exceptions in the log? I can look at the confignode code. its pretty strange

I have no issue with exposing that method to kOS scripters but its going to take some work. We have a bit of a grammar problem right now with kOS. Currently there is no Command for passing parameters to a preexisting structure and also get a value back. We can get values, and set values. Just not at the same time. If you want to have this method available, feel free to add it to the GitHub backlog, there isnt a lot there other than addon integration.

For the upcoming v0.11 almost all of the work remaining is in documentation. If anyone wants to help with this I would be eager to accept pull requests or links to Tutorial videos people make.

I cant wait to see what everyone comes up with there are a ton of possibilities. I will add attribute anywhere the community feels it appropriate. I will never try to dismiss or forget his contribution.

I am also committed to keeping one release with all of the interested parties involved in its development. Even if we end up adding modular behavior to accomplish it. it is all just clever engineering.

Could you settle for the action group bindings we have now?