NathanKell

Hey ferram, I'm finally up and running with .22 and a new hard drive. But now that you're sampling over a bunch of points...why not just do ConfigNode temp; e.atmosphereCurve.Save(temp) and then pull the keys from the node? Change them in-place and do e.atmosphereCurve.Load(temp) Let's say you have a function correctKeys(), even. This will help. As to handling integration, here's my idea. I looked again, and I _think_ you can actually do it all on your end. public static Dictionary<string, List<FloatCurve>> TLTIsps; It was private, is now public. You can change all the floatcurves in it however you want. As I gradually make all engines use this system, that will work for everything. But just to be sure you also get the ones I haven't hit yet, check for modules[whatever] field public List<ConfigNode> configs. Trawl through that to find all atmosphereCurve nodes and do correctKeys(). That will handle any ModuleEngineConfigs or ModuleHybridEngine that aren't using my techlevel system yet. Finally, to deal with ModuleHybridEngines, instead of a List<> you just have two ConfigNodes: public ConfigNode primaryEngine; and secondaryEngine. In any of these three cases, you need to not touch thrust; MFSC also has thrust correcting, and because I detect vac- or atmo-rating based on a field engineType, I'd rather not have KIDS guessing how to correct it and override. Now, if you still want me to add extra stuff I'm _way_ more than happy to (I owe you big for FAR!), just say the word; but you expressed an interest in doing at your end so I offer this explanation above.

Cool. Since hubbazoot has put the Ordan Industries telescopes up for adoption, you might want to put science modules on them, for a start!

While you're reusing models, the two escape towers have identical models and textures. That'll save ~1mb in memory, and 3.5 on disk.

Awesome! Is it biome aware? Other thoughts: Radiation sensor (discover the Van Kerman belts!) Telescope: Vislight (kinda what you have, but..), Infrared, UV, X-ray, Gamma Radar (Mapsat is basically this for topo maps, but surely doesn't give us science!) Biologicals package (test biologicals in microgravity) Centrifuge Crystal growth in microgravity (must be man-tended, presumably) Solar observatory (a specialized telescope; detect sun spots, coronal mass ejections, etc.)

You can try a MM config with @PART[kerbalEVA] as that's the name of the EVA part. Don't know if the changes will take though.

Oh. Right. Sorry. That reminds me that I need to implement OR and NOT. That would fix it; subgoal with minalt, wrapped in a NOT. subgoal completes on minalt (your max alt) and then is made forever false by the NOT, failing the mission. That system would also allow ORs for partgoals, for example: and OR() over all antennae, stock and remotetech; an OR() over various mod telescopes or the RamScoop that Sandworm has been using to fake one; etc.

regex, thanks. :] So, before we actually get down to what-parts-where, let's first figure out generic progression. Because IMO stock KSP just doesn't have enough (differently-efficient!) parts to constitute what we need. There are two things that would help us here that I plan to make. One is a new module, built from RemoteTech, that is a "half-command" module. It will allow you to stage, and to right-click parts, but not to actually control the craft (thrust or rotate). This is to allow sounding rockets and uncontrollable satellites that can still return science. Because it makes sense that controllable probe cores are hard to make. But probes themselves, easy. Second is ModuleTechLevel, which can be applied to any part, and based on the system I wrote to calculate MissionController costs, allow the tweaking of any named and typed variable in the part itself or in any _other_ module that's derived from PartModule. This means that you could add ModuleTechLevel to a fuel tank, and have the fuel tank gradually decrease in dry mass the further along the tech tree you are. This would prevent having to manually create advanced and un-advanced copies of parts.

The way to fix MechJeb if it costs too much is either: (a) Give the part a reasonable mass, like at minimum 0.1 (then it'll only cost ~1800) ( remove MODULE { name = Module Command ..... } from the MJ part cfg.

http://forum.kerbalspaceprogram.com/threads/45070-TT-s-IVA-Tutorial There, I helped.

MedievalNerd: Hmm. Does your AR202 part have ModuleCommand? sarbian took it out, in the dev build, but maybe you don't have the dev build. If so, remove it, and your cost will be normal. For altitude: set the altitude goal in a separate, early SubGoal(). The goal will be marked completed and not go back to failed when you descend again.

Both. And AIES. It's the only answer.

This is what I'm waiting for, oh yes.

try \n ? Unless that's read in as actually a backslash. If so I'll fix the parser.

Yeah, my rule of thumb is start the turn at 100m/s and go 1dps or less until level. Never had to throttle down, though. Yes. That's why the dV is the way it is. You're talking about then removing the realism again, in the service of "I want it to cost more dV to get to orbit."

Hey wait. Is GetValue() defined when there's more than one key/value in a node? If it's defined to be the first, you could write a wildcard MM script that adds those values to EVERY part (should add to end of node), and GetValue would get the original one if it existed.

No(t yet). My old hard drive started dying, so I spent today fixing that (and then having my desktop out of commission as the drive imaged over) rather than adding the support ferram needs, apologies again (and to you, ferram!). I will have it up tomorrow for ferram, and then he can implement the other side on his end.

I can answer two, though I've never actually used PartTools. 2. I know Procedural Wings uses bones for scaling of the wings, so I know there's _some_ bone support 1 and 3. Yes, single models may have multiple textures. I've seen in mu files references to multiple diffuse textures, IIRC. And even if PartTools won't let you export them, you can do it with MODEL nodes in the CFG--parts can now have multiple _models_.

Interesting you should say that. I was wondering if there were interest for that, and considering doing so. The KASA modpack is mostly in my sig: it's just some specially-rolled engine configs and names for MFSC, and the the other stuff in the sig. As to tech tree, see this thread I just created. I'd apply all the parts I use to the tech tree that thread ends up with. Other than the *.craft files, which I can release too, of course; though I do use some rescaled parts from mods that have no-distribution clauses, so those can't come. Only thing shown so far is the rescaled FASA warhead, but there's some others you'll see ere long.

Have you tried it? They optimized the loading/unloading code (check ksp.log for details)--sumghai was able to run MapSat v4 WITH a full complement of mods!

You keep not answering WHY that's true, other than "because I wants it to be!!!" Tastes differ. And no, any old rocket won't do better--it might well flip out and crash, unless you're a very good pilot. And if you change the drag, then that's heightened, as ferram has said a number of times.

So, I've seen a bunch of posts regarding how, for example, the MK1 pod is available before any kind of probe, and how rockets are available before planes. Now, a bunch of folks have responded "This the Kerbal Space Program, not the Human one, Jeb must be first" or words to that effect. Which is fine, but for those of us who want a closer-to-real-life progression of the tech tree...I made this thread. Basically, unlike part mods which can be dropped in ad-hoc, it's very hard to coordinate one's mods with one's tech tree. I thus suggest that we hash out a community real-life-inspired tech tree, so that we can have a common basis, and so we don't, each of us, have to manually adjust everything. I mean, we still have to adjust everything, but at least we can cooperate and not duplicate effort. Further, this would give mod authors the chance to determine where they want their part on the tech tree, and give plugin authors a common set of nodes and their positions to query, if such authors are interested in supporting a more real-life-based tech tree. So. Thoughts. To start off, here's how I see things: 1. Separatrons, a heavy simple probe core, and the basic jet / cockpit / wings / jet fuel should be available at the start, along with size 0 LF parts (large solid rockets took much longer to develop than LF rockets; planes, however, beat even Goddard.) However, the 24-77 and 48-7S are too good for TL1; force people to use lots of LV-1s and 1Rs? 2. Some probes, science parts, a small SRB, and size 1 LF parts 3. Mk1 Pod, more science. Maybe size 2 LF parts And so forth.

That's....not so good for future-proofing. One thing I'd really like to see is the ability to add a module that can transmit science when connected to the network but NOT control the craft. So you can launch uncontrollable, lightweight early satellites that have no heavy, expensive guidance ring (probe core) but can still have sensors and transmit data. Like how RT can control debris, except with only right-clicking allowed, not actually turning/burning.

Huh, always knew them as gallants, rather than garrants. Learn something every day.

Ogamaga: Sorry, typo on my end. Try replacing it with the file I just posted too, sounds like (since the links were broken) you have an old version.

EDIT: Link fixed.