scimas

There is already a recent issue open on Principia's github requesting an API. But, given the mod's inherent complexity, I guess it will be a very long term goal at best. I would have liked to contribute to it, but I simply don't have enough experience with programming. Even someone who has experience will need to get familiarized with Principia's complete code, which I'm assuming would be a time consuming task. It doesn't mean that I'm opposing that request, but I understand why it may not happen. I'm really thankful that the devs give regular significant updates to the mod!

I had figured out a basic method to calculate slope at current spot, but your library does provide better functionality, thanks!

Simply removing that sentence should be good enough. The first two statements of the wiki are consistent with what the function does; it's only the last sentence that contradicts the first two statements. Another thing I need help with, has anyone figured out a way to obtain the local orientation of the surface, basically a normal vector to the surface of the celestial at current position? I don't need exact normal vector at every point, approximation over, say, about 2 m^2 area is good enough too. I want to try to improve my landing and rover control scripts using it.

Is there any possibility that the MOD function will be changed to calculate the mathematical modulus instead of remainder of integer division? Also, from the KOS wiki is not quite accurate. For example, what it implies is (-3) mod 5 would be (-2) - the mathematical modulo 2 with a negative sign; but it's actually (-3) - the remainder of integer division.

Is there any way to detect the current biome of the ship in KOS? As far as I can tell neither SHIP nor BODY has any reference to biomes.

You would also need to use inertially fixed burn then, otherwise the direction of the delta V vector would be wrong.

You're probably using the wrong 'version' for 1.2.2. The devs provide separate download for each of the latest version of KSP, ie one for 1.2.2, one for 1.3.0 and one for 1.3.1. If you mix it it up, KSP will crash on load. And Principia works only with the 64 bit version of KSP, so maybe you're using 32 bit. Or maybe your download got corrupted..

It should point you properly. Here's a code snippet that might help. LOCK rot_axis to VCRS(np, UP:VECTOR):NORMALIZED. LOCK new_dV to np*cos(15) + VCRS(rot_axis, np)*sin(15). rot_axis is the k vector, np is the v vector from the wikipedia article. You can eliminate the last term since we already know that k and v are perpendicular making their scalar product zero. So new_dV is your new np, lock steering to it.

You will first need to define what do you mean by 'up.' You either are near Kerbin and want to nose up as in away from surface or in orbit and then nose up might mean towards the normal vector, or many other things. In any case you will need another vector to determine where to point the ship. Let's say that it's the first case, away from ground. So node deltaV becomes your first vector and the predefined 'UP:vector' second vector. Their cross product (normalize it) will give you a vector that you can use as axis of rotation. Now take the deltaV vector and use Rodrigues' Rotation Formula to get the vector where you want to point your ship. Do remember that KSP uses a left handed coordinate system when calculating cross products.

Yes, it looks about the same thing. I will add my logs and save to that issue just in case they are useful.

Just came upon a System.NullReferenceException bug, but I'm unable to reproduce it. I had a vessel landed (flat on its side) on Mun. The only way to go was fire up engine and hope for the best. So I did. Within a second the particles for explosion showed up and KSP crashed to desktop with Principia logs showing NullReferenceException. I do have the save file and the logs, though not sure whether to create an issue on github.. Also, not sure if its related or not to Principia taking control of vessel as it leaves surface, but sometimes (usually after quick load when ships bounce on surface,) KSP fails to recognize that the ship is in flight. If you don't allow that bounced ship to touch ground, its state remains 'Landed' until it does touch ground, and thereafter its state is tracked properly.

@ebigunso @Pand5461 got it. Is it more consistent in showing correct values? And from ARP page "API for information reading and alarm acknowledgement." I think it isn't implemented in kOS though, is it? At least the Addon section of the wiki doesn't list it.

Thanks for the 'flameout' idea, I'm using something very similar to this code now! Though I didn't understand what you meant by Alternate Resource Panel, is that a mod or another structure in kOS?

Yeah, I checked, KSP does shows zero resources in the stage.. that's super weird. Guess I have to figure out other variables to write staging logic. kOS devs, please take 'fixing' this as a feature request if you can!

Is this a bug or intended behaviour? The resource values for a stage (STAGE:RESOURCES) are all zero unless the next stage has a decoupler. I'm running into a problem because of this. The context is this: I'm placing a satellite in orbit. The stages are as follows (0 - upper engine, 1 - stack decoupler, 2 - fairings, 3 - lower engine). When I perform a 'STAGE' command on launch pad, the resources in the current stage are detected as zero . And yes, I am waiting a full second before I check for the resource values. My script is basically staging once (current stage 3) and then staging again (current stage 2) because of this. Could someone confirm this either as bug or intended (and if its intended, I would appreciate if you tell me the reason too)? Thanks!

Ok, so it does persist even after the script has ended. Having another condition would help with it not firing, but it would bog down the CPU if I run multiple scripts one after another in a single session. I guess I'm going to use return statements instead.

Had a question about triggers and preserve. Does a when trigger with preserve persist after the script has ended? If it does how can I get rid of it, apart from toggling power to the CPU?

Alright, I tested some of this. It seems that Principia does create a single node. I was able to lock onto the node, the delta V vector and then execute it using standard kOS code! Although Principia's delta V vector keeps changing as opposed to the stock manoeuvre system, the time to burn remains same which helps a lot. But if that's a problem for someone, Principia provides 'inertially fixed' manoeuvres too. The only details I was manually providing was the burn time, but that can be calculated in the script itself too. What I haven't tested is whether it creates a single node and updates it for every manoeuvre in the flight plan or creates a separate node for every manoeuvre. Either way it should be possible to execute a complete flight plan with a single run of a script, assuming that the nodes are reasonably distant from each other in time!

Ah, I see. I had somehow totally forgotten/ignored that directions have those suffixes too.. and that makes my original question about the R function stupid too.

I don't understand.. If the R function does give rotations around the axes and not ship local rotations, why would changing the docs to reflect this fact break scripts? You aren't changing anything in kOS code itself, just clarifying the real working of the function in the docs. Same about the Q function, I'm just asking for clarity in the docs, not asking to change how kOS works. Because at least my method of learning any new programming language is to start with a tutorial, if one is provided, and then to look up any differemt/interesting/difficult things in the docs. I went from kOS tutorial to mathematics -> directions and found out that it doesn't make any sense, even accounting for the left handed system. Anyway, thanks for the clarification!

@eggrobin I had another question, when I click show manoeuvre on navball, does Principia create a single node and keep updating its values over time or does it constantly remove and add node according its calculations? I'm asking with kOS in mind, trying to write down a script that can execute nodes. The mod already has manoeuvre nodes defined and can get/set nodes in stock KSP. If Principia does create a single node, its really going to be fun playing around with flight plans that can be executed almost perfectly!

A simple improvement (at least concept wise and in my head, don't know about the actually difficulty involved in implementation) would be to enable editing of any manoeuvre in the flight plan. Whether to place the manoeuvres in the future of the edited one at the same time or to shift them (in time) by the same amount is something to be carefully considered. But I assume that leaving them at their own times would be easier. Have an 'Edit' button for a manoeuvre, when used all future manoeuvres go into a standby state. Once you click 'Done' or such, the future manoeuvres get placed one by one as the trajectory ahead is calculated. This would be a great QoL improvement. And I hate the word manoeuvre now.. ugh

Are the arguments of the R() function actually pitch, yaw and roll values as mentioned in the docs or are those rotations around X, Y and Z axis? If its the former, then there's something really wrong with my understanding of how rotations work. If it's the latter, please change the docs to say that. Please clarify the Q() function too. Are the args quaternion components or (x,y,z, rotation angle) where (x,y,z) would give the axis of rotation? I've spent entirely too much time trying to understand how directions and kOS direction operations work and I still don't think I understand it. In the end I started using cross products on up:vector, ship:velocity:orbit/surface and Rodrigues' rotation formula to get things done.

Are you on steam? If yes then you can get older versions by going to game properties -> Betas -> Previous version of KSP. Don't know what's the procedure for direct KSP buyers, aren't older versions downloadable?

It's not updated for 1.3.1 yet, but I guess the next version will support 1.3.1, at least their change log draft says so. They release updates every new moon, so the next one should be around 20th October.