Moach

say, i thought of a very, very simple concept to solve the whole command pod restriction deal.... since there\'s no 'selection screen' feature on the upcoming list yet, i thought we could try something... whadda you say, if i would model us a 'dummy' pod? - say like a low-poly ball, something that looks kinda like this: and the idea is - you start off with that inane ball of irrelevant hardware - then, it being somewhat small, you can attach the pod AROUND it, so the pod mesh itself ends up being a strut (or maybe an SAS module) it\'d require a revision of the collision meshes for pods to be made compatible with this - or, the pod-ball could have a seriously offset collider itself, so it won\'t intersect and cause stuff to pop off.... it would allow creating unmanned vehicles, and/or changing pod models at a whim.... but it\'d need a minor degree of cooperation from other modders to create struct-class pods that could be used with this thing..... this isn\'t really anything hard to do - but given the planned feature overlap, would you think it\'s worth it? or do you prefer waiting for HarvesteR to put in the whole pod selection deal?

yep, noted -- i have verified this same problem myself.... that thing is busted, not sure why... if anything, creating an action and batch to do this is quite easy.... open any of the redbugged files create a new action and start recording double click the background layer (promote it to 'layer 0') save and close stop recording now, go to file->automate->create droplet... check that the selected action is the one you just created.... choose somewhere to save the new droplet file (overwrite the old one, perhaps) check all the four checkboxes, set destination to 'none' now, create yourself a new one, then drop all the remaining 24-bit pngs found in the parts folder to it.... should work :thumbup: mind then, that\'s exactly how i created the old one... facepalm award goes to adobe for that thing only works on the PC it was created (so much for sharing.... which ironically, was the whole purpose of them droplets)

there seems to be a problem doing this when the radius is below 1... and since the pod has 1m diameter, its radius is .5, - which squared yields .25 (half of one half).... i worked around that by using a different order of operations, and multiplying radius by PI before squaring everything.... dunno if that could lead to any mistakes - for which i must 'thank' my 'wonderful' childhood math teachers and the 'glorious education' they gave me (read the quoted parts as intense sarcasm) i hate how much i suck at math... i really should be better at it by now.... i mean, i can do the logic, but this gradeschool stuff always has me fumbling in the most shameful ways... well, given the importance of this, i think it should be stickied.... if it were on the projects board, i could go ahead and do it myself... but since some forum weirdness took my global mod superpowers away, i cant do it here

it was tricky... i had to calculate the volume for the tank based on the difference between the top and bottom nodes - then from that i figured out the volume of the tank as a cylinder with 1m diameter which i then divided 500 from, yielding a measure conversion between volume and capacity noting that this is for a 1m part, then all you need to do for larger/smaller diameters is multiply i might have screwed up the math... it happens with an alarming frequency for me, but i have some confidence (hope) that this is somewhat correct

got it down for liquid fuel tanks: Fuel Capacity from tank height and radius - based on default tank Rated volume (from a calculated 1.51 height based on the distance between top and bottom nodes) 3.701m³ fuel capacity to tank height ratio (volume/fuel) = 135 (for 1m radius tanks -- multiply by radius for others) tank weight to fuel capacity ratio .0044 dry mass to tank capacity ratio .0006 explosive potential to fuel capacity full 0.0016 empty 0.0002 edit: got LFE\'s as well now: Liquid Fuel Engine parameters - based on stock LV-T30 model Thrust to engine weight ratio 0.01 Thrust to heat generation ratio 2.5 Thrust to fuel consumption ratio (fuel units) 0.04 Thrust to fuel mass ratio (mass units) 0.000176

i propose we create a table of sorts, based on the default parts and a few 'classic' addons (which seem to have a certain degree of accordance between eachother) and try to zero in on a 'balanced' set of ratios for each value.... let me give it a shot - hold on, i\'ll be back shortly :thumbup:

my programming carreer started off pretty much exactly like HarvesteRs.... not because its some weird 'twins telepathy' thing - (urban myth, IMO) but because we did go to the same game development course in college.... : started with *uurgh* AS2, then onto AS3 (a lot better less bad)... JS is rather self-explaining from that point... got some experience with C# too, but my favourite is C++ ah yes, nothing beats a language that unlike others, doesn\'t ever expect you to manage shooting yourself in the foot so often that you must be kept at a safe distance from the 'hard' stuff (pointers, OS stuff, etc...) - often at the cost of flexibilityy and performance.... no, in C++ you ALWAYS know what you\'re doing - \'cus well, if you don\'t, then you\'re kinda in for it..... but i really like the fact that it will absolutely not compile at the slightest sign of trouble.... newbies may find that aggravating, but after dealing with JavaScript and other 'it\'s ok to be wrong'-type languages that leave you doing CSI work to find that one line of code where you got a type-o as the compiler thinks 'it\'s ok, he\'s probably defining a new variable....', you\'ll find yourself thanking sweet heavens mercy for getting compiler errors a lot became much simpler after i realized that C++ wasn\'t really hard - it only seems so at first because MSVC is so bloated and unclear interface-wise.... nowadays, i\'m working with HaXe... which although is not as awesome as C++, still beats the living crud out of AS3... some months ago, i devised the general layout for a new language, more suited for Flash development, which i called AXIOM.... it was a mix of HaXe and C++, meant to exploit some low-level stuff that flash can do (if you have buckets of patience) in a most straightforward manner, built around syntax features, then converted to more verbose HaXe by a precompiler..... i did get around to coding that precompiler.... and it was working... but since it was taking too long, i decided to return to my real-work project and finish that at a more civilized day (perhaps when i finish said project) - if i don\'t decide to have Flash thrown out the window altogether by then... anyways... what was i doing... ah yes, i got a class to code here.... back to work now :cheers:

hmm, the DL link for the droplet fix was broken - fixed it: www.moachcraft.xpg.com.br/whatnot/Moach_KSP_TextureFix.zip :cheers:

that\'s because the default 'lock' isn\'t really just a lock... when PS has a layer set as 'background', it enforces a rule of 'there will be no transparent pixels' to some sense... if you double-click it, it offers to 'promote' the BG to an actual layer... and from then on, it allows 'end result' pixels to be less than fully opaque, i.e: allows transparent pixels in the final image adobe livedocs says: the presence of such a 'background layer' is the turnkey factor for 24 or 32 bit depth when saving PNG\'s - it being locked or not doesn\'t really matter, as long as it\'s not 'background' :cheers:

regardless of transparency - yes, but ONLY if you have the BG unlocked - if not, it goes 24-bit too.... so it seems if you\'re saving by ctrl+s, the bit depth is decided upon the status of the BG layer (you can\'t have transparency with it locked), while save-for-web goes by the presence of transparent pixels in the image or not as a rule..... we appear to be reaching a veredict :thumbup:

the 'save for web' thing appears to have a more thorough compressor which may do you a better job in squeezing every byte off the image file.... albeit, for PNG, there doesn\'t seem to be any aditional options compared to the traditional 'ctrl+s' method.... redundant perhaps - confusing, definitely :: it indeed appears to be more realted to the 'background' status of the image.... if it reads 'layer 0', you get 32 - 'background', and it\'s 24.... meanwhile, the relevance of the transparent pixel remains elusive....

by unlocking the BG to layer, you get 32-bit regardless of having transparency anywhere (i have verified this by running a batch on ALL my parts which no longer suffer from any redbugs) so you\'re saying that without unlocking it, you can also get 32 bit depth if you have at least one transparent pixel.... thats nice to know - it appears we have this alternative then :

it certainly appears to work that way : it also seems irrelevant to whether or not you actually have transparent pixels anywhere... unlocking the BG into a layer is what defines it to 32 bit, i figure and that\'s what the 'droplet' i posted before does - it simply takes each file, promotes the BG to layer and saves it again... i tested it here and i get no more redbugs - all fixed :thumbup:

if you\'re using photoshop, i have a quick fix for ya! i\'ve put together a 'droplet' (works kinda lika a batch shortcut deal) which opens the image, converts the 'background' to layer, then saves and closes i found that if you save a PNG with a locked 'background' layer, PS will automatiically make it into a 24 bit - then you get problems (the infamous redbug) but if you 'promote' the background to a layer (even if there are no others behind it) it\'ll assume there\'s a possible alpha channel there - and saves as 32 bit - solving the problem once and for all... so while this only works if you hhave photoshop, it does make life a LOT easier..... in simple steps: 1 - download droplet 2 - open KSP/Parts folder in windows explorer, search for *.png (using windows 7 here) 3 - set view mode to 'details', right-click the cllumn headers and open the 'select display items' thingy 4 - enable the 'bit depth' item, then have it sort your icons based on it 5 - get all the PNG\'s found under 24 bit, drag and drop onto the droplet icon 6 - have patience while photoshop grinds them down one by one.... 7 - ?? 8 - profit! :cheers: hope this helps :

alright! got new stuff :thumbup: - see first page

not sure i follow.... what exactly do you mean by 'attached to the part above it'? i just took the CFG from a regular decoupler and modified it to match my needs... i set the attach_bottom and attach_top just a few centimeters apart, in a way that allows the shield and pod meshes to overlap just a bit when attached so while i can\'t be of any further help since i don\'t exactly understand the question (might be \'cause i\'m a little drunk) - i advise you to look in the heatshields CFG file for anything that may help... there\'s really no secret there anyways, from the cfg... // --- node definitions --- // definition format is Position X, Position Y, Position Z, Up X, Up Y, Up Z node_stack_bottom = 0.0, -0.05, 0.0, 0.0, 1.0, 0.0 node_stack_top = 0.0, 0.0, 0.0, 0.0, 1.0, 0.0 // --- editor parameters --- cost = 1200 category = 3 subcategory = 0 title = HMMC9 HeatShield manufacturer = Kwersix Kitchen wares & Co. description = the HMMC9 is the debut of the company\'s line of spacecraft products - although given some funny looks by overzealous scientists, reentry heatshields aren\'t (we hope) too different from oven mitts! - and better yet, it\'s ASBESTOS FREE! // attachment rules: stack, srfAttach, allowStack, allowSrfAttach, allowCollision attachRules = 1,0,1,1,1 // --- standard part parameters --- mass = 0.2 dragModelType = override maximum_drag = 0.2 minimum_drag = 0.2 angularDrag = 2 crashTolerance = 12 maxTemp = 5400 stageAfter = False stageBefore = False

yes, i'm aware.... will do as soon as i get the chance plus, i got a new part to add - the 2m stack tetracoupler, which fits 4 1m engines under a 2m bulkhead :thumbup: and it's not as unstable as the stock tricoupler : but right now, hunger speaks louder.... must... eat.... fooood...... :cheers:

noted, it does not work, for some bizarre reason.... for now, just remove it - it's a highly experimental thing anyways (sometimes works, sometimes kiills everyone)

lolz! or... in case that wasn't meant as a clever joke, MAC here stands for Moachcraft Amalgamated Components - nothing to do with a certain computer manufacturer and operating system ;D and actually - regardless of what system you're running, addons should work just the same in any case :

i'm aware of the largely improper quality of the recording.... i'm gonna make a new video later, on my home rig, where i get good FPS and have a microphone handy so i don't need to screen-cam with my phone :

hmm, ok, that's the launchpad - i think it might be TOO experimental to be in the pack, then :

8) well, i cobbled together a few of my previously released (rather loosely, i\'m afraid) parts and added a few of my new contraptions and stuff into a single pack, which i intend to turn onto a more 'presentable' collection of parts : so, without further ado, i give you the MoachCraft Amalgamated Componets set! :thumbup: this pack includes: * the LES kit (unaltered), with abort engine tower, cone decoupler and stackable parachute * a revised version of the heatshield, with a better mesh and deflection-lift capabilities (will not override - old one not included) * my highly experimental launch-pad base decoupler (check 'crew' category in VAB) * the all-new long solid booster featured in edit: new stuff! * a compact and convenient SAS module designed specifically for upper-stage modules (where theres little rotating mass to stop) - applies a mild rotation damping to hold still wherever it stops (zero-Ki) * the infamous 2m TetraCoupler - attaches 4 1m engines in a triangle configuration with a fourth in the center * removed the non-compliant launchpad part which did nothing but cause problems on loading * set all textures to 32 bit depth (no more redbug) * re-classed the aeroheatshield to 'strut' - the new winglet class made it VERY unstable now, let\'s have a little photoshoot and i\'ll post pics in a bit.... the link above has been updated - go get it :thumbup: enjoy - :cheers:

ok...i made a video of me flying a straight-to-circular orbit and reaching a previously targeted altitude with a gravity turn... this also shows a new type of solid booster i made which burns weaker for longer (more realistic).... but the main thing is that it demonstrates how it's possible to perform the direct-to-orbit launch and become circularized at the target altitude before 12 minutes in flight i hope it's possible to learn a thing or two from it.... not sure if i explained it well enough (i was kinda busy with the flying and all) : :cheers:

sweeet! - this is gonna be awesome! ;D what's the diameter on those parts, if you don't mind me asking? - does it match that of other existing bits?

a general ground rule here would be, for every 'G' of accel you intend to put your parts through - add one level of symmetry for your reinforcement struts... that should (hopefully) keep your vehicle in one piece the same number of pieces you expect it to be