[1.6.1] Tiny Parts and Other Useless Junk

[Nuke]

this mod is currently in the process of being adopted. old post content:

Spoiler

A pack containing half meter, tanks, engines, rcs, various adapters and decouplers as well as other miscellaneous parts of my design. Most of the parts feature normal maps, and engines have overheat effects.

*list removed because formatting derp*

Pics:

more here:

-link busted-

Changelog:

 

beta 1 - initial release
beta 2 - fixed normal maps for long and short tanks, and the nosecone
         mpd thruster overheat animation looks better now
         mpd thruster now produces less heat and is less prone to self destruction
         mpd thruster weight reduction from 1.2 to 0.8
         gimbal ranges reduced on mpd thruster and gimballed engine to compensate for bang bang control
gamma 3 - moar parts
          a lot more parts
          some of them even work
          new resources
          atmospheric bits
          some ships
          and a cockpit
          also no longer calling it a beta since i dont need a reason
          this version requires at least ksp v.18
delta 4 - 0.20 compatibility (now uses new mod heirarchy)
          all textures are now png
          NEW! structural lattice construction kit
          some parts now come in a larger sizes
          better colliders for parts that had bad colliders (like the cockpit and the tail boom)
          depricated arrrghohn, all hall thrusters and mpd engines now use xenon
          resized fuel tanks to more strict specifications to make them compatible with the new lattice elements
          rebalenced some parts (mono tank is a lot less useless now)
          atmospheric vtol engine can now be throttled more quickly
          *known issue* 0.20 broke the sound effects so that badass mpd thruster sound doesnt work
fred 5 -  the release that never was. mostly fixing things broke from the tansition to ksp 1.0. 
6-ish -   compatible with newer versions > 1.0
          built in tweakscale support, replaces large varients of parts (requires mod man)
          ckan compatibility
          extra redundency
          the micro girder kit i teased about years ago now has rudementry textures.
          the readme wasnt snarky enough so i added mor snark.
          extra redundency
          27% more new bugs
          some of my particle effects are now borked, they need to be remade under the new system (known issue)
          extra redundency
          
          
          
          

Download:

https://drive.google.com/open?id=1WPu-nxiyoI-xSWWkb_FJ5wDdqelR4jVk

a message from my cat:

Spoiler

5+96359+9*-+++++++++++++++++++++

legal stuff for purposes of the re-release of the mod by zer0Kerbal:

mod is released into the public domain. 

 

links to adoption dev threads:

 

this thread will be locked pending the addition of more links. 

Edited August 17, 2022 by Nuke
legal stuff, cleanup

[BlueSubstance]

Can you add some Pictures? I would download it then.

[XOOM]

Saying "Pics when I feel like it" isn't the best way to get downloads.

[RealHogweed]

interesting, but we need those pics

[Nuke]

i miss the good ol days of modding back in the 90s when a vague link was all you needed, crappy ascii art bandwidth permitting

i also apologize im a horrible screencapper.

[Glaucus]

Loving these parts, great work.

However the smal fuel tank is invisible.

And can you please make a half meter command pod with integrated mech Jeb.

[Nuke]

well thats why its beta1 and not final42

[Glaucus]

Oddly rebooted game again and it's working now would still love a 0.5m command pod.

[Ferrit]

This came up at the right time for me, just needed some smaller engines to accompany an aerospike main engine. I assume these are balanced to stock parts? First glance would suggest this is so, would just like to have it confirmed before I break out the calculator

Only minor complaint is the textures can strobe somewhat so maybe make them a little plainer?

[Nuke]

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.

[ashrobhoy]

aww cute engins

[Ferrit]

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.

Cheers for the promt answers and nifty parts

If I spot any major divergence from stock balance I'll PM you the findings.

The bang-bang on the gimbols (!!!) is one reason why HarvesteR and co' decreased the gimbol value after the frst release of the them. On the upside I'm fairly certain that better ASAS is on the cards sooner or later.

[Carthaginian]

Any chance of getting them with 'less bling?'

[Menecroth]

Well, you stole my idea for a set of smaller tanks and engines. I can't say I'm really upset though. I really need something like this so I think I'll try 'em out.

[Nuke]

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.

[SciMan]

well, if you're looking for the control coefficients then they are in the .cfg for the ASAS modules, it already has the control gains available, look for

Kp (proportional)

Ki (integral)

Kd (derivitave)

and I suspect that it is a simple matter of reducing the gains until it acts like it should. I remember that some people have made "tuned" SAS modules by tweaking those values in the past, it should work for ASAS modules, too

As for the MPD thruster, you could try lowering the value for heatProduction from 500 to something a little more than 450, because at 450 it just barely brings up the 'overheat!' status bar on the staging display even when at full throttle for extended periods. Regarding the balance, most of the parts seem fine, but the MPD is almost not worth it because even with the 5000s of Isp that it has, its so heavy that it takes like 10 minutes just to get from a 250km circular orbit around Kerbin to escape velocity, even with a really lightweight ship. Love the sound on it, tho!

Edited October 7, 2012 by SciMan

[Nuke]

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.

Edited October 7, 2012 by Nuke
i derped and forgot the image

[Nuke]

beta 2 is out

[SciMan]

Hey, I was looking thru the part.cfg for the quad 0.5m to single 1m part and I think I found the reason that my part symmetry options keep getting reset to "1x / no symmetry" when I attempt to attach 4 engines to it.

You set "stackSymmetry" to 4, thinking that it would mean 4x symmetry, but it doesn't.

I also noticed the same type of mistake with stackSymmetry on the 19x coupler, but for this one you set it to 6 (thinking 6x symmetry).

Here's the stackSymmetry values that i know work, and what KSP does for each one:

stackSymmetry = 0 : no symmetry

stackSymmetry = 1 : 2x symmetry

stackSymmetry = 2 : 3x symmetry

stackSymmetry = 3 : 4x symmetry <--- this is the one you probably meant for the 4x0.5m to 1x1.0m coupler

The next values are guesses, based on how KSP seems to be treating the values. I have not tested them thoroughly yet.

stackSymmetry = 4 : 6x symmetry <--- and this one should work for the 19x coupler in theory, but it doesn't... see below

stackSymmetry = 5 : 8x symmetry

stackSymmetry = 6 and above : KSP does not know what to do with these ones, so it just resets part symmetry to "1x/no symmetry" like it does when it can't find the right amount of nodes for any of the other options

I changed the stackSymmetry value on the "4x0.5m to 1x1.0m coupler" to 3, and now it works just like i think you meant it to, it sets 4x symmetry for the 4 engine nodes, and (just like the stock tri-coupler) "pops" back to 1x when I remove the coupler from the thing above it.

However, when I changed the stackSymmetry value on the 19x coupler to 4, it doesn't set 6x symmetry... for some reason. I can think of 2 reasons why it might not work.

Reason 1: KSP can't figure out which nodes are "symmetrical" to the one chosen.

Here's what i think KSP "should" be picking, if I understand how you thought KSP chose symmetry "partner nodes" correctly:

single center node = no symmetry

the 6 nodes around the center one = 6x symmetry

outer ring, every other "even" node = 6x symmetry

outer ring, every other "odd" node = 6x symmetry

Reason 2: My values for stackSymmetry don't work for setting anything above 4x symmetry.

It could be that "stackSymmetry = 5" means 6x symmetry, and if that is true, then "stackSymmetry = 7" might mean 8x symmetry

[Nuke]

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.

Edited October 9, 2012 by Nuke

[Khiro]

Are these parts still in beta and being worked on? Definitely interested in small parts, and yours look really nice and shiny!

[Nuke]

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.

[Majiir]

Gods they're so ugly, in such a beautiful way. I'll have to try this out.

[Riley Evan]

Screenshots look decent, but agree with the comment on lower textures. Watching this.

[Psyckosama]

Screenshots look decent, but agree with the comment on lower textures. Watching this.

This thread dates to October.

Let the dead rest. Don't commit Necromancy.