Dunbaratu

The error in your screenshot says you never set the variable PIST to anything. When I gave the example "assume PIST is the piston part and CRANK is the crank part" I meant "this example assumes you've already set those variables to those values before you run this example code, or it won't work.". For how to set them in the first place, I recommend looking at the name tag system as a starting point: http://ksp-kos.github.io/KOS_DOC/general/nametag.html - - - Updated - - - Is anyone else out there running on Linux and experiencing the same problem? There are a few ways that Unity, really annoyingly, chose to make the Linux implementation differ for no good reason (they're not differences due to the OS. They're differences due to Unity just *choosing* to make things different on different OS's) It makes testing a mod a nightmare at times.

Laserdist is unable to be reliable at detecting hits on parts of the same vessel to which the laserdist is attached. I've wasted days and days trying every which combination to work out why and I can't find anything that fixes it at all. It has something to do with the timing of when parts are moved by the main game, and when the callbacks are called by the main game. it seems to be interleaving the movement of parts with the calls to those parts' callbacks, in a way that randomly jumbles whether all, some, or none of the parts have been moved by the time the mod tries to perform its ray cast. When I cast the ray, some of the parts are located where they belong on THIS physics frame and some are located where they belong on the NEXT physics frame, making the laser miss half the time. I've had a zillion bits of advice on moving the code to fixedUpdate, or to lateUpdate - I've tried them all. it makes NO difference. Advice on the unity forums themselves about the problem presume I'm writing an entire Unity game from scratch on my own and I am the one in charge of when the parts get moved and I can control that code, which I cannot because that's SQUAD's doing. For the moment I've thrown up my hands and given up. I have no clue. I suspect it may be related to why sometimes I can't click on parts with the right mouse button and I have to try several times to get a hit - that UI code works by ray casting too so it may be an underlying problem I just cannot fix. - - - Updated - - - The first and obvious question is : does your terminal window look greyed out and semitransparent or is it opaque. If it's semitransparent, then that means it doesn't have keyboard focus. If you can't make it get focus by clicking on it, then that's the root cause of the problem and where the bug really lays. Incidentally, clicking anywhere outside the window (like on the control panel to adjust the UCP, STAT, RT2, etc buttons) makes the terminal lose focus and you have to re-click the terminal to get it back.

The problem with normal arctan is that when you divide Y by X to get the tangent, you lose some of the sign information. The fraction (-1/-1) and the fraction (1/1) both result in 1. The fraction (-1/1) and (1/-1) both result in -1. So you can't quite narrow down which quadrant of the 360 degree circle you're in. A tangent of 1.0 MIGHT be 45 degrees or it might be in the opposite quadrant, at 225 degrees. Atan2 (a second variant of arctan) is a thing computer math libraries added to allow you to get the full quadrant information by having you pass in both the numerator and denominator components of the tangent separately so it knows what the sign of each are. (ATAN2 *can* tell the difference between 45 degrees and 225 degrees because it knows if that 1.0 value was the result of dividing two positive numbers or two negative numbers). No idea. That's too open-ended of a question, with multiple possible approaches. AG1 on. AG1 off. AG2 on. AG2 off. // etc...

In your example I imagine you should be able to get the vector cross product of the facing:vector of the crankshaft and the facing:vector of one of the piston housings to work out the crankshaft position. Something a bit like this might work: Assume PIST is the Part of one of the pistons, and it's oriented such that its STARBOARD facing is out the side of the engine (you may have to change STARVECTOR for TOPVECTOR in my example below if it's not): Assume CRANK is the Part of the crankshaft, and that its TOP vector is pointing radially outward while its FORE direction is along the shaft axis. LOCK cosValue to VDOT(PIST:FACING:FOREVECTOR,CRANK:FACING:TOPVECTOR). LOCK sinValue to VDOT(PIST:FACING:STARVECTOR,CRANK:FACING:TOPVECTOR). LOCK crankAngle to ATAN2( sinValue, cosValue ). You may have to try it with different variations of FOREVECTOR, STARVECTOR, and TOPVECTOR depending on how the orientation of your parts is defined. I'm just guessing from the image one way they *might* have been defined. Basically, FORE is the Z axis of the part's local transform, STAR is it's X axis and TOP is its Y axis.

kOS does allow you to read the position and orientation of a whole part. While you can't read the sub-positions and sub-orientations of parts within parts (the sliding piece within an IR part), you can read the positions of whole parts. So whatever whole part is attached to your rotating IR part might be queryable for its PART:FACING, to get an idea. I can't tell from the video exactly how your parts are attached so I don't know for sure if this would work. I've just verified this is true, and passed it on to erendrake. A fix is coming soon.

I used SharpDevelop on Windows, and I think others have had success with Monodevelop on unix. C# is like Java in that it tries to avoid the need for a makefile by tracking dependencies for you. Unlike java though it doesn't do the simple thing of just enforcing that you have to use the same name for the files as for the classes or the same name for the directories as for the namespaces, which means it has to keep track of that mapping in a separate XML file. That XML file holds the dependencies info.

Sadly, no it isn't. The :PITCH suffix doesn't really mean "pitch". It's a badly named suffix dating back to the original mod author that we're now sort of stuck with for backward compatibility. What it *actually* does is rotate around the X axis of the universe, wherever that X axis happens to currently be pointed. To get what you want I recommend this: lock proPitchOrb to 90 - VANG(SHIP:VELOCITY:ORBIT,SHIP:UP:VECTOR). lock proPitchSrf to 90 - VANG(SHIP:VELOCITY:SURFACE,SHIP:UP:VECTOR). . I don't know your purpose, so it's up to you which kind of prograde you want - the orbital or the surface. Both of them work by using the up vector as the normal to the horizon, and comparing the angle between that and your movement vector. In general, that's the solution to the problem "what is the angle between vector V and plane P" - it's (90 - (angle between V and P's normal)).

That's because Infernal Robotics is being supported in kOS in a very generic way that tries not to play too many favorites. Instead of implementing "this is how you use Infernal Robotics parts in kOS" we implemented "this is how you access the user interface widgets and tools that any other mods can generically put onto parts". And Infernal Robotics is just one such mod you can access this way. If you're using search terms on the docs, try "PartModule" - that's where you'll get a lot of hits about how the system works. The PartModule that IR adds to allow user interaction with their parts is called (for some reason I don't get - they made the name not me) "MuMechToggle".

The difficulty I always find with trying to do solar panel sun tracking, and the reason I rarely ever bother, is the limitation built into the stock KSP system itself that vessels on rails don't fully "exist" in the normal sense, and thus cannot be steered, rotated, or anything. That makes stationkeeping, and solar panel rotation, both utterly impossible for a set of multiple satellites that are not within 2.5 km of each other, unless you're willing to spend all your time constantly swapping focus between them and never, say, trying to timewarp through 60 days quickly. It would be unfair, for example, if the game started tracking perturbations and the like and distorting your orbits if it didn't *also* let vessels on rails move themselves, because that limitation would utterly prevent your ability to do proper stationkeeping to compensate for the perturbations.

Pitch of which way the nose is facing: LOCK currentPitch TO ( 90 - VANG(SHIP:UP, SHIP:FACING:VECTOR) ). If you want the pitch of which way you are actually traveling, in case you are not headed nose-first or are tumbling, then replace SHIP:FACING:VECTOR with SHIP:VELOCITY:SURFACE or SHIP:VELOCITY:ORBIT. And since SHIP:UP is rotating as you move around in orbit, you have to keep re-querying that, which is the same problem as you could get with any navball reading, even if it was just encapsulated in one single suffix. Would it be better to have some direct navball-oriented data? Sure. Is it top priority? Not for me anymore at the moment, given how easy it is to derive from what is there. It used to be worse but it's gotten better - good enough to be workable. There's other deeper architectural stuff that it's more worth it for me to spend time on, because it's stuff that user scripts *cannot* work around easily in one simple subtraction of two values the system lets you query - like getting the terminal to work remotely, or adding user function calls. Adding navball-oriented pitch and roll to a Direction is easy enough if someone wants to open up the code and add it. Just be careful not to create a name clash with the already existing (and badly named) :PITCH and :ROLL that's already there.

What are you trying to do with it? A lot can be accomplished in a way that actually ignores the underlying weirdly rotated reference frame by just always thinking in terms of vectors relative to other vectors rather than relative to the absolute axes of the universe. Dot products, cross products, and rotations around vectors can allow you to write math expressions that cancel out how the underlying universe's axes are rotated.

Supposedly a position number was added to IR's right click panel recently at the request of us here in kOS for specifically that purpose. Make sure your IR DLL is up to date.

Uhhhmmmm...... what makes you think this is related to kOS?

Yes. The features talked about in this video are now in the release and work fine.The video was made before they were released and the features have changed ever so slightly since then, but the links in the description to the examples code were updated to the new way. Read down into the comments of the vid to see the changes that occurred after it was recorded. The video makes it look slightly harder than it now is.

The speed is a global setting for all of kOS rather than being different per-part. This was mostly because it was pictured as being a matter of people tweaking kOS for their own gaming machine's capabilities. We can't easily settle on a number that works for everyone without having to really nerf it to be unnecessarily slow for the people with faster computers, so it became a config setting. Also it has a direct impact on animation framerate of the game, so there's also a matter of user preference - would you rather have a fast kOS CPU or a smooth animation experience? This makes it ironically that you might want to set it SLOWER on a faster computer, if your computer's speed is mostly due to GPU rather than CPU, otherwise it takes your otherwise fast GPU-bound framerate and turns it into a slower CPU-bound framerate as the framerate is held back by running so many kOS instructions per frame. Maybe it should be moved to depending on each part... but.... I'm tempted to say that doing that will require a bit of an overhaul on how CONFIG:IPU even works in the first place. It really should be tied to the universe's physical time more so than the animation framerate, if we want to simulate a slower or faster computer in the gameworld. A CONFIG:IPU of 150 on a machine that's getting a framerate of 30FPS is *literally* running the kOS script half as fast as one with the same CONFIG:IPU of 150 on a machine getting a framerate of 60FPS. I've been thinking about interesting ways to have lower tech CPUS that run slower, but the above problem would have to be addressed first. As it is already, not everyone is *really* getting the same speeds out of their kOS CPUs.

I am in the middle of researching how to make a KSP mod have a TCP/IP server in it (it's a bit funky because a KSP mod is unable to spawn processes or threads, and normally at least one or the other is required for a correct TCP/IP server of any sort.) I have a plan that I'm trying to work out involving more than one Monobehaviour and their Update()'s behaving like psuedo-threads. Anyway the point is that I an trying to tackle the problem of the remotable terminal over a TCP/IP socket, like doing a telnet. First I have to JUST see if it's even possible to have any sort of TCP/IP server *at all*.

Well it already does detect a problem and mentions it - the recursion went on too long and blew past the limit - I don't want to prevent recursion in case there's some weird way it can be useful. What might be better is to improve the "config:IPU exceeded" message to make it show exactly what it was executing when it happened. Then it would at least highlight the LOCK statement that caused it.

Yes this causes recursion. LOCK X TO X + 1. It would take a lot of work to change it because in this case X is really a function, not a variable, so there's nowhere for it to actually be temporarily stored while being re-evaluated.

It works exactly like it's supposed to. The problem is that what it's supposed to do versus what you'd reasonably expect it to from the terminology don't match, and part of that is what is in my opinion a major terminology mistake made by the mod's original author back to the early days before we had our hands on it. What they *actually* do when you say R(a,b,c) is rotate C degrees around the UNIVERSE's Z axis, then A degrees around the UNIVERSE's X axis, then Y degrees around the UNIVERSE's Y axis. These have nothing to do with the ship's orientation at all. That terminology mistake is this: He chose to call the three components of a R() direction by the names :pitch, :yaw, and :roll. The moment those magic three words are used, people immediately think in terms of a ship-oriented reference frame, and that's utterly wrong. So the error you're making is this: - When you thought that dir*vector rotates the vector, you were right. - When you thought that sun:position is a vector pointing toward the sun from your ship, you were right. - When you thought that R(90,0,0) meant to rotate around a line that is perpendicular to sun:position, you were wrong. It rotates around whatever happens to be the X axis of the universe at the time. Because that might not even be perpendicular to the sun's position, it might not *look* like a 90 degree rotation to you. Rotating a vector around an axis that is not perpendicular to it causes the vector to sweep a cone shape, if you can catch what I mean from that. We can't help that the universe's XYZ axes are weird - that is inherited from KSP itself. And it's useful to have access to a means of rotating around those raw axes directly, which is what the R() tuple does. So it's not that it's not working like it's *supposed* to, but that it does a poor job of communicating to the user what it is that it's supposed to do, because of the awful terminology choice to use the words Yaw, Pitch, and Roll. Now, with that aside, how do you get what you actually DO want? What you want is to start from a direction aimed at the sun, and then pitch down 90 from that. Do you mean 90 relative to however your ship is pointed at the time, or 90 relative to the SOI planet, or..... I have to understand what "down" you meant, and if you tell me I can try to give an example. It may be better to phrase it differently - describe what you want your final orientation to look like- which way is the nose pointed, which way is the top of the ship pointed, and which way are the wings pointed.

The missing doc changes are now present, namely these: new methods for making Direction rotations A means of accessing waypoint information for locations that pop up in contracts New :POSITION and :ALTITUDEPOSITION suffixes of a LATLNG (geocoordinates) allow you to convert the latitude/longitude of a location into XYZ 3-D space positions of that location. Note, the intended way of getting the 3-D data about a waypoint is to first get the Waypoint's :GEOPOSITION suffix, which is a GeoCoordiantes structure, and then use the GeoCoordiantes' :POSITION or :ALTITUDEPOSITION suffix on that to get the 3D position. Example: // You were given a contract for temperature surveys from the surface // at "Herman's Lookout Beta", whatever the heck THAT is. So you // run code like this to get its 3D position: SET wpName to "Herman's Lookout Beta". // Or whatever it was called in your game SET wp TO WAYPOINT(wpName). LOCK contractPos TO wp:GEOPOSITION:POSITION. // Now contractPos is always the vector pointing to the position of the surface at the contract's waypoint. // and it continually updates as you move and as the planet rotates. // Note how contractPos is a LOCK while the others are just SETs. The waypoint is the same // but the 3D position can move if the planet is rotating or you are moving (the position is always // relative to the CPU vessel as the origin). These were in the original 0.15.5 announcement but at the time the links to their doc pages didn't work right yet.

if kOS is not listed in CKAN something is wrong because it's supposed to be and the support files are there in kOS for it. Sorry for the thread derail - I regularly now do an advanced search for mentions of kOS ever since SQUAD decided to make an un-index separate forum for support for modded installs (grumble) that requires doing that in order to not miss some user's problem reports.

I was trying to diagnose this by eyeball and I suspect there's a mismatch between the code you posted upthread for seek.ks and what you were actually running here. My reason for suspecting that is that the posted error implies extgroup1 is a list of only 1 item, but in the code I saw posted it would have to have 6 items in it or else it would have had to throw an exception earlier when trying to do all the extgoup1:add(blah) lines. Are you saying this worked prior to v0.15.5 ? Like on v0.15.4 ? Because this looks like a parser error but.... NOTHING between v0.15.4 and v0.15.5 had anything to do with the parser... that's weird. As a test, can you break up the expression into more than statement, like so: FOR L IN extgroup1 { SET theMod TO L:GETMODULE("MUMECHTOGGLE"). EXTMODS1:ADD( theMod ). }. I'm trying to diagnose whether it has something to do with parsing the complex expression with it all embedded together in one statement. But like I said, I'm baffled by the idea that this is somehow a new problem that just showed up because of the 0.15.5 update, given that 0.15.4 and 0.15.4 had zero parsing changes. In fact I think the last parser change was back between 0.15.1 and 0.15.2.

Just to let people know: Several of the links in the release announcement lead to either 404 not found pages, or to pages that are out of date by just a day or two before the release and fail to mention the new feature being talked about. This will be fixed, probably Sunday. The documentation source file changes are written, but the pages hosted on the site weren't regenerated from the source yet when the announcement was made.

Just to let people know: Several of the links in the release announcement lead to either 404 not found pages, or to pages that are out of date and fail to mention the new feature being talked about. This will be fixed, probably Sunday. The documentation source file changes are written, but the pages hosted on the site weren't regenerated from the source yet when the announcement was made. - - - Updated - - - I love that new part models are being made, Camacha. That's great. We should have plenty of variety to work with that way. When we have multiple part models, it means we'll have to think about what computer features should really scale as you climb the tech tree and buy better versions of the part. One comment on the artwork - putting the kOS identifying decal on the top or bottom of a stack-mounted part means that once it's part of a stack, you can't see it anymore. Maybe there should be an identifying decal on the outer cylinder wall of the stack-mounted part too. I don't know if erendrake agrees, but one thing in general I thought might be kind of cool is if kOS parts followed the inverse of the usual part progression. Typically in KSP you start with the small lightweight diameter parts and then get big diameter parts as you get better tech. For engines that makes sense but for computers maybe it should go the other way around - you get the bulky heavy computers FIRST on the tech tree, and then graduate up to smaller, but more capable ones later. If we want to go with that, it might affect the artwork decisions which is why I put it out for discussion now. The way you'd want to make the large diameter vs small diameter parts look might change depending on which ones you're envisioning as being the 1960's tech versus the 1980's tech. And a lot of people have been asking for a surface mounted computer too - maybe we can start giving those out high up the tech tree. Anyway, thanks for the work. This will be cool.

Absolutely true that this is *one* cause of it, but I've heard reports of it happening in other cases too. There's code in kOS that *attempts* to save the value of all variables in memory when the craft goes on rails, and then restores it when the craft gets fully loaded again. But this has never really worked ever since complex structures were added ages ago (it works on integers, floats, strings, and booleans, but nothing more complex than that), and it can throw uncaught exceptions. In its current state I'd rather see it disabled entirely since it doesn't really work anyway and at least disabling it would make it stop throwing exceptions. It's supposedly getting trapped now so the exceptions don't percolate upward but I'm still seeing complaints about the problem from time to time.