Nuke

are pre-compressed textures are supported yet? task manager is a good place to start

il agree on the command seat issue. i like to build small open cockpit aircraft and dont like that i have to jump through hoops just to get a kerbal in the seat. if you need to lign the hitchiker up to the MK1-2, you can just rotate one or the other till they line up. this is what i usually do.

this + centrifuges please.

deep friers are tricky in normal earth conditions. i used to have a fry daddy but now i just deep fry in a pan on the stove. do corn fritters, onion rings, fries, donuts, shrimp, fish, chicken, etc. every time i damn near burn the house down. ive gotten rather good at it, but if you dont respect the grease, it will burn you. hot oil in space, hell no! not a ship i want to live on. see oil at temperature is hot enough to ignite with very little added energy, it just takes one little droplet to flare up and you got a chain reaction on your hands. now you got this grease pit bolted in a centrifuge doing 3 gs. frying your fries will probily work. but what if the motor fails or worse, jams up suddenly? its sort of like spinning around with a bucket of water. it will spray everywhere it will likely get in some control panel and cause a flare up, which will ignite all the other microscopic droplets floating around the cabin. hell no. pretty soon the whole interior is burning (and i hope you are not running oxygen rich, because that might make that grease auto detonate). now if you have some kind of ultra reliable mega 1g centrifuge on magnetic bearings, you might be able to deep fry without fear utter terror of the stuff you need to breathe to live being replaced by fire.

it would be about as dangerous as a dirty bomb. not super dangerous but enough to cause some deaths.

you can, and i do, but moose are a beast to be reckoned with! they are writhing death machines. you shoot it and the bullets bounce off and it comes after you, you try to mow it down in your car and it crushes you, gets up and walks away. and they are everywhere! at bus stops, in malls, you look at it cross eyed and it will trample you. i dont think gaters are nearly as dangerous. with all those teeth its obvious what it can do and what end you should avoid, and you still see cajun folk jumping on their back and hog tie em and putting them in the gumbo. ive never seen anyone do that to a moose and live.

lizzards are cute. moose now. moose are evil.

also pretty sure a low flying aircraft at mach 3 would make a flir scanner light up like a christmas tree, even at several kilometers distance. control systems could handle that, pepper its flight corridor with lead, you just need to hit it once, the plane's own velocity will destroy it. if thats not good enough, ground based laser weapons aren't far off.

i would add a gatling gun

it was canceled not because of safety but because icbms pretty much made them obsolete. this was the '50s, everybody wanted nuclear and we didnt have hippies to protest it yet.

im slightly schizophrenic, so i doubt il be allowed on a space craft. they dont even let me drive.

this was supposed to be a doomsday weapon, so who cares about the path of death left behind it. you could probibly do a design with a heat exchanger to better isolate the core from the atmosphere, but the risks of using a flying nuclear reactor on earth are still to great (look at how frequent plane crashes are). but that doesnt mean you cant fly around on saturn with one.

probibly can be made to work. might require a mod though. e: seems the api for the 3d mice is some proprietary hardware locked crap, so going through an emulation layer to provide a fake 3d mouse might be difficult (not that it hasn't been done before with trackir). joystick emulation doesn't work either because there is no absolute look axes you can bind them to (this is why trackir works in mechwarrior 2). we do have relative axes but if you look left for example, the camera will keep turning left, and if we center, it will just stop turning left, it wont go back to center. so thats not an option (unless you enjoy sore necks and nausea). to get data out of the face tracking program, ftnoir has the option of using the freetrak api which is incredibly easy to use (you just need to export 4 functions and a struct from a dll), among other options (joystick emulation, its own api). but if you go with the freetrack api it also supports freetrack and trackir users (sort of, natural point made them take down that version, but you can still get it) out of the box. you still need to get the data into the game though, and apply it to the in game camera. you could do this with a plugin. i actually attempted this a long time ago. unfortunately i didnt have any experience with c# or unity so what i did was a dirty hack involving the hull cam source and this cs file that i wrote (im calling it public domain): using System; //using System.Collections.Generic; //using System.Linq; //using System.Text; using System.Runtime.InteropServices; using UnityEngine; namespace FreeTrack { public class FreeTrackClient { //a struct for the freetrack data to go [StructLayout(LayoutKind.Sequential)] private struct FTData { public int dataid; public int camwidth, camheight; public Single Yaw, Pitch, Roll, X, Y, Z; public Single RawYaw, RawPitch, RawRoll; public Single RawX, RawY, RawZ; public Single x1, y1, x2, y2, x3, y3, x4, y4; } //do imports [DllImport("FreeTrackClient.dll")] private static extern bool FTGetData(ref FTData data); [DllImport("FreeTrackClient.dll")] private static extern string FTGetDllVersion(); [DllImport("FreeTrackClient.dll")] private static extern void FTReportName(Int32 name); [DllImport("FreeTrackClient.dll")] private static extern string FTProvider(); //a bool to check if were inited private static bool ftInited; //a place to count consecutive update failures (for reset) private static int ftBadUpdates; public static int maxBadUpdates; //this is pulbic for tweaking purposes //data frame from the dll goes here private static FTData ftData; //a place to store output values private static Vector3 ftOffset; private static Quaternion ftRotate; //the following vars and the four functions that follow are the external interface //you must init the code somewhere with initFreeTrack(), this returns a bool which wen true indicates a successful init, fail otherwise //you may then set the constraint variables and scalers (you can do this at any time) //then you must call updateFreeTrack() to update local position and rotation. its return is the same as initFreeTrack(). note that if the update fails it will still return true. //after that you can get the local camera rotation with getRotation(), which returns a quaternion //and you can get the local camera offset with getOffset(), which returns a vector //constraints/scalers. can be changed at any time public static Vector3 minOffset, maxOffset; public static Vector3 minEuler, maxEuler; public static float transFactor, rotFactor; //init function (call before using the class) public static bool init(){ //tell the console what were doing UnityEngine.MonoBehaviour.print("Attempting to init FreeTrack"); ftBadUpdates = 0; maxBadUpdates = 5; //set things to zero ftOffset = new Vector3(0.0f, 0.0f, 0.0f); ftRotate = Quaternion.Euler(0.0f, 0.0f, 0.0f); //default constraints and scalers minOffset = new Vector3(-0.4f, -0.4f, 0.0f); maxOffset = new Vector3(0.4f, 0.4f, 0.4f); minEuler = new Vector3(-180.0f, -180.0f, -180.0f); maxEuler = new Vector3(180.0f, 180.0f, 180.0f); transFactor = 0.02f; rotFactor = 50.0f; //output create output struct ftData = new FTData(); //handel no dll scenario try { ftInited = FTGetData(ref ftData); } catch (DllNotFoundException e) { UnityEngine.MonoBehaviour.print(" Error: "+e); ftInited = false; } if (!ftInited) { UnityEngine.MonoBehaviour.print(" Cannot init. No FreeTrack client or error."); } else { UnityEngine.MonoBehaviour.print(" Init successful!"); UnityEngine.MonoBehaviour.print(" Provider: " + FTProvider()); UnityEngine.MonoBehaviour.print(" DLL Version: " + FTGetDllVersion()); //report the game's id to freetrack (this doesnt work and causes an exception) FTReportName(3431); //escape velocity of kerbin, lol } return ftInited; } //update function call it to refresh ftOffset and ftRotate. the return indicates if the interface has been inited, not if there was an update public static bool update() { //dont call a bunch of null functions if (ftInited) { //load data into the struct if (FTGetData(ref ftData)) { ftBadUpdates = 0; //constrain eulers to within set constraints Vector3 ftEuler = new Vector3(-ftData.Pitch, -ftData.Yaw, ftData.Roll); ftEuler *= rotFactor; if (ftEuler.x > maxEuler.x) ftEuler.x = maxEuler.x; else if (ftEuler.x < minEuler.x) ftEuler.x = minEuler.x; if (ftEuler.y > maxEuler.y) ftEuler.y = maxEuler.y; else if (ftEuler.y < minEuler.y) ftEuler.y = minEuler.y; if (ftEuler.z > maxEuler.z) ftEuler.z = maxEuler.z; else if (ftEuler.z < minEuler.z) ftEuler.z = minEuler.z; //convert to quat ftRotate = Quaternion.Euler(ftEuler); //constrain offset so it stays within a unit box (this box should probibly be defined in the part) ftOffset = new Vector3(-ftData.X, ftData.Y, -ftData.Z); ftOffset *= transFactor; //scale it, it seems way over sensitive if (ftOffset.x > maxOffset.x) ftOffset.x = maxOffset.x; else if (ftOffset.x < minOffset.x) ftOffset.x = minOffset.x; if (ftOffset.y > maxOffset.y) ftOffset.y = maxOffset.y; else if (ftOffset.y < minOffset.y) ftOffset.y = minOffset.y; if (ftOffset.z > maxOffset.z) ftOffset.z = maxOffset.z; else if (ftOffset.z < minOffset.z) ftOffset.z = minOffset.z; } else { ftBadUpdates++; //if this fails too many times assume the markers are off the camera and center everything if (maxBadUpdates >= 0 && ftBadUpdates > maxBadUpdates) { ftOffset = new Vector3(0.0f, 0.0f, 0.0f); ftRotate = Quaternion.Euler(0.0f, 0.0f, 0.0f); } } } return ftInited; } //get rotation public static Quaternion getRotation() { return ftRotate; } //get offset public static Vector3 getOffset() { return ftOffset; } } } unfortunately my hack didnt age well and it stopped working as soon as the next ksp version came out. others have tried to make it work but no success. i presume that squad added some kind of security patch to the plugin loader that prevents loading external binaries but i dont know.

i say we wait till we can build a large railgun on pluto, capable of solar escape velocity and then some. fire off cubesat sized probes en masse. then we can send thousands of probes to thousands of potential systems. of course we need to work on power supplies and figure out how to extremely long range radio. it would probibly allow you to get spectroscopy data on exoplanets. with such large numbers of probes you might get lucky and manage an aerocapture maneuver on a few of them, since you will be carrying a very limited quantity delta-v for course corrections and holding orientation for observations, though this is unlikely.

metal version:

i dont think it would be that bad. it might take 2 people about a minute to fill a sandbag with one holding the bag and the other filling it. a simple light weight apparatus (a fold up aluminum hopper) can probibly accomplish the second man's job. of course with space suits (baring any spacesuit advancements in the near future) that might take 2 or 3 minutes. mission control would of course probibly want the crew to slow it down for safety and for energy/oxygen conservation to 5 minutes a bag. even then it would only take 83 man hours to fill a thousand bags. thats 2 weeks work plus overtime according to most labor standards. if a crew of 4 pitches in, 2 people shoveling, one putting new bags on the hopper and tying them closed when they are full, and a 4th man moving the bags to their intended destination, you could probibly do it in about 3 or 4 days, barring any accidents. you could also employ teams of 2 working in shifts for similar results. finding a cave site would be very useful, but you may need to reinforce it because cave collapse is a concern. a sprayable concrete mixture with local aggregate would probibly work here, probibly with some light reinforcement (kevlar mesh?). the tools for this would be rather massive, and so probibly wouldn't be considered unless you were building a permanent base. if you were then you would probibly want to bring some airlocks, some cinder block forms for building walls, some sprayable epoxy for sealing in and possibly some sprayable foam insulation. you could hose out a habitat in no time. problem is its hard to find caves from orbit, and if you did find one you would probibly want to inspect the cave to make sure its fit for habitation so it would require a number of precursor missions. i dont think mission planners would want to go for this.

its not really hard to write up a fake cpu and assembler. i did a bytecode interpreter to extend the programming capability of an atmega328 microcontroller (to pretty much let me run code from anywhere, not just the flash, all be it with greatly limited performance). 2 things though. first off not many people have experiece with asm. so you may want to consider emulating a cpu that has existing compilers for various languages. its considerably easier to emulate an instruction set for an existing cpu than it is to write a c compiler for a custom one. the other thing is having a computer isnt much use if you cant interface it to the ship's systems. so you need to emulate some peripherals too. not sure if any of the programmable cpu mods do this (or do this enough). and id like to see one with an interface that other mods can use. for instance id love to be able to program infernal robotics, then i can write some ik code for big stompy mech action. or you could use rover wheels and a reaction wheel for self balancing vehicles. so exposing some kind of fake peripheral bus to other mods would be awesome.

didnt know they had those. like i said upgrade editions i tend to avoid like the plague.

i think of multiplayer as single player with better bots. so i like multiplayer games where i can join a server with a bunch of people i dont know. in the context of ksp, im not sure what multiplayer would be other than a bunch of players flying their own missions in a shared universe. i dont think there would be any actual need for interaction. you would need to introduce some new goal that needs multiple players to accomplish.

not sure if frontier: elite2 and frontier: first encounters qualify. those were newtonian space trading games that were way ahead of their time. you can orbit things, do slingshots, etc. didnt give you much for navigation though, you pretty much flew a fairly flat trajectory to your destination, but thats because you had pretty much limitless deltav and nobody wanted to wait to get anywhere. its also one of the hardest games i ever played. i struggled on some of the earlier missions and just gave up. got tired of getting blown up by fast moving dots that you couldn't shoot. looks like an elite/frontier clone. going to have to check that out.

i actually use lua to test ideas and prototype systems and stuff. its also pretty quick to build a gui application for custom hardware interfaces (arduino and other stuff). lua for windows comes with a script editor and all the modules you would ever need (most of those libraries are also cross platform, so things written on windows can theoretically work on everything). i use it to test game engine ideas. there are a number of lua based game engine frameworks as well. its also a good way to extend the capabilities of your engine and has a nifty c api. never used python. but i dont think ive ever heard one person say one bad thing about it. its just something i haven't had a need to learn yet. not sure how it would be to make a game engine with it.

it was created because one of jebs descendants accidentally sat on the create universe button.

the universe's largest slurpee machine.

well lathe has oceans, it could be full of some kind of oxygen producing bacteria, perhaps living off of geothermal vents on the sea floor. i can understand how the surface is totally uninhabitable due to radiation. but a few meters of water is all you need to shield any organisms that might be living below. then comes the question how is laythe keeping its atmosphere. magnetic field? and if so, how is it interacting with jool's? but we have plenty of real world examples of a moon around a gas giant having an atmosphere, but we dont know of any that have liquid water. whatever lathe's oceans would be made of, it would need to be something fairly inert.

you can write games in many languages. the question is do you want to design your whole engine from scratch, make extensive use of libraries or use a pre-existing framework? i personally would opt for c++. its fast enough that you can really optimize where you need it, and still gives you all the oop goodness that makes your code shiny. the only libraries you really need are sdl and opengl (unless you want to use one of those multi-gigabyte microsoft sdks so you can use directx), that covers input, graphics, sound and the like. toss on a physics api if you want (physics code is fun so i am writing mine from scratch). its a considerable amount of learning to go from hello world to something that you can play. ive been working on my engine on and off for at least 5+ years and its still not quite a game yet.