michaelhester07

https://obsproject.com/ Open Broadcast Software will let you do recordings. It's faster than fraps too. If you have an Nvidia video card you can do shadowplay. It's fast enough that recording goes unnoticed.

HandleD3DDeviceLost HandleD3DDeviceLost: still lost Skipped frame because GfxDevice is in invalid state (device lost) That line in your log says your KSP is not the active window. I don't see any crash in the log file either.

Active Texture Management I don't think I've ever requested a sticky before but this one probably needs a sticky. I see so many threads created about modded KSP installs crashing on startup with 32 bit KSP. The problem is that with lots of mods comes lots of memory consumption. KSP pre-loads all textures at startup and keeps them loaded throughout the game. This is probably done to speed up load times for when you encounter ships in the persistent environment. The problem with this strategy is that Squad only expects to load their assets and only tested for their assets. They expect KSP to run with a 2gb footprint with some margin for in game memory changes.. When you start adding mods to your KSP that add parts you increase the memory footprint. If you have few mods you'll edge close to the 3.5gb hard limit for memory used by KSP before it crashes. That limit is imposed by the 32bit Unity engine. This means your KSP may suddenly crash mid game for no apparent reason. If you have a lot of mods then you'll break that limit before loading finishes. In both cases you'll see a small window saying KSP crashed when you alt-tab out of it. If you were to read the log file you'd find right before the crash dump there was an error for running out of memory. So far the best way I've found to help reduce that footprint is Active Texture Management, which I linked above. If you have a lot of mods installed and have frequent crashes on startup or in game I suggest that you get this mod. It will put the textures on your video card buffer and save at least 40% of the memory consumed by KSP normally. To a smooth and stable modded experience

I had the maiden flight of the Mk 2 Torus hull last night. Well 2 nights ago. I'm going to build one over duna soon. Turns out trying to get a strut out from KAS from a box attached to a stanford torus will most likely destroy it. I guess a Jeb boson was hiding in the box. PS: that torus was utterly useless: it didn't have a recycling bin, docking port, orbital construction dock, or antenna. I couldn't even satisfy the space station contract it was for. I'm going to them like: you want a station? I'll give you a space station! Then they come to me and go " it doesn't have an antenna. Impressive but no." I also had a rover launch from a minmus base to check out anomalies. You can see the base truck in the first slide, the rover in the second. The rover had 2 probe cores, some fuel, and a docking port in the center so I could control it properly while flying.

Delta V is the big number. I really wish Squad would provide fuel measurements in terms of that in stock because this game really is rocket science. They already show the navball maneuvers in terms of deltaV. Landing on the mun and getting back to orbit I've found requires in the neighborhood of 1500 d/V. 2500 if you want to get back to kerbin with your lander. Without a mod like Kerbal Engineer or calculating the deltaV yourself you won't know if your craft is capable of that. A simple recipe for a mun lander. Left to right is top to bottom Mk1 parachute, mk1 capsule, TR-18 separator , FL-400 tank, 3x Landing gear (medium size), LV 909 A last note: any part with a mass less than .01 doesn't actually count towards your ship's weight (it's regarded as weightless). You can go nuts with OX-STAT panels, Batman 100 size batteries, and Communotron 16 antennas, as well as all the small science experiments and your ship still has the same delta V as if you didn't have any of that.

I want to add a request for a change to Module Manager: Add support for the Reload All button from the database tab of the Ctrl F12 menu. I found that when testing models for a mod that using this would clear any changes done by Module Manager. If that's doable... thanks!

You can practice on the ground if you have the rover wheels unlocked. Launch 2 rovers out of the spaceplane hangar each with a docking port and practice how it looks on the ground so you know what to expect. You'll have to drive into the grass just west of the runway end. Now on to space: 1. RCS design: You can either design your RCS so the ports are mounted where your center of mass is... or you can place 2 sets of ports at either end of your ship and let the computer calculate the thrust out of each set for you for the same effect. The latter method I recommend for bigger ships as the COM will change a lot. ... in space ... 2. Select target mode navball indicators. Target the ship you want to dock to by double clicking it or selecting it in the map view. Now click the speed indicator on the navball until it reads "target". It will usually read "orbit", and "surface", and then "target" when you click on it. Usually target mode is selected for you when you're within 90km of the target. 3. Learn what your prograde and retrograde markers look like. Your ship's movement is indicated by the green makers on the navball. The prograde marker is the one without the X in the center of it. Thrusting toward this will increase your speed relative to your target. Thrusting toward the retrograde marker, the one with the X in it, will reduce your speed relative to your target. 4. Learn how those markers behave. Thrusting toward your retrograde marker makes the marker move away from your ship's center of thrust (the center marker on the navball). Thrusting toward the prograde marker makes that marker move toward your ship's center of thrust. 5. Learn the target prograde and retrograde markers. You should have seen these on your ground simulation too. They're purple. The large circle one is the target prograde marker. This is the direction toward your target. The one that looks like tri-foil is the target retrograde marker. This is the direction away from your target. 6. When you line up your prograde marker with the target prograde marker you're moving toward your target. When you line up the retrograde to the target retrograde you're also moving toward your target. If you line up non-matching marker types (prograde to retrograde) you're moving away from your target. Line up the markers by moving them as described above. 7. With RCS it gets easier: The W and S move you forward and backward according to your center of thrust. The shift and ctrl keys move the prograde marker up and down. The A and D keys move the prograde marker left and right, all according to your navball. This only works when RCS is enabled and you're in docking control mode with the translation mode enabled (blue indicator on the bottom left). To orient your ship you can swap over to ROT mode (green indicator) with the spacebar. Then the WASD keys change your orientation as before. ... now that the learning is done ... 8. Zero your relative speed to your target when you're within 500 meters of it. Thrust toward your retrograde vector until your target velocity is 0. Use low thrust so you don't blow past it. 9. Right click your docking port, select "Control from here". This probably doesn't matter unless your docking port is not on the top of your ship. 10. Activate docking mode, select Rotation. Orient your ship toward the target prograde marker. 11. Activate translation mode. Turn on SAS and RCS. (T and R) Thrust forward with RCS (W key) until you see the green prograde marker. Now use shift, ctrl, a or d to align the prograde indicator to the target prograde marker. Remember how the indicator moves from step 7. 12. When you're close to the target's docking port switch to chase camera mode. This part is kind of an art now. You'll have to match the direction of the target docking port with your ship's docking port. In chase mode the RCS translation mode thrusts your ship as such: W - forward, S - backward, A - strafe left, D - strafe right, shift: strafe up, ctrl: strafe down. Strafe your ship to line up the ports, then thrust forward. When you're close enough the magnetic rings will take over. When they take over turn off SAS. If you're docking 2 ships step 12 is different than if you're docking to a station. You can orient each ship to point toward each other's prograde vector when you're controlling from the docking port. This eliminates most of the strafing work as the ports are already lined up. It is ultimately easier to dock 2 ships than it is to dock to a station you can't reorient.

You can try the progressive science parts from my stanford torus mod (shameless plug) http://forum.kerbalspaceprogram.com/threads/84106-0-25-Stanford-Torus-0-5

Hold the Alt key and you can speed up a NERVA burn with physics warp. Be careful that your ship is well strutted before you go above 2x.

There is a thing with KSP where any part with a weight less than .01 doesn't actually get counted against your ship's weight. I've noticed this in kerbal engineer and it seems to hold true. With that said, you can change up things on your ship to make it lighter: 1. Remove the goo experiments, carry the light 4: temperature, gravity, seismic, atmospheric 2. The unshielded solar panels are the same power output but slightly lighter than the shielded versions and will survive a trip through the atmosphere just the same when retracted. 3. The Communotron 16 is in the same massless category as you found out. 4. You can possibly create an analog of the solar panels with the small cube strut and the ox-stat. This would create a similar solar panel that falls in the massless category and net you deltaV off your ion engine 5. You don't need to tri-couple the ion engines if you know how to physics warp to counter long burns. hold the Alt key when you press the warp increase key. This will give you the 2x-4x warp you're used to seeing in atmosphere. 6. Missed one: Solar panels are more effective at eve's altitude than at kerbin's altitude. Solar panels near moho provide nearly limitless power. Squad really needs to update the ship mass so that these .005 mass parts add weight correctly.

I've kept a simpler idea of transfers. It worked for me out to Jool once and Dres, Duna several times and back down to Eve and Moho once. It may not be perfect but here's what I do. 1. Transfer Window: I estimate a transfer window by where the planets are on a "clock", like an old face clock (funny I have to describe it like that ). The transfer window I use is 6:18 to 6:27 on that clock, where kerbin is the hour hand and the target planet is the minute hand. For Eve this also remains true. 2. Ejection direction: From LKO I setup a burn to eject my ship in prograde kerbin orbit when going out, and retrograde kerbin orbit when going in. 3. Try to plot a direct transfer: I plot a transfer burn to get close to the target planet if not dead on (seeing a SOI change on it). If I can get that I'll do the burn. 4. Early transfer corrections: More often than not what looked like a direct transfer changes when I leave kerbin's SOI. A small burn early corrects the intercept. 5. Later transfer corrections: I use kerbal alarm clock to track the transfers so I can do other things in the 66-190 days it takes to transfer. This means I add a late transfer node and make sure that the transfer is still on target, usually 20% of an orbit out from target. Part 4 and 5 burns usually don't take more than 300 d/v since the initial ejection burn setup most of the transfer. 6. Capture burn: When I get into SOI of target I do a capture burn at periapsis until orbit is achieved... unless I don't like the orbit i'll get, then 6b 6b: Orbit correction burn: If the orbit I get when I enter is one I don't want (like a polar orbit around eve) then as soon as possible I'll do an orbit correction burn. Burning toward blue or purple nodes will change the direction I'll get around the planet for a cheap d/v cost. My latest interplanetary cruiser has an 8000 delta/v capacity with a 2k lander. Since flag contracts I rarely plan for return flight as it is more lucrative to leave the guy on the rock to plant flags whenever they come up.

Kerbin needs more life, not just KSC. Here we have a small society of kerbals whose biggest achievement isn't launching spaceships, it's getting to the point of having a space program without ever having: Cities Globalization Farms Highway Infrastructure Airplanes Religion.. You name it from Earth's history or current industry, and they never had it. They magically got plopped down on a greenish planet with a space center and have no other purpose in life other than to go to space. Kerbin needs to be filled! Give them history, give them cities. I need to go download the kerbin city mod. Make it so that they had to engineer the space program and not that it just popped up out of nowhere.

That's actually exactly what I'm uploading: the part folder with the mu embedded in it. Sketchfab complains it "An error occured while trying to convert your model."

Sketchfab is supposed to support .mu right? I can't upload a zip file to it with the .mu for my stanford torus.

I don't have any pictures of eclipses. I just know they slow down resource harvesting on my mun base. I'm one of the few who get annoyed with munar eclipses.

You're not driving that truck in the space plane hangar that's doing "Tokyo Drift" below your spaceplane? Seriously watch for that one truck that power slides across the SPH. As for me: Team: Operations Location: Vehicle assembly building Mundane task: Programming the stage separations in the computer Why: Cause the other guy keeps putting the launch clamp in the wrong stage. Alternative choice: R&D making the logical connection between how the temperature on the mun relates to being able to build a new rocket part (it doesn't make a lot of sense until you stare at it for hours).

I've been going through all my models from the Stanford Torus project and converting most parts to convex hulls after learning how to separate out parts for this conversion. The torus and all parts from my main career are "fixed" this way too, and it loads the physics much faster now. The new hull design is almost all convex hull marked so it becomes possible to make a wheel out of it. (I couldn't make it roll though)

This weekend was spent designing a new stanford torus hull. I'm most of the way there on it. Other than that I visited Dres for the first time ever pretty much.

Typically 4 stages, 5 if you count the separator for the command capsule: Stage 1: Boosters, maybe main engine firing on low throttle for control Stage 2: Main engine to LKO Stage 3: Transfer stage to destination (mostly kerbin SOI) Stage 4: Landing and return stage (built with high deltaV, around 2500) (stage 5): command capsule for re-entry + parachutes Permanent flag contract base: 4 stages. Landing stage is slightly smaller since it has no plans to return. Satellite contract ship: 4 stages: Same as above, but final stage is high dV for positioning (6000 delta V between transfer and final stage) Basemaker: 4 stages: Has extraplanetary launchpads with the garage part from my mod to build bases with. Stanford torus build station deployment ship: 1 stage, maybe 2 depending on where I want the station. Usually launches from extraplanetary base. Stanford Torus build station: 1 stage. When the torus is done it gets recycled into the station. Interplanetary cruiser: 2 stages. 1 8000dv main cruiser, 1 2000 dv lander

You can also select the "texture" viewport style in Blender to see what the textured model will look like. This shows the normal direction correctly. You'll have to assign textures via the UV editor in Blender for this feature. For Blender to Unity to KSP I would suggest this route instead of doing materials in blender as Unity will pick up your textures even if you had no materials assigned.

Actor::updateMassFromShapes: Compute mesh inertia tensor failed for one of the actor's mesh shapes! Please change mesh geometry or supply a tensor manually! What does that mean and how can I supply a tensor manually?

Hint: More boosters

I've scrapped the pipeline idea for now to redesign the torus hull. I'm getting closer to the look from Elysium. This image was a test for a 10km diameter hull with rendering distance set to 120 km. I had to scrap that since the physics are instantly lethal to kerbals when the center of your ship is 5km from where your kerbal "collides" with it. This is a shot from the science module looking down the ring. I was going to have the ground as "plates" that you could pre-fabricate and store as subassembles but they seem to wobble from physics. The ground will have to be "integrated" into the final hull like before. Daytime shot from inside the science center looking downring Outside looking at the unfilled interior This hull will be 2km diameter, the largest I can build it within the default physics box.

If you're going for ice planet you'll want more white than blue. Hoth from Star Wars is a perfect example of that concept. IRL Enceladus of Saturn is a perfect example of an atmosphere-less ice planet. http://en.wikipedia.org/wiki/Enceladus For your reading pleasure.

What mod did he use to get the render distance like that? I want to go for a 10km torus and it despawns at 2.5km.