Snjo

I don't have any of the other stuff, but the inventory code is here: https://github.com/snjo/KerbTownQuest, or a bit more updated in Raz's repo here https://github.com/HubsElectrical/KerbTownExtensions (some features turned off) The code that is in both repos is made by me (I think that's all of the code), and you can use it how you want. The rest of the interesting stuff is probably in the main KerbTown repo, including the abillity to switch to the interior of the flight control center, but not the models etc. That code was recently released from its earlier license. edit: Oh and the fuel pump and whale skeleton is from the unreleased FS Housing Programme (which may have working inventory in an early state, or at least the bag model)

It's awkward to work in two solutions back and forth, or to compile to two dlls from one solution, and it increases the possibilities for user errors due to dlls missing or duplicated. If firespitter.dll references the FStools.dll, and that is missing, there's an instant meltdown without people knowing why. And it would need to reference it because other modules use the same parsing tools as the switcher modules. Also, to you, those switcher modules may be the one take away from FS, but for other people it will be FSanimateGeneric, FSwheel or some other stand alone tool. There is nowhere to draw that magic line. The switchers are in flux right now because I am still in the initial dev phase, as you can tell by them only having been in pre-releases. After v7.0, they should remain fairly unchanged, just like how FSanimateGeneric has seen only a very few updates in the last year (like implementing sound effects). The plan is to release v7.0 this weekend, as soon as I clean up some parts. Most of the code issues have been fixed. Others are being pushed to v7.1 There is no harm in having unused code in a dll distributed with your project, but you are of course free to extract the classes, rename them and compile them into your own dll. edit: BTW, whitespace is now allowed in values separated by semicolons and commas in the switchers. Makes it easier to spot your errors

Assigned it to a 7.1 issue

One of the problematic things for modders in having multiple download sites, is the work involved in maintaining them. Since many modders already use github, I'd suggest that a replaceport have the ability to fetch mod updates from a github repo, and its changelog notes. That way, we can just make a release there as normal, and not have to update the mod page each time. github delivers releases in a format that's easy to parse in php etc. Example.

It depends on what's possible with InfiniteDice's Skillful code. He targets parts, but the playback vessels aren't parts. So I would need to have him add an additional amount of code for it to work. We'll just have to wait and see if it's feasible or not.

Hmmm, there's nothing special about my bools, but the class is meant to be extended internally, so it has some protected fields, maybe that triggers something. You could try recompiling my dll with those set to public. Also it uses namespaces, maybe that triggers something? Hard to say, may be a conflict with another mod. Put you KSP_Win\KSP_data\output_log.txt on pastebin or something like that, and maybe there's some info there.

Not currently. It's possible I could listen for the ApplyDamage message that Skillful sends. Just depends on if it sends it only to proper parts or to any gameObject. If it worked, I could tell the thing yo go off rails when it was hit.

Added the texureRootFolder value to the plugin

Last time I tried to move kerbals around between parts, I broke the ability to load not just that save, but ALL saves. So I'm not going to introduce something that is that prone to severe bugs and therefore requires huge amounts of testing. If you get enough shots in you, you will die anyway, either because the cockpit explodes, or you hit the ground. (Yes, yes, I know the cockpit tends to survive, don't remind me)

That's a lot of cool ideas. Thanks! On the list

Now THAT is a good idea Of course, if you use textures from several folders you would have to leave it blank or truncated, but you could at least put the for isntance "MyMod/Parts/" in there to skip that part of it.

InfiniteDice has tested quite a bit with my parts, so they get destroyed just fine In addition, he included an ability to do custom damage code for other modders in their own plugins. When a part takes damage, I can read that info from an ApplyDamage(float normalizedHealth) kind of function, and do funny stuff based on that. Right now, the only parts that do anything with this info are the wings. When they take damage, the control surface response gets nerfed, and if it's totally damaged, but not eploded, the surfaces jam. If you have any other ideas for interesting ways to break parts when taking damage, do tell

Don't split manually, set it to smooth, then click the wrench tab and add an Edge Split modifier to the object. That way it's a non destructive split.

I didn't enter this week simply because I was overloaded with coding my mod. I know I need to up my texturing game, so I wish I had had the time. I don't think we should be afraid of making more challenging parts. It has been stated in the past that the main focus of the challenge is the modelling aspect, but there is no reason why we have to adhere to that if it's more interesting to widen the scope a bit. After all, when people make mod parts, they will invariably have to make parts that are more than fuel tanks. There's a lot to learn about how KSP works from making something like a winglet, solar panel (or if you are adventurous, a wheel), about how to set up not just the model, but the proper hierarchy of transforms, animations etc. You could even define sound and particle FX through the part fx node system. Of course I personally wouldn't mind plugin work too, but THAT may be out of scope

Ah hahahahahahaaaa ha haaaa, enjoy! Sorry, just had landing gear flashbacks.

The documentation for the mesh, fuel and texture switcher modules is done: http://tiny.cc/fsdoc

No. While FSwheel is compatible with stock landing gear, the rover wheels have a different suspension setup. If you used the FSwheel module, the wheels would roll, but nothing else would work. You could of course make new rover wheels using FSwheel, but it only supports the simple visual suspension setup. (InfiniteDice's wheels use a reworked FSwheel and does a lot of advanced stuff without the crazy multi-part visual suspension)

Unfortunately, the water launch simply doesn't work for some people. It's one of those things that are nice to have if it works, but that there is no way to fix if it doesn't. We'll just have to wait and see what curious bugs appear when I replace the code on that rotor again

I ended up putting the data in static variables to store them. Check the source here: https://github.com/snjo/Firespitter/blob/master/Firespitter/tools/FSnodeLoader.cs https://github.com/snjo/Firespitter/blob/master/Firespitter/FSnodeLoaderTest.cs (not usre if that test is compatible with the above class anymore) https://github.com/snjo/Firespitter/blob/master/Firespitter/customization/FStextureSwitch.cs - but it is used in this one These examples are very custom to a particular use, but you can see the system of static lists in the FStextureSwitch. This isn't the best system ever, but it works. I've since abandoned nodes for parsed strings in FStextureSwitch2. They are much easier to work with since you don't need to restart the game each time you change the part.cfg. edit: and then i parse floatCurves using this parser

The internal model has a hard coded rotation of 90,180,0, so if you add that to the part's rotation, that might work. (I have not read through the source yet, but just thought I'd chime in with that piece of non obvious info)

For sure. Just had to fix some coding first. It would be tricky for it to know which objects should receive which texture. Of course it could just do it in sequence, but it's not supported currently. Also I see you used backslashes in your paths, which are only supported in the latest version of the dll (If you guessed that I spent way too long hunting bugs because I had made that error myself, you would be right). It now replaces \ with / for you internally. If you post an issue to the issue tracker, I may remember to take a look at it Did you give it time to spin up, and can you see the blades pitch when you use Shift/Ctrl? The code should be fairly independent of all other code and mods, so not sure what went wrong. I will have to rewrite the whole thing anyway to make it use less magic and more resources though, so still new bugs to make. Still finding bugs with the fuel tank switcher and part symmetry, think they are all squashed. As nice as part symmetry is, it's hell to code for. Had to add in ModuleID on the texture switchers. Also it's possible the fuel switch has to be before the tex switch in the part.cfg so that it has tank types defined before the tex switchers mess with it.

So the issue for you is that a tank with WasteWater doesn't show a resource, therefore not making it obvious that the tank is there? The tweakable sliders are not delivered by the switcher module, they are delivered by the stock code if a resource is present. If you need to make it clear to the user that the tank is different, you can use the textureDisplayNames values to give the tank setup a different set of names like "Structural;Fuel;Waste Water", and then that will show up for the selected tank type edit: if the thing truly does bug out, send me a part where that happens, and I can debug it.

If you check out this source, it loads a shader from a file, but you can also type out a shader like you see in the commented out section. However, it can not be a CGPROGRAM shader like you see there. Which is why I compiled the shader in unity, and imported that from the file. It grew from 20 lines to 40 000 though.

What is a non-tweakable resource? When the tank is set to empty/structural, there is obviously no resource, and therefore no resource amount to tweak No. I have to nuke the entire resource list in the part, and in symmetry counterparts before rebuilding the list. Making assumptions about which resources not to touch in case they are used by some other module is a highway to the nullref zone. edit: BTW I fixed a bug with symmtery parts not saving the selected tank properly, the dll is here