Crzyrndm

Black Lines are for scale Green Line is X-Section area at that location Yellow Line is the 2nd derivative of X-Section area (rate of change of slope of the green line) You want to minimise the magnitude of the yellow line, to do so you smooth bumps out of the green line. Yellow magnitude is proportional to the Wave Drag area the window tells you, and how small is "good" depends on how large your craft is (the ratio of area to wave drag area *may* be a fairly consistent measurement, but I don't have any number for that either)

http://forum.kerbalspaceprogram.com/threads/122650-WIP-Filter-Extensions-Part-Search Feedback appreciated

Download is in two parts for a while as I built this against the dev version of Filter Extensions Place in GameData (location doesn't matter): Part Search .dll and Filter Extensions .dll (note, if you are already using Filter Extensions, remember to overwrite/remove the old one)

About Part Search (name to be decided...) will be an addon for the mod Filter Extensions utilising it's established filtering methods to rapidly create completely customised categories. It's use will be twofold Providing an extensive and easy to follow means searching through the part catalog for end users. Providing an in game UI for creating subcategories to be used with Filter Extensions. The initial focus will be in creating a UI that isn't prone to breakages / a complete mess and exposes the full functionality provided by FE in a manner that is easily used. For the time being, permanent additions will have to be achieved by copying the generated nodes out of the logs and into somewhere more appropriate. Download - Requires Filter Extensions v2.2.1+ License is GPLv3

Both, although FAR is not quite working right.

This should do the job, just add IS Fuel Switch to the resources Category definition at: 000_FilterExtensions\Configs\Stock Categories SUBCATEGORY { name = IS Fuel Switch icon = FILTER { CHECK { type = moduleName value = InterstellarFuelSwitch, InterstellarFuelSwitch2 } } } and maybe find an icon for it...

For people wanting a 1.02 version

Have a bit of a play around with this .dll and tell me what you think. You'll need a cfg with this somewhere in GameData with the highlighted line to see anything (previous versions shipped with a settings file, I don't think the last few have. Edit existing ones if they exist). It's very quickly put together so it does tend to break every now and again (just reenter the editor if that happens) and it doesn't support everything fully. I'm just looking for feedback on whether continuing development is worthwhile (UI scripting is a PITA, and this stuff doesn't lend itself to easy UI's...). EDIT Ok, I'm convinced. Not by the intended usage, but by how a powerful it could be as a part search plugin (sidelining as a subcat creator)

That's already a thing. Bottom of the UI, you can choose what fuel to use (or if using MFT/RF, they are setup for those). The rest of it is unlikely to happen to my knowledge (2 you can normally achieve with a little bit of clipping, 1 isn't going to happen, 3 could happen if someone with the knowledge to do so added it to the shader(? I think that's where the materials are done))

That is the method of last resort which is looking increasingly likely the more I look into this. Optimising it isn't really an issue, it's just a really awkward way to do things (and prone to issues when people do something unexpected)

Before you say "category = none", the issue is at hand is that the category is no longer a reliable method of determining visibility with the proliferation of custom subcategories, hence my issue. Stock parts are no problem, I can easily filter those out by name. However, I know in the past there has been some mods which have used dummy parts for various reasons that also shouldn't be visible in the editor. I was wondering if the existing dummy parts share a common attribute that I can check to prevent them being visible in the editor categories. 1) What mods make use of these dummy parts? 2) What common attributes are likely to set them apart from parts that should be visible?

Assuming by orientation you mean the collider/mesh transform orientation, I don't think this is the case. Debug.Log("orientation: " + part.transform.rotation.eulerAngles); [COLOR=#008000]// part orientation[/COLOR] Debug.Log(meshFilterWingSurface.transform.rotation.eulerAngles); [COLOR=#008000]// mesh transform orientation[/COLOR] Debug.Log((Quaternion.Inverse(part.transform.rotation) * meshFilterWingSurface.transform.rotation).eulerAngles);[COLOR=#008000] // rotation of the mesh transform relative to the part transform[/COLOR] [COLOR=#008000]// there is no collider for this particular mesh[/COLOR] The third value is consistent for all part rotations for all meshes/colliders, which (if I'm not barking up the wrong tree) would indicate to me that the orientation of the mesh faces is consistent (and presumably correct because it works half the time).

if the root node is techTree, that's the one you need to check GameDatabase for. You can then get the RDNodes using techTreeNode.GetNodes("RDNode"). As for why there is two, I don't know. print them both to the log and see what they look like (the node.toString method will show values just as they would appear in a .cfg)

you will also want to use "%hideempty = true" in the experimental electrics patch to avoid duplicate values (% operator is edit or create depending on whether the value exists or not)

@ferram I'm a little bit lost with this one. Initially I thought it may have been down to the lack of delay between symmetry counterparts sending updates, but testing has disproven any link with symmetry or update rate. Any wing I place to port of the cockpit (up to and including perfectly vertical) is voxelised as if it was slightly larger on most surfaces than it actually is (the only surface that seems to be exempt is the outer face). Any wing placed to starboard of the cockpit is voxelised with minimal protrusion. Symmetry type/count, order of placement, changing update delay all has no effect on the issue. The major difference in the FAR setup from standard parts is the "forceUseMeshes = True". Could this be the cause? EDIT Orientation, not location. Port facing is enlarged, starboard facing is normal.

You probably want something like string[] allNodePos = new string[allNodes.Length]; for (int i = 0; i < allNodes.Length; i++) allNodePos[i] = allNodes[i].GetValue("pos"); or even string[][] allNodePos = new string[allNodes.Length][]; for (int i = 0; i < allNodes.Length; i++) allNodePos[i] = allNodes[i].GetValue("pos").Split(','); which will give you each of the pos numbers in individual cells (eg. allNodePos[0][0] is the first number in the first node)

I can guess what's causing that, will try out a few things and hopefully get a fix out shortly

Already done, you can enable it in the settings file (nothing ingame just yet)

Give yourself a bit more credit man, you adapted/created just about all of the ~300 icons and I don't think I've ever turned any of those away (I *did* trim down the subcategories a bit when they started going off the page...) That is definitely one of the driving forces for splitting it up. 1) Urgh, documentation... I agree it needs to be done, it's just another of those time consuming things that need constant work (The stuff in the OP is probably already out of date and not complete -.-) 2) The current set of cfg's would be their own complete download (with icons being packaged with the plugin for now atleast). Doing each one individually is as much a PITA for me as anyone else I have an idea on this front for something a little less complex than a full editor (which is a complete PITA), but might be useful. It's just getting the motivation and time together to implement it.

Ferram seems to be having a few issues getting the marker to behave with FAR v15.x (probably related to the fact that he considers it of very little use because of how FAR works.) FAR provides multiple analysis tools that are more reliable and give you much more detailed information about how your craft will behave in different conditions than the location of the CoL indicator ever will. You can find more information about those tools here in the "design analysis" spoiler.

That is exactly what has been done, just in a slightly different way. If vertical speed can't match or exceed a percentage of airspeed, there must always be a horizontal component to the craft velocity. The limit I have set allows a climb rate of up to 95% of airspeed, which requires horizontal speed to be above ~31% of airspeed (by a bit of basic trig).

Just to clarify, the line of code should look exactly like this (the missing brackets above is annoying me...) WheelSound.audio.pitch = (float)[COLOR=#ff0000]([/COLOR]10 / (1 + Math.Exp(-averageRpm)[COLOR=#ff0000]))[/COLOR]; You only need to move the .dll specific to the mod. When adding references in Visual Studio, you have to change the copy local field to false to get rid of the majority of the rubbish. I assume there's something similar in Xamarin. You should also be moving it to overwrite the .dll shipped by the mod in question, which will be in GameData/<insertModFolder> or one of it's subdirectories. DO NOT put it in the <KSPInstall>/Plugins folder and DO NOT have the old and new .dll both inside GameData.

Note: This enquiry is at an investigative stage currently, not looking to actually change anything right now. What would be the best way to handle this split for CKAN? Can it understand separate multiple zips/packages per Github release (does it even need to be split?)?

Well that one looks to be well and truly shot down... (and that picture reminds me I need to find where Squad is keeping their "no icon" icon now...)

So, a couple of things I have been thinking about that I don't really know enough about to decide how to proceed. 1) Texture format. With 1.0 having DDS texture loading as stock, and with FE currently being distributed with something like 320 32x32 icons (~20% larger than a single 512x512 on pixel count for whatever that's worth) it's may be worth making the switch. The sizing appears to be compatible (32 being a multiple of 2 which is required as I understand it). What reasons are there to not convert? (assuming the lack of read/write access isn't an issue, I haven't actually got as far as testing that...) 2) Distribution method / Icon Loader Right now, FE the plugin comes bundled with a fair number of configs that one would need to manually remove if they were not wanted / have an alternative setup. The automated functions of the icon loader and (optionally) Filter by Folder are useful features in their own right that could be of benefit to more users and authors. Looking around, I see several methods that could be used. Option 1: Split the plugin and configuration files into separate downloads. This would allow for easier creation/distribution of alternative configurations and leaves the plugin itself with less baggage (particularly useful for authors who could just use the plugin to get icons to work and/or create categories/subcategories as they see fit. Also useful for those that want to customise the lists for themselves without having to deal with updated configs). Downsides would be increased complexity (plugin install and configuration install), and deciding what to do with the icons. Widespread use of CKAN mitigates the install complexity somewhat and I can continue distributing a single package if need be. Option 2: Split the icon loader off into a separate plugin that would disable itself if the full FE plugin was detected. Keep FE in the current single release format. Simple, unlikely to need updates outside of KSP version changes, but only really useful for part mod authors that want to avoid writing a plugin just to get the icon to work. Downsides would be a lack of features (obviously) so no making categories/subcategories without requiring a full install or a different plugin. Option 1 would be my preferred method but I don't know how to effectively set up distribution. What would CKAN require to split things up, what to do with the icons, etc. Thoughts?