Orum

Sorry for the late replies, and for not yet updating it to work with KSP 1.0 (not even sure if any changes are needed). Between a patio removal/rebuild and a kitchen remodel, I've been extremely busy, and I don't expect to be able to devote much time to gaming or development until the end of the month. When you mouse-over the parts in the editor and view the detailed part info (right-click), it lists all rates, both for "MaxEC" (the maximum electric charge it will generate per second), and below that it lists all fuels required per-second when generating at the maximum rate. At less than the maximum, fuel rates are scaled linearly--e.g. generating electricity at 50% of the MaxEC, it will use 50% of all fuels listed at that rate. Sure, anyone is more than welcome to write a MM script to do this. I'd also recommend you create "Water" as a byproduct if the resource is available, but it's up to you. NihilRex was going to write some, but I'm not sure if he ever got around to it, and I haven't been on IRC recently to talk to him. However, if you write MM configs, are willing to share them, and would like me to list them in the first post, I'd be happy to. Just post a message in this thread and I'll link people directly to your post with the configs. All I ask is that you list the version of ODFC (probably KSP too, and maybe even MM version) that you used when you wrote the config, and include that in the post. Then any updates can be done just by editing your post. Probably. I haven't tried yet, but I'll put it on my "TODO" list once any necessary updates to get things working with KSP 1.0 are done.

Yes, I think this may at least be due to how animation is imported into Unity ("Legacy" mode), though I'm unsure if this is a Unity or a KSP/.mu requirement (but I generally assume the latter as the other import methods appear to work in Unity as far as I can tell). EDIT: I also think it's worth noting that I would have liked to use true "Box" colliders from within Unity, but matching the opening of the iris is harder to do there compared to just doing an animated mesh in blender. Yes, it's probably less efficient than doing box colliders, but I have even less success at scripting things in Unity compared to blender, and it's as simple as adding two key-frames in blender and it matches the blades of the door very closely. Right, I'm trying to get the bounding box to scale. I know it's possible via scripting, but Python is such a...unique (being as polite as possible here) language that it proves to be very difficult for me to script in it. I have an offer from someone to help but real-life obligations have kept me extremely busy as of late, and I haven't been on IRC when he is and had time to spare.

No, this just isn't true. Here's an example (an "iris" style door) as proof, in Blender first, with colliders visible: And then in Unity 4, again with colliders visible: And finally in game, first with doors closed, Jeb standing on top: ...And falling through as the door opens:

I know this isn't true, and I've verified it experimentally with another part I created recently. Mesh colliders I created & animated (via scale) in Blender imported into Unity worked just fine. Yeah, the main issue with primitive colliders is they have to be created in unity, and can't be done in blender. No, but I'd certainly like it to be as good as possible, given that it's already an approximation. An approximation of an approximation can start to really show. I did find someone on IRC though who was willing to help with scripting this in blender, and using only scaling/translation (which unity can import) and keying every single frame. Ugly, but there's no other way to it Blender and have it import correctly into Unity.

This is already working, as I said in the first post. The problem is just with the collider. It's not, strictly speaking, a skinned mesh collider, as it's just moving hooks around based on empties, though the empties are linked to the bones. Here's an example frame part-way through the animation, with empties visible: I don't think pWing's is the proper analog as it has no animation of the colliders. Anything using "ModuleDeployableSolarPanel" should be much closer to my needs, but the only ones I know of are of course in mu format, and the blender mu plugin will not load animation As I said, the panels are already unfoolding smoothly, and while the bounding box is "smooth", it's still not something I can approximate without a huge number of keyframes. And baking the animation is the whole problem, as it doesn't seem possible to bake a mesh animation in blender. As for "max", are you referring to 3ds max? Because, I don't own that and have no plans on buying it, as I just can't justify it with the small number of parts I've made/plan on making, and having to spend the time to learn a new 3D modeling program. Lastly, as for using a collider for each individual part linked the rig, I don't think that's an option performance-wise. Right now with a bounding box I'd have a total of 92 tris for the colliders alone (for the entire part; already pretty high), and if I went to per-piece I'd have 308 tris.

Whether I do it via the vertices directly or object scaling and movement, both have the same issue--tracking the expansion of the panels. Though it makes a sine-ish shaped curve, even playing with the bezier handles and keying at both ends I couldn't get it anywhere close to the motion of the rig. To truly track it well over 180 frames requires an immense amount of keyframes, and calculating and entering the variables by hand is unbelievably tedious. I thought I could do it with a Python script, but Python makes Malbolge look like an easy language to script in, and more often than not I ended up doing horrible and essentially irreversible (if not for reverting to a save) damage to the mesh.

I have a set of deployable solar panels similar to the stock 1x6 panels, with rigged animation and all that goodness. This imports into Unity just fine. The problem, however, is the mesh collider I'm trying to use to approximate the panels in both compacted and deployed states, and everything in between. It's essentially a bounding box that I've tied to to the rig via an ugly mess of empties, hooks, constraints, and parenting (empties to the rig). This mesh deforms just fine within Blender, but as soon as I import into Unity, nothing happens. "Ah," thought I, naïvely, "I'll just bake the animation and that will solve all my problems!" Unfortunately, since the animation of a mesh is not the same as object animation, and it's not tied to simple editing of the object's transform, this doesn't seem to work within Blender. So, is there some way to bake the animation on a mesh-level instead of an object level? I'm open to other ways of doing this as well, if you think this is the wrong way to approach the problem.

I ran into an odd problem the other day that I think is SCANsat related. I was using an ALCOR capsule in IVA, with SCANsat up on one of its RPM MFDs (using RasterPropMonitor-dev19), orbiting Jool and getting the lovely map of static. I was on a transfer orbit to Bop, and the instant I entered its SoI (I had already fully scanned it with the three included antenna on an earlier probe) KSP froze--or so I thought initially. Its frame rate had actually dropped to about 1/15 (that's 1 frame every 15 seconds). At first I thought this was just related to changing SoIs while in IVA, but it happens even if I only enter IVA after changing SoIs. What's odd is IVA worked perfectly as long as I removed SCANsat's map from all of the MFDs, and SCANsat would still work perfectly if I used it in its normal windowed mode. So, I'm assuming this is some problem related to interaction between SCANsat and RPM or ALCOR, or all three. But, where do I start debugging such a problem? Nothing shows up in the log and attempting to do anything in KSP at such an insanely slow framerate is nearly impossible.

I'm not certain, but I believe you can mod the in-game UI with [thread=107471]TextureReplacer[/thread]. If you want to go above and beyond what TextureReplacer can do, it still might be a good place to start code-wise.

Alright, I'm putting the shared assets on github today, and I hope to have pull requests submitted for the netkan files this evening. You will probably need to remove either ODFC or SatBatts (whichever you have reinstalled) and re-add them after the pull requests are approved. Sorry for any inconvenience. Edit: Pull request has been merged, try uninstalling whichever mod of mine you have installed and reinstalling both of them, and it should work now (in theory).

I'm aware of this (it conflicting with my own mods). However, I don't know if there's really a way to fix this. Let me explain. CKAN does not let you share ownership of a file between multiple mods. As this is by design I do not believe it will change. This presents an issue for modders who want to share identical content (agencies, flags) between multiple mods they are the author of--each file can only be owned by one mod. The obvious solution here is to make a mod with the shared content (in my case, just the flags/agency), and have both other mods depend on that shared mod. The problem then becomes hosting of this mod. I asked SirCmpwn (developer/administrator of KerbalStuff) on IRC if it was okay to have such a mod on KerbalStuff, as I know in the past he has deleted mods consisting of just flags. His opinion on the matter was that such a dependency should not be hosted on KerbalStuff, and that CKAN should instead support files being owned by multiple mods. You can see the issue this causes. I'm looking to see if I can't find another way around the problem, such as hosting the shared content on DropBox, but I haven't been able to get this to work yet via CKAN. The alternative is to create a GitHub project just for the flag/agency, but I fear that may be deleted for the same reason SirCmpwn doesn't want such content on KerbalStuff.

I'm working on these--well, I started a little over a year ago on hovercraft parts, but real-life stuff took over so I haven't been back to KSP until the last few months. However, now that my fuel cells are released I'm going to get back to working on my hovercraft stuff, though not quite as you described. I tried the realistic "skirt" style hovercraft, but I honestly don't feel like that style belongs in a game that is renown for the uniqueness of user creations. So, I'll be doing things a little differently but I hope they'll be more fun and flexible to use as a result. The plugin itself is actually mostly done, just the complicated stabilization is left (and this is non-trivial to do correctly). The models themselves I haven't started yet, but hopefully they won't take too long now that I'm getting familiar with blender.

IntakeAir

It's only for fuel cells. The reason is it's designed around using ElectricCharge to calculate when fuel needs to be burned, so it won't serve the purpose of general conversion well. That said, it would be trivial to add support for using something other than EC as the primary output/determining factor for when fuels are consumed and byproducts are produced. So, if you want that, let me know and I'll add it. As for a comparison with Regolith, I can't help you as I'm not really sure. I've never used it in one of my games and haven't looked at the plugin. But, if there's something it does that you'd like ODFC to do, just ask. I'm always open to suggestions. Not sure if there's a way to do something like this and still make it a generic (i.e. config file based) thing. It's probably something that's better done in the life support mod.

Fresh out of the box from Okram Industries, I bring you "On Demand Fuel Cells." What is a fuel cell? I'm glad you asked. Put simply, it burns fuel to produce ElectricCharge, similar to what was used in the Apollo program. What fuel? Well, that depends on what mode you have it in. As for the "On Demand" part, the idea is to only burn fuel when you really need to, and otherwise not do anything. To clarify, this is actually a two-part mod. On the surface there are the included parts you can play around with right now, and are usable in stock KSP with no other dependencies. They come in both radial and stackable form, and each features three sizes that I hope will cover almost all your needs for stock KSP. I've tried my best to balance these, but as there is no concept of a "fuel cell" in stock, it's a bit of a guess. I'll happily take any comments or criticism on these, from aesthetics to balance. Underneath, however, lies a powerful plugin that I've tried to make as flexible as possible to allow support for use with other mods and other users' creations. It features support for things not used in the stock parts, like byproducts for use with something like [thread=40667]TACLS[/thread]. A significant effort has gone into documenting the plugin as well as its implications to consider when modeling parts. This documentation is included in the distributed archive. Download v1.0: KerbalStuff | DropboxAlso available via [thread=100067]CKAN[/thread] - Last tested on KSP 0.90 FAQ: (This is included in the archive but is posted here for ease of access.) License: Note that there are actually two separate licenses in use here. The plugin itself and its source code (which is included in the archive) are licensed under the CC BY-NC-SA-4.0, a copy of which is included in the archive. Everything else in the archive (except the CC BY-NC-SA license itself) is licensed under my own license which is also included in the archive, and reproduced here: All files contained within, with the exception of the CC BY-NC-SA-4.0 license itself, are copyright Orum on the KSP forums ( http://forum.kerbalspaceprogram.com/members/100536-Orum).The plugin (ODFC.dll) and its source code (files contained within the PluginSrc directory of this archive) are licensed under the CC BY-NC-SA-4.0 license. The CC BY-NC-SA-4.0 license is included in the "CC BY-NC-SA-4.0.txt" file, and can also be found at this URL: https://creativecommons.org/licenses/by-nc-sa/4.0/legalcode 1. Definitions: a. Content - Copyrighted materials not licensed under the CC BY-NC-SA-4.0 license or consisting of the CC BY-NC-SA-4.0 license itself. b. Component - Any portion of the content defined above. c. Hosting - Keeping a copy, ephemeral or permanent, of the content on a system with the intent to distribute. d. Non-Commercial Use - Use of the content where every party and every potential party is not required to pay a fee or provide compensation, beyond Internet access fees, in order to access said content at every quality level available to any party other than the party responsible for creating or hosting the content. e. Commercial Use - Use of the content that does not fall under the definition of "non-commercial" above. f. Content Management System - A system intended to facilitate users with the installation (including downloading) of or the management of (including installation and uninstallation) the content or components thereof. g. Repackaging - Combining a component bundled in a manner that precludes separation of the content prior to the downloading, extraction, or installation of the component by anyone other than the end-user of the content; or the download, extraction, or installation of a component where the component does not consist of the entire content by anyone other than the end-user of the content. h. I/me - The owner of the copyright. i. You - The individual or organization exercising the rights granted or restricted by this license. j. Third Party - Any party that is not you or me. k. Party - Any individual or organization. 2. Permission is explicitly granted for the following, but does not imply permission for items similar to the following: a. Hosting and distribution of content by sites to which I have uploaded the content. This is limited to KerbalStuff (kerbalstuff.com) and Dropbox (dropbox.com). b. Downloading, installing, uninstalling, or other management of the content via "The Comprehensive Kerbal Archive Network" (CKAN; https://github.com/KSP-CKAN/CKAN), and other non-commercial content management systems, provided they don't violate any other portion of this license. c. Non-commercial use of the content or components. d. Creation, distribution, or use of files created by you or a third party modifying the included *.cfg (config) files via ModuleManager (https://github.com/sarbian/ModuleManager), provided they don't violate any other portion of this license. e. Creation, distribution, or use of textures created by you or a third party for use with included components, provided they don't violate any other portion of this license. 3. Additionally, explicitly forbidden is the following: a. Repackaging of the content by anyone other than me without explicit permission or authorship from me. b. Asserting or implying that endorsement or sponsorship has been granted to you or anything created, edited, or otherwise modified by you without explicit claims made by me. c. Commercial use of the content or components. d. False claims of ownership of the content or the copyright of the content. 4. This license, or an updated version of it authored by me, must be included in an unmodified state with the content or components thereof. As this is the first public release there is no changelog. Future releases will include it. Acknowledgements: stupid_chris for debugging assistance and RealChute, RoverDude and PorkJet and taniwha and others (can't remember them all) for help with Blender, Mu for buggy PartTools and not being there while being there and his pro-modder t-shirt, darklight for being upside down and for moral support and his exception detector, SirCmpwn for hosting KerbalStuff, the folks over at CKAN for making a good mod manager, and last but not least all of #kspmodders (except SpaceCore) for their assistance and tolerating me. Without them, this would not have been possible!