Search the Community
Showing results for tags 'manager'.
Found 6 results
-
Some suggestions to improve the Parts Manager: - add a key binding (for example tilde '~') to open and close it, also make clicking away from it with the middle button close it. - make right clicking on a part in the staging list open it's Part Manager; make right clicking on a stage number open the Part Manager with filter activated for that stage - add stage and parts categories icons to the left of the list for easy filtering and navigation of the list. So with one click you can view just the parts of the stage you're interested in and filter for the type of part you're looking for. Sort of like this but also with per-stage filtering: - specify the part type and size (S, M, L..) next to the part name (idk what CBL-375 is)
-
I think it would be very useful to implement one key shortcuts (underlined letters) for button-type options in the Parts Manager. Maybe they would be activated / highlighted by pressing Alt (or another key combination). I think it would speed up gameplay.. not having to move the mouse and click everything, constantly going from parts to the PM menu. Most OS and app menus use this system, it's very efficient. This is what I'm talking about: -
I've been working on custom liveries for use with the new Variant construct introduced with 1.4. I'm aware of certain issues regarding the command modules and how they break the flags and so forth. However, assuming those issues get sorted... I have the following Mod Manager script that seems to work quite well for adding my custom livery files as a Variant for each part that I want. ////////// avionicsNoseCone \\\\\\\\\\ @PART[avionicsNoseCone]:HAS[!MODULE[ModulePartVariants]] { MODULE { name = ModulePartVariants primaryColor = #ffffff secondaryColor = #4c4f47 baseDisplayName = White baseThemeName = White } } @PART[avionicsNoseCone] { @MODULE[ModulePartVariants] { VARIANT { name = Stealth displayName = Stealth themeName = Stealth primaryColor = #2c2c2c //dark gray secondaryColor = #000000 //black TEXTURE { mainTextureURL = Livery/Stealth/Skins/Airbrake } } } } This works fine, and if you notice, the first thing it does is adds a ModulePartVariants module to the part, but only if the module does not exist. Then, it adds the new Variant for the custom livery. Couple questions for you all... 1) given that this is the syntax for a single part, and it's rather lengthy... Do you see any way it could be streamlined and maintain functionality? 2) the "name", "displayName", and "themeName" seem a bit redundant... but it seems to work like this? Am I misnaming something here? ...or should they be different for some reason?
-
I would like to know how I should make a MM patch to make some Non RO parts tagged as RO. I tried with this method but It didn't work. The mod (at the moment , I'll do more RO patches in future for other mods) is NEBULA DECALS. Thank you for your help!
-
Hello everyone from ksp here is my second mod (it's not a mod but a plugin!) My plugin will be alien manager. But in the future the mods will be public. thank you for your patience -
I'm thinking of building a web service to help people simplify their mod installs/updates process. Functionality: Mods would be submitted to the system with their name, link to github/curse download links, description of mod, etc. Users would be able to search for and add mods to their basket. When all their mods are added to the basket, they would be able to download a zip file of all the mods properly organized into the gamedata folder. Then just unpack this one zip file and overwrite the 'gamedata' folder to update all their mods. The mods you selected will be saved for the next time you want to upgrade. Groups of mods can be shared by developers, or by popular channels. Imagine watching a video, and then being able to download their exact mods list in a few clicks. Feasibility: The basic software to make this is not overly complicated. I'm just wondering if this sort of thing would be useful, or if someone has already done something similar?
