Nuke

c++ seems to be the most versatile. its also good to know some c. i also like lua and think it is highly underrated. - - - Updated - - - "arduino language" is really just c++ with a couple of (sometimes annoying) transformations happening behind the scences. in many cases you can take the same arduino board and get a copy of avrstudio and program it straight c/++ without the arduino baggage.

never met a spider that my cats wouldnt eat.

alpha and beta voltaic devices exist, but these are very low power devices. as i understand photovoltaics, they only convert a very narrow band of the visible spectrum. id be more interested in technologies that can either widen the spectrum absorbed or divert the appropriate spectra to an array of narrow band cells tuned to different wavelengths.

oh great now i know what to name my variables in my guidence code. yay! now it can be less confusing than that video.

if you go with igbts dont forget to use a flyback diode in reverse bias, otherwise the energy stored in the coil can fry your electronics when you switch it off. you dont have to do this with mosfets since they have an intrinsic reverse biased diode.

little brainfart there, been spending too much time on other game forums where thinking is usually a bannable offense. of course i meant mass. going interstellar is nice and all, but i have a feeling we will be using fusion in space long before that happens. so an engine+reactor package you can stick on a single rocket and launch in one shot would be a great thing to have in order to bootstrap a more active human presence in the solar system.

i think something like a polywell or dpf will be better suited for space flight. tokamaks by their geometry tend to be rather large and heavy. direct conversion is a plus, but brayton cycle + radiators is also a viable option if your core can be made smaller.

we start building an invasion fleet.

engines like this will come in handy when we start exploring the kuiper belt in more detail. right now the way to do that is with a new horizons style flyby, which has its limits, only one or two objects at a time and no sticking around for very long. if instead you refuel at each object you explore and then pick up the propellant needed to go to the next object. mission can go on as long as the power supply holds out. it shouldn't be hard to find various ices on low gravity objects out there, you just need to set down and use your craft's waste heat to melt the ice.

old versions of directx were really bad. it didnt really stabilize until around version 8. upgrading just one version up could break some games. meanwhile opengl games from the same period work fine. i even had some luck with glide based games through a wrapper. but thats getting old games to run on new hardware, going the other way would be even more difficult. for one a lot of new hardware doesnt have win 9x drivers. though i did once see a video of

ive seen a lot of movies (from the 20s onward), so this would require more thought than i have time for.

the spice must flow

i am disapoint, not one dune reference.

i like to think of it as a potential cross between a hybrid rocket engine and an ion drive. or rather an ion drive running on a as of yet undetermined solid fuel.

you could probibly check for ablation by weighing it, letting it run for a long time, and then weighing it again. any loss in mass should be detected thusly. i think thus far all test articles were run for very short times due to the durability of the electronics in a vacuum. (ninjad) have they tried the device in different orientations with respect to earth's magnetic field? might there also be inducing eddy currents in the copper frustum giving it its own local magnetic field, which might attract it to the nearest metal wall of the vacuum chamber. i know they rotate the engine on the test apparatus to determine that the force is directional, but if the center of magnetism is offset, it could also cause the device to be attracted to the opposite wall of the chamber which is now closer. you could probibly check for magnetic effects with a magnetometer array to see what kind of fields are in play.

im firmly in the 'conquer them first' category. we need to find them and kinetically bombard their cities, when the nuclear winter sets in we land the shock troops.

i tried building air cars out of lego, the results were not that spectacular. of course you cant get much air into a duct tape reinforced coke bottle without it exploding. had a car that could drive across the room before running out of air, it had this cumbersome trailer for the 3 coke bottles that powered the thing. i had 3 servos on there, one for steering and 2 to actuate the 3 speed + reverse transmission. i think i was running a 4 piston pneumatic engine but im not sure. drive time never exceeded 30 seconds.

it might be more acceptable for manned missions using nuclear-electric propulsion. you can always eva to swap out a thruster with a spare or bring them in for regular maintenance.

assuming the engines have a 180 degree range of motion, you can get 5 degrees of freedom with just two at opposite sides (left and right in this case) of the cg. this gives you roll, yaw as well as translate vertical, horizontal, and forward/back. you could control pitch while using forward thust, but that is not desirable for a docking manuver. you need a third one for pitch, though you could just use a pair of fixed thrusters for that. the configuration for a 3 thusters would be kind of like a 'T' with the center of the gimbal range aligned with the line segments of the character. the center of thrust for yaw, and horizontal translate modes would need to be at the same point as the cg, though with variable throttling you can gain a little bit of trim control. 4 thrusters in an x config gives you a little redundancy should one fail. for example of course the 180 degree gimbal such as this is mechanical in nature and offers the spacecraft yet another point of failure. you got hoses, bearings, servos, all of which can go wrong or get damaged by debris. since you only have the one system you dont have a backup system in case something goes wrong. with a main gimballed engine and a separate rcs system you have one should the other fail.

i once managed to rescue a ship on a high (300ish km iirc), but planet intersecting trajectory when its reactor overheated and blew up (i was using one of the nuclear-electric mods) making the engines useless. this happened before the circularization manuver and so the ship was pretty much doomed. fortunately i had another nuclear electric ship in a lower, circular orbit. with a great feat of rendezvoodoo i managed to plot an intersect of the two orbits just minutes before it hit atmo. this was followed by one of the quickest and dirtiest dockings i had ever pulled off. that was followed by a radial burn to push perigee far enough out of kerbin to not die. there was a little unintentional aerobraking involved but it worked. it was nerve wracking and took 3 reloads to pull off correctly. doing similar with a sub orbital vehicle and an engine module would be even more difficult. you would need enough extra fuel on board to abort the maneuver and re-orbit the engine module should something go wrong. however the whole thing could be planned well in advance. one thing you couldnt begin the de-orbit burn until the sub orbital module module and engine module are right on top of each other, posing a collision hazard at high relative velocity (compounded with the fact that you are actually wanting to get as close as possible). you then need to bleed off the difference in velocity very quickly, followed by a quick and dirty approach and docking. i think the current school of thought on docking at nasa is slower is better, and this would be the complete opposite of that way of thinking.

first off i consider the evolution of air combat is as such: 1 recon: lets see what the enemy is doing 2 bomber: while were looking at the enemy lets drop some grenades/mortar shells on them. 3 fighter: shoot down the above so they cant look at us or bomb us 4 cas: while we have these fighters with machine guns why dont we use them to support the ground forces 5 multirole/superiority/fighter-bomber: hay lets build a plane that does everything! 6 strategic bomber: lets make our bombers faster/fly higher so they cant be shot down, oh and lets give them nukes! 7 stealth: haha you cant see us enter drones. first job we give them is #1. we realize we can put munitions on those drones, or better yet, make the bomb a drone (jdam) and now they are doing job #2. because drones can do manuvers that can kill human pilots, they can evade fighters or even attack them decisively, which sort of makes #3 obsolete. 4 is one of those jobs that i think really benefits from a human pilot, since you are directly supporting troops on the ground, so that one is safe. since 1-3 can be done there is no reason why we cant have multirole drones, i think we already have them. #6 is another place where we want humans in the loop at least as far as nuclear munitions goes, however the ability to send a jdam means that this one is split between drones and manned. 7 is another thing drones can do. so thats my view on the future of air combat.

bricklink is your friend.

i use mint on my lab computer and the version of debian for raspberry pi. i think i learned more linux voodoo with that raspi than i think i ever had using it on a pc.

i think you would see a flash but this would quickly be obscured by massive clouds of steam.

pac man