Respawn

love the mod. ^^ Lunched my 24 satellite Gps grid last weekend in my remotech save. It turned out great. -> Some images from the tracking station from differet angles with and without the remotech connection lines. XD Launched the satellites 4 at the time on a carrier rocket into a 60º inclined waiting orbit at 1 hour interval (60º of kerbins rotation), making it 6 launches. The waiting orbits was a 45 minute orbit with a PE of 83845.85m and an AP of 450513.15m (roughly ). After launching all satellites into the waiting orbit I started releasing 1 satellite at the time at AP and circulized into a 1 hour circular orbit. And deorbited the carrier rockets for a clean finnish. Absolutely love the preplanning that can go into all the orbits and antenna ranges, line of sight, battery charge duration and solar recharge rates when. when you combine this gps mod with remotech. Tnx for this mod! <3

Rosetta was featured as part of the Von Karman Lecture Series at JPL yesterday heres the video

heheheh! Check out this one. Link: wigglewiggle wiggly enough for you? hehe

Hehehe. I found that making a stable system is pretty hard.

I found this crude but fun little gravity sim web page thingy. where you can mess around with planetary bodys. http://labs.minutelabs.io/Chaotic-Planets/ I've now spent a coupple of hours messing around with it. I made a cool semi-chaotic 4 body system but seemes pretty stable. with 2 central bodies orbiting each other counter clockwise and 2 lighter bodies orbiting the 2 central once clockwise, while orbiting each other counter clockwise. Link: semi-chaotic stable 4 body system I'm interrested to see what you guys can come up with.

I've played alot of mmos and as a result had many nicks, characters, usernames. but Respawn or something similar has been one of the few "names" I keep comming back to. One of my first AO characters was called respawn, one of my Aoc characters was called Respawn allso had an assassin called Despawn, I had a coupple of characters in wow called Respawn, Darkspawn, Warspawn, Spellspawn, and so on, and plenty of other similar nicks in other games. Respawn tend to be one of the first nicks/usernames taken in most games or game related forums so I often have to settle for something else unfortunatly. First time i used Respawn was about 14 years ago in some random fps.

Yeh.. I've been experimenting a bit now on different ways to unwrap some parts unfortunately i'm pretty new to blender and this shows in my parts. =D I'm a numbers guy, and when drawing in any program that has a "command line" type of ui option, I tend to type instead of using my mouse pointer. I'd like to specify exactly how long my lines are and exactly what angle and so on directly instead of roughly estimating while moving my pointer around. I've been using auto-cad and similar programs for designing mechanical parts, electrical layouts and schematics, on and off for about 15 years. My ocd is getting the better of me when messing around with what seems to me to be rough estimates in blender. *? Might not be strictly necessary for ksp parts but still ..preference. I'm still learning how to use blender though, so i'm not excluding the very high probability of being able to find ways to improve. hehe

hm.. most of the light grey part of the engine is one continues island with about 5-10 pixels of coloring beyond the uv lines, but the yellow/black striped part is about 10 to 15 px beyond that. don't think that should be to close. Im looking at the UV map again now and somethings weird about it. In my standard viewer it looks as one would expect but when i open it in my editor the alfa channel seem to block anything beyond the uv lines unless you set it to ignore the alfa channel. hmz.. BTW: I'm using an ancient version of paint shop pro. (PSP5.0) hehe.. from back in the days when 1.4Mb floppys still was the thing. a rare gem of an image editor ^^ You sortof have to define your own filters. ......Yeh think i found the problem. Looks like Paint shop pro 5 decided to layer the information outside the uv lines below/behind the rest for some reason, and i'm just guessing blender/unity didn't like it and decided that, that's a black color And it indeed is as you say it's picking the pixels right outside the uv lines when i zoom far enough out. So a paint shop pro 5 bug. ..Great. Although my other texture maps seems to be ok. hm.. User bug then probably. doh! Never mind..

I just started making my own parts for ksp, and i just made my first engine. To my surprise It actually worked great the first time i loaded the part up in ksp. Just guessing my way around in blender and unity. However when I zoom out ingame these black lines appear on my model. and they disappear when i zoom back in. All though this model was just to figure out how to make an engine work, I'd like to avoid those lines in my future parts. I thought it was a problem with the texture but now i'm not so sure, texture is .mbm but was made as RGBA png as none of my other parts have encountered this issue using the same file types and same coloring techniques The texture is colored way outside the uv layout, so my guess was maybe something bugged in the conversion process .png to .mbm with the alfa channel ? Being able to avoid this at an earlier stage then only noticing it hours into a game session and zoomed out would be great I have no idea how .mbm files work that makes it appear to change with range or if its something else, I'm new to this. I bet someone here recognize the problem right away. Any feedback is appreciated.

Yes if you set specific colors to be transparent KSP does read those colors as transparent for that flag. But "No Data Transparency" does not appear to work and will simply be replaced by white. Here's a test I did where i colored the background green and set green as transparent. As you can see on the cupola its transparent and on the flag its replaced by flag texture.

If you want to push rather than pull, try with more sas torque then you think you'll need and then double it, and have a ridged connection between your rocket and your claw, and you'll find the spin easier to counter. I had a docking port between my rocket and the claw on my first asteroid. My thinking was that i could leave the claw there and use it as a docking point for future missions, made for some funny moments, but very inefficient burns as most of the fuel went into counter spin as you might imagine.

I'm messing around with rss and rt2 atm, and i had a similar problem. The sun got in the way just as i was about to do my capture burn. However my plan to get around the problem is to set up 2 relay stations at (what would be) L4 and L5 of the kerbin-kerbol L-points. 60º ahead and 60º behind kerbin in it's orbit. I know the game doesn't simulate Lagrange points but those two points are stable sun orbits in the game and i'm allowed to pretend. ^^

May I suggest a change the accuracy of the display value of the orbital period? I've been messing around with rss and rt2 and when the orbit period is longer then a day KER is only showing days as a decimal which is ok i guess but rounded to 3 significant figures, that's an error bar of about +/- 40 sec. This might not be a problem when playing with the stock planets but with the larger planets and speeds with RSS it's very noticeable. In the worst case scenario this inaccuracy could result in a orbital migration between 2 satellites of half an orbit in 554 days in my case. So whenever I want a higher orbit accuracy than that I have to do the calculations myself. 5 significant figures would give an accuracy of slightly less than a second. Or better yet, make it display the orbital period like the other time values showing dd:hh:mm:ss could this be possible?

If its a distance problem i recommend making adjustments to the "GameData\Remotech2\RemoTech_Settings.cfg" file. The second line should say something like: RangeMultiplier = 1 If you change this to 2 you'll effectively double the comm range of your antennas. I changed this number to get Remotech2 to work with for my real solar system modded save, and it works great.

well.. Just downloaded the RSS mod an hour ago to check it out for my self. Stationary orbit is at about 35,777,650 m altitude if you still wanna know. Holy crap, the dv requirements is just silly with this mod. built a craft with 12500 dv, and spent it all just to get to stationary orbit to double check my result. Edit: In RSS: Kerbin / (Earth analog) rotational period: 86164.0916 sec radius: 6371000 m GM: 3.98161x10^14

Orbital r = cuberoot( (t² x GM)/4pi² ) To use this formula to get a Synchronous orbit you need to know the mass of the planet, and how long a day is for that planet. t is in seconds, so if your planet rotates once every 6 hours, that's 21600 sec GM is Newtons gravitational constant times the mass of the planet. Not knowing how this changes with RSS i'll show you using the stock numbers. Kerbin GM would be roughly 6.67384x10-¹¹ x 5.2915793x10²² = 3.531515x10¹² multiplying (t²) 21600² sec with (GM) 3.531515x10¹² and deviding this number by 4pi² and then take the cuberoot of that number you'll have your orbital radius. (3468722.89m) now if you want the orbital altidude simply subtract the planets radius to get your number. (in my case: 3468722.89m - 600000m = 2868722m) probbably a coupple meters off due to rounding errors.

There's always a "window". (There's always a way.) No need for perfect alignments, unless you're planing something special. It totally depends on the planing and type of mission. I usually stick to rough estimates. +/- 30 degrees no problem. If it's way off I either timewarp or change my plan. If your delta V budget only allows perfectly executed optimal transfers you'll have to adhere to those plans or end up not completing your mission. Having a more flexible plan with more than one backup plan allows for way more interesting and fun gameplay sessions in my experience. Although doing something perfectly as planed can be rewarding in it self.

Try docking 12 ports at the same time.. I made a huge fuel tanker to send to the jool system, just because.. reasons.. Docked it together in kerbin orbit, the last 4 corner pieces/crafts had 12 docking ports each in multiple directions. Its totally doable, just requires a lot of patience. I'll suggest reorienting your "puzzle pieces" normal/anti-normal of your orbit, so you don't have to keep re-aligning your second craft too often as you might prefer a slower approach then usual. Point your crafts north/south when in equatorial orbit, makes it way easier. Good luck.

Great tool Awesome work Lando.! Downloaded v2 about a year ago, but didn't really use it. Just downloaded the 3.1 version a couple of days ago and have been messing around with it since. ^^ Adding any sort of module seems to generate errors. The .cfg file is easy to fix afterwards anyway so that's not a problem. The texture template is still a bit wonky, left side is slightly skewed and its a bit too narrow, and the end cap is a bit off center for the bottom of the cylinder model, but seem to fit the top well, except the top is slightly rotated. Here's a look at a fancy texture i made for my planned Jool station Just need to do some adjustments before i send it out there. Here's the texture if anyone is interested in using it -> http://i.imgur.com/p3DdjJp.png I allso made a metal container box texture thingy for the cube model that turned out pretty great. -> http://i.imgur.com/kYen7ES.png If there's a new version in the works, I'd like to request edge smoothing. If that's at all possible. ?? That would be great. Again, Awesome job, love it.

That's hilarious ! hehe! I-beams have a known tendency to do weird stuff to your crafts, phantom forces for no apparent reason. However i had a very similar base module do almost the exact same dance on Duna, after some time i realized one of the legs was "broken", and sas trying to correct for some instabillity, dunno how that happened but got fixed by a simple kerbal eva repair.

Judging from your stats display, you start off with 2.22 TWR, I'm guessing you're wasting alot of fuel fighting drag when you pass about 1000m after launch. I don't use MJ but I bet there is an option for limiting thrust to terminal velocity, if not try gradually throttling down until you're out of the densest part of the atmosphere, or until you drop the solid rocket boosters, whatever comes first. Then throttle back up to full. However if that's not your problem then I would consider rebuilding the entire rocket. It does not look very efficient.

shift + rotation keys

I have it written down in my personal notebook along with alot of other ksp related numbers. In my notes i've written down 5.29229x10²² which does not fit the wiki, but is the number that i've used. Anyway we do know the mass of the planets, the numbers are available ingame. In map view while focused on planet, there's a tab on the right displaying relevant information. The mass of kerbin listed ingame is 5.292e+22kg and GM is listed as 3.532e+12 Not knowing to what degree those numbers are rounded, only using Kerbin as a referance, you can say that the gravitational constant ingame is somewhere between 6.6726e-11 and 6.6758e-11 G(irl) falls within those numbers and in either "extreme" would not make much difference. so.. (for now at least, until the devs decide something else.)

sry for not staying quite on topic Someone mentioned that the gravitational constant G might be different in the kerbal universe, i'm just saying it's not likely. @velocity : all i'm saying is: that the formula works in-game. So i can conclude that the most likely reason is that G(in-game) = G(irl) If G(in-game) != G(irl) then some of the other units definitions in that formula would have to change. (since it does work) Along with alot of other units used in other formulas due to the first change. If you assume they changed G(in-game) by multiplying it by 10. (Using my formula would result in wrong altitudes, whitch it doesn't.) There are however 2 ways you can modify unit definitions for the example formula in my previous post to still give me the correct answers: 1'st way: you could change the definition of (in-game time) from "1(kerbal)sec=1sec" too "1(kerbal)sec=0.316228sec" but then you would also have to change the ISP definition to keep dV "m/s" consistent. Which sounds ridiculous. 2'nd way: the in-game mass-unit 1 could represent 0.1 tons instead of 1 ton. Which would give me the correct answers. But if 1 mass-unit is 0.1 tons then 1 kN(ingame) units listed in engine descriptions would have to represent 0.1kN for "f=ma" to still be true. Which does not make sense. @garek : in that example it would not cancel out but feed back on itself to give a bigger error.

The kerbal universe has the same gravitational constant as our universe, i'm pretty sure.. I've been using it to plan my orbits and intercepts, and the answers i get is exactly right (Depending on how many decimal places i use.) i.e: if you want an orbit with a specific period and want to know what altitude you need. cuberoot(("orbital period in sec"², times gravitational constant, times inertial mass of the planet) divided by (4pi²)) you get your desired semi-major axis. simply subtract planets radii and you have your orbital altitude for circular orbit. And this holds true for all planets and moons as far as i've tested. If you redefine G you would also need to redefine mass and distance to end up coming out with the same numbers. If G is 10 times higher the inertal mass would be 10 times higher so either the mass number would have to be 1/100'th or 1m would have to be redefined cuberoot(1/100) and if distances is redefined kN (thrusts) would have to be redefined, and probably alot of other things i can't come up with atm. Redefining G has a lot of consequences if you still want your standard real world math formulas to apply. So instead i believe they just said hm.. lets make it smaller and just say it's more dense.