Snjo

Nice work! Before I forget, if you need the UV layout guides for a part, let me know. I stopped including them at some point early on, and now that they take up texture memory if included it doesn't make sense to include them anyways, except if it was in a zip. The problem with the names is of course that any object can be named anything, often Cube01, Cube02, or something ungueaable like upperSlatBackupOhGodImHungry. So I will make a way to list all the objects in a part if the texture switcher is in debug mode. When you switch the texture on an object, you actually switch the main texture on its material. Other objects might use the same material, in which case all of them should update, but judging from your picture that might not be true. That makes it a bit awkward if you then have to switch multiple objects each time... I guess you could target a range of objects for each tex switch module. Yeah, that makes sense. And then you could optionally define two or more modules on a part to switch different sections separately.

v5.5 Download new since last pre-release: -Updated gyroscope and nose SAS to use the new SAS module. Converted cockpits to the new reaction wheel system. (very weak reaction wheels) (thanks to PolecatEZ for some input) new since last official release: -F-86 fighter jet wing with deployable leading edge for increased lift+drag -F-86 tail control surfaces (elevators and rudder) -Folding electric plane propeller -Greatly reduced the weight of the landing gear. (Check the balance of your craft) -Added brake lights to some gears -Trim tool displays current trim -Water Launch Module: On slower machines, try setting a longer timer setting if you are put back to the runway at lunch. Edit the line timer = 4.0 to a higher value (seconds). (Parts\Utility\FS_moveCraftGadget\part.cfg)

Yeah, if it's not loaded it doesn't exist, it's all made up. Basically, you can easily fake a station on the Mun doing some work, sending signals back and forth with you current location, but as soon as you start faking physics on that imagined piece of hardware, you're in trouble. My guide has some very basic info on editing part.cfg files edit: Blender for modelling, Unity for making parts out of the models, some image program for textures, and Visual Studio for writing plugins in C#. Oh and notepad ++ is good for writing cfg files, or just regular notepad

Converting an engine to Kethane is as simple as changing the resource it uses in the part.cfg. And of course, you should paint it green. If the Kethane pack still has that jet engine, you can look at that for an example of resources used. Throwing code over to a KSPAddon means it's not running on a part, and therefore it wouldn't move around. You could tell it where in the world it was taken from, but you would also need to fake its idea of movement and orbit, and a whole lot of other stuff. Point being, it's doable to have simulated satellites, but it's complicated as hell.

It will rip apart if you do the move after physics kick in, cause it's no longer on rails. Do you mean to run it while it's loaded, but on another vessel, or unloaded? For loaded stuff, any code running in OnUpdate will run, but you know that (Also Update(), FixedUpdate etc, OnFixedUpdate is less good) For unloaded stuff, I guess you'd have to throw the code over to a KSPAddon... Partmodule thing: OnUnload() // or something { SillyCode.backgroundModules.Add(this); } [KSPAddon(KSPAddon.Startup.Flight, false)] public class SillyCode : MonoBehaviour { public static List<PartModule> backgroundModules = new List<PartModule>(); Update() { foreach (PartModule pm in backgroundModules) { pm.OnUpdate(); } }

Oh, wow, that sounds great! Yes float section with the landing gears does retract. If you can mention which files have updates, it'll make merging things quicker

Is it just me, or was there a wheel skid sound effect when you landed? I know I haven't gotten around to add that yet.

It has to start trying before physics kick in, otherwise it will be ripped apart. Or at least that was the way in .19. It keeps trying for a set amount of time, hopefully ending after physics has started and everything is loaded. The time it tries is a cfg value.

I just updated my runway to deal with the bouncy issue too. It seems more than 200m in one collider is a problem. Split the mesh or the collider into smaller chunks of 100-200m and it's fine.

You can blame my typo for that. I put an umlaut after the word timer. Make sure the line is timer = 10.0, not timer¨=

v5.5 pre-release Download -F-86 fighter jet wing with deployable leading edge for increased lift+drag -F-86 tail control surfaces (elevators and rudder) -Folding electric plane propeller -Greatly reduced the weight of the landing gear. (Check the balance of your craft) -Added brake lights to some gears -Trim tool displays current trim -Plugin: Deprecated the FSswitchButtonHandler function, replaced by FSgenericButtonHandler. Removed FSbuttonHandler in favor of FSgenericButtonHandlerID -Updated some broken craft files -Water Launch Module: On slower machines, try setting a longer timer setting if you are put back to the runway at launch. Edit the line timer = 4.0 to a higher value (seconds). (Parts\Utility\FS_moveCraftGadget\part.cfg) MODULE { name = FSmoveCraftAtLaunch moveAtLaunch = True launchPosition = -1199.2, 66.2, 4095.4 timer¨= 4.0 }

I was testing the new landing gear code on a part called FSnewFighterTailGear. I must have thrown the wrong craft file in the zip file. I'll make sure to replace it. Those FSmoveCAL lines are the attempts to move the vessel to the ocean. While those are running, you should be hovering above the ocean. Are you being moved back to the runway after those have completed? If so, it might just bee that it doesn't try that move for long enough, because your computer is doing the load too slowly. I think it tries for three seconds. I'll make a new build where that is a config value, so slower machines can have a longer countdown, and we'll see if that helps.

Throttle control is very important in airplanes, and especially in helicopters. In planes, you need to control the pitching tendency of the plane by either adjusting throttle (if the engine isn't in line with the wings, otherwise it doesn't matter as much), and/or using trim (alt+WASD) to adjust for different pitching tendencies at different speeds and altitudes (air density). (Alt+x resets trim BTW) In helicopters, you need to be on the throttle all the time to not shoot up into the air, or plummet to the ground. Get used to keeping your pinky on shift/ctrl.

Press Shift

That's a new one! If you right click the engine while it's running, what does the thrust reading say? It should read more than 0.0 thrust, and it should not say it's deprived of any resource. If you press alt+f2 you will see the error log. If there's lots of red text there, something's gone wrong. In that case, post the KSP_win\ksp_data\output_log.txt to pastebin.com and post the link to it here.

As part of solving the runway launch selection problem, I assume each instance will get an ID, which could be used by a module. But to make things even easier, are you planning on including module persistent values in each instance as well? The way each instance is stored in the GameData, independent of save games, means we'll have to figure out a system for storing persistent values in each saved game per instance. In my case I'm thinking of storing fuel amounts on fuel pumps etc. But also more general thing like remembering if an elevator was up or down when you last visited a location. Given that you already cracked the nut of storing and reading the nodes and KSPFields, this might be something you are already planning, so I thought I'd check before doing something silly.

Having fun making KerbTown fuel pump: FS Housing Program (includes KerbTown plugin)

Obviously the texture is not very good yet, but the fuel pump code is complete. Each fuel pump in the picture can fill a different kind of fuel, so you can set the left one to fill LiquidFuel, and the right one to fill Oxydizer/Electricity/Kethane or whatever. You activate the pump by clicking on it when you get close, and that GUI shows up. If you are out of range, it shuts down, and only check a single bool (in FixedUpdate and OnGUI), so as not to overload the system if there's a whole load of these all over the place. Gonna fix the texture tomorrow, in the meantime, try it out: Download

You might want to look at my FSbuoyancy module for a very simple implementation, or the upcoming InfiniteDice version of the same for a very complex one

Maybe I'm missing something, but is there no way to retrieve the values used to create the static in a module on the static? Say I want to check what altitude and CelestialBody a static is at, a value used in placement, is that even stored in a module on the object, or is it just placed as an empty gameObject? An extension like suggested above could include a reference to either the Kerbtown.KerbTown.StaticObject which has all the values, or have all the values given to it, like in a partmodule.

Thanks! Helping is half the fun, and it also helps you think through and learn from what you've done previously. We can only improve by sharing our discoveries. I wonder why the stock float code changed, and how. Since there doesn't seem to have been anything gained in the process. I can imagine one thing that can be done to make subs even easier to make. Remove the partBuoyancy AND remove gravity from the part rigidbody. So when you are under water, the only gravity effect you see is a custom force that gently pulls you up or down to simulate ballast over/underweight. And of course when you reach the surface, you need to prevent the part from flying above it. Then there's the issue of the position camera, and the missing water plane when you are below it.

Well, as long as it's optional, it can only help. The modder can choose to extend a kerbtown class if they want to be sure their idea of active status matches up with kerbtown's active status. If there ends up being a whole decision tree for whether a static is active or not, it's better to listen to the result than trying to keep up to date with it through own code. Of course there are many reasons not to be controlled by your code, like making interplanetary comm systems that are always on. Or making a space base fixed to a Lagrange point, constantly updating its position.

Per planet makes sense, but if people start adding lots of objects with scripts on them, maybe creating an extension of monobehvior to extend from that has an OnFixedUpdate or similar that only fires when in range would be good. So the module would be class FSgasPump : KerbtownBehavior // KerbtownBehavior : MonoBehavior { public void OnFixedUpdate() { Debug.Log("I know I'm in range, cause I'm called by KerbTown"); } } Haha, this one is a small runway of dubious quality, kind of like the island runway. The main effort is the fuel pump, which I've had the model for for months. The plane is, when you get close, you have the option to fill up a selected tank with an amount, hopefully draining your cash reserves once that's in (I think I'll find the Kerbal wallet or make my own for testing purposes). I don't want to fill all tanks up automatically, cause that means my bomber with default 500 out of 1500 fuel filled won't take off. Of course, oil rigs, kethane integration, solar farms that fill your batteries, all things are possible

I'm working on place-able airport parts, and I've got a runway and a fuel pump up and running. The fuel pump functions very crudely for the moment, but I must say, creating KerbTown stuff was surprisingly painless. Thanks for creating this awesome tool, it saved me from having to invent a much sloppier version of it I notice code runs on all placed objects regardless of whether they are in visual range of the active vessel, which must also mean they are all fully loaded. They probably don't create draw calls, since they are outside the cameras range, but have you done any work to allow for a custom load/unload range for placed entities, so that stuff on Duna doesn't take up memory or run code when you are on Kerbin?

I think it was intentional at one point, to prevent you from flying too high, but since then I introduced the atmospheric nerf, that will make you lose thrust the closer you get to space. All the atmospheCurve does is consume more fuel the higher up you are. Since there's no reason to think the engine could chew through all its fuel in a second, I guess I'll put it back to 100. You still won't get more than 0.01 thrust or something when you're closing in on the vacuum.