Nuke

rtgs are horribly inefficient and dont give enough power to take electric propulsion to its maximum potential. so id rather see money go to actual nuclear reactors in the 1-10MW range.

the list of potentially useful electric propulsion schemes is longer than my arm. the stock ion engine is already op (in terms of thrust) compared to real ion drives currently in service. you might just have a generic catch all term like "plasma thruster" to cover those systems. i wouldn't mind some larger ion engines, xenon tanks, and bigger solar panels. but i wouldnt go too overboard and have 50 kinds of electric engines.

what i have in mind is a ground to orbit (perhaps beyond) combat flight sim in a scifi universe. so aircraft will essentially be aerospace fighters.

thats good to know. didnt want to implement a complex system that probibly doesn't work. since my game is not going to be a building game, i just need a way to describe the aircraft to the flight model. so a small number of blobs with no occlusion should be a sufficient abstraction.

cD is a lets see what happens variable. when you design an aerospace structure its usually a big unknown, and has to be determined experimentally. literally stick it in the wind tunnel and see what it could do. you control all the variables so its easy to determine the cD from the data with math. you can then determine which regime of flight the structure is most useful. in a simulation this is probibly best represented as a curve (probibly based on a real world analog like a concorde fusalage or a naca 2412 airfoil) in the velocity domain from standstill into hypersonic. cross sectional area can be tested procedurally in real time. the wind vector will always be changing so just using a dimensionless area area doesn't quite work out. the wind will always change aoa on the pitch and yaw axis and therefore the area exposed will not be constant. so in my last attempt at a flight model i used values for the cross section on all 3 orthogonal planes, placed into a vector and then dotted with the normalized wind vector (which was rotated into model space). i was rather happy with the result. actually the hardest thing i had with my drag model was barometric pressure calculations. i started with a flat gradient, but apparently that is not a very accurate model for a planet's atmosphere. tempurature is a factor as well as density. i learned that real world avionics were calibrated around a more scientifically accurate model, so i used the standard atmosphere. looking around i found one for mars as well. thats about as far as i got. my blob model as i now call it has one major problem, there is only one blob. i never got around to implementing multi-blob systems. im not sure what to do about blobs in front of other blobs. my theory is once you figure out the exposed cross sectional area for all the blobs, use that as the radius for a circle centered on the blob in the plane perpendicular to the wind vector. circle-circle intersection can be used to determine what factor overlaps between any two circles, just check every circle against every other circle and store the factor of overlap somewhere with subsequent factors multplied into it. then its just the sum of all the areas times all the factors. with that data i can not only determine total linear drag for the whole system, but also drag for each blob individually, giving me a means to compute torque induced by drag for the whole system. i never got around to implementing this idea, since i suck at math.

you can probibly use some volumetric fog on the inside, and probibly a bitmap ring from a distance. the transition between them will be difficult but doable. freelancer (an ancient game by today's standards) did a pretty seamless transition from background bitmaps to dense debris fields. but making it look convincing is the easy part. many people would be happy with just the eye candy, but i want at least some physical interaction with objects in a ring system. full physics with all the things in the ring would be computationally impossible. all the objects will be going at orbital velocity. if you take your relative velocity to nearby ring objects and graph it out against your chance of hitting something, at some point the chance of hitting something will be 100%, at this point its a simple killbox. this will likely be fast enough where an object that will hit you in the next frame will not be visible through the fog and probibly slow enough that it wont break collision detection. cross that threshold and boom, otherwise do collision detection as normal on some of the objects. since all the objects are on rails (sort of, they dont exist until you get close to them, and are removed if you get too far away from them), it should be fairly easy to cull out most of them and thus reduce cpu load.

you can integrate as many objects as you have cpu time for. just get the vector sum of all the forces you want to account for and use that for your current integration step. for a spacecraft you dont have to account for mutual attraction for planetary objects, because the effect by a spacecraft on large bodies is infinitesimal, and you get a result that is close enough. for objects with large amounts of gravity, you must account for the effect of that object on all other objects (and those objects on eachother), and thats where the impossibility comes from, an endless recursive loop.

i dont know why all space suits dont have some kind of emergency maneuvering facility. even if its just a co2 tank and a few cold gas thrusters (a 4 thruster system would be sufficient for yaw and pitch control as well as propulsion). for more thrust perhaps use small hybrid thrusters using onboard reserve o2 (which could also be used for emergency life support), and rubber/acrylic/whatever. its unlikely you will get separated with much relative velocity, so only a few seconds of thrust would be neccisary to return to the station or whatever. key thing is its an emergency system, not intended for regular get around use.

thing is with the booming chinese economy, they are the ones who are poised to get to mars (or return to the moon) first. nasa could do it if it had the funding, but i dont see it happening.

id like to have a dense atmosphere, low gravity object, essentially a titan analog. lathe has too much gravity and too little atmosphere to be a respectable analog.

my record is 1.5 bottles of tequila.

idk, a 30 year stream of cold war surplus nukes plus whatever else we managed to produce might make an earth sized dent in its trajectory, and probibly solve nuclear disarmament and energy problems in the process. probibly need to retrofit a lower stage to existing mirv missiles, and upgrade the warheads with a maneuvering unit of some sorts. then again if you cant move it with nuclear ablation, you could probibly use nuclear ablation to smash another more manageable object into it.

i dont see a whole lot of pessimism so much as people in the know shooting down the ideas of the layman. if the idea is new or not very well understood, and someone in the know has no idea, they will just revert to the default skepticism that comes with the scientific thought process. at that points you might get a "thats impossible" out of someone, possibly out of nothing more than lazyness or the lack of will to think about or investigate something new. i dont like saying something is impossible. its like watching old scifi and having some character say that something is impossible when you have an example of why it is possible sitting in a box somewhere or even on your desk. then again if you ask "is x possible" and the answer is no, but then go on about why it should work. you kinda missed the whole point of asking. its rather depressing, its almost as depressing as some of the things that go on in the ksp suggestions board.

i dont thing this would give you any more isp over a conventional chemical engine. the only thing it really does is make the fuel take up less volume. but i have seen a thing about a microwave electrothermal engine that actually gets you better isp. a few kilowatts of microwave power is all you need, it just flash vaporizes the water (or any other propellant, it can run on lots of things) and spews it out the tailpipe with nerva-esque performance (~800s). its sort of a happy medium between plasma engines and chem engines that wont need a polywell or a couple football fields of solar panels to operate. http://alfven.princeton.edu/projects/microwave_thruster.htm

im of the opinion that a game should never make you wait unnecessarily. i would argue that some of the things in the op's list dont qualify as waiting. burns, rovering, and flying really dont coun't because its not so much waiting as it is requiring time to accomplish a thing in game. time warp kinda does make you wait, especially for those long transfers. another step in warp (and a few more steps in physics warp for those infernally slow ion engines) would be awesome and would fix this. wouldn't be against a waypointing system for rovers, where you set up some waypoints, and your rover can traverse the surface while in warp. add altitude to the waypoints, and you can do the same thing with aircraft. this would obviously not work for space navigation, but would eliminate some of the time spend traveling along the surface.

scaled are the ones you could go to build something like that. given the exotic ceramic composite materials they plan to use for the thermal protection system. but id like to see a source on this myself.

you dont even need to drill. just detonate it near the surface or in a natural indentation. the ablation of material will produce thrust. just send a constant stream of warheads in to do that spaced out enough so they dont harm other incoming warheads when they go off. like i said poor mans orion drive.

ive landed on dres, its a very boring place.

poor man's orion drive?

i like nukes! this has been my screen name for almost 20 years. oddly enough, its always available when i sign up for stuff.

you might be able to simplify stuff, like using spheres instead of ellipsoids, and circle-circle intersections instead of ellipse-ellipse intersection. ksp seems to have a min and max drag and then use the aoa of the part to determine which to use (lerp between min at 0 aoa and max at 180). that is probibly good enough. i assume the angular drag parameter is how much extra drag the part produces at maximum aoa, and is reduced to 0 when aoa is 0. the sum of the two would be equivalent to your cross sectional area. non zero values of angular drag might result in torque to turn the part into the wind. which kinda makes sense and is adequate to explain part behavior in the atmosphere. determining our part cross sections the ksp way would also work. the result would be a one dimensional value that would be represented by the area of a circle, and those are easy to intersect. then just do the nose to tail occlusion factoring (i just made that up) thing. the result would be close enough to be useful.

it does appear there is currently at least some directionality to the drag model, at least enough for the angle of your ship to affect your trajectory in an aerobraking maneuver. probibly some room for improvement. how about a drag model involving a system of triaxial ellipsoids, which would represent parts drag parameters. the diameter of each axis represents the cross section of the part on that axis. these ellipsoids can have their own position and orientation with regards to the ship. you can slice any ellipsoid at any angle through the center and get a ellipse as a result. you can then use ellipse-ellipse intersection maths to determine the area of overlap between any two ellipses. parts would be sorted front to back with regards to airflow and transform (from ship local to wind space coordinates where z is the axis of airflow) is applied to the ellipsoids. ellipsoids would then be sliced along the xy plane to get the ellipse to represent the cross sectional area of the part. this ellipsoid would be scaled by the cD (this could also be dimensional so you have different cD at different angles of attack). this allows for drag happy parts to have very large areas, making them difficult to cull out completely (parts in rear thus can affect stability). then a process of culling starts with the forward most part, and works its way back, each time determining what factor of the current ellipse is covered by parts in front of it. the ellipse is then scaled by this factor for further part culling. this process repeats until the last part is scaled. the area of each ellipse would then be used to determine the drag forces on each part. you can not only determine the overall net drag of the system, but also local drag, and therefore net torque from drag for the whole system.

at that altitude and speed a simple gravity bomb could land two countries away from where it was launched. but why use that when you can use a million dollar missile and hit your target in the nuts with it. i figure the best way to launch a missile at that speed is tail launch it, that is have a missile tube with a tail hatch. instead of being fired out the front, it is released out the back. when ready to fire take some bleed air and use it to shoot the ordinance out the back of the tube or perhaps use some kind of drag inducing device. then bring its propulsion and guidance on line as it departs the plane's wake. plane never makes a stop. its an engineering problem im sure they are smart enough to figure it out.

im mostly just havent been in a modding (or any other hobby) mood in the last several months. you can blame various battletech games and some computer problems. im a natural procrastinator. i dont consider the mod dead, just in hibernation.

i dont think i ever got that far. was writing a mod for freespace2 open that added newtonian physics and aerodynamics (and even orbital mechanics). unfortunately the game engine wasnt designed with this in mind and it never worked out. will probibly port the flight model into my game engine eventually, but its barely an engine so far. that will come in handy if i ever work on perfecting the flight model.