madlemur

Looking at a comprehensive "Stock" experience: Kerbal Alarm Clock Science Alert (based on difficulty settings) Precise Node Deadly Reentry (based on difficulty settings) Real Chute Kerbal Engineer Redux (low difficulty - SPA/VAB free, cheap flight; mid difficulty - SPA/VAB cheap, flight moderate expense, high difficulty - expensive everywhere) SCANSat (field of view and/or range determined by difficulty settings) RemoteTech (again, difficulty settings) StageRecovery (really, any mechanic to recoup some stage value) Life Support (difficulty to range from no LS, to Snacks!, to TACLS) KAS IR RPM Firespitter Looking at a moddable experience: KSP-AVC Module Manager CKAN ATM/DDS Loader (at the very least, non-leaky image loaders, if they weren't fixed in 0.90) Texture Replacer Tech Manager Community Resource Pack (or anything that makes resource creation/sharing easier) KSPAPI/Docs for API RPM Firespitter Although some of the mods include parts, I specifically did not include parts packs.

Quick look gives me the generic advice of pulling the WHEN statements out of the UNTIL loop. Set up your WHEN events before you enter the loop.

I do believe that it is. There have been reports of multi-hour delays as ATM converts/compresses the textures to a DXT format, which will make subsequent loads MUCH faster.

I believe this is Windows-only, as it uses the DirectX API.

OK. Then I think I will "downgrade" my installs to the original png/mbm/tga files, and let ATM manage the compression/caching. I'll just have to review the exceptions I set up so I can make sure I don't mangle my toolbars and plugin GUIs...

What if I've already converted my textures? Painfully loading the mods, and adding exceptions to the dds.py script until all the icons worked, and my game loads in less than 15 minutes (it's actually under 2 minutes, but it used to seem to be around 15)... Did I mention I'm running 64-bit Linux? Would I be better off reinstalling all my mods and letting ATM compress them, or would I run into the same issue of having textures compressed that shouldn't be? Would you like my exception list, so you can merge it with yours (or more appropriately, create new .tcfg files for you to add)? Which reminds me... Kerbal Alarm Clock got mangled because the CKAN entry is installing it in the wrong place... Need to pop over and correct that...

I was happy to see this on CKAN when I went to configure/update my KSP. I have an Arduino gathering dust, and I can probably get over the inertia to build a KSP control center (rather than building a whole CNC rig so I can run grbl).

*cough*kerbalstuff*cough*ckan*cough*

Stealing designs from Corellian Engineering?

For me, it's a matter of time and focus. I tap a few minutes here and there while at work to read up on things, and when I'm at home, I usually don't have dedicated "me" time (we've had to institute a no-electronics bathroom rule), so it's tough to spend a lot of dedicated time watching videos. "Modeling and Asset Management" is a perfectly specific focus...

I assumed non-English speaker, told myself the eye twitch was due to the coffee, and moved on... But I like the link. Alot...

Hmmm... Maybe I'll suggest that the wiki accept BBCode...

You'd be better off using a fuel balancing mod. As NathanKell mentioned, you'd create a loop and likely annoy the Kraken...

I'd agree with having descriptions of "modder's mods" is a good idea, but documentation should be limited to links to their respective docs. Trying to keep them synced with the mods could be... troublesome. I would think this would be primarily a resource for actually interfacing with/using the core KSP platform (and the rest of the asset toolchain).

While strictly correct, I think that misses the intended target of the KSP player who wants the thrill of seeing something they have created in their game. Well, I'm assuming the intended target audience is the casual modder AKA, KSP player who wants to "do moar" than just play. If it's kept reasonably current, it will be a great help. I've tried to find tutorials, and easily half of them are .18 or earlier (at least it seemed that way), and at least half the remaining tutorials were targeting Blender as the game engine, and I was unsure how much of the information they provided would even make the .blend->.mu export, much less be functional in KSP. The Unity tutorials were even worse (as far as being presented as tutorials for creating Unity games, vs. using Unity as middle-ware [i.e., not trying to leverage every standard package Unity ships with]). Even if the tutorial was some basic information and a link or two to more in-depth treatments, that would be helpful. Or perhaps an "upgrade guide" or "trail guide" for the other tutorials, so I know that if I'm watching Unity videos, I can ignore X, Y, and Z, and be aware that T, V and Q need a slightly different treatment when prepping for KSP export, etc., etc. It's not unique to this community, but there's often a feeling that "it's obvious" what needs to be ignored/translated/reconfigured between older tutorials and the current state of affairs. For new modders, it's not obvious, and the trial and error of figuring that out is discouraging, and trying to sift through the huge number of threads for those gotchas can be very painful and off-putting. Especially for the ADHD crowd (myself included)...

I agree with one of the previous posters, start with something a bit more complex than a simple fuel tank. Not horrific, but maybe an airlock and/or ladder. Save animations and such for later tutorials (although I'm keen to get a clear, concise tutorial on creating KSP-compatible animations, including animated collision meshes). Unless you want to break it into smaller chunks... Initial tutorial on setting up Unity for KSP, with some general notes on what to be looking for in a modelling package (exporting to a compatible format, etc), Modelling 101, wherein a fuel tank is built, which would include some very basic UV-mapping notes, and an introduction to the parts configuration file. From there, you have several topics to hit: optimizing UV mapping (texture atlas, etc.), normal maps (or even just non-texture maps, if you want to include AO maps), mesh reuse (have a part with a bunch of identical dongles? model one dongle, then copy it after it's mapped/textured), animation (at least in Unity, if not in Blender), stupid collision mesh tricks (well, understanding what and when it's used, and how to go about creating a VAB/SPH part grab collider vs an in-game physics collider mesh), grokking the part configuration file, etc., etc...

He has SE... He wants it in KSP.

You want a full blown crafting mod with multiple resources and a complex manufacturing system. Sounds like you want a Kerbal version of Minecraft with a bunch of mods like Buildcraft, Tinkers Construct, etc. Mods that have taken years to mature. I actually hope someone is working on that, but it doesn't exist today.

Any suggestions for sizing in Wings3D? I'm sure it can be scaled, but I'd rather model at near the same scale/resolution...

D'oh! I meant 80-85 degrees. You're right that 40 degrees is way too small. That's what I get for doing maths geometries trigonometries without enough of the caffeines...

I've used Wings3D in the past. Is it possible to do animations in Wings? I've been eyeballing a project, but it will require animations... I'll learn Blender if I must, but that learning curve is pretty steep (and fiddling with Blender isn't nearly as fun as Dwarf Fortress).

Just for fun, I went ahead and installed Blender and Unity. Ow. What I did do, before rage-quitting, was to remove the airlock and ladder from a hitchhiker module, and slice out half of a door. I know what I think would work, but I really don't have the skills to actually do it. I'm hoping someone with the skills and interest sees this... Take a re-scaled Hitchhiker module (probably needs to be 3.75m rather than 2.5m), and remove the ladders and airlock. Where the airlock was, make a door that crosses about a 40 degree arc (this would allow 4-way radial mounting of stuff). Animate the door opening (my personal thought would be an accordion door that folds up flat against the hull). Beef up the interior to have a docking node in the back and/or top of the bay (can that be tweakable?) to secure the rover, and some bulk along the sides to accept supplies of some sort (modular tanks?). As an alternate (and understandably more difficult), hack off the sides of the hitchhiker and replace with stacks of 1/4 Universal Storage cores. Then the builder could customize the loadout on the part. This may make it impossible to tweak the size of the part, since the requisite US cores don't really scale. And it would probably only work with a larger part that could support maybe 2 bays of an octo-core. Hmmm... Maybe that won't work. But I like the idea. Now that the bay is done, let's talk egress/ingress... I think it would be possible to take the stock ladders, change the angle of deployment (tweakable?) and replace the steps with ramp panels. Then the builder can place the ramp(s) in the precise location needed for their particular rover design, and they will retract and fold away just like the ladders (bonus points for having the ramp storage cover used as the transition piece from the bay to the ramp). Further ideas: 4 doors on a mostly empty shell with a round-table in it, allowing the rover to exit from any side. IR horizontal sliders with winches to raise/lower the rover/parking platform. Notes: While crossfeed may be allowed, I would think that CLS would find this to be a blocking part. Not enough room for passenger traversal. Seems easy enough, until I force myself to remember my experiences with Blender...

What size are you looking at? It seems to me that the ideal solution for some hard-working modeler to whip up would be a two-part combo. One part is the lander/garage part, with internal node(s), accordion door (or sliding door or whatever), and a ramp part that can be scaled independently from the lander. Also, you can place one or more ramps in any location for the wheelbase of your rover. Think of it as ladders for rovers. Reuse the animations from 1xN solar panels, and they'll fold up nicely into, or flush-ish with the hull. I'd do it, but I'd have to learn Unity modeling, probably Blender, not to mention hand-waving some actual artistic talent...

Use MM and add TweakScale support to the part. MODULE { name = TweakScale type = free }

All I ask is that you have a sensible progression in the techs. Nothing annoys me more than a tech tree where I start getting components I can't use for two more tech levels (here's a 1.25-2.5m adapter, too bad you don't have any 2.5m parts yet! or handy space station reactor, too bad you don't have anything to lift it, nor any other station parts!). The worst is probably BoxSat, which starts giving you components around Tier 2, but the actual frame isn't available until Tier 4. (If my geriatric memory isn't fooling me.)