Jump to content

Alphathon

Members
  • Posts

    60
  • Joined

  • Last visited

Everything posted by Alphathon

  1. 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.
  2. 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.
  3. 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
  4. 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).
  5. You can set the compression type in the dropdown to the left of the save button in the dds exporter.
  6. 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.
  7. 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.
  8. 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.))
  9. 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.)
  10. 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.)
  11. 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).
  12. 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.
  13. 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.
  14. 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.
  15. 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.
  16. 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.
  17. 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).
  18. 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.
  19. 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.
  20. Hi all. Here's what I've been up to over the past few weeks: I have implemented custom categories (the pale brown ones you can add in the editors by clicking the +). I have added custom subcategories to the subassemblies list. I have added a separate craft file loader which is accessed using the button directly underneath the subassemblies button (see screenshots). The list can be filtered by VAB, SPH or both. (The graphics for these toggles are non-final.) At the moment it lists all stock/expansion craft and those in the current active save. In future I plan to add subcategory buttons for other saves and subfolders. Stock craft and the auto-saved ships have [Stock]/[Auto-Saved Ship] appended to their name as they do in the editors' load craft window. Where present, a rendering of the craft is shown in place of the subassembly icon. If a craft or subassembly contains unprintable parts (that is parts which are blacklisted from the workshop for technical reasons or which have not yet been unlocked) a warning icon is now displayed in the corner of the button, much like with parts which won't fit in a container or which are too resource-expensive. I have done a fair amount of work on the craft/subassembly loader which you can see in the screenshots. The icons under the part names currently show the selected inventory type (which can be toggled on a per-part basis) and the part's variant if it has one. In future this will also include B9 subtypes, module variables (motor mass etc), resources etc. Unwanted parts will in future also be disableable, probably via a toggle to the left of the part icon, but this is not yet implemented. Any parts which are added using symmetry are added as a stack (e.g. the batteries in the screenshot below). I have added support for cross-section profile names/icons added by taniwha's Custom Bulkhead Profiles to the Filter by Cross-Section Profile supercategory. I have added variant and B9 subtype icons to the "queued item"* tooltip/hover window and made its box blue (so it matches those in the editors). I have been playing around with the "new" Unity UI system (that is uGUI/Unity UI rather than the older IMGUI system) with some success. Using that system has a number of advantages: it is much easier to do UI scaling and I can use the same font the game uses (Noto Sans rather than Arial). It is supposedly also much better performance-wise as it doesn't redraw/recalculate everything in OnGUI() (which can run several times per frame) but without actually converting the whole UI over I don't know how big of an impact it will actually have. It is however a little trickier to build the UI in code (although not as difficult as some posts I've seen would lead you to believe). At the moment my plan is to convert over the App Launcher app and maybe the tooltip renderer and "queued item"* tooltip/hover window to uGUI as they should be relatively straightforward. The workshop and recycler UIs will probably take longer though (a lot of the logic would have to be changed) so will probably be in a later release. I have also added a few (mostly) workshop-related "hints" to the main loading screen. *"Queued item" here refers to a specific type of object (a class in coding terms) which is used by the queues of both the workshop and the recycler, but also by the craft/subassembly loader. Here are some screenshots: These are some craft/subassebly tooltips: This is the "queued item" tooltip/hover window at the moment:
  21. Here are some screenshots of the different "supercategories"/"advanced mode" categories, as well as the current state of the sub-assembly loader:
  22. Well, it's been quite a productive week! I have added the standard "supercategories" to the workshop: Filter by Cross-Section Profile, Module, Resource, Manufacturer and Tech Level. Like in the editors the different "supercategories" are accessed using buttons to the left of the main list and each has its own specific button colour. There is still some UI work to do to them but they are all fully functional. I haven't decided yet whether to have them expandable/hideable like in the editors as I don't really see the need to do so. (It's barely useful in the editors and TBH I don't know why they aren't just always visible.) I have developed most of a rudimentary .craft file loader, which is capable of loading an entire .craft file's part list into the queue. Since they use the same file format this also doubles as a subassembly loader. I haven't yet built a browser/interface so at the moment it isn't very functional but it mostly works when tested with hard-coded file paths. It also doesn't do any checks to see if parts are inventory compatible etc yet. I have made a fairly basic but functional app for the App Launcher (sidebar), which lists all craft with either a workshop or recycler (anywhere in the game world), displays their current location and allows the player to switch between them. If a craft is within load range of the current craft (≈ 2-3km radius I think) it also displays the current status (progress, current part etc, basically the same info as shown in the PAW) allows manufacturing/recycling to be paused/resumed and allows the player to open the workshop/recycler menu for any of the appropriate parts. When a part's name is moused-over in the app its model is highlighted. The app's button is positioned alongside the stock apps and behaves in a similar manner, rather than opening a window like most other mods' apps. (The only other mod I know of which does something similar is Kerbalism.) The UI and functionality of the app are still WIP. I have also made some small alterations to the code for the part list which improves performance greatly when dealing with large categories.
  23. Finally got the screenshots done. Here's the main recycler menu in its current state. As you can see each inventory is listed separately and can be collapsed/expanded at will using the arrow/triangle on the right. There are icons next to the inventory names indicating whether they are stock or KIS. Kerbals' inventories display the part the Kerbal is in in small brackets/parentheses after the name. (If a KIS inventory has been named it does something similar, although there are no named inventories in the screenshot.) In future I may add a way to show/hide all the Kerbal inventories at once (so that you don't have to scroll through loads of parachutes and jet packs on larger vessels). I may also add a collapse/expand all button. Stacks are displayed in the same manner as their respective inventory system (i.e. white ×N in the bottom right for KIS; gold N in the top right with a green bar on the far right for stock; where N is the stack size). The stack size is also listed at the top of the part details (above Mass). To the right of the part info is a list of the resources that will be recovered if the part is recycled, along with the time it will take and its (packed) volume. As you can see this vessel has no free space to deposit Material Kits. The Add paused toggle in the bottom right is functional (if it is "on" any part added to the recycler queue will be paused automatically) but is graphically unfinished (i.e. it won't look like that when I'm done, although I haven't decided yet how exactly it will look). The add to queue button is currently off-centre; this will be fixed before release. The width of the window may also change. Since I have added Waste Material as a resource I have also updated the Material Extractor to process and store it. I have also updated the labels for the converters/buttons to make it clearer what each one does. (The Hitpoints and Armor Thickness are added by BDArmory and have nothing to do with this mod.) EDIT: Here are some more. This is how the right-click menu for the Recycler queue currently looks. The icon for the "return to container" button changes depending on whether the part came from a KIS or stock container. I have also been playing around with how the Workshop shows "insufficient space". I have added an icon in the bottom right which shows the details when hovered over. When there is a large enough container available but which currently hasn't enough free space an orange warning is shown in both the recipe and the icon. A red critical warning is shown if there is no container with a max. capacity large enough to hold it even when empty. (I also notice that currently the Licenced from text is able to extend beyond the container box. This is not supposed to happen – it is supposed to shrink the text if it is too long – so I will be looking into that.)
  24. I'm afraid not. I am planning to post some screenshots of the recycler soon though. (In fact I had planned to do so before now but I just haven't had the time. Thankfully it isn't work getting in the way atm, just real life in general.) TBH I hadn't realised it had been quite so long since my last post. (Time seems to have lost all meaning at the moment.)
  25. Good news everyone! Over the last few weeks I've had some more time to work on the mod and have made some good progress, especially on the recycler: All parts, from both KIS and stock containers, can now be recycled. Parts are now recycled based on their actual state – formerly they were recycled based on the AvailablePart (for non-modders this is basically the base/source/default version of the part used by all instances of the part), so they would use whatever state that happened to be in at the time, rather than taking into account things like variants or motor mass. The recycler's queue now functions like the workshop's (with dragging, stacking, right-click menu etc). If a part contains resources they are now drained before it is recycled. If they cannot be drained (e.g. there isn't enough space on the vessel to store them) they can be dumped. Otherwise, recycling of the part stalls (the part is paused) until capacity becomes available or they are dumped. At the moment, "dumping" basically just erases the resources from existence, but in future I plan to make this function like a drain valve, i.e. it exerts a force on the part when ejected. Similarly, if a part is finished recycling and there isn't enough space for the resources the player must either dump them or have the recycler wait for space to become available. If a part is in the queue but hasn't yet begun recycling (including if it is stalled due to having (an) undrained resource(s)) it can now be returned to an inventory via an option in the right-click menu. Where possible this will be the inventory it originated from, but if it is full or unavailable it will use other inventories instead. It currently will not try to add it to containers of the other type (i.e. parts from a KIS inventory will not be "returned" to a stock one and vice versa) but I may implement this as a(n optional) fallback in future. As a side note this does not work for Kerbals' inventories. As far as I can tell there is no unique identifier for inventories themselves (or at least one that persists after quitting the game) so I have to use the host-part's PersistentID. Kerbals also do not seem to have a unique identifier, and since they can move from part-to-part and there can be more than one Kerbal per part the part's ID is not a good proxy. That said, all this means is that the part doesn't know where it came from – it can still be restored to a non-specific inventory – so it is hardly game-breaking. Items can be added to the recycler queue paused. This is not the same as the 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. I also plan to add this functionality to the workshop but haven't done so yet. Mass which is not converted to useful resources is now converted to a new Waste Material resource. This prevents mass from just magically disappearing. This acts just like other resources in that it must be transferred out or dumped. Currently this resource has no uses or containers but I intend to develop this further in future. (Possible uses: burn it to produce EC; reprocess it to extract additional useful materials). I may also add other by-products such as CO₂ (which could be vented or used in a greenhouse etc), although I won't go much further that that until I get to the resource overhaul mentioned at the bottom of the OP. Similarly, when a part is cancelled any as-yet unconverted material is also converted to Waste Material. If a part is being produced in the workshop and is cancelled it will now be transferred into a recycler if one is available. Otherwise it now also yields Waste Material equal to the mass of resources already processed. I may in future also implement a similar system in reverse (i.e. allow a partially recycled part to be returned to a workshop to be re-built) but I haven't done this yet. Oh, and I have also added the catch-all BDArmory category.
×
×
  • Create New...