Snjo

Hunting down exceptions is hard, especially if you fall into the trap of long Update/OnUpdate/OnStart methods, since the error log will only tell you that the expection happened somewhere in that method. If you break up the method into smaller chunks, you will be told which sub-method it happened in instead, making it much easier to find the place where it failed. The difference between public override OnUpdate() { // 100 instructions } -> NullReference Exception in OnUpdate and public override OnUpdate() { bunny = Dothis(); DoThat(bunny); nowFinishHim(); } -> NullReference Exception in DoThat(object target) in OnUpdate() is five hours down the drain searching in the wrong place

I don't know, but it goes great with ice cream

I can never resist a stupid idea! Banana

v2.0 -Scaling the building model now works in VAB too thanks to Bac9's help. -Default building size configurable in the settings.txt -Complete refactoring of the code, so let me know if there are bugs! Download from Curseforge or Kerbalstuff

You could of course do the same kinds of things KerbTown does with you own mod, and since it's MIT license, you could also get some pointers from Raz's code to do it. I just warn you though, that for me at least, the code was almost indecipherable with its partial classes etc. Before KerbTown came out I was experimenting with creating such a mod myself (hence that file I linked being named FS Housing Programme), loading models from the game's database, and placing them at a location. I immediately dropped that when I saw the complexity and versatility of Raz's work. Now KerbTown does miss some things of course, like save-specific instances and persistent values. And it probably also has a lot of features you don't need to make if you aren't aiming it at other modders. edit: for ideas on loading models, see this, and for ideas on using coordinates, see this

The positions are stored in the static's cfg file when they are placed, meaning the maker can deliver the static with some instances already defined. You can also add modules to them in much the same way as parts. They are regular MonoBehaviour classes. They do not support persistent values though. Check the gas pump in this old package and its code here

I updated the official release for 0.24.2. I thought I saw someone mentioning bugs that would lead to a 0.24.3, but time will tell I guess. It's still too hot and humid here to get any proper work done. This has been the craziest norwegian summer I can remember! (Which probably means it's like a Floridian winter)

I feel like it already does. I changed the code a while back from referencing ModuleEngines to referencing a wrapper that can talk to ModuleEngines, ModuleEnginesFX or FSengine. What happens when you try?

Actually, there is no default behavior per mod. Each modder is asked to return a true or false statement for whether the mod is compatible with KSP's version, and Unity's version. The typical solution is to compare a set of values to the game's version number, but how to perform it, and how lenient it is, is entirely up to the modder. They might change also anything and everything based off of that, like changing part behaviors, or disabling code, but most of the time that's more work than it's worth. Keep in mind, that since it's a true or false test, it might warn you of versioning differences in both directions, i.e. both if the mod is too old OR too new. Any mod that doesn't include this function, will not show up in the warning window. It's important to keep the plugins up to date, because even though the KSP features used by the mod might not have changed, it may have been compiled for a KSP dll where a reference is just different, even though the name is the same. This will cause a severe crash with no reasonable feedback, even if the code with the error is never even run.

There are two sets of engines, the old ones, which use the stock engine module with a lot of hacks on top, and the new ones based on a totally new piece of engine code. The old one, used in v6 and earlier, tilt the thrustTransform to control pitch and roll, and vary the thrust amount to simulate collective. The tail rudder is a separate engine with 0 output unelss you yaw, in which case it ramps up the thrust, and flips the direction of the thrustTrasnform to yaw left/right. So rockets. The new code, used in v7, which has only been shown as a test so far, uses actual blades with lift code on them, both for main and tail rotors, just with different axis response settings. They are more complicated to set up, but more customizable. You can opt to not use blade physics, and just use the new engine module's thrust system to get most of what you need. I think I did that on the electric main rotor in the pre-release. Translation is only done by pithing and rolling to create thrust in the desired direction, while maintaining altitude by altering the collective. This is easily done with hover mode. BTW, for any code explorers out there, there IS a module for , just no part using them If you check the video I made of v7 features, you will see the blades pitching. That's the very real thing that control flight, since the wing code is running on transforms inside those pitching blades. As for instrumentation, if you use a throttle prop, it will show the collective value in normal mode, since normal mode reads the throttle for collective, while keeping engine RPM as a separate internal thing. If you use hove mode however, pressing ctrl and shift to go up and down won't look correct. In this state the blade pitch varies wildly, but that's not seen in the throttle, however, there is an internal value called longtermHoverCollective, which is a smoothed average for the current collective. It would be possible to feed that to a throttle using a new throttle prop code. I know it's very long ago since I started talking about those parts. I just haven't been doing much modelling, and know that starting the IVA of that cockpit will be a big job, so... I still want to, just need to get in the right mood I guess. The biplane parts came out so well that I kind of rested on my laurels. You can add the thrust reversing module to any engine, except ones with the gimbal module (cause that overrides it in silly ways).

If you are annoyed by the version warning, a recompiled version of the dll is here. I have still not gotten any proper reports of bugs, so if someone DOES have an issue after 0.24, post steps to reproduce and an error log. edit: And now it's been recompiled again for KSP 0.24.2

While HoneyFox was putting out a version, Raz altered the license for the source code to an MIT license, meaning you can do what you want with it. All KSP plugins are required to be Open Source, but they are still copyrighted, and only grant you free use through the conditions in their license. As for the rest of the material in the mod, they are not covered by the MIT license in my interpretation, since the OP only states the copyright. Repository License

That wasn't true when you wrote it, but is now It was always true for wheels, but not for other parts. If you need to align other stuff, get the latest dll If you add the module to any part, it will compare its rotation to the world axis. Keep in mind that this will probably show correct when the part is pointing straight UP, not forwards, but I'm sure you can work around that (Due to this ostensibly being a rocket game, all parts are built facing up) The module to add in a cfg is like this MODULE { name = FSwheelAlignment } edit: I forgot to sync the changes, so if you downloaded before wednesday/thursday, and it didn't work as expected, download the dll again.

The costs have always been there, just not in use. However the prices are not good, just the result of copying sections of cfg files blindly around, so every wing costs 1000, not matter how big or small for instance. I will have to fix that, but in the mean time, there is no shame in editing a price if you are playing career mod and see a dumb price. It's not cheating, just fixing a "bug"

Oh right, I forgot to update that version file. The version file is used by some mod manager (I can't remember which now), and it shouldn't affect anything unless you use that. If you don't use that, but still get an error message about the version when you get to the main menu, you must have an old dll somewhere, because that error message is based on info internal to the dll.

It was a zip file. 39MB.

I've updated the official releases to be v6.3.3 with the 0.24 dll, which has lots of new features that will be used in v7, but is already in use in a few other mods like B9.

I tried uploading Firespitter just now, but got Error 400 after the file upload step. "Bad Request The browser (or proxy) sent a request that this server could not understand." (Using Chrome)

When does it crash?

Under which circumstances does it break? Can you post an output_log from KSP_Data? I would think the error is with MechJeb just because the code in FS is almost entitely contained inside each part, whereas MechJeb reaches into all manner of things.

And here's the preliminary 0.24 dll

In the interest of backwards compatability, here's a release of the final version of the dll for 0.23.5. Starting the 0.24 reference updates now.

Hadn't noticed 0.24 was out. I'll do a recompile today, but with summer being here, I haven't finished all the features for the new parts yet, so it may end up as FS v6 + dll v7.

If you use FStextureSwitch2 from the most recent dll from snjo.net it should switch all objects of the same name, not just the first found.

Nothing. The VAB model can't be scaled, only the SPH model can. I talked to bac9, who made the models when he worked for Squad, and he figured out that it's simply not possible because of things. The work area is still increased though. It just looks a bit silly building through the roof.