Nuke

the military is for whatever the state that runs in says it is for. this could be "peacekeeping missions", this could be "defensive maneuvers", could be a "police action" and it could just be making sure the trains to the death camps are on schedule.

for some reason every modeling program that i have ever modded on has had this problem with whatever game i was modding. its something to get used to. rotate your mesh 90 degrees on the x axis. idk how to do this in blender, im a 3dsmax user.

even playing purely stock some of the tabs seem a little bit more crowded than others. add mods and it becomes a nightmare. engines and tanks should each get their own tabs. utility needs to be busted up into like 3 different tabs (electrical could use its own tab, so could wheels). modders should be allowed to add their own tabs so they can stick all their parts there. also is it too much to ask for each tab to remember what page you were on last time you had it selected?

yea but then the solar panels and their structural trusses are heavy. batteries are heavy, rtgs are heavy, nuclear reactors are heavy. there is no way around the problem. you want a supply to give you the most electrical power with the least weight. also a thruster is a thruster no matter if you point it front back or sideways. in ksp i have been known of using ion engines for steering using exotic action groupings. ive also done orbital transfers purely on rcs power. im quite fond of thruster arrangements that serve both purposes.

i also own an r/c heli. hobby grade parts work for us but are not that well designed. they are built for mass production and are made more cheaply that what you would see in actual aircraft applications. the motors and speed controllers used in r/c applications are not quite the state of the art (if they were we wouldn't be able to afford them). the primary point of failure in a brushless motor is the bearing. the smaller motors are much more sensitive to imbalance than their larger cousins. as motors get bigger you can start using fluid, air, or magnetic bearings instead of ball bearings and active balancing. hobby grade speed controllers have to be small and light while pushing a lot of power, they get hot as a result and are often designed with insufficient heat sinking. larger motor controllers will need to push even more power, so they use higher rated components, need better cooling systems, possibly active cooling. its an engineering problem that is quite workable.

most electric thrusters are quite small. its the power supply thats big and heavy.

in an environment of increasingly harsh conditions and dwindling resources, war is inevitable. genocide often comes with war. at this point its join up with the state or become its enemy. last place you want to be is on the conveyor belt in the murder mill.

The performance of small brushless motors have lead to a boom in their use in r/c aircraft. Then we started seeing them in sport class aircraft, solar powered research aircraft, etc. This has made me somewhat curious about the maximum limits of electric propulsion which can be achieved. Currently there are limits on the power output of aircraft power systems. It takes many megawatts (mechanical) to keep a commercial airliner flying. Suppose this problem went away. perhaps you have or or more 100MW polywells onboard. regardless of the power supply, what could you do with it as far as propulsion goes? could you achieve supersonic or hypersonic flight purely on electrical power? what about non-mechanical systems like what you see on ionic lifters, would they offer any improvement over electric ducted fans or props?

i have one but i havent uploaded anything in years, no ksp content.

when it comes right down to it, humans are horrific creatures. in the decay of civilization this will inevitably cause, those with the power to do so will horde and ration out resources, let people live, and dispense murder whenever it suits them. forget about suicide booths, there will be cannibalism.

i got one on my todo list for the half meter parts pack, but i havent been feeling very artistic lately.

point is that is part of earth's formation. a very violent, all be it natural event. you still cant compare that to events caused by climate change through biological/artificial means.

the current state of the planet is that the poles are mosty uninhabitable, and the equator is a little warm but livable. i have a feeling things will flip in this scenario. the equator becomes uninhabitable, and the poles hold the bulk of humanity. the north would be ruled by eu, canada, russia, and the united states of alaska. the south would be run by australia, new zealand, south africa, chile, argentena, and the antarctician emprie. the rest of the world will be ruled by giant sandworms. i dont think we are close enough to the sun to become a venus-ish hell hole. i dont think that counts. that environment was caused by a planetary collision (the one that formed the moon). its also interesting to note that the first life came into existence in the era directly following that one. earth tends more to snowball, i dont think we have ever had any long term bbq-grill-earth events since the end of late heavy bombardment.

coders sometimes need the art department to make some graphics to test features they just coded. but since artists are rather busy people with a todo list a mile long, they will just do the bare minimum for the coders to do what they do. eventually the coders will shift from adding features to fixing bugs, and the art department would then be free to cross items off of their lists without the coders bugging them so often. its pretty much just an artifact of how development works.

A1 = JS2.A3; A1 = A1*116; A1 = A1/100; if ([A1 > 255]) then A1 = 255; endif CMS.A1 = A1; the first line copies the throttle axis to a variable, if your throttle axis is somewhere other than js2.a3, change this, the format is js(stick number).a(axisnumber). the 116 in the second line is your scale factor. i want to map the output into the range 0-255. but my throttle only seems to have a range of 0-224. i want the threashold to be around 220, so there is a small deadzone at the base of the throttle. 255/220 = 1.1591. but since you are using int math this number doesnt make sense, so multiply it by 100 and round to the nearest integer, in my case 116. thats also what the A1/100 in the following is for, its essentially decimal fixed point math. the last line saves the variable to one of the cms axes. remember to leave the physical throttle axis unmapped and map the cms axis in its place. i also have the revers flag ticked in my cms control, that is probibly important.

probibly not very much. just its orbital parameters. its peanuts.

i think kerbals should get paid in chickens.

you could probibly support both libraries, conditionally using one or the other based on your platform. the data they output are pretty much the same, though linuxtrack has a few other functions to export. it would be nice if we could support all tracking devices on all platforms, but no unified multiplatform head tracking library exists. for example linuxtrack doesnt look like it supports inertial trackers. ftnoir and opentrack, don't support trackir cameras, freetrack does albeit kind of unofficially, but it is the most cumbersome to setup and quite well aged. i suppose its possible to support all the interfaces (except, ironically, naturalpoint's), having some kind of autodetect. the freetrack protocol does seem to hit most of the bases though, except for linux/osx. so two protocols is probibly enough.

different joysticks have different response curves, some are adjustable, others are not. frankly i like linear response curves (saitek is notorious for funky non flat response curves, fortunately im a ch user). then again in space joystick usage is completely different from in the atmosphere. in the atmosphere i want zero deadzone and a flat curve. but in space i like a little bit of a deadzone so that thrusters remain off with the stick at about 5% of its range, ramping into a linear curve within another 20% (essentially a j-curve). then again i want my gimbals and reaction wheels to be linear with no deadzone, but my thrusters to do a j-curve with a deadzone. with the throttle i want it flat but with a safe zone at the lower 5% (not the middle, idk why ksp puts the deadzone in the middle of the throttle, that doesn't make any sense) so that i dont waste fuel. for some reason my throttle doesnt go all the way to zero and it sometimes wastes fuel because of this. i actually have a throttle safing script in my ch profile to avoid accidental firing. needless to say i like to have different joystick parameters for different flight modes, different control methods (thrusters, reaction wheels, control surfaces, gimbals), and possibly even for different craft. some craft maneuver more aggressively than others, so no one set of settings fits everything. so some kind of input scaling options would be a good idea, possibly exposed through tweakables.

both nuclear ramjets and ntr prototypes have been built and tested, and both proved viable. seems all you would need to do is change over from propellant to atmosphere as needed. this seems a simple matter of closing the intake and injecting lh2 into the engine when atmospheric operation becomes impossible. i have a feeling you wouldn't need a precooler though, besides you would need to spend hydrogen in air breathing mode to run the precollers, and you want to save that hydrogen for when there is nothing to intake. then you got the problem where a ramjet doesnt work subsonic, or or past mach 3 or so. perhaps some kind of hybrid ram/scram configuration. still this isnt an engine you can launch from the ground. perhaps you can combine turbojet/ram/scram into a single nacelle and somehow fit a nuclear reactor in there as well. perhaps fit a single reactor into the fuselage and run heat exchangers to move thermal energy to the nacelles, which would be beneficial in a radiation containment capacity (it would be the coolant loop of the reactor, not exposed directly to the core but through a heat exchanger). you still wouldn't need a precooler, because the turbine would be isolated and shut down at around mach 1 when the ramjet takes over, heat is less of a problem with this type of engine. i rather like the idea of a nuclear engine that can work surface to space purely on nuclear power (and without any regard to atmospheric composition). you can land at titan with the same engine you took off with from earth. it would certainly allow flexible spacecraft design. the other side of it is it sounds so complicated it probibly wouldnt ever work. not to mention you end up with a ship suboptimal for transfers (assuming space plane). what about an air augmented nerva? same concept as an air augmented rocket, but with a nuclear engine providing the heat.

thats why you do it on a different thread. if you did it on the same thread you would need to spend a lot of time waiting for data. do it right and the game wont even know that there is another thread moving pixels around. you might get some bus contention on the pci-e interface, since textures being streamed in need to be moved to the video card pretty quickly. the best time to do this is while physics is being handled, when rendering is not being done pci-e traffic should be virtually non-existant. whenever you have a race condition the rule of thumb would be the main thread goes first. the texture loader doesn't need to operate in near real time like the main thread. the other big rule is that you must always have something to draw when something unexpected happens. last thing you want is to have to load a gig of textures when two spacecraft with different sets of parts meet. so a bare minimum of data needs to stay in memory so that the object can be drawn when it needs to. higher definition textures can load over the course of several frames, which is a blink of the eye for the player. but you can still draw with the low res data until that happens. that way you never have to wait for the hard drive (in the main thread). as for the memory cost: most squad models are under 100k and a 64^2 (a good minimum) texture would be 12k. thats certainly much less compared to the 512^2 textures @ 768k by themselves (times hundreds of parts). you are not going to save all the memory, but you stand to reduce your memory usage a lot.

it looks like opentrack can emulate the freetrack interface. so you can use that to open up a lot of other interfaces that wouldn't otherwise be supported. the downside is that it doesnt support freetrack api on linux. which really doesnt make sense. the source for the freetrack dll is available here (its freakin' pascal), im surprised nobody ported it to linux. seriously it only exports like 4 functions. might be possible to build a wrapper to convert linuxtrack calls to freetrack calls on linux.

orders of magnitude. cfgs (a few k) models (tens to hundreds of k) textures (a few megs) thing about textures is you can down sample them fairly quickly (or preoptimize them in a compressed format with pre-generated mip maps but i wont go there for simplicity, thats another discussion entirely). the formula for texture memory usage is w*h*bpp. for technical reasons power of 2 textures are preferred. 24bpp is common for 3 channel uncompressed bitmaps (dxt1 can do 4bpp, but again thats a different discussion). a 24-bit 1024^2 texture has mip levels of the following sizes: 1024 - 3072k 512 - 768k 256 - 192k 128 - 48k 64 - 12k 32 - 3k ... as you can see just dropping a couple mip levels shaves a lot off of your texture size. so if the textures to all your unused parts dropped down to the 32^2 level, you free up a lot of memory. if you track your texture usage stats internally, load higher resolution versions of textures that are used a lot, unload high resolution content that is not used at all. since texture usage changes based on gameplay, you need to keep on the ball to optimise texture quality vs usage while meeting a memory usage target. you can do this in another thread for best results. textures are usually passed by reference, because there is too much data to move around. thing about references, they can be changed quickly. so you can load new data->change the reference->unload old data. to do this on another thread you just need spin locks on those references, so you can only change them when they aren't being used (if they are buffer em up and try again on the next loop of the texture management thread).

you could probibly stream in and out the higher resolution mip levels based on texture usage (preferably in another thread). after all textures are the lions share of memory usage, the rest of the data is negligible. you do have to keep everything in memory, so if you suddenly need to draw something, you can without needing to wait. but you dont need to keep it all in memory, just what you need when you have an unexpected need to draw something. for example your ship might only use a tiny fraction of the parts available to you. so you can reduce the maps for those unused parts down to a really low mip level, like 64x64 so that you have memory for other tasks. now lets say you rendezvous with another ship with completely different set of parts. you dont have to wait for the engine to load any textures, just use the low res textures instead, and load the high res versions during approach, and once loaded you can start drawing those textures in full detail (which in most cases is going to be while the ship is still smaller than the target box) without a hickup while this happens.

SpinCalc is your friend.