Jump to content


  • Posts

  • Joined

  • Last visited

Everything posted by Alphathon

  1. 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.
  2. I don't use BDArmory but I've had a quick look at how it works. I'm not sure how to handle their subcategories. I might try to replicate their extra column but that will require some more UI work; otherwise they'll probably just end up in the "main" list like normal categories. (That said, I'll have to do the same sort of thing for the "Advanced Mode" categories (cross-section profile, module, resource etc.) so it may be almost "free" in that respect.) As far as I can tell ammo is just treated as standard resources so it should work without any further intervention (although I may need to add recipes for them). Depending on how they do it I may have to specifically code support for the universal ammo boxes and possibly for any other pre-launch variables in other parts though. All of this will probably have to wait until after the initial release though. I'll probably add a temporary config-based category equivalent to the "all" subcategory in the meantime as that should be fairly trivial.
  3. I don't think it's the perspective – it looks like some parts of the model are overlapping others in a seemingly impossible manner. (Seems to be a characteristic of IVA modelling.)
  4. Whatever I end up naming it I intend to retain the "OSE Workshop" part in some form, if only out of respect to the original author. OSE does stand for ObiVanDamme Space Engineering after all. It also provides continuity with the previous versions of the mod. As such it will probably take the form OSE Workshop <something> (as with the previous continuations OSE Workshop Continued and OSE Workshop Reworked) or similar, although I haven't ruled out other formats (such as <Something>: an OSE Workshop mod/continuation). (Also, wouldn't "Bill's Workbench" be more appropriate? )
  5. @JUSTFoox I do not have a planned release date, so just "when it's done" I'm afraid.
  6. Oh absolutely. Rest assured there's no need to worry about me though. I'm far from overworked or anything; it's more of a time-management issue. (Most things in the mod need to be worked on several hours at a time since you really need to think them through to understand what's going on. The UI scaling is an exception as it is basically just finding all the values which need to be scaled and adding a multiplier.) Still, the concern and understanding are much appreciated .
  7. Hi all. Sorry for my longer-than-usual absence. Work is still keeping me quite busy so haven't had much time to devote to development. I have however got UI scaling working across both the Workshop and the Recycler, although it needs some refinement here and there. (Scaling a pixel-based layout by a non-round number results in numerous slight misalignments and such which need to be sorted.) Thankfully 1.12 doesn't seem to have caused any issues with the mod so at least I haven't had anything to deal with on that front.
  8. Thanks! I've just tested it with the UI scaling and it would seem KSP doesn't apply it automatically . Looks like I've got something to add to the to-do list. I don't know whether I'll do it before the initial release or not but it will come. On a more general note I haven't much progress to share. (I've been busy with work so haven't had a great deal of spare time.) I have done some work on the recycler though: the UI now resembles the Workshop's, inventory items are separated by container (rather than all just appearing in one long list) and the recycler lists items in stock inventories as well as KIS ones (although it cannot yet recycle them). I've also been playing around with sound effects when buttons are pressed etc although I'm not sure if they'll remain in the final version.
  9. Thanks! At the moment it's fixed, but I do plan to have at least some degree of resizability and I have coded it with that in mind. How exactly it will be implemented I don't know though. One thing I do plan to do though is to have a "large" mode: currently the parts list, category buttons etc are scaled to 75% of those in the editors (VAB/SPH) but in "large" mode they'd be 100%. From a coding POV that's fairly trivial to do, I just need to actually do it. I have also toyed with the idea of a minimal UI which only shows the queue and print progress without the part list etc. I haven't ruled out completely dynamic scaling (i.e. to any arbitrary size) but I haven't any specific plans for it either. The part preview is already the same scale as the editors' so that probably wouldn't change (although it could easily become taller without changing anything else). The progress bars etc are all at the same scale as the stock UI too. The queue can fairly easily be changed as long as it remains a multiple of the part icons. I would also assume it would respect the stock UI scale setting, as I think that applies automatically to all UI elements. (I haven't tested this though so I may be wrong.)
  10. Mine has attachRules = 1,1,1,0,0 which should be all it needs. The second number corresponds to SrfAttach, so if it is 1 it should work fine.
  11. Yeah, pressing R should cycle through all the available attachment points/modes, so it should go bottomNode → dockingNode → srfAttach (i.e. surface attach) → bottomNode (again). On some parts there may be many more attachment nodes to cycle through.
  12. KIS/KAS allows parts to be either attached by a particular node or surface (depending on the part). That part can either be surface-attached or node-attached. Unlike in the editor though you have to tell it which mode you want it in. Notice how in the screenshot it says Attach (bottomNode)? That means it is trying to attach its bottom node to a node on the craft. Hit R until it gets to surface and I think you should be good.
  13. This past week or so I've been mainly working on the queue system, and have made some fairly significant changes to it: Parts can now be added to the queue in stacks. Individual parts (or stacks of parts) can be paused. For items in the queue this means they will be ignored and not manufactured until unpaused. Parts which have already been started (i.e. are partially constructed) are moved back into the queue and display a small progress bar indicating their progress. Queue items can be dragged around to re-order the queue. Parts in the queue now have a radial menu which shows up when you right-click them. This has a short expansion animation similar to stock manoeuvre (maneuver) nodes. Currently this only has cancel and pause/resume buttons but will later allow things like stack size management. I have re-designed the bottom part of the interface and added individual progress bars for each resource. The part icon is now surrounded by six buttons, three of which are currently implemented: pause, cancel and switch target inventory type. Here are some screenshots showing how it currently looks. You can also see the cancel and resource transfer dialogue boxes, resource sliders, the updated recipe window (with dividers and warning icons) and some other minor UI tweaks. The radial menu for the queued items can be seen in the black box overlaid on the first screenshot, which was only added because you cannot both right-click and item and drag one at the same time.
  14. If you don't want that restriction in your game it looks like you can change the volume limit in the part config. For what it's worth I'm working on OSE Workshop and will probably be implementing some kind of similar volume restriction down the line too. It just doesn't make sense not to unless you head-canon it that the container expands the printer part.
  15. Thanks. I do try to be thorough but I'm certainly not infallible so if you do have any suggestions please feel free to make them. Different perspectives are always welcome. If you do make a redundant suggestion all that will happen is you will find out more about (my plans for) the mod, so it's no big deal. All I'd say is most of my short-to-medium term plans are in the OP so if you're not sure give it a quick read.
  16. Update time. I've done a fair amount of work on this since my last post, although most of it has been general structural and minor UI stuff rather than anything worth talking about specifically. Some of it is though: Standard categories added by USI tools (Rovers, Manufacturing, Logistics, Construction, Kolonization and LifeSupport) are now added automatically to the Workshop UI. As I understand it current USI mod versions use CCK but this is included for anyone using legacy versions. I wrote a Localiser method (which acts as a wrapper for the stock Localization.Format() method) which allows the player to use British English spellings/terminology if they wish. This is done via an option in the settings menu. Examples include motorised instead of motorized, anticlockwise instead of counterclockwise, cancelling instead of canceling etc. This applies to all Workshop UI elements (i.e. anything directly controlled by the mod) but does not apply to things like part descriptions and doesn't effect any other part of KSP's interface (so motors still say counterclockwise in the editors for example). 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. Although not implemented at the moment this could also be extended to allow for other regional language variants (e.g. Swiss German or European/Brazilian Portuguese). Cancelling a part which has already been started now pauses production and brings up a dialogue box letting the player know how many resources have already been used etc. This replaces the existing system which simply displayed an on-screen message telling the player to hit the button again to confirm. I have added the ability to modify the amount of resources added to a part. This is done through stock-like sliders, much like the variables for motorised parts. "Static" resources such as ablator and solid fuel, which can normally only be changed in the editors, are added as part of the manufacturing process. (This is how they already worked but the player couldn't choose how much to add – they always included 100% of their capacity.) For transferable resources such as liquid fuel or electric charge this is done at the end of the manufacturing process and is displayed in a dialogue box. If a resource is unavailable the transfer will obviously stall, but the player can cancel any or all of the planned transfers (either because they've stalled or because they changed their mind). A full tank/battery/container transfer takes exactly 20 seconds, just like when transferring resources between parts in-game. In future I plan to allow the player to change the amount to be added after they have added the part to the queue (both during the manufacturing process and the resource transfer phase) but this is not yet implemented. Some resources are blacklisted and cannot be added (some from stock, others from the Community Resource Pack): intake air, intake liquid, intake atmosphere, solar wind, and thermal power. EVA Propellant is always set to full as it is always refilled when a Kerbal enters a pod. Duct tape is currently also blacklisted but will at some point get a recipe and work like ablator etc. I have been working on a "pass-through" system for keyboard shortcuts. At the moment it only works for time warp. In an ideal world I'd like it to work for all or most (in-flight) shortcuts, but I've been having some issues getting pausing working. As far as I can tell each shortcut has to essentially be re-implemented by the workshop in order to work (I haven't found a way to truly let them just pass through to the main game without also sacrificing camera and mouse lock). Once this is set up I intend to add shortcuts of my own for Workshop functions. These will be selectable in the options menu. Warning icons now appear in the recipe box next to resources etc which are currently unavailable. These icons are the same ones used in the editor Engineer's Report (e.g. for ElectricCharge required but not generated). The recipe is also separated into sections (resources required, resources to be transferred, volume required and build time, although they aren't labelled as such) using horizontal lines as dividers.
  17. Screenshots! This is how the interface currently looks. Most of the elements shown here are as they will be once finished, but some changes are inevitable. Some almost guaranteed changes are that I intend to round off the top corners of the window (Edit: this is now done), and that the pause and cancel buttons will be changed at some point. The grey piece at the bottom left is also a placeholder and will probably change. Most of it should be pretty self-explanatory. The parts shown in red in the items list are those which are too large for to fit in any of the available containers, or are blocked from being put in containers for some other reason. None of the screenshots show any parts with B9 subtypes but they show up in exactly the same way as stock variants. If a part's mass varies based on its variant, B9 subtype or motor mass (or any other as-yet unimplemented variables) the mass in the description is highlighted in yellow/gold and has an asterisk after it, and has a tooltip explaining it. (Note that the in-game cursor does not show up on screenshots. The tooltip appears at approximately the same place as stock ones do.) Here you can see most of the variables available for robotic parts, as well as the numeric input for the hinge's Angle Limit. Also, the text in brackets/parentheses after the part name shows that this is a part added in the Breaking Ground expansion. For modded parts, this will show the mod folder's name (except for a few hard-coded exceptions; e.g. Infernal Robotics parts display as Infernal Robotics, not MagicSmokeIndustries.) This is how the mouseover widget for queued parts currently looks. This part is very much a WIP. Here is an example of switching between stock and KIS containers. As you can see, in stock mode several of the parts turn red. This is because they either lack a cargo part module, have a cargo part module but are blocked from being put in a container (examples of this are the stock containers themselves, which can be manipulated on EVA, but cannot be put in another container), or are too large for any of the available containers. Here is an example of search-as-you-type working. Finally, here is the current state of the PAW. Notice that there is now a progress bar at the top, and a pause/resume button underneath the close workbench button
  18. Hi all. Here's what I've been up to in the last two weeks. I implemented stock-like sliders and used them to implement variable Motor Size and Output(%) and Extension/Angle Limit for robotic parts. I also added stock-PAW-like toggles for Motorized, Allow Full Rotation for servos, Ratcheted for rotors, and Attach nodes for parts with a Dynamic Nodes module (such as the rotors). It should be fairly trivial to use these for the other variables (e.g. resources such as solid fuel for SRBs, ablator for heat shields). I have also implemented a text input mode (like the # button on stock PAWs) for the Extension/Angle Limit. This will be generalised and added to the other sliders later. 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.) The workshop UI is now not drawn when the KSP UI is hidden (triggered by the F2 button by default). (I think) I have fixed the scrolling issue (or at least worked around it in a more robust manner). I did most of the remaining UI work Behind the scenes I built a new class for the queued items which uses ProtoPartSnapshots rather than the AvailableParts used before. This doesn't have much impact on the user but does mean a lot of hacky workarounds involving variables (variants/B9 subtypes, motor mass etc, basically anything that differentiates a part from its "base" version) can be avoided, and will allow me to implement things like item stacks and pausing of in-progress parts down the line. It has also allowed me to build a specific hover widget for the queued parts (similar to the part preview in the editor) which displays things like the selected variants, recipe, whether it is destined for a stock or KIS inventory, build time etc. It should also be useful for the recycler when I get to it. I have also just taken some screenshots of various features which I will post soon. (I need to properly crop them etc and get them uploaded somewhere.) Any part with a cargo module can be manufactured and placed in a stock container. The way the stock system works means that if it doesn't have a cargo module it cannot be added. At the moment this means any of the large or crewed stock parts and any modded parts which don't have one cannot be manufactured using a stock inventory. They can however still be put in a KIS inventory (as long as you have one big enough – some parts, such as the Rhino and Twin-Boar engines, are too large for the containers included with KIS but I'm pretty sure other mods add larger containers). Also, if you get another mod which adds a cargo module to them (like the one Hohmannson mentioned) they'll go into a stock container just fine. I plan to add the ability to add cargo modules to parts at some point down the line, but haven't done so yet (see the Planned features/ideas (for future releases) section of the OP). Thanks! Sort-of, in the sense that you can manufacture parts in the field. Any vessels would need to be built "manually" (piece-by-piece) using KAS or the new in-flight construction mode added in 1.11. In that sense it is no different than the previous iterations. The calculator needs to be identical to the KIS one as it is being used to test if there's enough space in KIS containers. If it's different that may introduce problems where the workshop and KIS calculate different volumes. If I were only using the stock inventory system it wouldn't be an issue as the volumes it uses are explicitly encoded in the cargo module. As I said though I suspect it's the implementation of it in the mod that's the issue rather than being an intrinsic part of KIS, and even if I can't fix it it isn't really a big issue unless you're using a lot of part mods.
  19. It is its own part, as are the recycler, ore processor etc. The mod is based on an existing mod – OSE Workshop Reworked – which is linked at the top of the thread (or click here), so you can take a look there if you want to see the part. The model for it will be changed at some point down the line but for now the part shown there is what will be included. At the moment the part holds 2 Kerbals and requires 2 Kerbals to operate. Engineers with the repair skill boost the speed by 1% per level (so level 3 Kerbal = 3%). The Kerbal's stupidity also acts as a negative multiplier to the speed if that option is enabled. Again, this is all carried over from OSE Workshop Reworked and may be changed later.
  20. New part models are on the planned features/ideas list (near the bottom). As for different workshop sizes/profiles it is certainly something I am considering but have no concrete plans as yet. I would say it's likely but not certain.
  21. 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.
  22. 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 B9 part switch. Like with stock part variants, parts which use B9 to offer multiple part variants can now be used through the workshop. 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.
  23. 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.
  24. 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.
  25. 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?)
  • Create New...