Stratzenblitz75

Alright, after reviewing your design, I see some areas where you can make improvements. For your first stage, it doesn't look like you have enough wheels. Evenly supporting your craft is very important for stability, so try to distribute your wheels evenly to balance the mass of your speeder. In the case of your first stage, add some more wheels to the back to support the mass of those three vectors. Also, you'll need some fins on your first stage to keep your craft going straight. This is because the ablative fairing at the front creates a lot of drag and will tend to cause the craft to flip. This true of all of your stages. These two adjustments should get rid of the side-to-side wobbling you see at the start. Also, giving your vectors more gimbal can help with stability. That said, right now, your final stage needs the most work. First, I suggest you opt for using 3 or 4 wheels instead of 2. You can get 2 or even 1 wheeled designs to work, but they take far more effort to balance properly. Having at least 3 wheels will ensure your craft's stability without sinking a ton of time into balancing its aerodynamics. Additionally, you need a tail to keep your final stage going straight. Once again, this is because of the drag the front fairing produces. I'd suggest using a rearward facing fairing plus some control surfaces to keep it pointed straight. If you want to use seperatrons for the final stage, you need to clip them into a fairing or otherwise they produce an insane amount of drag. My favorite way of doing this is to angle them by 15 degrees, and attach them to an octagonal strut to create a ring of outward angled seperatrons. You can then place this assembly inside a fairing so that just their nozzles poke out. This system is especially useful because you can simply add more rings if you need more thrust. If you want to avoid clipping of any kind, then don't bother with seperatrons; use only vectors because they have the best combination of low-profile and high thrust. One more thing for your final stage; make sure the flap you have mounted to the bottom is deployed upward slightly, but not too much. At high speeds, you will need a down force to keep your craft on the ground. If its too low, your craft will easily bounce off the ground. If its too high, your craft will be smashed into the surface. It is a fine balance so you'll have to do several runs to find the right angle of deployment. In general, make the "show aerodynamic forces" option your best friend. This handy stock feature allows you to see what parts are creating drag and lift, and how much. I found it invaluable for locating high drag parts, and either replacing them or adding fins to counteract their drag.You can enable it with F12, or through the debug menu. Hope this helps! BTW, what was the highest velocity you achieved with your design?

There's two main techniques I use to make my craft more stable. For one, reduce the friction control on the wheels. In KSP, the friction control is wholly incapable of handling high-speeds so you need to set it to as low a value you find tolerable. For all of my runs, I had the wheel friction control set to 0 so that it wouldn't interfere with the performance of the craft. Of course, without friction control, your wheels don't get any grip so you have to raise it again when going slow. The other technique is downforce. When going fast, you will need some force to keep you pressed against the ground so that your car doesn't become an airplane. For this, I find flaps very effective because you can fine tune their deployment angle. If you're willing to share craft pics, I can give you more specific advice. Hope this helps!

Hey everyone! I want to thank you all for giving your inputs in this thread. I've certainly learned a lot from the information you've brought to the table, and the ideas you have given me. It is because of your inputs (@suicidejunkie 's suggestion in particular) that I've managed to break escape velocity with a stock land-speeder: You made this video possible! -Stratzenblitz75

Today, I went fast. Faster than I've ever gone before:

Yes I did. Turns out, the physics delta makes no difference to the max speed. The only time it does make a difference is when the FPS is very low (10 ~fps), and the physics delta is high (0.12). In this case, you will experience the bug much sooner. I believe there is some collider below the surface that instantly destroys anything that touches it. That said, I've managed to get around it sometimes. On a few runs, I've had the craft fall through this collider into the ocean. Its very inconsistent though. I don't think this is possible. In stock KSP you can't switch vessels while "moving over the surface". So, I just got around to testing this and YES. A lower terrain quality does increase the maximum speed reached significantly. With this knowledge, it should now be possible to break escape velocity over the surface.

10,000 subs! You know what that means; time for another sub special!

Today, I sent a station to Eeloo:

Here's a land speed record for ya: 2490.3 m/s. Completely stock.

Over my time of playing KSP, I've had my fair share of bugs. But none of them come close to a bug I encountered on one of my Laythe missions. I honestly have no words...

Thanks! The propellers on the planes are not your average propellers; they have a unique bearing that allows them to survive time-warp/quick-loading (essentially, they use linear RCS ports to act as an axle, and 1x1 structural panels to hold it in place. I've found that this configuration is very resilient against time-warp. Although, it has some problems with high-g maneuvers.) About the splashdown: the carrier splashes down at about 50 m/s, with ~10 m/s of vertical velocity. This is within the impact tolerance of the MK3 fuselages so they cushion the impact and everything survives. Also, I've found that the indestructible parts cheat does not work against water for some reason. When I was testing submarines for another video, I found it quite infuriating that I couldn't just chuck them into the water with alt-f12 for a quick test.

Here's an eve aircraft carrier. Also, seems I forgot to post my last video:

Today, I landed a stock aircraft carrier on eve.

Interesting idea! I will give it a shot and let you know how it goes. Indeed, it is relevant. Its another instance where a mod changes how the stock game loads the colliders. In this case, Bradley used the better time warp mod's slo mo feature to get around the stock limit. But why does this slow-mo work? Stock time-dilation does not have this effect; during my low FPS runs, the time dilation slowed time to a fraction of normal speed, but this had no effect on the top speed reached. Perhaps the mod maintainer, @linuxgurugamer, could give us some insight?

Alright, the results are in for Laythe and Minmus! I simply repeated my first procedure for both of these planets. For Minmus, I had to build a new craft with downforce thrusters in order to keep it from flying off the terrain. However, the mass and acceleration is the same. Here are my results as compared to Kerbin: Applying the limit calculation, we find the speed at which new terrain colliders stop loading are: For Laythe: 1,148.34 m/s For Minmus: 1,103.12 m/s Very interesting... It seems that the speed is similar for both Laythe and Minmus, but not quite the same. They are both over 200 m/s slower than on Kerbin. Any ideas on why this could be? Interesting! Although, that post was over 4 years ago. I wonder, have the terrain colliders changed since then?

Okay, I've conducted some tests and unfortunately, the other craft does not seem to be affected. HOWEVER, I could only get with 1000 m of the craft due to my lack of guidance skill. As a result, while it was loading the craft, it was freezing it in place. If I could get within 200 m (Which, I think is the distance where it unfreezes a craft touching the ground), we could determine this conclusively. You might be onto something with this. Unfortunately, I did not gather enough data to support any conclusions. Literally, this is all I got: --- Laythe --- Mass: 27900 Thrust: 4000 Acceleration: 143.369 HDG Velocity Distance Time 0 1757.5 10800 12.2744 90 1683.5 9900 11.7518 180 1777.3 11100 12.4437 270 1689.5 10000 11.811 --- Minmus --- Mass: 36045 (Extra mass for downforce thrusters) Thrust: 4000 Acceleration: 110.972 HDG Velocity Distance Time 212 1579 11200 14.2075 231 1637.3 12000 14.7061 250 1630.3 11900 14.6447 270 1585.4 11200 14.2075 As you can see, I just tested various headings to get a general idea of how the terrain collider's behaved on these planets. If you compare the acceleration vs. final velocity of these runs, to the runs conducted on Kerbin, you see that the top speed on Laythe and Minmus is slower: Acceleration Kerbin Laythe Minmus 143.369 1922.1 1777.3 NA ~110 ~1870 NA 1637.3 Not sure if you can draw any more conclusions from this, but you are welcome to try. I'll go perform some more rigorous tests and get back to you. Do tell! I haven't done much experimenting with part-to-part collisions so I'd love to know more.

Yes! Indeed it is possible. I've tried this on laythe and minmus and got some interesting results as well. It seems that the speed at which the bug occurs is slower on laythe, and even slower on minmus. This would make sense since the collider squares would be smaller. That said, I'd need to do more experiments; my results on these planets are not conclusive. No idea what Kopernicus is doing, but it VASTLY increases the top speed. You can easily get up 3 km/s with Kopernicus installed. It seems as if kopernicus removes the 1381 m/s limit completely.

Not sure, haven't tested it. That is an excellent suggestion though. I'll test it as soon as I can!

Greetings! If you’ve ever tried to build a landspeeder and tried to set a landspeed record at Kerbin’s poles, you may have run across a strange bug. For whatever reason, you simply cannot get your craft to go above a certain velocity. It just sinks into the ground and explodes as if the terrain colliders simply ceased to exist. Even stranger, it appears that the speed at which the bug occurs is related to the acceleration of the craft. The land speeder above can reach 1808 m/s at full throttle, but at 50% thrust limiter, it fails at ~1600 m/s. So what is going on here? Curious, I devised an experiment to see if there was some sort of predictable relationship between acceleration, final speed, and distance traveled. Here is what I came up with: Hyper edit THIS CRAFT (which for the purposes of this report, we will call “Craft 1”) to 40 W and 80 N (These coordinates do not have a special purpose; they simply give plenty of room on the north pole to perform the experiment) Remove Atmosphere with hyper-edit Enable infinite fuel (For constant acceleration) Detach Beacon Quicksave Quickload Set Thrust Limiter to 100 Engage full throttle and ignite engine Pause the moment the camera clips through the surface (You can rapidly pause-unpause the game to do this. I found that this does not affect the speed at which the bug occurs) Record velocity and distance from beacon in a table Repeat steps 7 through 12, decreasing the thrust limiter by 5 each time (thrust limiter = [95, 90, 85, etc.]) Calculate the acceleration for each entry using the thrust and mass of the craft Calculate the time elapsed for each entry using the distance traveled and acceleration Here are the results of my experiment: Very interesting. It appears that the speed at which the bug occurs IS affected by acceleration. In fact, looking at the graph of distance vs. time, we get something that looks strikingly linear. If we take the equation of the trend line of that graph, y = 683.83x + 4367.8 solve these kinematic distance equations for the final velocity, d = (1/2)*(vi + vf)*(t) d = 683.83t + 4367.8 (1/2)*(0 + vf)*(t) = 683.83t + 4367.8 vf = (1367.66t + 8735.6)/(t) and take the limit as ‘t’ approaches infinity, lim t->INF (1367.66t + 8735.6)/(t) = 1367.66 we get a speed of 1368 m/s. This suggests that a craft traveling at a constant velocity above 1368 m/s will encounter the bug, while a craft below this speed will not. To test this prediction, I simply took the previous craft and accelerated it up to speeds ranging from 1350 to 1400 m/s. Then, I checked if the craft encountered the bug or not. Here are my results: Speed Bug? (T/F) 1350 F 1360 F 1376 F 1380 F 1381 F 1382 T 1385 T 1390 T 1400 T This data shows that my estimate of 1368 m/s is very close to the actual value. The real limit appears to be 1381 m/s. Below this speed, it does not encounter the bug at all. Once a higher speed is reached, it encounters the bug within 5 seconds, but not immediately. So, once a craft reaches a speed above 1381 m/s and remains at that speed for a certain amount of time, terrain colliders cease to exist. For curiosity’s sake, is it possible to go past this speed, and then slow down and have the colliders come back? To test this, I built this thing and set it off. And there you have it. Once the craft slows down to 1380.8 m/s, the terrain colliders instantly come back and shred it to pieces. What happens if we vary the frame-rate? Do we still get the same results? To test this, I built a new craft, which we will call “Craft 2,” with rings of inward facing seperatrons. When firing, they tank my framerate to 10 FPS. Then, I repeated the above procedure with and without firing the seperatrons. Here are the results. From this, it appears framerate does not have an effect on the final velocity of the craft. Note the differences between Craft 1 and Craft 2 are likely due to the fact that I launched them at different headings (270 and 120 degrees respectively). More on that later. Alright, so it appears that something is going on at 1381 m/s, but what exactly? The game doesn’t instantly stop reading collisions after this speed, since a speeder can go much faster. What if the game loads a “radius” of terrain colliders around the craft, and after 1381 m/s, the game stops loading new colliders? This would explain why a craft at a constant velocity encounters the bug 5 or so seconds after reaching 1381 m/s, rather than immediately. Using this kinematic equation, we can find the distance traveled by the craft from 1381 m/s to the speed at which the bug occurs. From these distances, we will be able to calculate the radius of the terrain colliders. Here are the results from applying this calculation to all of our data entries: So the data seems to be scattered around ~7.4 km, with the variation from the lowest and highest value being about 2.5 km. Since all the distances are similar, despite the acceleration, it seems that KSP does STOP loading new colliders after 1381 m/s completely, leaving just a 7.4 km radius of colliders left to travel on. But why does it vary by 2.5 km? This could make sense if we consider that KSP does not load terrain continuously, but rather, loads it in chunks. Would this explain the variation? In an ideal KSP, the distance from the craft to the boundary of the terrain colliders should be constant. However, KSP likely does NOT load terrain continuously like that. Rather, it loads it in square chunks. In such a system the distance from the craft to the boundary can vary depending on direction and distance traveled. If this assumption is correct, then it should be possible to map out one of these terrain chunks by slightly changing the angle at which the craft is launched at and measuring the final distance. So, I did just that. First, I tested headings from 80 degrees to 100 degrees in increments of 2. Then, I converted the results from polar to Cartesian coordinates. Here are my results: Hmmm, it looks like a corner of a square. In fact, if you multiply the slopes of the trend lines, you get a value very close to -1, which shows that the edges are perpendicular. 1.183*(-0.8245) = -0.9753835 So indeed, KSP does load terrain in square chunks. Alright, now let’s take ALL the data gathered from this experiment, and apply the kinematic equations from above. Here is a plot of that operation. In conclusion, this study shows that KSP loads terrain colliders in squares, and completely stops loading new colliders after reaching 1381 m/s. Effectively, this means that once a land-speeder passes 1381 m/s, it only has between 6 km and 9 km (depending on the direction and distance traveled) to hit the land-speed record before falling off the remaining colliders. But, why does the game stop loading new colliders after 1381 m/s? My theory is that the devs coded a limit into how fast the terrain loaded in an attempt to optimize the game. After all, why load terrain colliders past this speed if a collision at these speeds would almost always guarantee death anyways? If any KSP devs would like to comment on this, it would be greatly appreciated! Comments? I’d love to hear your thoughts on this as well. Also, feel free to download my test craft and perform my experiments. I have not tested this on other computers, so I’m curious if that would make a difference. Just be sure to conduct them on a STOCK INSTALL with only hyperedit and KER. This is because I've found that some mods such as kopernicus change the way the terrain colliders are loaded. Bye everyone! -Stratzenblitz

Today, I went fast. Very Fast.

Wonder no more! This album will show you how:

Third video of 2017! We are on a roll, now 4700 subs and climbing! So, here's a sub for all you subs.

Here's an SSTO Submarine. Because, why not?

Today, I went to Laythe... In a flying SSTO VTOL submarine:

I really doubt it. I don't know how large BDArmory's physics range is, but it is certainly not larger than kerbin. Plus, the monorail needs launch clamps to stay stable and since the launch clamps do not follow the the curvature of the planet (They mount relative to a flat plane), there is no way for them to support a monorail that goes below that flat plane. Plus, you won't be able to go over land with them. If you have too many launch clamps clipping through the terrain, you will have problems. Now, if you are thinking about building a monorail around gilly, that might be possible... Nope, Vesselmover does not work. At all. It doesn't load the launch clamps properly so the monorail will have no supports. You might be able to make a monorail without them, but I haven't had much luck with that. As for the fairings, it is a simple craft-file edit: Place a fairing, but do not build it. Save the craft. Then, open the craft file and find the code: MODULE { name = ModuleProceduralFairing isEnabled = True interstageCraftID = 0 nArcs = 2 ejectionForce = 100 useClamshell = False stagingEnabled = False fsm = st_idle EVENTS { } ACTIONS { DeployFairingAction { actionGroup = None } } UPGRADESAPPLIED { } } Then, edit it: MODULE { name = ModuleProceduralFairing isEnabled = True interstageCraftID = 0 nArcs = 2 ejectionForce = 100 useClamshell = False stagingEnabled = False fsm = st_idle EVENTS { } ACTIONS { DeployFairingAction { actionGroup = None } } XSECTION { h = 0 r = 0.649999976 } XSECTION { h = 333 r = 0.649999976 } XSECTION { h = 333.200012 r = 0.200000003 } UPGRADESAPPLIED { } } This will create a fairing that has a length of 333.2 meters, and a radius of 0.65 meters. I've found that ~300-500 meters is the limit of fairing length before you start having collision issues with the monorail car.

I don't think anyone has built a monorail this long: