xZise

Would the part stay half-full if you didn't fix the mass flow? Maybe then (for a future version) the last value should be omitted and it burns until it runs out of fuel. Oh and to the developer of the mod: You maybe should add markings so you can what type of booster it is (long burning or not). Although this might not be applicable when you can modify the burn profile. Okay I upgraded from 0.4 to 0.5 and the new B type boosters look nice. Although I'm missing a B to 1.25 m adapter and a B sized launch clamp. Fabian

As I said I don't want to diminish your great work. Especially the ghosting is useful (although I would have used little arrows at the edge of the navball, so you could show more than two markers without blocking the view on the navball). And although I like the DPAI quite a lot it would be nice if you only need one instrument, so I'm really looking forward to see docking instrumentation. Fabian

Ah okay. Hopefully you don't need to add that much parts, as it seems that with to many parts in the VAB it is very laggy. Especially I'm wondering about those 2× parts: Don't they work the same, but simply are two single parts in one, so you can already simulate them? Fabian

This sound awesome, although I'm not sure what do you mean with constant thrust: Doesn't the Isp change? Fabian

Yeah but that is my “problemâ€Â. When you press D, the navball beneath rotates to the left and your craft yaws to the right. On the DPAI it isn't inverted: When you press D, the “background†moves to the right (including the marker) and your crafts yaws to the right. Fabian

When you are starting and the 90°/E marker is on the right, you press D to yaw right. Of course the navball beneath is rotating in the other direction, that's why it's confusing (at least for me). And “don't think†is hard to obey: I'm adapted to the navball, and if I want to to the right there I press the button to go to the right and if I read the DPAI I have to inverse the “thinking†and this isn't working automatically (yet). Fabian

Actually I would love to, but I have basically no knowledge in C# or the KSP API. My computer is also not set up to develop plugins for KSP. But I did a quick look in the source codes of both plugins and it might work, but I want to test it first. So maybe I set up all that to test it.

That's the problem: When I want to rotate towards the marker, and lets say it is on the upper left quadrant I have to use S and A to rotate to it, instead of W and D. Which is pretty counter intuitive, because when you want to rotate to the upper left of the navball you would use W and D. Fabian

Yeah the rotational offset it is somehow „reversed“ compared to the navball. You need to press A to move the marker right and D to move the marker to the left, while W moves the marker up and S moves the marker down, while on the navball all movements are inverted. Fabian

Now I don't want to diminish how complicated it is to develop this, but isn't showing the correct alignment easy? Instead of showing your offset (like the DPAI does) you add a marker which you need to “hit†to be aligned. For example two crafts in equatorial orbits and the targeted docking port is facing south you add a marker on the navball at the normal vector* facing north. I don't know how to do this exactly, but when you know the direction the targeted docking port is facing add the marker on the navball where vector inverted does point. The more complex thing would be to show the lateral offset/movement, if that's it what are you talking about. And I personally think that can't be integrated into the navball as it is. And I haven't tested it yet, but it looks awesome. Especially the retro-maneuver node would be sometimes handy, when you placed the command pod the wrong way. Fabian *: Of course it is not always the normal vector.

I can't test it now, but I'm able to print steering. Or at least it works for the different axes (like PRINT steering:pitch), although I'm not sure if this actually the correct value. Fabian

But don't remove spaces in quotes/strings I don't know how the parser works so maybe the strings get sorted out first and then you can remove all spaces which are to much. I have to check if, but maybe it is possible when you "buffer" the variable: LOCK target_steer TO prograde. LOCK steering TO target_steer. IF ABS(target_steer:pitch - steering:pitch) < 2 AND ABS(target_steer:yaw - steering:yaw) < 2 { print "Aligned!". }. I personally would say stuff like this should be reported there: https://github.com/Nivekk/KOS/issues As it seems it is KSP's failure but I don't see why kOS simply but it into a (-360;+360) or [0;+360) interval prior to giving it to your script. Fabian

Double click on “Reply With Quoteâ€Â. Fabian

I'm with you on this one. A future kOS version should support something like SURFACE:RETROGRADE, ORBIT:RETROGRADE, TARGET:RETROGRADE. How about in your github? https://github.com/Nivekk/KOS/issues On another note, I tried to check for inequality with <> and != but both don't work. I guess it's because it's missing here but it looks like it's supported here and here. Also maybe you can add something to switch a variable from locked to unlocked and back? Like: LOCK steering TO prograde. UNLOCK steering. // This will fix steering to the current prograde vector but doesn't change LOCK steering. // This will lock steering again to prograde And I don't know if it is already possible, but is it possible to determine the targeted steering value from the actual steering value? So I can start my engines as soon as the craft is aligned correctly, because it takes a bit of time to orient to the targeted vector. Fabian

First of all thanks (?) for your reply, but I actually know what the different crosshairs do: green = lateral offset orange = rotation relative to targeted docking port direction → centered orange crosshairs mean both docking ports are parallel to each other; You only need to move sideways/forward/backwards to dock yellow = change in offset I'm pretty sure that the white lines (in LDC) display the same rotation as your orange one. There is no display (in LDC again, apart from the numbers) showing your required movement. But it's quite a time since I last used LDC. On another note I really miss the camera part of it. I would love to see DPAI having a camera too. Fabian

This depends on how you would define it. It was only a suggestion by me to add into the mod, so it is NavyFish's responsibility (if he decides to uses this) in which direction the chart goes. I personally meant with higher going towards the center. Actually there could be a silhouette of a docking port added to help with determine in which direction the graph needs to be moving to get better results. Afaik the white lines in Romfarer's mod are the same as the orange crosshairs in the DPAI, and if you look closely also the LDC is slightly off to the left and top. Maybe the DPAI scales differently and exaggerate "more" than the LDC. What I'm wondering if you could add an option to mirror the DPAI (either only one axis or on both axes). It's a bit confusing which direction you have to rotate to move the orange marker in the right direction. Fabian

Ah! Interesting approach I'll test it. It's not finished so I can accept when I have to use 0-x, as this will most likely get fixed. Fabian

Hi, is there a way to check negative verticalspeeds? I tried the following code: SET -pref_v TO -altitude/-100. IF -verticalspeed > -pref_v { … }. The minus signs are only all possibilites where I tested it. Of course I tried it only with one sign at a time. I always get “Error: Unrecognized term: ''.†(except for the first minus, there I get only a syntax error). Now how do I check negative verticalspeeds variably? Fabian

It's the closure distance to the target where the distance/velocity gets greater the higher the the lines are. The green line indicate the distance (like the green crosshair) and the yellow line indicate the velocity in direction to the target. It's only an idea trying to visualize how far you have to go forward to connect to the other docking port. Fabian

Ah okay! Wouldn't be nice if there are graphics for this too? For example something like this: Fabian PS: Now I'm not color blind, but I guess switching between red/green might be hard to see for some color blind. Maybe draw them differently? Dotted?

Hi, is there a way to determine the velocity in the top/bottom direction? There is the movement left/right/up/down relative to target but not in the third axis, and I don't mean the vectorial (shortest) distance. So it is negative when you are behind the docking port. At the moment you already can see THAT when your lateral displacement lines are red, but you can't see if this is changing and you have to counteract. Fabian

Now as far as I know, only feet/inch use a 1 to 12 ratio. Almost any other unit uses another factor like yard/feet = 1/3. Now statue mile/feet = 1/5280 does use a multiple of 12 (440) but how often to you count in 440 ft steps. Both tons (1 short ton = 2000 lbs, 1 long ton = 2240 lbs) don't have multiple of 12. Now I don't know all imperial units, maybe there are values in between them to make them multiple of 12 but these are the most common. The biggest problem with this 12 factor is, that our numbering system is usually decimal. The SI units would work in a duodecimal system (1728 (base 10) m = 1000 (base 12) m = 1 (base 12) km) but how many really use the duodecimal system. The same applies to binary prefixes (1024 B = 1 KiB, 1000 B = 1 KB): You can faster say that 12 265 843 B ≃ 12 MB by simply cutting 6 digits away, but to convert it into a binary prefix it not that straight forward. But as soon as you have the number binary, you simply can cut 20 bit away and get your MiB value. Also 1000 or 100 has a lot more divisors than 12, okay granted not 1/3 or 1/6. Depend on your scale: A scale with a spring usually measures only Newtons and convert it into kilograms with a fixed factor. A modern scale COULD measure the default weight (for example the tray) and then can deduct the local gravity, although I don't know if any scale does this as all are used on Earth. But when you have a scale were you put a weight on another end to counteract the probed mass it measures a mass. [edit]Okay the type of scale where you place a mass on another end is then called a “balanceâ€Â. So it appears that a balance measures the mass and the scale the weight and simply label the measured value incorrectly.[/edit] Fabian Fyi: hPa is totally legitimate as hecto is the prefix for 100. hm would be 100 m.

Hey, can you maybe link to the posts in the op? I'm wondering at what altitude the craft achieved the velocities. With 2340 m/s you need at sea level 26.8 minutes to circumnavigate Kerbin. At 20 km altitude (which is the maximum altitude I usually fly, but of course not as fast as the rest of you) you already need 27.7 minutes. And at 50 km altitude you need 29 minutes. I know it's only a difference of 2 minutes but I wanted to add the results from here in the wiki and tried to explain how fast those velocities are (when you only need half an hour to go round the complete planet). Fabian

Hi, I got different values for Moho, Eve an Bop. For example Moho: ((6.674e-11*2.5263617e21*1210000.0^2)/(4*pi^2))^(1/3)-250000=18173165.1 (from Moho's center not surface) You can see a complete list at http://wiki.kerbalspaceprogram.com/wiki/Stationary_orbit#Altitudes Fabian

This measurement was taken at the northern pole pit? Fabian PS: I love how you could do science in KSP. Nice work!