Alphathon

The #autoLOC_[number] isn't an error per se, it just means the localisation string is missing. In other words, the game doesn't know what text to use for the sliders and other controls. That suggests to me that you don't have the Breaking Ground DLC, which is required for the wheel mount to function: AFAIK the wheel mount doesn't extend/retract the wheels anyway – it rotates them allowing you to, for example, drive sideways.

I've another update for you all. I've developed the icon renderer a little more and added some features: Part icons can now be scaled, which is used in a few specific circumstances. The first is stock flag parts, whose icons now scale depending on which orientation and size is selected (previously the scale was based on the largest configuration, so the smallest were tiny, which made previewing the chosen flag difficult). The second is any part which is manually coded to be scaled; at time of writing this only applies to the PT-3A Command Node Module from Benjee10's MMSEV mod, whose icon is quite small for some reason. The third is detailed below. I have also added the ability to show a part's attach nodes on the icon. This is toggled with a button in the upper left of the icon box, similar to the change variant "drop" button. The button only shows up if the part has nodes. The size of a rendered node reflects how large it appears in the editors. On parts with the ModuleDynamicNodes module, (e.g. several of the Breaking Ground motors) the rendered nodes reflect the selected option. If any of a part's nodes lie beyond the bounds of the icon box the icon is scaled to accommodate them (as seen in the second image). In most cases this is a fairly slight scaling, but for some parts it can be quite dramatic, e.g. a few of the expandable/inflatable parts from WBI Pathfinder such as the Ponderosa IHM pictured. I'm not completely happy with the shader used for the nodes (it's not obvious in the screenshots but it is slightly glitchy and doesn't feature backface culling) so I may have to write one especially rather than using a built-in one. (Unfortunately the one actually used in the editors doesn't draw onto transparent backgrounds so only shows up when in front of the part's model.) In addition to the icon stuff I have also made some changes to the damage repair system, meaning that engineers, especially high-level engineers, need less tape than other Kerbals to repair (roughly 20% less per level). Since tape is used at a fixed rate (without tools), this also makes engineers faster. If a Kerbal has a tool (currently hard coded to the KIS wrench and electric screwdriver) they also repair more quickly and efficiently (again, especially engineers). The total mass of the tape used is now added to the part's mass. Finally, the amount of tape (and so time taken) to repair damage scales with the total amount of damage (e.g. at 1 damage only 10 tape is required per point of damage; at 50 damage it takes about 12 per point; at 90 damage it takes just over 19 per point), making it easier/cheaper and quicker to repair minor damage. The scaling is logarithmic and beyond a certain point (currently 100 damage) it becomes impossible to repair using duct tape. In future I intend to expand the damage/repair feature to allow repair using spare parts and/or resources, which would not have the limitation on the damage repaired but will probably be engineer-only (and obviously require access to the required parts). I may also add an upper limit to the total lifetime amount of added duct tape mass that can be added to a part, and therefore probably the ability to replace tape-repairs with spare parts/resources or by using stock repair kits (so as to remove the added tape mass). I also have some other ideas for expanding the damage feature but they aren't fully fleshed-out yet.

Hmm, I'll see if I can explain it a bit better. B9PartSwitch is used by the resource containers included in the mod. It is also hard coded into the plugin for the workshop (at least for now) and so is a true hard dependency – things will break without it installed. Neither Firespitter nor InterstellarFuelSwitch are dependencies. They are not used directly by any part in the mod. However, the workshop plugin can interact with them, allowing players to print parts which do use them. The interaction is partly done via reflection and partly by accessing KSP's built-in interfaces (KSPField and KSPEvent variables specifically), which are how mods add controls to the PAW. If either of them is installed the workshop can use the switcher on parts that have it. If they aren't installed nothing bad will happen. The only dependencies (currently) are B9PartSwitch, KIS, KSPDev_Utils 2.4 (included with KIS), CommunityResourcePack (or any other mod which adds the appropriate resources), ModuleManager, SpaceTuxLibrary and ClickThroughBlocker.

Oh, I think I misunderstood you. I know what B9PartSwitch is – it is already supported by the workshop; in fact it is a dependency. I thought you were talking about some patch(es) to add B9PartSwitch functionality to other parts.

I've managed to get Interstellar Fuel Switch (InterstellarFuelSwitch, InterstellarTextureSwitch2 and InterstellarMeshSwitch) working I've also added a time warp button next to the printing/recycling progress bar that lets you warp to the (estimated) time of completion of a part. The time warp cancels if part production/recycling stalls (e.g. due to running out of resources). Of course, if you use KAC that's probably the better choice. Oh, and since I took those screenshots, I have made all grouped variables/controls (including resources) collapsible, much like those for B9 Procedural Wings in the previous post. That is always an option of course and in many(/most?) cases it will be the most straight-forward and fool-proof method. It's one of the many reasons the craft/subassembly loader exists. That doesn't mean there'll never be a reason to do it manually though and it wasn't that difficult to implement. (Adding mod support is usually only hard if necessary functions are locked behind a HighLogic.LoadedSceneIsEditor check or rely on something that cannot exist/happen within the workshop/in flight, e.g. some property of the vessel the part is attached to; I'm looking at you WBI switchers.) Since the module itself generates the mesh for the wings on the fly as the variables are changed I may even be able to preview it directly in a separate window or something (much like with the icon renderer). Whether it'll be worth it will depend on how much work it takes though (so no promises). I don't think things with lots of sliders are really any easier to do in the editors than the workshop; any difficulty arises when some other form of feedback is required such as CoM or the relative scale/position of parts. (I'm not sure what you mean regarding RCS. All (standard) RCS variables are accessible in flight anyway AFAIK. BTW, while there is a screenshot of options for an RCS thruster further up, they are currently not enabled in the workshop. ) Yes. I think I mentioned it earlier in the thread, but in short the first publicly available version will almost certainly be an alpha or beta of some sort (probably an alpha since it will not be "feature complete"). When that will happen I cannot say, but not until I am at least reasonably sure the core functionality is all working properly. What I will say is I really want to make sure it is out before KSP2 renders it effectively obsolete. Is that a specific mod or just a general description? Either way I assume it/they either convert parts with FS/IFS to B9 or add B9 switchable tanks to normal tanks? If the latter there's a patch included with CryoTanks that does that to a degree.

Hello everyone, I have finally managed to get back to working on the mod and have some progress to share. Switchers Most of the work I have done has been implementing various part switchers: Firespitter's FSfuelSwitch resource switching module; associated FStextureSwitch2 and FSmeshSwitch modules also work as expected. ModuleKerbetrotterResourceSwitch from Feline Utility Rovers. The UI from its pop-up window has been more-or-less replicated within the Workshop, although the mass change is shown in the tooltip and it is graphically slightly different. ModuleKPBSModelSwitch, a simple model switcher used in Kerbal Planetary Base Systems. Controls for B9 Procedural Wings have been implemented which replicate those in its editor UI window, albeit in a more stock-like style. As there are so many of them they are packed together more tightly than they would be normally. Unfortunately there is currently no way to visualise the changes made so I don't know how useful this actually is. Wild Blue Industries' WBIResourceSwitcher, the most basic WBI switcher, which has a simple cycler button, not unlike Firespitter or the resource switcher used in B9 Procedural Wings. None of the above switchers have any impact on the part icon (yet?). Unfortunately I haven't been able to get Interstellar Fuel Switch (IFS) working: I have the interface elements set up but there is a hard crash (it doesn't even write anything in the log) whenever the resource is changed which I haven't been able to track down (yet?). Most of the more complicated WBI switchers are also not yet working. Mod Filter I have implemented a Janitor's Closet-like mod filter which allows parts from particular mods to be shown or hidden at will. It differs from the Janitor's Closet in a few minor ways: The official expansions – Making History and Breaking Ground – are listed separately (rather than simply under SquadExpansion). The WBI and USI mods are split up into their constituent mods/folders, and both have their own sub-group within the mod list which can be collectively toggled. This is (currently) a feature specific to WBI and USI – any other mod families which do a similar thing will not behave like this, although this may be changed later. CTRL-clicking (or CMD-clicking on a Mac) an item in the list disables all items except that one. A few mods have specific pre-defined labels rather than simply listing the folder name; however, they are still sorted by folder name (for now at least). More may be added in future. KAS → Kerbal Attachment System KIS → Kerbal Inventory System MagicSmokeIndustries → Infernal Robotics Squad → Stock* SquadExpansion/MakingHistory → Making History* SquadExpansion/Serenity → Breaking Ground* Workshop → OSE Workshop* *Making History, Breaking Ground and OSE Workshop use their respective localisation keys to get the appropriate name, so these may change by locale. Stock is defined in the Workshop localisation so may also change. At least for the moment it only handles mod/stock/expansion filtering; it cannot filter by size, resource or module like the Janitor's Closet can. It also doesn't have presets/saved filter configurations. Resource Categories I have further expanded the resource categories (both in the Workshop and in the editors) so they now include parts which use Firespitter, Interstellar Fuel Switch or the Kerbetrotter switcher as well as stock and B9 Part Switch tanks. Resource Icons I have added a resource icon for Duct Tape. I have also added a number of icons for modded resources added by the Community Resource Pack and Interstellar Fuel Switch. These are added via config files so can be easily expanded or changed. Most of the icons are simply the chemical symbol of the resource (e.g. CH4 for Methane), similar to the stock icon for Xenon Gas (Xe). A few are more specific: IFS's Buckyballs' is a visual representation of the C60 molecule; Kerosene, EVA Propellant and Intake Atmosphere use the same icons as stock Liquid Fuel, Monopropellant and Intake Air respectively; radioactive resources such as Uranium have a faint radiation symbol behind their chemical symbol. (I haven't added icons for any other non-chemical resources yet such as WasteHeat, SolarWind or Regolith.) Like the other resource icons I have added, these icons are used in the resource categories (both in the editors and the Workshop) and in the craft/subassembly loader.

It puts them in a KIS inventory. These are entirely separate from the stock inventories. If you right click on a part to bring up its PAW there should be an option to open any inventories on the part. All Kerbals have an inventory so if you haven't added any specific container parts to your craft the printed parts are probably in a Kerbal's KIS inventory. Here is a dev screenshot from my continuation of OSE which happens to show what I mean: Notice how at the bottom of the list there are buttons labelled "Nielsby's inventory" and "Catemone's inventory". If you click on one of them that Kerbal's inventory will open. These are separate from the ones at the top which have the parachute and jetpack in them. If it isn't in any of your Kerbals' inventories you may need to check every other part on your ship for a built-in inventory. P.S. In order to get them into a stock inventory you have to place them on the ground using KIS's build mode and then pick them up using the stock system.

I don't think OSE is doing this directly. My best guess is that the vessel you are trying to build has one or more rolls of duct tape in one or more of its containers, so EL is trying to build the duct tape part(s) along with it. Since the duct tape part includes the resource duct tape EL would presumably require duct tape to "fill it up". Try removing any duct tape rolls from containers on the vessel and see it that works. Note: I have never used EL and don't know if that's how it works, but its the only thing I can think of.

Did you check the alpha channel? It isn't visible in that screenshot. Edit: looks like Doc Shaftoe beat me to it While you're at it, don't forget to remove the texturing from shuttleUV1_emit

Oh, that's a totally different nVidia exporter than I've used. (Looks like they released it around 2020 and I didn't hear about it.) From what I can tell the compression settings should be the format dropdown in the top left. For whatever reason it seems that they changed the names of all the compression options with the new exporter, so DXT5 is now BC3; I would guess that DXT5_nm is the BC3n shown in the screenshot. As far as I can tell benjee10's textures are saved using normal DXT5 so it might be worth trying plain BC3 (that might be what the model is expecting, and if given BC3n the channels will all be wrong unless it knows how to handle it on-the-fly).

You can set the compression type in the dropdown to the left of the save button in the dds exporter.

If by that you mean the "seam" down the middle that's probably a result of the weird normal map system KSP uses (I'm not sure if it's a Unity thing or just KSP). Most other software uses the R, G, and B channels for the normal map, but KSP uses R, G/B and A for some reason. (I say G/B because usually these are identical and I cannot remember which is used.) When viewed in an editor such as Photoshop your normal map should be mostly a sort of pink colour rather than the blue you'd normally get.

In the last few weeks I've been mainly doing more code clean-up and so-on, hence the lack of updates. I have made a few tangible changes though, which I thought I'd share. Craft loader changes: Craft files are now organised by save, with different saves treated like categories. The current save appears at the top of the list and is the default, followed by the category containing stock craft; after that, other saves are listed alphabetically. (The image shows the stock category.) I have refined the graphics on the VAB/SPH tabs and they now act like tabs rather than simple buttons. I have improved the performance of the craft loader (when displaying a loaded craft) – it is now similar to that of a single part. The craft loader now separates out inventory contents as separate parts. (Previously they would be manufactured along with the container part. This also meant that they would not be properly accounted for in the recipe.) Unfortunately this does increase load times when selecting a craft (or subassembly), sometimes quite dramatically, as ConfigNode manipulation is a rather slow process. The increase in load time is directly proportional to the number of containers and parts stored within them so a craft with many items stored in containers can take several seconds to load. Stacks of identical items are now merged into a single stack. (Previously only those added in symmetry were treated as stacks.) Stack merging: Stacks of identical items in the queues can now be merged together by dragging one over the other. Identical here essentially means "is unprocessed* and has the same part config", meaning if two parts differ in any way (modules present, amount of resources, values in any given module etc) they cannot be merged. It also checks to make sure they are targeting the same inventory type (KIS or stock) but does not check whether the item is paused or, in the case of the recycler, whether they came from the same inventory originally. When dragging an item, any other identical (i.e. mergeable) items are highlighted in green; any items which are identical other than resource quantities and/or target inventory type are highlighted in orange; any other items which are the same part type but are different in some way are highlighted in red; items which are different parts are not highlighted. * i.e. manufacturing/recycling of the part has not started; simply, if a part has a progress bar or Partially constructed at the start of its name it cannot be merged. One side effect of the comparison method is that some seemingly identical parts added from craft files cannot be merged with parts added directly from the part list. This is usually because the craft file, and therefore the extracted part config, was created with different (or no) mods installed or on an older version of KSP, so has different or missing modules or fields in those modules' configs. It is also likely (although untested) that if a part is added to the queue before a mod is (un)installed and another is added after they will also be unmergeable for the same reason. If possible I'd like to work around this issue but haven't sound a working solution yet. Another side effect is that modules which have some kind of unique identifier or other unique per-instance value will not be considered equal. For such modules manual workarounds would need to be written on a per-case basis. Down the line I intend to extend the feature slightly so that orange-highlighted items can be merged but require confirmation of which stack's values to use. This will only apply to the workshop, at least for resources, as in the recycler the resources are actually present and contained within the part, rather than being just a "command" to fill the part up on completion (for Liquid Fuel, Electric Charge etc) or manufacture them alongside the part (for Solid Fuel, Ablator etc). I may also add "original inventory" to the criteria for it being orange when/if I do this. Other changes: I have added resource icons for Dirt and Waste Material. Controls for the workshop and recycler are now grouped in the PAW I have added a few module manager patches which override the KIS volume for some parts, similar to the flag parts. Since these override the volume KIS uses the changes are global (i.e not restricted to the workshop). The inflatable heat shield's volume now reflects its deflated state. The value used (16,000 L) was estimated by comparing its size to other parts. The surface science parts use the same value as their stock packed volumes.

I've got quite a lot done since my last post but most of it is "under the hood/bonnet" sort of stuff so there aren't many screenshots for me to show off. I have upgraded the resource categories so they now include B9 parts – if a part has a B9 subtype which includes a particular resource it now shows up in that resource's category. This applies to both the workshop and the editors. (Previously they would only be filtered based on the contents of the default subtype, so, for example, the OSE containers would show up under Material Kits but not Rare Metals, Exotic Minerals, Dirt or Waste Material.) I hope to expand this to other resource switchers, such as Firespitter, Interstellar Fuel Switch and the switcher used by WBI mods in future (when I implement them in the workshop itself). I have added resource icons for Material Kits, Rare Metals and Exotic Minerals based on the decals used on the containers. Dirt and Waste Material will come at some point too. I have implemented the stack manager in the recycler. It looks and works broadly the same as the workshop one but for obvious reasons cannot change the total number of items, only split them between different stacks (so there are no Delete, Clone or Add new stack buttons and adding or subtracting from a stack increases or decreases an adjacent stack). StoredParts (i.e. items stored in a stock container) now use the new icon renderer in the recycler. Most of the features of Conformal Decals are now properly implemented aside from a few kinks I need to work out with the CDL-T Text Decal part (everything is functional but some of the controls aren't showing up when they should). However, the decals do not currently show up in the icon renderer. I have done quite a lot of code cleanup, mostly converting redundant/repeated code to functions etc. I have also managed to improve the performance of both the part list and the craft loader (although the latter is far from smooth still). I have done quite a lot of work on the craft part loader. Each part now has a toggle next to it so it can be ignored when the Add all to queue button is pressed. In the screenshot below there are two disabled/deselected FL-T100 Fuel Tanks which would not be added to the queue. Unprintable parts (i.e. those which are both a) too big for any connected KIS container and b) are either too big for any connected stock container or can never be stored in one) are disabled automatically and cannot be enabled (e.g. the Kerbodyne parts in the second screenshot). Parts now also display their contained resources; if available they will use the specific icon for that resource, otherwise they will use the generic "fuel can" resource icon. When the icon is hovered over it displays the name and amount of that resource contained within the part. Finally, if a part's cargo type cannot be changed (generally this means it is not stock-container-compatible) it now has a little padlock icon over its bottom-right corner to alert the user. I have added a set as target button to the app next to the switch to button, so OSE vessels can be targeted more easily. (Not that there's any real need for it, but the craft list is there, so I might as well take advantage of it right? If you have any other ideas for useful functions that "might as well" be added to it please feel free to suggest them. (I already plan to have some kind of resource display.))

I've got quite a lot done this week. The flag parts now have a proper browser to select which image to use. Queued parts in the workshop now have a stack manager which is accessed through the right-click radial menu thing. It allows the stack size to be changed on-the-fly, as well as for additional stacks of the same part to be created – stacks of 1 can be added by clicking Add new stack, and any given stack can be cloned or split in half; stacks can also be deleted from the list as long as there is at least one left. The changes do not take effect until the confirm button is pressed. Any part in the queue can be managed as long as production on it has not started. I am not yet sure if I am completely satisfied with it graphically, but it is functionally complete. I intend to do something similar for the recycler although this will of course be much more restrictive. I have added some controls to the inventory browser in the recycler: a toggle to show/hide Kerbal inventories, a button to collapse all inventories and a button to expand all inventories. Again, the graphics are subject to change. I have implemented a generic handler for PAW UI controls. This includes sliders, option selectors, toggles, cyclers, "event" buttons and labels. Unfortunately this doesn't mean that mod- or module-specific code isn't required as many modules need to perform a setup process before the controls work properly (or at all). Some controls also show up when they shouldn't (for example the engine throttle slider shows up regardless of whether individual throttle is enabled.) Hopefully though this should mean that turnaround can be much more rapid (much less coding will be required to support most mods, at least in theory). The screenshots below show some controls which are functional more-or-less without intervention by me. None of the controls for either part were manually coded for except for the variant/B9 selectors. There are now pack/unpack buttons in the app (when the packing feature is enabled in the options). There are also some other changes I haven't taken screenshots of. I have converted the WorkshopQueuedItem class (i.e. parts in the workshop/recycler queues and in the craft/subassembly loader) over to the new icon renderer; only StoredPart and ModuleKISItem items (as displayed in the recycler inventory browser) still use the KIS icon renderer. Finally, I have made my own version of the graphics used by the scrollbar "thumb"; the stock version was never really designed to be scaled down as done in the mod, which resulted in the ends being sort-of "pointy". (This can be seen in several of the other screenshots.)

I meant in Sandcastle; sorry if that wasn't clear. The actual issue I'm talking about is with the KSP labs themselves and would need to be worked around by Sandcastle. OSE isn't related to this other than it being how I encountered the issue. BDArmory and KIS (and probably other mods too) also have to do the same thing. If it is the same problem I had then no Science Lab will be printable and there's nothing you can do about it yourself – Sandcastle would need to be patched. Otherwise there may be a specific issue with that part in particular, which I'm sure would also be useful for Angel to know about. P.S. what inflatable parts are you referring to? If you let me know I can make sure they are compatible with my overhauled version of OSE. (You should PM me or post it in the dev thread in my signature rather than here so as to not clog up this thread with stuff unrelated to Sandcastle.)

Have you tried other science labs? If those don't work either I suspect its the same issue I had with parts containing ModuleScienceLab in OSE where they wouldn't print (details in the spoiler).

Hi all, long time no see. I have finally managed to get back to working on the mod and have some updates for you. First, I have added support for categories added by Filter Extensions. Add and engine type categories are fully supported; replace type categories are not fully implemented yet. In Filter Extensions' default configuration this means that all newly added categories are added, some additional subcategories are added to the stock Filter by Function category and some of the categories in Filter by Cross-Section Profile and Filter by Resource have been moved around and given bespoke icons but the folder-based changes to Filter by Manufacturer are not implemented. As a side note if a category added by Filter Extensions has only a selected icon (rather than both selected/white and normal/black) the Workshop will generate a normal/black version of it so it matches the functionality of the stock categories (as well as CCK); Filter Extensions itself does not do this in the editors so you end up with white icons used by both button states. Any categories added by Filter Extensions which contain no parts (e.g. categories for mods which aren't installed) are ignored. This is why the Struts sub-category does not show up in the screenshot of the structural parts below, as compound parts (struts, fuel lines) are currently blacklisted from the workshop. (This may change in future. They were originally blacklisted because they cannot be used properly in the KIS construction mode but I think they may work in the stock construction mode – I haven't tested this yet.) You may also notice that I have removed the scroll bar from the categories list, mirroring the style used in the editors. (They are still scrollable, there's just no scroll bar.) (In the screenshots the pale blue numbered categories are from the Moar Filter Extension Configs sub-mod.) I have added a Filter Extensions config for the Workshop as well. It collects together all parts from the mod itself as well as any parts which contain either a workshop or recycler module. Both module types have their own subcategory. The screenshots below show these subcategories with both Keridian Dynamics and KPBS installed, both of which have both workshop and recycler parts. As it is just a config this category will show up in the editors as well. (This is in addition to the Workshop category the mod adds to the Filter by Function list, which similarly includes workshop/recycler parts from other mods but of course does not have sub-categories.) I have also added support for the categories added by Nils277's Kerbal Planetary Base Systems (KPBS) and Feline Utility Rovers. To mirror the behaviour of these mods their parts are no longer shown in the main Filter by Function categories if configured to do so. A catch-all mod category is also added to Filter by Function if configured to do so. A small caveat to this is that KPBS does this via an in-game option, which cannot be accessed by other mods, so I have set it up to show this category if its config (GameData\PlanetaryBaseInc\KPBS_config.cfg) has the value separateFunctionFilter set to true. The config already has this value listed but as far as I can tell by looking at the code for the plugin it is never actually used by the mod itself (either it is obsolete or was simply never implemented). The same value is actually used by Feline Utility Rovers to enable the category in its config. The subcategories in these categories show up in the order they do in the main Filter by Function category, rather than the seemingly arbitrarily different orders the mods themselves use. I have also added a fallback "none" subcategory to these categories (the one with the ? icon); this will only show up if there are parts with their category set to none/-1. (They are visible here because of a personal Module Manager patch I have in my install which is set up to move some types of part out of their "normal" categories and into various CCK categories. This has nothing to do with mod but I thought it was worth explaining.) Finally, I have added flag parts to the icon renderer. This includes displaying of the correct mesh for a chosen variant/orientation/size and properly displaying the chosen texture on the mesh. It currently does not take the mirror option into account. It is also worth noting that (currently) the size of the icon is determined by the largest mesh, which means that when smaller sizes are selected the icon can end up very small. I may be able to work around this later on.

I cannot say for sure but I don't see why not. The reason CRP is a dependency is essentially to prevent conflicts when defining resources and so multiple mods can use the same resources without defining them specifically. As far as I can remember the actual recipes/resources used are all defined in configs (i.e. they aren't hard coded in the dll anywhere) so at the very least they can be changed using module manager patches. Assuming SIMPLEX works in the same way as CRP (i.e. defines resources using the stock system rather than its own) it shouldn't be a problem. P.S. I haven't had time in the last few weeks to work on the mod but should be getting back to it soon.

I haven't any plans for it but I'll have a look at it. I don't use it myself so I don't even know if its compatible with KIS or the stock inventory system. If it is though I'll just add it to the list. (In principle I'd like all mods to be compatible if possible, although in practice I'll prioritise easy or popular mods and ones I use myself.) As long as they are loaded in the current scene you can access the built-in assets using UnityEngine.Resources.FindObjectsOfTypeAll<T>(), so if you want to load a Texture2D called "stock texture", you can do something like Texture2D stockTexture = Resources.FindObjectsOfTypeAll<Texture2D>().FirstOrDefault(obj => obj.name == "stock texture"); Since FindObjectsOfTypeAll returns an array of all of the loaded assets of a given type you can loop over them to get a list of their names, then output them to the log or something to see what's available. Bear in mind though that the list will also include assets loaded by mods. Alternatively, there are methods in the GameDatabase class which can be used to access particular files, such as GetTexture(). GameDatabase needs an instance reference so they take the form GameDatabase.Instance.GetTexture(). Some assets are only loaded in particular scenes so can't be used unless you can load them from the stock sharedassets containers (I have tried to do this but haven't had any luck). For example most of the editors' UI assets are only loaded in the editors so cannot be accessed in flight. Since KSP is built using Unity the Unity Script Reference can be quite useful.

Time for another update. I've started work on the new icon renderer to replace the KIS one. Unlike the KIS one it displays the parts using a constant 50% ambient light with no directional light, mirroring the behaviour of the editors' icons. (The KIS one has a single strong directional light and uses the same ambient light as the scene, so it varies depending on the current vessel's location.) It also rotates the parts slightly slower – a full rotation takes 6 seconds like in the editors (I think KIS's takes 5s). Currently the new renderer is only used in the workshop part list and part preview (i.e. it isn't used in the workshop's queue, the craft file/subassembly loader or in the recycler) but once it is finished I will extend it out to the other UIs. In addition to the differences mentioned above the new renderer is also able to display part model changes implemented using B9 Part Switch. It is currently able to switch textures and toggle sub-meshes; other changes (mesh rotation, mesh position and mesh scale) will come later. Here is a part from Benjee10's Planetside Exploration Technologies/MMSEV showing several different B9 subtype combinations: I have also added compatibility with the variables for the flag parts, i.e. Orientation, Size, Flag Image and Mirroring. At the moment the Set Flag button simply cycles through all the available flags one by one but I hope at some point to create a UI similar to the editors'. Changing the Size and/or Orientation changes the mass as expected. I have not yet looked into displaying the different variables on the icon renderer (the system the FlagDecal parts use to change the mesh is somewhat different than either the stock variant or B9 so will need to be specifically implemented). Something else to note is KIS does not seem to calculate flag parts' volumes properly (it seems to use the volume of the largest mesh available), which, as you can see from the screenshot, can result in ludicrously large values. I don't know if there's anything I can do about this – I could override the part's volume calculation to use the right mesh but I think KIS itself will recalculate it when it is added to the inventory so there isn't really much point (I'll give it another look at some point to be sure). I think it may be possible to workaround this by adding a ModuleKISItem to the part and using the volumeOverride variable to set the volume but more investigation is required.

Thanks! I don't have a Git repository just yet I'm afraid. Once I get it to (what I consider to be) a releasable state I will of course set one up though. In terms of mod compatibility there's not really anything special going on – it's not really any different than interacting with KSP itself. If you want an idea of how it's done you can look at the code for the previous versions of OSE Workshop (there are links to their threads in the OP), as they already interacted with KIS and KAC (KIS by directly referencing the dll, KAC by reflection) and I'm really not doing anything that different with any of the other mods. For some mods such as CCK you don't even need to reference the dll, as all the useful information is loaded into stock ConfigNodes which can just be read directly. (You could take a look at CCK's source for an idea of how that's done.) Usually the tricky part isn't so much the implementation but figuring out which variables need to be changed to have the desired effect, but if the mod is well documented and/or uses clear, unambiguous variable names it usually isn't that hard. As for the GUI I've mostly just tried to replicate the stock GUI. Most of it isn't much more than plain Unity IMGUI buttons, boxes etc using stock textures which I have then laid out to match the stock UI. Off the top of my head the only bits that are really any more complicated are those which depend on mouse position (queued item dragging, resource sliders, tooltips) and the very few animated UI elements (partlist sorting dropdown, queued item radial menu) but that really just requires the element's state (position, scale, whether the pointer is held down etc) to be stored in a variable between frames/OnGUI calls.

My guess would be the Kerbetrotter Ltd Feline Utility Rovers. It looks (from the log) like eberkain has that installed and it for whatever reason tries to add its own version of the rovers category to CCK in addition to the one found in CCKCommonFilterConfig. CCK ignores this as it won't add duplicate categories (presumably to prevent conflicts when multiple mods try to add the same category).

Thanks Yes, it will still have dependencies. The previous versions had KIS, FirespitterCore, B9 Part Switch, CommunityResourcePack, ModuleManager, ClickThroughBlocker, ToolbarController and SpaceTuxLibrary as dependencies (some hard, some soft). It is also dependent on Breaking Ground for the robotics modules and KSPDev_Utils 2.4. KIS is likely to remain a hard dependency for a while but should eventually be removed. While it is still listed in the OP of the last version's thread I'm not sure if FirespitterCore is actually still used for anything so it will probably be gone. It used to be used for the resource containers I think. B9 Part Switch wasn't previously a hard dependency but was used by the resource containers. Currently it is also required by the plugin but as mentioned above I will probably convert that to a wrapper. Regardless it will remain required by the containers and maybe some other parts down the road, so it will still be required unless the switching functionality can be replaced by another mod's through a MM patch. CommunityResourcePack is required for the resources and I don't see that changing. ModuleManager is used by various patches and will probably continue to be. I don't think it is a hard dependency strictly-speaking but is required for the recipes to work. Once I have converted it over to uGUI I don't think it will need ClickThroughBlocker. Until then it will. ToolbarController is only used as part of an image loader and may no longer be necessary. The few references to this have now been removed. I'm not sure what SpaceTuxLibrary is used for TBH. SpaceTuxLibrary is used for the colour picker and part highlighter. Breaking Ground will probably be wrapped like B9 so shouldn't be a dependency. KSPDev_Utils 2.4 may or may not be removed. I've only used it in a few places and I don't think it's doing anything particularly complicated so may not even be really necessary. TL;DR: the mod will definitely still require B9 Part Switch, CommunityResourcePack and ModuleManager. SpaceTuxLibrary may also be required. KIS will also be needed for the foreseeable future. A few other dependencies are uncertain.

I have another update for you all I have spent a bit of time working on the App and have fully converted it over to uGUI (as mentioned in my previous post). At the moment it shows all vessels in the game world with either a workshop module or a recycler module along with their statuses. As you can see in the screenshot each vessel is labelled with its craft type icon, name, and situation/location. If any of these change it is updated. Vessels can be switched to by using the curved arrow to the right of the label. Inside each vessel's box is a list of workshop/recycler parts. Mousing over a part's name highlights the part's model (using the same green glow you get when mousing over the part). If the vessel is in load range its status is shown (including progress bars if relevant), production/recycling can be paused/resumed and the workshop/recycler menu can be opened/closed (using the 3-dot "menu" button to the right of the pause/resume button – this simply toggles the workshop/recycler menu and is not a dropdown or anything... at least not yet). The statuses are grouped by part so if a part has both a workshop and a recycler the part is not listed twice (not true of any OSE parts but some other mods do this with their parts, such as Keridian Dynamics whose parts are seen in the Keridian Mobile VAB and Repair shuttle vessels in the screenshot). The size of the window changes dynamically based on its contents. All the tooltips in the App also use the uGUI system. There are a few things I haven't implemented yet, such as how to handle vessel (un)docking/decoupling, when a vessel is destroyed or when a part is added/removed from a vessel using either stock construction or KIS. At the moment if there are too many vessels they will simply continue beyond the bottom of the game window so I'd like to add some kind of scrolling and possibly vessel collapsing similar to the inventories in the recycler. The vessels cannot be sorted in any way so they just show up in the order they appear in the code (which I presume to be roughly by launch date but may be influenced by (un)docking/decoupling etc) so I'd like to add that capability. At the moment the only way to tell which vessel you are currently flying is by the absence of a switch to button so that could be indicated in some way (perhaps a different coloured label or simply by being placed at the top of the list). There are also other features I intend to add down the road such as the management of power/resources, converters (e.g. ISRUs), inventories and queues. I also hope to implement background processing (similar to Kerbalism) at some point so that "out of range" parts can also be managed. Assuming I do that I will also add some checks to make sure the current vessel can communicate with it (e.g. it is in communications range or both are connected to the same relay network), but that is probably a long way off yet. EDIT: I also forgot to say the icon is likely to change as with all instances of that icon used to represent the mod. I have also implemented kOS variables in the workshop, allowing the boot file and disk size to be changed for manufacture. The disk size also changes the resource cost and build time (slightly). kOS processors also have a recipe now. Unlike B9 and KIS, whose plugins are dependencies, kOS is added in a wrapper using reflection so is not required to be installed. At some point I intend to do the same for B9 and the expansion modules, and probably add support for the 1.12 stock alarm clock in a similar manner (Kerbal Alarm Clock was already supported in this manner before I took on the mod); KIS will probably take a bit longer as a lot of the code relies on it and I also need to do things like replace the icon renderer. Finally, I have added some size 1/1.25m containers for the resources. These are identical to the size 2/2.5m versions other than their size/capacity and some writing changes on the textures. They hold 375 and 750 units of resources respectively (compared to the 3000 and 6000 of the large versions). I intend to remodel them at some point (along with everything else, in a style probably similar to reStock or Nertea's Near Future mods) but that will come much later. Thanks, and welcome to the forum! Soon™ In all seriousness though I'm not confident it is reliable enough yet to be used in an actual live game (it does thing like mess with the parts list in ways that also effect the editors so at the very least I need to be sure that's all working as intended). I think theJesuit suggested that further up. I'm still thinking about the name but think I might try to distinguish it from the older iterations in some way (to make it clear it isn't "just" an update/adoption of the existing feature set like with Reworked and Continued), so maybe something as simple as OSE Workshop 2.0, possibly with a subtitle.