Nuke

Explodey Death Machine

two pages and noone posted babylon 5? sad, very sad.

the google is strong with this one.

https://en.wikipedia.org/wiki/Elite_%28video_game%29

this is why im switching to reactos as soon as it hits beta.

as a proponent of the raycast drag model i must say that im actually rather impressed that you took the time to give it a decent testing run, dispite your previous assumptions that it probibly wouldnt work. you are indeed a true rocket scientist. i guess this challenges everyone to tweak the code and see if we cant cross off some of them cons. of course im completely lazy and i dont want to have to code another *expletive* drag model.

years of playing orbiter have made my space skills so good its almost trivial for me to go entirely stock. but i play the game mostly for the fun of it and for me that involves mods. so many mods it takes me nearly 5 minutes to load the game on an i7.

all the ones i can find + trial and error + existing knowledge of virtual cockpits in other games. i actually started porting some old models i had, but their interiors were designed for humans and need to be adjusted. other than that they work in game. anyway with the pictures of kerbals and established height thereof i think i can produce an analog with that. unfortunately i got sidetracked by a less important electronics project.

im modeling some cockpits and need some proportional guidlines for desiging the chairs, panels and controls of the cockpit to make them suited to the kerbal's proportions. what i need is some kind of stand in model with the right proportions, it need not be very good nor does it even need to be textured. it can be modeled with cylenders and spheres for all i care, but it does need to be the correct proportions for a seated kerbonaught wearing a space suit. does anyone have such a model on hand or at least some kerbal measurements so i might produce my own?

not much difference than going to mun, just need to do a course correction to compensate for the inclination (rotating your plane is more efficient while your orbit is eccentric). you can also time it so minmus is at the ascending/descending node when you get there. minmus has very low gravity so its a hard target to hit, on the other hand its also a slow target so its easy to sync orbits with it if neccisary. you can also take off from/land at minmus with your jetpack (probibly not enough pack fuel for a round trip)

i noticed that to get 6x symmetry, a value of 5 seems to work, a value of 4 doesn't seem to work at all. after sciman brought to my attention that i was using the symmetry setting incorrectly in my half meter parts, my first guess was that stack symmetry values corresponded with the symmetry settings in the vab (supporting the enumeration hypothesis). i tried a value of 3 in my quad coupler and it worked. i inadvertently changed symmetry in my 19 coupler to 5 (theoretically it should have been 4 but when i tested it it worked as expected), and this allowed me to fill in the inner 6-ring with 1 engine placement and the outer 12-ring with 2 engine placements. id bet that 4 is reserved for some as of yet unimplemented feature (5 way symmetry?). id suggest trying a value of 6 or 7 for 8 way symmetry. i dont have an 8 way adapter so i cant test this.

dont worry im working my way up to little boy.

perhaps what you fail to realize is that if that ship crashes it will go up like a north korean nuclear weapon.

yea im still working on them. i kinda got side tracked by another project/colonizing the kerbonian system. i think most of the bugs have been addressed, though i still want some more feedback about balance before i upload a new (probibly going final if there are no more bugs found) version.

my method for deorbiting spent ships for disposal is to fly up next to them with another ship, eva over, point the ship retrograde, light the engine, and hop out before it gets too far away from your other ship.

thumbing through my photobucket for more goodies. similar design as above, but with the plan to get extra fuel into orbit to refuel my fleet of colonization ships. thats 3 5m tanks by the way. depending on where i park the thing (and im not given much of a choice because its very hard to steer the thing) i usually have between 10000 and 20000 units of fuel left for refueling operations. needs a re-design though as im convinced i can get 12 boosters (they're 1.75 meter tanks with large berthas) instead of 8 on there (spinneh station used 12, but with only 2 tanks each instead of 3, will work on that). i want a 2 kiloton booster, but the vab is kinda small for that. im also starting to move away from magic refueling mods like the romfarer lazor system (they feel kinda cheap) and use docking mods and the like. id rather just send a kerbal out to run a fuel hose during an eva, but nobody has made a mod for that yet.

thanks for bringing that to my attention. probibly explains why stack symmetry never worked. it was try this, nope, try that, nope, aw screw it. i figure the stack symmetry was never meant to be used on couplers with concentric rings like my 19coupler. the outermost ring has a different symmetry than the next ring. compound that with the fact that the outer ring is offset by 15 degrees. i figure i could probibly get one ring to handle automatic symmetry, but not both, and probibly not the outer ring because of its offset. i doubt a value greater than 5 would be recognized, as numbers 0-4 seem to correspond to the 5 symmetry options available in the vab. best bet would be to go for the 6x symmetry. you would at least get the inner ring in automatically. because the outter ring has 12 nodes and that number is divisible by 6 it seems it would theoretically be possible to populate the outer ring with engines by simply placing two of them, assuming the angular offset doesn't effect it. *edit* yep i was right. seems a symmetry of 5 lets you load up the 19-coupler by placing only 4 engines. which is a real time saver. these bugfixes will be in the next version (ive already applied them to the dev version). though id like some more feedback on other issues before i roll out a new beta.

beta 2 is out

i think i ramped it up to test the glowey effects and forgot to ramp them down again. will be fixed in the next version. technically the mpd thrusters are kinda nerfed. some of the theoretical designs can produce as much as 60 newtons of thrust. the catch is you need about a 1-2 MW reactor just to power the thing. so i went and used specs for vasimir instead. the weight nerf is to compensate for the fact that i still need to figure out how to do an actual reactor and power systems so the engines consume electrical power and fuel to run. il try to kill the overheating issue though. its not something i had intended. you should be able to run the thing at full blast for long periods of time seeing as they only put out about 5 newtons each. i figured its been awhile since i just played ksp, so i launched this with help of a couple of the undeviginti couplers. the thing is way more useful as a base component than it is as a coupler, or a fuel tank for that matter. i think il make it much lighter and drop its fuel capacity to about 1000.

theres always the 2001 soundtrack or wagners ring cycle *runs*

i had intended that engine to be used as a stabilizing thruster, so you could use a bunch of big fixed engines and then put a few of these around the side of the lower tank in the stack to kinda help steer the behemoth (when i launch i go for tonnage, launching kiloton boosters and putting jon's law to the test). used as a standalone thruster its not very good. im not sure if its a thing i want to fix or not. i may tone it down in the near term though. *warning* wall of theory *warning* i kinda have some experience with control theory and some with pid controllers, but on the hardware side. the first thing i learned was that proportionality matters. essentially you have a a control signal, an error (or feedback) signal, and the thing you are controlling. for ksp your error is in degrees of rotation and falls into the range of (+/-)0..180 (or 0-pi if using radians), and the range of control is (+/-)0..gimbalRange. what ive been seeing is that when the error is small, within a degree or two, the gimbals are snapping all the way over to gimbalRange, and likewise when it traverses zero with great angular momentum, the gimbals snap to the other extreme. what should happen, is that the gimbal angle should be proportional to the magnitude of the error by some factor. if you scale down the (+/-)0..180 to a range of (+/-)0..1 and then multiply by pF (your proportionality factor), and then multiply it by gimbalRange to get the angle of the gimbal (you cap it there as well incase pF > 1). you can even do this on a curve if so desired but linear relation always worked in my algorithms. enter pid algorithms. even responding in proportion with the error is not enough. so throw in some calculus terms integral and derivative. the integral part looks for and corrects recurring errors. and derivative corrects for errors predicted errors. most pid algorithms represent the terms as a series of weights. so a set of pid numbers 20,10,10 (these may be floats but ive only done hardware side pid and most of the time they are integer values rather than floating point values), would give twice as much weight to the current state of the control system as opposed to the past states or predicted states. i dont think the pid algorithm is at fault though, they really need to be tuned for the application or even adjusted in real time based on changing situations. i think whats wrong is the proportional scaling described in the previous paragraph. i kinda hope its something they (devs and plugin makers) work on in the future. possibly by making the pid values user tweakable on the fly. *end wall of theory* so for now i may tone down the gimbal ranges on the engines, or create specially tuned sases to make my parts work better. to sum up heres a list of known bugs: 1 - some normal maps need to be tweaked (namely the lf tanks and im not happy with the nosecone either) 2 - control problems with gimballed engine 3 - balence re-evaluation needed 4 - i dont like the glow animation on the mpd thruster, its going white hot too fast. let me know if i missed any. should reiterate that the purpose of this beta is to get feedback, find problems, and improve balence.

yea i need to tone down some of the normal maps. im kinda inexperienced with normal maps. other stuff i had done involved baking from high resolution mesh. but i used 2d techniques to generate these to save time. as for balance i think i used the calculator that was available back around the time .13 was released. i couldn't find it anywhere when i went looking for it to re-check my values. the large undeviginti coupler is definitely not balanced, as it carries a sizable portion of fuel (i did that so i could play around with vtols). but its heavy and makes a good hub for space stations and moon bases. need some more up to date balance guidelines. i also notice a thing where mech jeb likes to go bang bang on gimballed engines' gimbals (not enough p in their pid), i think the standard asas does as well. might do a custom asas for that with better tuned pid values.

well thats why its beta1 and not final42

theres always hank 3 and marduk, with some cash, coe and sarcofago hank sr. and celtic frost thrown in for good measure. country and black metal for the win