Alphathon

Hi all. I know it's been a while since I posted an update, and I thought I should probably fill you all in on how it's going. Rest assured I am still working on this. I have set up a dev thread detailing my progress so far, planned features and what I plan to do with regard to release. The simple version is that I am approaching a releasable version of some form. I would consider this to be a pre-release of some description (which I'd probably call an alpha rather than a beta as it probably won't be feature-complete and will undoubtedly be buggy) rather than a fully-fledged release, as many of the changes made will require more testing than I can do alone, especially given the vast number of mod and version combinations likely to be in use which may interact with it in unforeseen ways. https://forum.kerbalspaceprogram.com/index.php?/topic/201718-wip19x–111x-ose-workshop-continuation-name-tbd/&do=findComment&comment=3954489 If you want to post more information in the dev thread you are more than welcome to. I cannot guarantee support as such but it would be helpful to know the details so I can potentially fix the issue as part of development. I did have a quick look and couldn't replicate the problem in my test game (when crewed with two 5-star engineers in a sandbox game the build time was 6m, 56s). It's possible that whatever was causing the problem has already been fixed as a result of other changes I have made. However, I didn't do much in the way of thorough testing in different game types etc.

This is a mod based on OSE Workshop Reworked by @linuxgurugamer, itself a continuation of OSE Workshop Continued by @Aelfhe1m and ultimately a continuation of OSE Workshop by @ObiVanDamme. These mods allow parts to be manufactured directly on a craft using a Kerbal Inventory System (KIS) container to store them. They also allow spare parts in a KIS inventory to be recycled back into their raw materials (at a loss), and provide some limited support for those resources (an ore processor part, resource containers etc). This mod aims to overhaul many of the features of the previous incarnations, and add several new features as well, including a redesigned user interface; compatibility with the stock inventory system added in 1.11 (Some Reassembly Required); compatibility with part variants, B9 part switch, and other types of part changing normally only available in the editor; and compatibility with newer and modded part categories. The original mockup, which shows some as-yet unimplemented features is in the "spoiler" below. I am currently approaching the point where I can release a version of the mod. This will likely be some type of pre-release (which I'd probably call an alpha rather than a beta as it probably won't be feature-complete and will undoubtedly be buggy), as many of the changes made will require more testing than I can do alone, especially given the vast number of mod and version combinations likely to be in use which may interact with it in unforeseen ways. I cannot at this point give a date estimate though (it really depends how much time I have to work on it). Changes and new features (already implemented) Compatibility with the stock inventory system. KSP 1.11 greatly expanded the capabilities of the stock inventory system, which is now in many ways very similar to KIS + KAS. The mod is now able to place printed parts in stock containers as well as KIS ones, and recycle parts contained within stock containers. This mod is also compatible with older versions of KSP which use the pre-1.11 inventory system (as introduced in the Breaking Ground DLC), as limited as it is. I have been testing it sporadically in a highly-modded 1.9.1 game and so far it seems to be working OK. However, I am at this point not sure how robust it is. Obviously this can only be used with the limited number of parts designed specifically for it (or any other similar ones added by mods, if any exist). An overhauled user interface, with more information and options available to the player and a more stock-like layout. Specific changes include: The interface font has been changed to a smoother anti-aliased Arial rather than the previous aliased (pixelated) font. (I'd prefer to use the same font used in the stock interface (Noto Sans) but there isn't a version included with KSP which is compatible with the the old IMGUI system used by the mod. At some point I intend to convert the UI over to the newer uGUI system which KSP now uses for its interfaces, which will allow me to use the built-in Noto Sans TextMeshPro font.) The part categories are now shown on an editor-like vertical strip to the left of the part icons and use editor-like buttons. The part icons now appear in a scrollable area rather than "pages" as in the previous incarnations and more closely match the style of those in the editor. Part icons now spin when hovered over or selected like in the editor The part overview has been reworked to resemble the editor part preview (and indeed provide at least the same information). The search bar is now above the part list (like in the editor) and behaves better. Parts can now be sorted by name, mass, size, volume (KIS), packed volume (stock inventory system), buoyancy, max. temp, max. skin temp, max. pressure, G-tolerance, crew capacity and build time. The workshop UI now displays which mod a part comes from (similar to the tooltips added by the Janitor's Closet mod). This may be toggleable in future if people want that option (e.g. if they don't use many modded parts). A Workshop's progress is now shown as a progress bar in its right-click menu (PAW?) as well as the workshop interface. Compatibility with part variants. Now if a part has alternative skins or configurations which use the stock variants system they can be selected in the workshop interface. Compatibility with several part-switching mods. Like with stock part variants, several modded switchers can also be used through the workshop. These include B9PartSwitch, Firespitter, InterstellarFuelSwitch, KerbetrotterResourceSwitch (Feline Utility Rovers), KPBSModelSwitch (Kerbal Planetary Base Systems), B9 Procedural Wings, Conformal Decals Ability to modify the following values when manufacturing a part (which can normally only be done in the editor): Motor Size and Output(%) for robotic parts Extension/Angle Limit for robotic parts Motorized for robotic parts Allow Full Rotation for servos Ratcheted for rotors (when motorized is disabled) Attach nodes for parts with a DynamicNodes module (e.g. rotors) Quantity of resources "Fixed" resources such as solid fuel for SRBs and ablator for heat shields continue to be added during manufacture but their quantity can now be selected. Transferable resources such as liquid fuel and electric charge are transferred from the vessel at the end of the manufacturing process. Boot file and Disk Space for kOS processors Orientation, Size, Flag Image and Mirroring for flag parts Compatibility with the Robotics and Cargo categories. The previous OSE Workshop incarnations were developed before the introduction of these categories, and while they could be added to parts manually through their configs they were not there by default. Now they are. Compatibility with categories added by the Community Category Kit (CCK), Wild Blue Industries (WBI), Filter Extensions, Kerbal Planetary Base Systems (KPBS) and Feline Utility Rovers is now built in to the plugin. These populate automatically without any user intervention or manual coding required. The standard categories added by Umbra Space Industries (USI) (Rovers, Manufacturing, Logistics, Construction, Kolonization and LifeSupport) are also included, although these have been superseded in more recent versions of USI mods by CCK categories. Compatibility with other non-standard categories. Non-standard categories, including the one used for the workshop parts themselves, can now be added via a config. This currently includes Kerbalism and Infernal Robotics, but many more can be added as I find them (feel free to suggest any you know of that aren't added by any of the specifically implemented mods above). I have also added a (temporary?) catch-all BDArmory category.* As the system is config-based individual mod makers and players can support it themselves via a Module Manager patch. These can be set up to include (or exclude) parts based on any combination of part name, tags, modules, path (i.e. where the part's config file is) and manufacturer. "Advanced mode" filters/categories (Filter by Cross-Sectional Profile, Module, Resource, Manufacturer and Tech Level) are now available in addition to the standard categories (technically "filter by function"). These behave much like they do in the editors. Custom categories added using the pale brown/tan/beige + button in the editor are supported. Enhanced queue functionality, including part stacking, individual part pausing (including partially-manufactured parts), and queue re-ordering. Cancelled parts in the workshop are now be transferred into a recycler if one is available, allowing some of the resources used to be recovered. Parts in the recycler queue which haven't yet begun recycling can now be returned to an inventory. Where possible this will be the inventory it originated from, but if it is full or unavailable it will use other inventories instead. An OSE Manager app has been added to the sidebar, which allows workshop and recycler parts to be managed on any vessel in range (~2-3 km) without directly interacting with the part's PAW. I have added a new resource: Waste Material. Any mass which is not converted to useful resources by the recycler is now converted to Waste Material rather than simply vanishing, as are cancelled parts (both in the recycler and those in the workshop not moved to the recycler). Resources now (and indeed must) be transferred out from parts to be recycled. If they cannot be drained (e.g. there isn't enough space on the vessel to store them) they can be dumped/ejected. Similarly, if a part is finished recycling and there isn't enough space for the recovered resources the player may either dump them or have the recycler wait for space to become available. (Previously they would just be lost.) Items can be added to the recycler queue paused. (I also plan to add this functionality to the workshop but haven't done so yet.) This is not the same as the pre-existing functionality of pausing the recycler as it only effects newly added parts – any already queued but non-paused parts remain non-paused, and any individual item can be unpaused at any time. The former feature of specifying which categories are displayed in a workshop through the part's OseModuleWorkshop module is currently non-functional and should be considered obsolete. I have moved most of the text to a localization file, allowing translations to be easily done. I have also implemented an option to switch to British English spellings/terms via a setting (e.g. motorised instead of motorized, anticlockwise instead of counterclockwise, cancelling instead of canceling). This applies to all Workshop UI elements but does not apply to things like part descriptions. The way the system works means that it will have no impact on users who don't have English selected, and in fact the option won't even show up in the menu. I fixed bug where items in the deprecated Propulsion category would not show up: they now correctly appear in either engines or fuel tanks as appropriate. I worked around a memory issue: The KIS volume calculator seems to calculate the volume by loading up the part model and "measuring" it, but it seemingly never unloads it. (Since the KIS code documentation says to remember to destroy the object I suspect it's the Workshop's implementation but I haven't looked into this.) Previously this was done every frame for the selected part meaning that over time memory usage would creep up. This was especially bad for complex models (e.g. the large KIS containers) and could lead to several GB of extra memory use in a few minutes. This is now done only once on flight startup. Workshop UI is now not drawn when the KSP UI is hidden (triggered by the F2 button by default). The mass of the workshop module/part now increases as parts are manufactured, to simulate the part actually being built from the resources. This makes sure the total mass of the vessel doesn't change while manufacturing. (Previously it would decrease as the resources were used up, then increase again when the part was added to the container.) Parts are now recycled based on their actual state – formerly they were recycled based on the default version of the part, rather than taking into account things like variants or motor mass. * BDArmory uses a custom sub-category system which cannot simply be added through a config. I intend to look into replicating the system completely at some point after the initial release. Until then, I plan to include a basic config-based category which includes all the BDArmory parts. What still needs to be done (for this version) Currently, part variants and B9 subtypes do not play well with the stock inventory. Cosmetic changes and changes to things like tank type seem to work fine but changes to part mass do not; packed volume does not seem to be variable. However, I have had conflicting results when testing this in the VAB too so it may be a problem with KSP rather than the mod. Edit: As far as I can tell this aspect of the stock inventory system simply doesn't work. If you add 1 part with a mass-changing variant (e.g. the T-12 Structural Tube from Making History) to a stock container in the editor it will display correctly at launch. However, if you leave the vessel and reload it will revert back to default (in the case of the tube 0.075t/75kg). If you add 2 or more of the same part with a mass-changing variant in the editor but choose different variants, they will use whichever you chose last (until you leave the vessel, when they revert to default.) It would seem it doesn't take the moduleMass value into account. I don't think there's anything I can do to fix or work around this. There is still some GUI work to finish I'd also like to make sure the design is colour-blind-friendly. If it isn't and I can't make it so without compromising it I'll add a colour blind mode of some sort. If anyone knows of any other accessibility options/considerations that could/should be taken into account please let me know. Create a replacement for the KIS icon renderer that the mod uses. This is a WIP and on a basic level mostly done, but it needs more testing and there are things left to implement. Add the ability to add en masse all parts from a saved craft or subassembly to the build queue. This is mostly done but not yet completed. I'd like to look into the memory issue some more. If possible I'd like to not have it run at startup, as with large part counts this can increase load times quite substantially. It also appears to hang during said loading which is far from ideal. I need to make sure everything works correctly with save games and when switching vessels. Add any more stock (including expansions) editor-only variables that I haven't yet thought of. If you can think of any others please let me know. Light variables (colour, blink etc) Finish moving strings to the localisation file (mostly done I think). Add a few additional variables to sort by: resources required, etc. Fix a bug where scrolling sometimes zooms the camera as well as scrolling through the part/categories lists, part descriptions etc. I have worked around this issue. I need to think of a name for the mod Planned features/ideas (for future releases) I also have some plans for features which will (probably) not be present in the initial release, but may come in later releases. Naturally these are very much subject to change and may not ever come to pass. Planned "major" features (for far future releases) There are features which I plan to develop longer term, many of which will significantly change the nature of the mod. Most of them will probably be made as a separate dependent mod rather than being directly incorporated. While I won't go into detail here, most of them revolve around a new, far more expansive resource and recipe system and additional parts to facilitate this. The closest comparison I can think of is the MKS resource system. The basic idea behind this is to make colonisation a much more involved and challenging process rather than just a case of sending up a few modules and engineers and waiting. (Building a colony should require infrastructure, scarce resource management etc.) However, as I said this will likely be a separate sub-mod, so players who just want to build a few rockets on the Mun don't have to put up with a semi-realistic colonisation simulator.

The only "Pioneer module" I can find is the "MKS 'Duna' Pioneer Module" and it doesn't have a cargo part module, so cannot be placed in a stock inventory. Since none of the stock containers can be put in other containers I would assume the cargo part module and the inventory module are mutually exclusive, so KSP either just ignores the cargo part module or the order they're defined in determines which one "sticks". Since your mod adds an inventory to all crewed parts, no crewed part will ever be able to be put in an inventory. I tested this by only using AllowModPartsInStock.cfg (i.e. I removed InventoryforAll.cfg) and all the parts can now be put in containers (at least theoretically). It's also worth noting that the inflatable MKS habitats have an inventory module with 0 slots, presumably because they have 0 crew capacity. (As such, they also cannot be stored.) You might want to take that into account in your patches.

Do you have any particular parts in mind? It would help a great deal to know which parts aren't working but are expected to.

I'll DL MKS and take a look (I don't use it myself). I assume you mean using KIFA to generate the cargo modules (or does MKS already have its own?)

I don't unfortunately. (I'll make one at some point once I'm closer to releasing my version.) It's not really in a fully working state yet anyway. At the moment it basically checks if the part being produced has one of the cargo modules (ModuleCargoPart, ModuleGroundExperiment etc; I can list them all if you want). If it does it checks all parts in the vessel for the module ModuleInventoryPart, and adds any it finds to a list (it does not currently check for Kerbal inventories; I'm not sure how to do that yet). From there it loops over the list items and when it finds one with enough space* and at least one empty slot adds the part to it using ModuleInventoryPart.StoreCargoPartAtSlot(part, ModuleInventoryPart.inventoryModule.FirstEmptySlot()). (*The volume check is not currently working[nvm, I fixed it]. Interestingly it just adds the part anyway and goes over the max volume.) It does not yet take item stacking into account. It may be better to just skip the "adding to list" part and do it as it finds the inventory modules, but this way mirrors what the mod already does with KIS's inventories (so that some can be favoured I think). As for why else it is dependent, the workshop also uses KIS's volume calculator in the part recipes (which would obviously no longer be used in a stock-only version) and KIS's part thumbnail renderer. There may be other things it uses that I'm not thinking of/haven't come across. The recycler is much more dependent on it though as it is basically designed to manipulate the existing contents of inventories so at the very least the UI would have to be rewritten.

Hi again @linuxgurugamer, I had some spare time so I've started working on it. It's actually pretty trivial to make it use stock inventories as well as/instead of KIS ones. I've thrown together a crude but working version already (in the sense that you can produce an item and it is added to the inventory; it's far from robust, ignores a lot of things and doesn't have its own recipes or anything yet, but works as a proof of concept). Unfortunately the mod relies on KIS for more than just a place to put the finished items, so to remove it entirely as a dependency would take more work.

Will do.

It's on my to do list. I had planned to do it anyway to get it to work with the surface science parts but the 1.11 update makes it more important. Unfortunately I haven't had much time to work on it since the end of November. Note that I don't plan to convert it from KIS to stock, but to have it compatible with both. EDIT: This may depend on the direction KIS takes post-1.11 though. I had a quick look at the KIS thread and it seems it may be transitioning to an enhancement/expansion and UI overhaul of the stock system, so if this happens then presumably switching it to this KIS-stock hybrid would be necessary. This would however probably not be backwards compatible with 1.10 and earlier. MM patches can only change configs AFAIK, not plugins. You can presumably use MM to make a part compatible with the stock inventory (I haven't checked) but for the workshop to use it requires changing the behaviour of the plugin. I suspect that programmatically it shouldn't be that hard (or at least no harder than doing it with KIS), but as linuxgurugamer alluded to having the mod use both systems is itself a problem in terms of UI etc. If only one part could be produced at a time (no queue) you could just have two separate buttons: "add to KIS container" and "add to Stock container". Before 1.11 this wasn't a problem as only the surface science parts could go in the stock inventory and they were barred from being added to KIS inventories. Having standard parts able to be carried makes this more complicated.

This is how they are "supposed" to be. I'm not sure why or what the design philosophy behind it was but I would guess the low mass is to balance out the cost and mass of the resources. When the workshop creates an item it creates it based on an equal mass of resources, so you need a lot of them to make anything but the smallest of items. FWIW when I'm done with my version the resources will work quite differently so this will be less of an issue and the containers will definitely have more mass. I suspect the strange physics is purely down to the low mass. If you want to give them some mass even when empty all you need to do is change the mass value in the configs. They are currently set to 0 (which KSP rounds up to 0.0001). The correct files to change are B9-ose3000.cfg and B9-ose6000.cfg, which are located in Workshop/Parts/OSE_Containers. While they have a .cfg extension they are just plain text files so can be edited in something like Notepad. The values are in tonnes, so to make them, for example, 1.5 t change the value 1.5. Judging by the screenshot you don't have B9 part switch installed, which is required. This isn't listed as required in either the OP of this thread or CKAN for some reason so it makes sense that you wouldn't.

I've not had any issues with it. As long as you have current versions of all the dependencies it should work fine. The only part I'm not sure about is the "unpacking" feature which I have never gotten working (and which seems to be on by default). Be aware that some parts will not show up in the Fuel Tanks category (Mk2 fuel tanks, two of the small foiled tanks, a few of the large tanks etc) and some modded parts may not show up there or in the Engines category (there is an explanation of why below.) These can be found using the search box however, as can the stock robotic and surface science parts. Since I'm here I might as well update you all. I have begun work on my update/fork of the mod and so far have the following sorted out: Most of the UI re-arrangement and formatting changes, including new button graphics etc, are done or close-to done The extra stock categories have been added CCK categories are now supported. Other categories which are added by mods seem to be harder to do automatically so may have to be manually coded for. Search-as-you-type is mostly working, and now searches within the category selected (will be an option to switch between modes) A bug/oversight whereby some parts, including most of the Mk2 fuel tanks, did not show up in the engines/fuel tanks categories has been fixed (they use the old deprecated "Propulsion" category in their configs which the mod did not account for before) Stock variants are now selectable and mostly working I have no idea how long it will be until it is in a releasable state but I'll keep you all posted. By the way @linuxgurugamer, I have a few questions which you may be able to answer. Is there any way to change the control lock type in ClickThruBlocker? My version of this mod uses scroll bars but these are impractical when using the default lock type ("ALLBUTCAMERAS" if memory serves), as scrolling the mouse wheel both moves the scroll bar and the zooms the camera. I have come up with a hacky workaround to set it to "All", and while it does work it does not work all the time. Also is there a way to block interactions with part right-click menus underneath the window? Do you know if there's a way to load the stock PartCategorizer class outside of the editors? When I try to access it in flight there doesn't seem to be an instance, and I cannot create one. I wouldn't be surprised if it requires something else to be present before it will create an instance (e.g. graphics which aren't loaded in the flight scene or data from another class) but I can't find what and the logs aren't helpful. While on the subject of graphics which aren't loaded in the flight scene, do you know how to load assets from the stock asset bundles? I'd ideally like to use the stock category icons rather than those bundled with the mod but I can't seem to get the bundles to load no matter what I try. The path I'm using seems to be valid* but when I use it the load immediately aborts. Unfortunately the logs dpon't specify why it aborts. I have tried loading them synchronously and asynchronously, and treating them as web assets using "file://(/)", all using the built-in Unity functions; if there's a stock method for doing this I haven't found it. *If I use a path to a non-existent file it fails with a different error (something about a header being unreadable which I suppose is because there is no header to read). For the last two, if you cannot answer them do you know of anyone else who might be able to help? (If not I'll probably ask on the add-on dev subforum.) Thanks

I had a feeling that was the case and totally get it. (I can't imagine how much time it would take to actively develop all the mods you maintain.) I suppose I'll have a look into plugin development.

Hello again @linuxgurugamer, I have done a little more thinking about this and had a few more ideas about how I feel the mod should look and work. I've made a mockup of how I propose it should be laid out etc. I have overlaid this onto an in-game screenshot (mostly to show the transparent bits) but this was otherwise made from scratch in Photoshop (so may differ slightly from how it would actually look in-game). I realise that this may be more work than you can justify putting in. However, I have some programming experience so might give it a go myself. I've never dabbled with KSP plugin creation (or C# generally), but I don't see that as a hurdle. (It'll probably just take a bit of time to get used to it.) In fact, I have some other ideas for the broader mod (new workshop types, new models etc), so might make a separate fork. Being new to this though I may find it harder to integrate the other mods (Janitor's Closet, B9 etc) and stock part variants. That said, if you are up for it it is probably better to retain a single mod, and then I could make my new models/types etc as a sub-mod. I would also appreciate other users' input on these proposals. Proposed new/changed features: I've re-arranged the UI to be more like that in the editors (VAB/SPH) and have created stock-like category buttons. The categories are now in a strip down the side of the part list rather than along the top. (The icons used are those distributed with the mod, except the Robotics and Cargo icons which I created myself. The buttons are designed to resemble those in the stock editor interface.) The mockup includes several blank category buttons underneath the stock ones. These would not show up normally, but with CCK compatibility would house custom categories. The up/down buttons at the bottom would only show up if necessary (similar to the next/previous page buttons). The scale of the category/part buttons and search box are approx. 75% of those in the editors. The space between the part buttons has been reduced to 2px (the space in the editors is about 4px; the mod currently uses spaces of about 5-6px despite the smaller buttons). The part buttons themselves are 50px, similar to those currently used by the mod. The category buttons are 24px and are also 2px apart, so they line up with the part buttons exactly. The part previews are at the same relative size to their button as shown in the editors (i.e. they're larger than in the current version of the mod.) The part previews are not lit/shaded (as is the case in the editors but not in the current version of the mod; this may be a limitation of the game) The part list would be sortable by name, mass and size as in the editors. Cost would obviously be rather pointless, but other sorting values such as Material Kits required or production time would be useful instead. Filters such as end profile (e.g. Mk3 or 1.5m) might also be helpful but are not shown on the mockup. This might also be useful for Janitor's Closet integration/functionality. Instead of clicking on a part to add it to the queue as is currently the case, clicking on it now brings up the part's information. It is added to the queue using the "add to queue" button. This allows things like stock variants and B9 switching to be done in the main window. A new quantity value has been added. This allows the player to quickly choose how many of a part they want and add them all at once rather than repeatedly clicking until the desired number is added. This seems like an obvious addition to the "add to queue" functionality. The number is a text box so the player can type in it. The +/- buttons could be replaced with up/down arrows. The part description is designed to be as close as possible to the editors' part "tooltip", with the following differences: The manufacturer is on one line rather than two (to save space). However, since it is being manufactured in situ this may be renamed (something like "designer" or "original manufacturer"). The description box is shorter to make room for the recipe The part name has the mod folder appended in brackets/parentheses (Janitor's Closet integration) (I intended to add the scale indicator to the mockup but forgot) The panel to the right (I don't know what you'd call it; "modules" maybe) is placed further to the right. In between it and the rest of the panel is placed the list of variant/B9 switchers, which use the same UI style as the stock variant switchers in the editor right-click menu (which is also used by newer B9 versions). A series of dropdown lists is a possible alternative (user preference?) The afore-mentioned recipe is placed underneath the part description. This also includes the required volume, listed after resources required. Both the volume and the resources also list the total of what is available. For volume this would have to be limited by the max volume of the largest KIS container, not just the total. The current queue (and the queues of any other workshops on the craft) would also be taken into account for available resources. Currently, the mod does not show any parts which are too large to fit in any of the attached containers. This behaviour would be changed to it being visible but not being able to be added to the queue (possibly a greyed-out "add to queue" button with a tooltip explaining why. The afore mentioned volume listing could also be changed to red if this is the case.) As seen for the RSC thruster block, parts of the same type can be stacked. These stacks could then be split by right-clicking and selecting a stack-size to split off; this would be to enable players to move around items in the queue without cancelling the whole stack. Parts with different values (e.g. different B9 subtypes) would not stack. Items in the queue could be moved around, either by dragging them or by right-clicking and selecting an option to move it up or down in the queue. There is a new production speed mechanic shown at the bottom right. In the mockup this uses buttons; I think a slider would probably be better but couldn't think of a way to do this while also making higher speeds obviously locked/unavailable (possibly something similar to the Breaking Ground robotic parts' range limits would work). 1.0x would be "normal" speed. Slower speeds could be used to reduce energy consumption. (Useful if for example you are using a life support mod and are low on power and so need to build a new solar panel, but running at normal speed would drain the power too quickly.) Faster speeds would have some combination of: Higher energy use overall (e.g. at 1.0x the total cost would be 1200 Ec but at 1.5x the total cost would be 1800 Ec). This would of course be spread out over the course of the production. More expensive in terms of materials (i.e. it's faster but less efficient/more wasteful) Higher level engineers More engineers (the current Workshop only has space for two Kerbals, but that doesn't need to be the case; the K&K Workshop has space for three) More advanced/upgraded Workshops Multiple workshops working together on the same craft. Faster speeds may be unavailable if the craft is in motion on a body's surface, experiencing high g-forces etc. Buttons for settings and the Janitor's Closet have been placed in the bottom right The item progress bar is the same as those used in stock for fuel, electric charge etc. (and so is much smaller) Underneath the progress bar is a listing of the total time required to produce the whole queue. There are four buttons next to the progress bar: Cancel item, Cancel all, Pause item and Pause all. These replace the existing play/pause and trash can buttons. If the pause item button is pressed it will be moved back into the queue with a pause icon (probably in the upper left corner) and a progress bar underneath it. The next item in the queue will then begin to be produced. Items of the same type and configuration would also be paused. All fonts are the same anti-aliased font (regular, bold and black Arial I believe) and the colours correspond with those used in the editors (rather than the less subtle bright green used at the moment). On the backend the basic hard-coded category list would be moved to an config file. Various workshop types could then be defined which use a separate config rather than simply defining it on a per-part basis. These configs could have their own part blacklist. I would also add the ability to define the by exclusion of categories as well as explicit inclusion inclusion (so, for example you could define a type which lists all of the categories except robotic and science parts). This might be complicated by CCK though. Obviously this is not shown on the mockup. I happens to the best of us . To be fair, it isn't exactly made clear that command is required, and it would probably be better if the button didn't just vanish on non-controlled vessels. I think being able to access the workbench but being unable to actually use it would be preferable (probably with an error popup if you try to add to the queue or, if my suggestions above are implemented, a greyed-out "add to queue" button with a tooltip). That said, it does match the behaviour of the Mobile Processing Lab.

For what it's worth it works for me, and I don't think I had to do anything special to get it to work (I don't remember). If the base workshop works then I see no reason why the K&K one wouldn't. My only suggestion would be that maybe a Module Manager patch is messing with it somehow (either one you've written or one from another mod). It's also worth noting that the buttons don't show up if you're time warping.

You may be aware of this already but I couldn't find any mention of it in the thread. There appears to be a subtle typo in the configs for the Hadar Airlock Compartments A and B (parts/PIRS/_hadar_crew_s1_1.cfg and _hadar_crew_s1_2.cfg). The Minimum Crew to Operate is specified using "minimumcrew = 1" rather than "minimumCrew = 1". Apparently this value is case-sensitive, as both parts show up in-game as unmanned rather than requiring a pilot. Capitalising the "c" fixes the issue.

Hi @linuxgurugamer I have come across a few issues (I wouldn't call them bugs exactly) with the mod. Both of the stock categories added in Breaking Ground (Robotics and "Cargo" (i.e. deployable surface science and their containers)) are missing from the Workshop UI. They can be added by manually coding them in the OseModuleWorkshop module in the part definition but that shouldn't really be necessary. Those which are hard coded are also not in the same order as in the VAB/SPH (presumably a holdover from an earlier version of KSP). It might be worth considering moving the default list to an external file rather than hard coding it in the plugin. That way users can more easily change it and the associated icons if desired across all Workshop parts. (For example, in my own (temporary?) patch I used the icons which were bundled with the mod rather than those which are hard coded, as they correspond much better with those in the VAB/SPH; at the moment they don't seem to be used so I'm not sure why they're even there.) The mod doesn't seem to pay attention to hidden techs. Some stock parts such as the probe cores and the Mk1 Command Pod and Lander Can were changed in various patches, but for compatibility with older save games the old versions of the parts were retained but hidden so they could not be built. This was done by adding "TechHidden = True" and "category = none" to the config files; I believe "TechHidden" is used to hide it from the tech tree while "category = none" is a sort of hacky way to make it not show up in the VAB/SPH. (I suspect some mods also do this but I don't know for sure. Certainly I have done this in some custom versions of mods.) However, when using the search function in the workshop they still show up (so, for example, you get two versions of the Stayputnik). Unfortunately it may not be as simple as just hiding anything with "category = none" as some mods use that in conjunction with the Community Category Kit (CCK) or similar to make parts only show up in a non-standard category (I know Infernal Robotics does this using its own custom category plugin and I have done this in my personal mods using CCK). I don't know if there is a good solution to this problem other than adding them to a parts blacklist manually (I assume that's what the OSE_Blacklist in _OSE_Filters.cfg does). I also have a few minor nitpicks with the UI There is a bit of an oddity with the UI: search results do not show up until you click on a category, which is rather odd behaviour. (Presumably clicking on the category forces it to refresh the list.) I think either displaying them upon pressing enter/return or adding a search/go button to display the results would be a better solution. Alternatively you could have it refresh when text is entered/changed. The icons/models for the parts are (in my opinion) a bit too small for their buttons. I have compared some screenshots of the VAB menu and the Workshop menu and it looks like those in the Workshop should be about 25% larger relative to the button to match those in the VAB. Given how small they are it can be quite difficult to distinguish some parts so a slight scale up (if possible) would be welcome. If this is simply due to how KSP handles button generation then it's not a big deal. There are some other even less significant ones but this post is long enough as it is so I won't go into them here. I also have a few feature/compatibility requests. I understand if these are too much work. Would it be possible to add compatibility for mods which add their own categories, such as CCK and Infernal Robotics? I don't know if there's an elegant way to get a list of categories from the game (other than the ones explicitly listed in the part files), but it might be worth manually adding support for some of the more popular ones. Unfortunately, as far as I can tell there's no way to reference them using the existing system to add them via module manager like you can with the stock categories. (Either they aren't counted as categories internally or have non-obvious identifiers.) If it is possible to add compatibility it may also be necessary to change how the buttons are drawn, as currently they simply stretch or compress to fill the window, and if too many more are added they will quickly become overly squashed. (I would suggest adding another line of buttons once the number gets high enough, although something like a scroll bar or "pages" of categories could also work.) Still, the lack of compatibility isn't game-breaking due to the search function, so if it isn't possible (or is too much work) it's not really a problem. Probably the most significant incompatibility is that there doesn't seem to be any way to change the configuration/version of the parts produced (perhaps I'm missing something), so you're stuck using the defaults. For stock parts that generally isn't a big deal, although it does mean you cannot produce any parts with stock alternative skins (which I think were added in Making History), the various longer versions of the stock structural tube, or reversed Breaking Ground propeller/rotor blades. More problematic though is the lack of support for B9 part switch variants and other part-switching mods (Firespitter?), which closes off a lot of modded parts (including the materials containers included in this mod). Presumably these would require explicit support to be added for each type of part switching, and possibly an overhaul of the interface, so I recognise it probably isn't as straightforward as it sounds. As for how to treat it in the UI, my suggestion would be to have a context menu appear when you right click instead of that adding the part to the queue. Once all the values have been set in this menu you'd press an "add to queue" button. This is just a suggestion though and there's probably a better/more elegant way to do it, especially if you're willing to change the UI more significantly. If it can be done fairly easily integration with the Janitor's Closet mod would very useful, but I suspect that would take a lot of work for relatively little gain so may not be worth the effort. P.S. Thank you for maintaining this and so many other mods. This may be my first post here but I have used several of your mods for quite a while and greatly appreciate all your hard work. P.P.S. Sorry for the wall of text. Concision is not one of my strong points.