Kertherina

Sorry, i don't understand what you are saying. Especially the part where you say attitude vectors don't change, since that is exactly what i want to to: transform (rotate) the vectors into a different coordinate system. But i can't just pick any. To consider the roll around the longitudinal axis you have to pick a special vector as a basis vector for the local coordinate system, which is where the port (or starboard, up or down) vector i am talking about comes into play. With forward and port as two axes you can get the third one with the cross product, but you need at least two vectors for an unambiguous representation of the coordinate system. So the question is, how exactly do you get / update the port vector? Again, my only guess so far is set it up when simulation starts and then rotate it every time the rocket rotates, where it will accumulate an error over time.

The problem is that it is super easy keeping track of forward direction, but not the roll around the longitudinal axis. Angles are bad because they break down for certain situations (if you fly perfectly upwards,what is your roll?), you can do it with a second vector perpendicular to the forward direction though, which is port / starboard, or up / down what i have been mentioning up to now. Still 3 numbers, but doesn't break down if it's perpendicular to axes. Either way the same questions, how do you determine these extra numbers? For the angles you'd need the axis vectors first, so you're again where i am currently stuck because how exactly do you determine the port vector for example? You can't just do a cross product of forward direction with another basis vector because the basis vectors is what you have to determine. And to reiterate what i have been saying so far, the only method that is halfway decent i know so far is to initialize the port vector (or starboard, up or down, it doesn't matter) and then rotate it each time the craft rotates, and i am wondering if this method is the best out there because floating point errors will accumulate over time.

Thanks, but dot and cross products are not the problem. My problem is how to determine / update a second vector like port / starboard, up / down for a complete description of the local craft coordinate system. Currently i just have the forward direction vector. If i have the second vector, i know how to get the third vector and all the angles for the rotation. I don't see how an extra local coordinate system would help me here, directions would be the exact same vector as in the global fixed system, only positions would change but positions are not a problem. The only reason to use this would be accuracy, but i am already using 25 digit accuracy for the position exactly because i did not want more coordinate systems than are necessary. The same problem as before: Where do i get the starboard vector from? It's the negative of the port vector so if i have one, i have the other, which doesn't matter because either one would be enough. I could again set up the starboard vector at the start of the simulation and rotate it with the craft, getting floating point errors over time. Sorry, I really don't know how else to describe this problem. Just to make sure, it is clear how you need 2 vectors to fully describe the attitude of a craft?

Sorry, let me try again. The problem is in the step "move the axes as needed", for which i would need to know how i have to rotate each axis. For that i have to know the three basis vectors in both coordinate systems: x,y,z, and the new x',y',z'. Now, i have those vectors for the fixed coordinate system since that is the main coordinate system the craft also uses for position and direction. Then, i have the vector for the direction the craft points at ("forward"). But that is only one axis for the new coordinate system (z'), i do need at least a second vector (y' or z'). With a second one the third one would be the cross product of the other two, and then with all vectors i could then determine the angles for the rotation with the dot product. That is where the port ("left") vector comes in as the x' axis. But how do i get this vector? Without the axes of the local coordinate system of the rocket since that is what i want to determine in the first place, there is no way to just calculate them with a cross product or something. The only way to determine the port vector i so far know of is to manually set the port vector at the beginning of the simulation, and then each time the rocket rotates you also rotate the port vector. Which would accumulate floating point errors over time, which is why i am unsure if this is the way to go. Was that easier to understand?

Hi peeps So, i recently started writing my own simulation / game and i am hitting my first real barrier. I have two coordinate systems. One is fixed, with it's origin at the center of the sun at the time the simulation starts, and the other one is relative to the craft and thus also constantly rotating. (I would love to do all in one coordinate system but creation of crafts with wing and engine positions and orientations would get really ugly.) To transform a vector from the global c system to the local one i obviously need a description of both systems. I have the x,y and z vectors of the global c system of course, but the problems begin with the other vectors. I have the direction the craft points at, but i would need a second, perpendicular vector (third vector would be cross product of first two) since how the craft is rolled matters for the coordinate system and thus the transformation. I plan to use the port ("left") vector, to give me "up" as the cross product of "forward" and "port". Now, my problem is: How do i get the second (i.e. port) vector for a complete description of the attitude? The only possibility i came up with so far is that i set it up manually once when the simulation begins, and then rotate it whenever the craft rotates. But that sounds quite dirty and i don't know if the accumulative error would not get noticeable after a while (although i do use the GNU MPFR C++ library for arbitrary precision arithmetic so i could just use more Bit if the error gets too big?). An alternative might be introducing a value (angle) for roll and then get to the port vector with some rotation and cross product magic, but the problem with an angle would be that it breaks down for certain situations (flying straight up / down) so i really want to avoid that if possible. So, any thoughts on how to tackle this issue? (If you happen to know how KSP handles attitude that would of course be nice to know too.) I hope i could describe my problem clearly, if not i apologize and i can try again.

After having rescaled the Mk3 parts for my Space Shuttle recreation, adding heat shielding, real fuels integration and life support (made it 2 weeks for now, it is surprisingly hard to find data on how long the life support on the shuttle lasted), here is my config for Mk3 Parts: Dropbox Download Most values are definitely not 100% accurate, especially masses (especially especially the fuel tanks) which i basically just guessed so that it gives me a realistic empty mass for a shuttle (at least that means it can't be too far off), if you notice something off please let me know

Hello again. I recently finally figured out how to also get roll of the ship, now i can start to write my own PID controller Many thanks to all who helped me in the past! I did run into a bug after updating to the current version. I have a cfg that adds the kOS module to every command part to avoid having to add the physical kOS processors with this code: @PART [*]:HAS[@MODULE[ModuleCommand]]:Final{ MODULE { name = kOSProcessor diskSpace = 10000 } } It used to work perfectly. After updating kOS, when i try to launch something with a probe core i get a weird bug: After getting something to the launchpad (even only a probe core) my orbital velocity is 0 and instead i start with surface velocity of 400 m/s (Realism Overhaul). It doesn't move, but the Navball shows these velocities. If i activate an engine the craft accelerates as if there was no gravity holding it back, also heating acts as if i was really going at the 400+ m/s, so all kinds of strange stuff happening. Having a probe core without using the cfg that adds the kOS module to every command part and a separate kOS processor part works. Also, command capsules don't produce this bug which is what confuses me even more. Obviously, this is not the end of the world, i am mainly curious how something like this can cause a bug and want to let you all know. And for the record, i am using a lot of mods, list here.

Hi, i have a problem i haven't found being mentioned in the last couple of pages. The problem appeared when i updated TweakScale from 1.44 to 1.47, deleting the old files in the process. Going back to 1.44 fixes it. The problem is twofold: One, i get ridiculous masses when upscaling parts, like here: Link. The mass increase for one step gets larger than a factor of 1000. Two, when i upscale a part and then downscale again the mass is still nearly as high as it was upscaled. By continually up- and downscaling the mass will get even more ridiculous. After a few experiments this problem seems to appear only in mod parts though, stock parts act normally as far as i am aware. Also, i am using a lot of mods including RealismOverhaul, (hopefully complete) list here, so it may be some kind of mod issue. I am wondering though if this is a problem only i am having. So, anyone else got this problem? Any suggestions as to what the problem is? If this problem didn't come up before i can delete mods to see if there's a conflict.

Speaking of OpenGL, i for one can only run it in OpenGL. When i use DirectX KSP crashes because of memory usage.

Thank you for that hint, sadly i'm still stuck. I feel like i am overlooking something very obvious :/ I used two different approaches so far. One, i used the VANG function between SHIP:FACING:VECTOR and SHIP:UP:VECTOR to get pitch and similarly got the heading, but since this approach uses vectors there is just x,y and z but no roll information to work with (or am i wrong in that and just not seeing it?). (Link to script here) The second one is the approach from the tutorial, though again there is no roll information (that i can see) since only vectors are used, and at the end of the tutorial it uses the roll information included in UP to lock the steering to an attitude with a defined roll value. I don't see how doing something like in either of those two approaches with the up vector from the vessel and the up vector of the body to get the roll since i'd have to again use vectors and thus only get x, y and z information but not the roll. Sorry to bother you again.

Hello again, i have another problem. I'm working on a custom steering algorithm now since LOCK STEERING is not working for my RSS rockets and i am stuck. I have figured out how to determine the real pitch and heading of the craft from "SHIP:FACING", but i don't know how to get the real roll and without the roll angle i can't use raw controls. After several hours of trying stuff and googling / looking in the forum i am near giving up, so any help would be very appreciated Thanks in advance for any suggestions~

Thanks for your answer Speaking of Mechjeb, i for one would love to be able to use it with kOS to steer but as far as i know this is not possible, is that correct? Sounds great to me. Would it be hard to implement? Also, anyone who doesn't want to use an existing steering function could still write his own.

I have a problem for a while now with the steering in kOS. Most of the rockets i build that also fly perfectly well with manual control are not steerable with the kOS "lock steering" command. Raw controls with ship:control:yaw work. Gimbals / RCS fire in all directions, the net rotation is near zero and if non-zero random. Here is a sample script, here is the rocket. As you can see in the script, i fix the problem for the launch by using raw controls for the gravity turn, but as soon as the program gets to the first "lock steering" command i get the problem as described. Here is a video showing the problem, at 0:47 i deactivate SAS with "lock steering to up" and the gimbals go wild. Flying with SAS without kOS works fine, flying manually and with kOS raw controls works fine, only with "lock steering" i get this problem. It's also the same in vacuum, and for small probes (my first guess was that it had to to with rocket size / mass but seems it isn't, had a small probe recently with decent RCS and i had the same problem). An example for a rocket that does work: Rocket Script There seem to be a few others with the same problem and i read somewhere it might be due to the lack of SAS torque. I play in RSS, so SAS is both near useless and i don't carry any extra with me so i rotate with pretty much only Gimbal and RCS, could this be the problem? If so, is there is a way to fix this problem or will kOS get fixed to be able to function with RCS / gimbal? The only solution i could think of so far is custom steering algorithms based on ship:facing and raw controls but i don't really want to go down that road.

Since you start with only unmanned tech that would make the early contracts pretty much impossible if you have to use manned vehicles. I struggle with funding since i can complete barely any contracts. Also i tried again and i got the contract for launching a vessel and leaving the atmosphere, only the 5km contract wasn't fulfilled and then it disappeared. Also, if you have to manually recalculate every altitude at which i have to test parts i consider this a bug of RSS (or other mods that interfere which i just haven't realized yet) and besides reporting that i also want to know if others have the same problem. As it is career is pretty much unplayable or at least not fun any more for me.

Funnily enough i didn't fulfill the 5km contract with an unmanned rocket that went up to 30km, but i got it with a manned jet at about 17km. No Idea what's going on there. Also i didn't fulfill the requirement of flying at a certain altitude in other contracts to test parts (well, the one i tried so far to test a jet engine at about 17km) or the speed, both were in the margin that was given in the contract but they weren't checked off and i didn't fulfill the contract when i ran the test anyway. EDIT: Only noticed later i got no messages at all for completed contracts, so i probably just missed that the rocket got the 5km contract.