Dunbaratu

Doesn't it make more sense to do positionAt(ship,time:seconds+10) rather than positionAt(ship:BODY,time:seconds+10) ? You're comparing the body's position to the body's position and making a vector of that.

Yeah I get the backward compatibility problem. There's a lot of things kOS does by default that I wish weren't the default, but they'd be impossible to fix without breaking existing scripts. We often have the sane proper way of doing things ending up being the more verbose uglier way, and the less sane way of doing things being the terse way. A good example of this is the triggers like WHEN...THEN. By *default* they only fire once and then erase themselves. You go out of your way to specify when you want them to NOT go away, which feels really backward but that's what we're stuck with because.. backward compatibility with the way it was first done before we got our hands on it necessitates it be that way. So yeah I understand if it ends up being not so nice to work with because of backward compatibility. I deal with that problem a lot.

To me this looks like you're trying to set the trim values to values proportional to an error measured in entire degrees. (if pitch is off by merely 1 degree, then set the trim to its max of 1.0). Not sure if this helps the problem or not, but that's going to make for some very violent overcorrection once it does work. I'll pass this on to our steering expert and ask how the controls lockout works.

Yes, that would be perfect. I sort of thought it already worked this way and tried doing it like that at first, but it didn't. (My reason for thinking it worked this way was how the VisitWaypoints need the disableOnStateChange option or else they go unchecked again when you leave the waypoint, so I figured the same would be true of any other parameter - if it becomes false midway through you have to go back and try again from the top, but that doesn't seem to be the case.)

I don't know if a thing like this already exists (I couldn't find it in the docs) but if it did it would be useful for what I'm trying to work on: A Contract Parameter who's state depends on just an arbitrary expression the config file creates out of DATA and/or Expression Behaviour data nodes. This would allow me to make up my own arbitrary complicated conditions by just tracking them with my own data variables I change when other parameters trigger. What I'm trying to do is basically this: I have a Sequence representing the waypoints to hit for the rover drive course. Once the first parameter in the sequence becomes true (hit waypoint alpha), then I want to apply an additional condition that must remain true or else the driving course needs to start over (the Sequence list goes back to the first one again) the instant it becomes false. This additional condition is an "AND" (or "All") combination of these two things: altitude AGL < 10 and players keep hands off the manual controls. I can do each of those things individually, It's the combination of those terms together that's proving difficult with the tools available (or maybe I just don't understand them). Prior to starting the waypoint course, I want to allow AGL > 10 and manual controlling. After the waypoint course begins (the first VisitWaypoint happens), then from that point onward, the conditions AGL < 10 and non-manual-control must continually be true at all times until all the other VisitWaypoints have happened. If they have failed, then it doesn't fail the contract entirely, it just resets the waypoint list to the start and that attempt didn't count. You have to start the sequence over. I've gotten a bunch of attempts that *nearly* do this but not quite. The hardest part is that each VisitWaypoint is an instant effect, while the other conditions are continual effects. If I try to connect them to the VisitWaypoint in a boolean combination with Any, then the contract allows "hopping" landers to work, which just land at each waypoint, flown manually, and once the player lets go of the controls for an instant after landing it considers that a success (I don't want it too. Once the first waypoint is hit, I want it to fail and reset from then on, even when not near a waypoint at the time, whenever the controls are touched or the vehicle rises above 10m.). I finally worked out that I don't think the built-in conditions can do exactly this, but thought "no problem, I'll track these conditions myself in my own expression Behaviours".... and then ran into the problem that I don't think I see a way to say "this is a parameter which succeeds when my variable foo = 1 and my variable bar = 2" or anything along those lines. Thus the comment at the top of this message.

Thanks for the quick bug fix. I've tried it and the problem is gone now.

You can get the position of the center of the body (with something like ship:body:position, or kerbin:position) in the same XYZ reference frame as the predictAt vector. So you can do vector subtraction between the two to get a vector from the future position to the body center. The magnitude (:MAG) of that is the distance from that position to the body's center. (The effective radius for gravity calculations. Once you have that, if you want to know the altitude above sea level, subtract the body's radius. (body:radius is the sea-level radius of the body). If you want to know the altitude above ground level, you can do (body here):geopositionof( (xyz vector here) ):terrainheight + (body here):radius to get the actual terrain's distance from the body center and do the same thing as suggested above for sea level height. Be aware that when it comes to predicting terrain height, once you get there the actual terrain can be as much as 3 to 4 meters off from the geoposition:terrainheight prediction (at most). The prediction is based on the ideal smooth curve functions defined in the game's terrain generator formula, and the actual ground when you get there is a digitized approximation of that created by drawing polygons between sampled vertex points of that function. The amount by which it can be off varies depending on your graphics load settings (how fine-grain your terrain polygons are). (This was behind one of the bugs in KSP's early access days. You'd change your graphics settings, then go back in and reload your game, go back to a saved landed ship on the mun, and it would clip right through the ground and fall forever into the Mun's hollow interior. This happened because the terrain approximation polygons were now in a slightly different location than they were when you saved the game and the vessel's position happened to be slightly under the ground polygons rather than slightly above them. If you notice it takes a second or two to reset your vessel's position a bit and it seems to jump up a bit to a new spot when you load a vessel from the map view now, that's due to squad's fix to this bug. They now, upon loading, move the ship up or down a bit as necessary to match the new location of the terrain polygons.)

Specifically, in this code: https://github.com/KSP-KOS/KSLib/blob/master/library/lib_navball.ks You can use the function compass_for(ship) to get a number from 0 to 359 for what you're looking for.

To answer your earlier question, the version of ContractConfigurator I'm using is 1.9.2.1, which is the most recent one listed in CKAN, but probably not up to date with your develop version. I had to wait until I was home to access my gaming computer to find this information out.

Does PartUnlocked and PartModuleUnlocked mean merely that you have the tech tree node that allows them ulocked or does it mean you have actually paid the cost of that specific part so it is no longer greyed out in the VAB? For the purpose of making contracts I think it would be more useful if it meant the node containing the part is unlocked, not necessarily the part itself. For my rover contract it would be useful if it said "you don't get the contract until you *could* make rover wheels", rather than "you don't get it until you already *have* made rover wheels once." I think most players never unlock parts themselves in the science center, instead waiting until they're in the VAB or SPH and need the part, and then they unlock it from *there*. So if I wait for wheels to be unlocked before I give out the contract, that's going to effectively mean it won't show up until someone already built something with their new wheel parts, rather than it showing up in order to incentivize them to make something for the first time with wheel parts once they can.

Okay I put it into pastebin: http://pastebin.com/eUHtTtiT The eventual goal is to make this require the player keep their hands off the controls, and the contract has to be completed by their kOS script driving the rover to count. But for now for testing purposes I have that requirement commented out so the contract can be driven manually by hand. I also commented out the requirement to have a kOS CPU part unlocked in the tech tree, for the same reasons, so this can be tried out on a stock install. You do, however, need a career that has advanced far enough that you have rover wheels unlocked.

We've thought about this before, but there is some debate among the kOS developers as to whether or not this would be outside the remit of kOS. I'd like to be able to draw the line somewhere between "what kOS does do" and "what kOS doesn't do", so we don't end up turning an already kind-of-large mod into something so large it's just as big as the base game itself is and we don't have the ability to deal with it in our spare time. We agree that there should be such a line, but not on exactly where that line is. Camera controls may or may not fall beyond that line. They're not autopiloting, but then again they are part of the player experience while watching the autopilot.

I saw your github issue but it came at a time when we just were working in that area of the code and testing to recreate it is a pain. I'll try it tonight (I'm in UTC-5 so that will be a while yet) and see what I can find out.

I'll try to trim the example down to one that has the problem without other things today. My current version has other dependencies in it like needing a plugin DLL I made for a new contract parameter "hands off controls" for kOS purposes, and it refers to agencies you might not have. I'll try making a minimalist example that still exhibits the problem and post it here.

Sorry if I'm being difficult but I'm really struggling with understanding this. How do I make Parameter sequence work? I'm trying to visit waypoints, but force it to visit them in the proper order. You have to hit the 'alpha' waypoint before the 'beta' waypoint, and so on. The goal is to make them an effective "driving course" for a rover test contract. So I tried doing it something like this: PARAMETER { name = Run the course type = VesselParameterGroup PARAMETER { name = Sequence type = Sequence PARAMETER { name = ReachWaypoint1 type = VisitWaypoint // order of the waypoint in the WaypointGenerator list, even though // WaypointGenerator disallows the index field, it's got an implied // one based on the order it appears in the list in the file: index = 0 title = Reach KSC Rover Point Alpha notes = Must be within 10 meters of Alpha. distance = 10.0 showMessages = true targetBody = Kerbin rewardScience = 2.0 rewardReputation = 1.0 rewardFunds = 6000.0 disableOnStateChange = true // If I don't do this, the checkmark goes away when I leave the waypoint. } PARAMETER { name = ReachWaypoint2 type = VisitWaypoint // order of the waypoint in the WaypointGenerator list, even though // WaypointGenerator disallows the index field, it's got an implied // one based on the order it appears in the list in the file: index = 1 title = Reach KSC Rover Point Beta notes = Must be within 10 meters of Beta. distance = 10.0 showMessages = true targetBody = Kerbin rewardScience = 2.0 rewardReputation = 1.0 rewardFunds = 6000.0 disableOnStateChange = true // If I don't do this, the checkmark goes away when I leave the waypoint. } PARAMETER { name = ReachWaypoint3 type = VisitWaypoint // order of the waypoint in the WaypointGenerator list, even though // WaypointGenerator disallows the index field, it's got an implied // one based on the order it appears in the list in the file: index = 2 title = Reach KSC Rover Point Gamma notes = Must be within 10 meters of Gamma. distance = 10.0 showMessages = true targetBody = Kerbin rewardScience = 2.0 rewardReputation = 1.0 rewardFunds = 6000.0 disableOnStateChange = true // If I don't do this, the checkmark goes away when I leave the waypoint. } PARAMETER { name = ReachWaypoint4 type = VisitWaypoint // order of the waypoint in the WaypointGenerator list, even though // WaypointGenerator disallows the index field, it's got an implied // one based on the order it appears in the list in the file: index = 3 title = Reach KSC Rover Point Delta notes = Must be within 10 meters of Delta. distance = 10.0 showMessages = true targetBody = Kerbin rewardScience = 2.0 rewardReputation = 1.0 rewardFunds = 6000.0 disableOnStateChange = true // If I don't do this, the checkmark goes away when I leave the waypoint. } } PARAMETER { name = nearGround type = ReachState title = Keep altitude below 10m AGL maxTerrainAltitude = 10.0 } } And the problem is that even when I hit the waypoints in the proper order, and it DOES give them all green checkmarks in the contract display, it sill doesn't consider the sequence itself done for some reason I don't understand. It still shows as un-checked, even with all four VisitWaypoint's contained inside it checkmarked, and the "nearGround" parameter at the bottom checkmarked too. With all 5 things showing as green, it still doesn't get marked as completed. If you want I can post the whole contract file, not just that snippet, but I'm just not understanding why the contract parameter won't close out even when all its component parts have closed out as green checks.

Ah I see what happened. It gives me the alphabetical first one every time when I make a list like that. I was getting "Lovelace Labs" all the time. It worked without complaint, but wasn't what I was looking for.

Am I correct in understanding that for the "agent = ....." setting, the two choices are either "specify nothing" or "specify exactly one"? I have a collection of contracts for kOS I'm making and I'm trying to make about 3 or 4 new agencies to generate them, but with some randomness where it will pick one of the ones I specify, but I don't specify the exact one - just a set to pick from. Maybe if it allowed an array here and it means it's a set to choose from randomly that would be neat, like so: agent = Turing Machinations agent = Lovelace Labs agent = Von Neumann Architects Meaning "pick from one of these 3 choices to be the contract provider". (edit: Hey, it actually DOES work like this already, it turns out, but it wasn't documented that way.)

Thanks for the fast reply. So do all the waypoints within the same BEHAVIOUR section attempt to collect together if I give them the same name and call them all clustered = true, and set their count = fields?

This has bothered me ever since the new forums came into being. When I search with the sort order set to "Relevance" and then do the same search again right away with the sort order set to "Date", I'm not *really* changing my mind and searching again. I'm getting the search I wanted the *first* time but had no means of selecting in the forum software. Can we please have the sort order selectable on the advanced search screen so I don't have to keep searching twice back to back? Every time the search screen tells me I need to wait a bit before searching again, I feel like saying back at it, "Well, I wouldn't have had to, now would I, if you'd have let me pick the search I wanted the first time? I didn't want the 'Relevance' search. That was *your* idea that this is what I wanted, not mine, Mr Forum."

That's not enough to answer the question. First of all, "clustered" is only given in the docs as an option for the basic kind of waypoint, not for WAYPOINT_NEAR or RANDOM_WAYPOINT_NEAR, secondly if I made a bunch of vanilla waypoints and then gave each of them a clustered=true, how do I pick which is alpha, which is beta, etc? How do I make a cluster of RANDOM_WAYPOINT_NEAR's be in the same group as the first WAYPOINT they are assigned to be near to? Is there a group name field to put them in? Are the other sorts of waypoints, like RANDOM_WAYPOINT_NEAR meant to be derived classes of the basic WAYPOINT, such that all the fields of WAYPOINT are also available for RANDOM_WAYPOINT_NEAR? If so then I'd know they have the ability to do clustered = true for them too. If so, that wasn't something I noticed in the docs.

I've dug through the documentation and a few examples from existing contract packs but I'm still lost on this question: How do I make a contract whose waypoints are indexed sub-points from a root point? In the contracts API that means it looks like this:"myname alpha" is *actually* called just "myname" but with waypoint index = 0, and the one called "mayname beta" is *actually* called just "myname" but with waypoint index = 1, and so on. But I don't quite get how ContractConfigurator wants me to express that. Do I call the waypoints by the name "myname alpha", "myname beta" and so on, and ContractConfigurator will strip off the words "alpha", "beta" and so on when communicating them to the KSP API? Or do I name them "myname" and give them an index number and the KSP API will add the terms "alpha", "beta", and so on itself (which is what it seems to do with the stock contracts. The actual name of the waypoint is stored without the greek letter names, and it generates the greek letter names for display purposes only. I'm trying to make some contracts for kOS contract packs. The difference between these two approaches is important because in when a script asks kOS for the waypoint called "mypoint gamma", kOS assumes in order to find that waypoint from the API, it needs to strip off the word "gamma" and instead look for a waypoint called "mypoint" with index == 2, because that's how the stock contract waypoints work.

The problem with allowing multiple syntaces to do the same thing just because you *can* is that eventually it leads to Perl, where trying to read someone else's code is a real pain because they're using one of the other 20 ways to write the same statement than the one you're familiar with. I'm not a fan of the period syntax either, but it predates my involvement in the mod and I dislike the practice of making multiple correct ways to do the same thing even more than I do the wonky period syntax. It gets out of hand very fast.

As something distinct from the existing List()? Can you explain further?

Don't use SHIP:OBT:POSITION, that's the position relative to the center of the universe which is YOU in kOS's reckoning, so you're taking a magnitude near-zero vector and stretching it out to length 1 when you normalize it. It's going to be super fiddly which way that's pointing. If you're looking for a vector where you guarantee you know the origin of it, use vector subtraction to force it to work no matter what the underlying XYZ looks like. Try (object:POSITION - BODY:POSITION) to get a vector you know for certain means a vector from a body to the object, whatever object happens to be. Also be aware that the kind of calculation I'm speaking of presumes that origin and destination are both in the same SOI and share the same parent body (i.e. going from Kerbin to Duna, it's using Sun as the body they both orbit.) That's not wrong, you just need to ensure you understand that when doing their math. If you tried to transfer from, say, Kerbin to Ike rather than from Kerbin to Duna, the fact that Ike's parent body isn't the Sun like Kerbin's is could cause problems if you don't account for it. I'd just make it explicit by passing a third parameter, the common body they share, and then using that as the origin point for all your vector position subtractions).

One of the things that's nearly impossible to do with manual controls with rovers is to steer mildly with the keyboard. If you don't use a joystick, it's nearly impossible to do the sort of steering needed to keep a KSP rover from flipping.You can't hold the controls steady at a mild amount. The longer you hold in the key, the tighter and tighter you turn. Trying to hold it at, say, 10% deflection and KEEP it there unmoving for several seconds just isn't in the user interface. You can use capslock to slow it down but that still doesn't change the fact that the longer you hold the key the more you deflect - it just changes how long you have to hold it to move the controls the same distance. Holding it at a constant deflection that isn't 100% isn't something the controls support. You can try doing the tappy-tappy-tappy technique but that doesn't really hold it in one place, it still wiggles it back and forth across the point you want to hold it at. This tends to cause rover flipover, because what you want to do to avoid flipover is to steer by deflecting gently and carefully and the keyboard controls defeat every attempt you make to do this. Imagine trying to drive a car along an highway on-ramp where you want a mild but constant turn, if you weren't allowed to hold the wheel in place at a mild deflection from center, and instead had to move it tighter and tighter, then let go and let it recenter, then move it tighter again and then let go an let it recenter, etc. At best you'd be all over the lane, and at worst you'd cause it to skid a lot. This is what you're doing when you rover drive by keyboard at high speed. One of the reasons I go with a kOS script for rover driving is the mere fact that a script *can* hold the controls steady at a given deflection and keep it there in a way the stock controls deny to you. I can make it micro-correct the steering to keep things straight on and thus it allows me to drive faster before it gets dangerous. I can drive rovers with the balloon tires on Duna at about 20 m/s before it starts getting flippy, and there's no way the keyboard controls let me do that. It helps alleviate some of the boredom of visting more than one biome, although even with that I still won't want to do more than just two or three biomes per rover landing. I tend to use this driving script to hit the locations in one of those alpha/beta/gamma contracts where they're within a few kilometers of each other.