Shaggygoblin

+1

Just updated my PD version (downloaded full client) yesterday, Feb 15, 2024. QWERTY user here, with a clean install on Windows 11. I cannot rebind 'E'. every bind I try to use 'E' winds up entering 'D'. Also mentioned here:

My keyboard is fine, and I'd rather rebind the yaw/roll than use a yaw/roll swap mod. Alas, when it prompts for keypresses, it takes 'E' as a 'D'. It accepts 'D' as 'D'. Pressing 'Q' and 'E' for yaw left/right gets me " Q D " in the field. Pressing 'A' and 'D' for roll left/right gets me " A D " in the field. Incidentally, I can not manually unset by pressing the appropriate default keys, as 'E' always enters as 'D'. I get that it's a nifty thing to bind two keys in one entry here, instead of a bind for left and a separate bind for right; sometimes it's easier, and more importantly, less prone to breakage, to have the latter. I love where KSP2 is headed, but do not forget: KISS PS: Consider where there's a slider with a numerical denotation for it, allow the user to enter a number, for precision's sake. A slider that defaults to '1' but goes down to 0.5 and up to 2.5 I should either be able to set back to 1 without pixel-hunting the slider, ultimately ending up with 1.0036497. Let me just type '1' in the numerical field next to the slider.

@linuxgurugamer just a heads-up; UnBlur is not listed in OP as dependency. Is this a specific thing intuited from @Eleven's log and applicable to his situation only, or is it a new dependency? For posterity: UnBlur is not a dependency. Good description of 'What, Why, & When' is on UnBlur Thread.

This and sounding rockets were, to me, the perfect early game that just made sense... add in KAX, FS, or another 'early planes' mod and boom: very lightweight realistic early progression, starting with conceptual crafts using the SR's & 'make believe' with the BR's... Saw one of my nieces sitting in a refrigerator box pretending it was a plane... cheesy as it is, "KAD" (Kardboard Assisted Drafting) is essential, imho. Now to to convince someone to take inspiration (textures) from BR and apply it to a plane parts pack, keeping the spirit of BR in the process... Plywood is working now... needed .dds'ing. DDS4KSP 'still' serves it's purpose.

All of this mod 'should' be in the first node of the tree: start with imagination, move to realization... Cardboard and lay-about material for inspiration/imagination before the 'real deal'... think about younguns playin' make believe in the back yard... the name fits that perfectly, so does the start node, or at most the first 3 nodes... a side note: A fire extinguisher strapped to the bottom of a BBQ... but no appropriate fuel tank... try filling the Fire extinguisher with, i don't know... CO2 maybe (think "ant engine" with a pool of mono in it's base) otherwise we are using the stop sign tank at the bottom and the BBQ legs clip through it... alternately, clone the 'can of mono-prop' into a second small tank for LF+Ox for the Fire Extinguisher engine... or just add a pool of LF+OX to the Fire Extinguisher... the mono fits the spirit of it better i think. For your consideration: Xenon BBQ anyone? can we get a small model of a propane tank to go under the: "The new BBQ-3.7 Deluxe(patent on appeal)!! Now with a built-in Meat Slicer(patent pending) and a Xenon fueled IR/UV(?) Cooking Element(patent also pending)!! ...Err, I mean Reaction Wheels and an Ion Propulsion upgrade option!!! (The BBQ-3 Has no user serviceable... scratch that... The BBQ-3 has no serviceable parts at all... Not responsible for lacerations or dismemberment due to attempted servicing.)" ...lol, perhaps this propane tank could be a xenon tank connected to a xenon/electricity fueled hotplate, maybe add a few R/C Toy Li-Po Batteries for the high Electric demand of the ion hot-plate... I'll see if i can hand-jam a tweak to the FE Engine to add some fuel options... possibly the mono-prop tank as well... not a modeller, as plastic models don't count in this regard...lol. maybe just add a resource node to it and let fuelSwitch or another similar handle the contents via the r-click in the editor, but that would add a dependency... Please, open the Large and Small 'plywood*.jpg' for the fin texture in Paint or any photo editing program that can save as .dds or .png. The .jpg doesn't do it on my install. It just shows the normal basic fin texture (grey/yellow trim). I haven't tried it that way, will test shortly. Attaching some tweaks for you to use if you'd like. Nvm, Forking & tweaking there... PR shortly Github PR @linuxgurugamer

I agree, system power, in the general term, weighs heavily... That said, i'm running 60+fps in Star Citizen at medium settings. I have no SSD's but my PC reads Kerbal from a RAID (1+0 or 0+1, don't recall which... relevant: decreased access/read time, slightly increased write time, iirc) Win 10 x64 (Pro (as if it matters anymore...)) KSP x32 not installed on OS disk, internal RAID 8GB DDR4 AMD 1090T CPU AMD7700 series dual GPU on single monitor @1080p (can go from 24 to 240Hz (Sony PS3 3D Monitor))

so... last 'complaint' was, by my local time, 7 days ago... and a solution in the same rendering it not a fault of the 'mod/plugin'... I call that a success and worthy of a .version to 1.0.5. Gratz again, Sarbian!

sorry for taking so long to get back to you. I had updated my post after you quoted it, asking for "logs without DTL installed"... my edit to the post included several logs of various install scenarios with/without DTL and such. I link to it here for easy navigation: http://forum.kerbalspaceprogram.com/index.php?/topic/128660-1051-41-dec-31-2015-dynamic-texture-loader/&do=findComment&comment=2344492 Going to try the current version now. I do note you say DTL is now possibly incompatible with ATM. Should we run one or the other, but not both until further notice, or is this 'incompatibility' being addressed? Also, I am not clear on if DTL will help while using -force-d3d11 or -force-opengl will achieve significant results? Is it your stance that it will not be a significantly noticeable amount of benefit using either of those options combined with DTL? Are you looking to take this further, if Unity allows it, and apply this to DynamicLoad the video ram as well as the system ram? I have no idea if that is even possible, just thought i'd ask. Cheers to you for your good works shaggy

I too am getting this exact error after the recent update to DTL. i 'think' this is when it should start calling/loading the start screen after the loading progress bar, but it just can't find/load it. Does DTL do anything with any of the Non-Part textures and such i.e.: UI Screens/Windows/Scenes (is the Start Screen a scene?)? I don't know what those appear as in the log. Going to remove DTL and try to get it to the Start Screen and upload the output_log.txt for a comparison...might help, might not...lol. my output_log.txt's: Output Logs < {this is a Folder of 4 output logs, renamed according to launch options. I want you to have all of them, as too often i see ModDevs saying that they need 'more' or 'all' when peeps post snippets of the log.} One of them was an out-of-memory crash. Using the -force-d3d11 and -force-opengl will get me to the start screen with 2.3-2.7 GB SysMem usage and between 300-500 MB VidMem usage, according to @Sarbian 's GCMonitor Also of note: my shortcuts are not normal: I launch all 3 with 'High' priority, same as setting it manually in Task Manager. C:\Windows\System32\cmd.exe /c start "KSP No Switch" /High "D:\Kerbal Space Program 1.0.5\KSP.exe" C:\Windows\System32\cmd.exe /c start "KSP DX11" /High "D:\Kerbal Space Program 1.0.5\KSP.exe" -force-d3d11 C:\Windows\System32\cmd.exe /c start "KSP OpenGL" /High "D:\Kerbal Space Program 1.0.5\KSP.exe" -force-opengl (i don't use the -no-singlethreaded or -popupwindow, no-st: because on very rare occasion (once after 3+ months on one save) it has corrupted a large save. -popup: because i get less resource usage when not rendering the desktop behind a borderless window. (yes, debatable, but what i see happening in PerfMon, ProcMon, and TaskMan tells me fullscreen is better than windowed as far as utilization and responsiveness goes...)) Happy New Yaer!!! (no, not been imbibing...well if you count coffee, i have...lol) @SQUAD @MODERATORS : BRING BACK THE PREVIEW BUTTON WHEN POSTING!! /endCaps

Thanks for the info! As FAR as color, you can never go wrong with salmon or coral! JK, definitely some checkerboard/tracking pattern, one of b&w or b&y would work. I'm more interested in the function, in the end. But aesthetically, as a vet myself, I would prob fly a historically-plausible camo/color pattern, if given the option (TexSwitch, or other means...) I would not fly anything painted neon green, however. At first read, this page appears to be a decent source of war-time colors/patterns, if you choose to go that route. As well there's this one dedicated to post-war colors/patterns. I like the B&Y or 3/4-color as you don't see them often. Again, thanks for the point to Taerobee and hope to see this one flourish as well!!! Edit: The pattern on these "Rockets" would look neat as well, especially when launching prior to unlocking controls. cant the fins a half degree for a little spin to stabilize the ascent and that pattern could appear as an oscilloscope!!

Maybe you guys can help me out here. A while back, sometime between .90 and 1.0.4 I was using a mod for a short while that had an A-4 or V-2 with a B&W Checked Paint to it, there were 3(?) parts: the Tail (Engine/Fins), tank, and the cone. Might have been 4... I can't recall what it was... I thought it was from Tantares or another Launcher Parts Pack or History Pack, obviously it was, but it eludes me which one.. I checked Taerobee... not the same one going by the pictures, but could have been an older version before it was split from Tantares into the separate Taerobee mod... Any ideas appreciated. Looking forward to your finished product as well! Looks amazing!

i couldn't sleep, this was keeping me awake...lol i had: ... ,@RESOURCE[ElectricCharge]:HAS[#maxAmount[<200]] // missing 3rd closing bracket. I was adding <=200, =<200, <200, [~#maxAmount, [!#maxAmount... doing circles because of a bracket...lol I need an Auto-Closer for Brackets & Braces in NP++ Nori, YOU are a PEACH! Now, if we can get the Author to incorporate this... We might ought to get a couple/few/several more peeps to verify this works as well, but two for two is a good start! Ty, again, Nori!! Time to SLEEEEP!! :BEFORE[sETIctt]

To whom it may concern, I use LOTS of probes. I have many custom ones. Many I got through various Mods, including MM Patches from this mod. I love your mod. However... There's an issue in SETIctt-Settings.cfg. Specifically: //---Add electric charge---\\ @PART [*]:HAS[@MODULE[ModuleCommand]:HAS[#minimumCrew[0]]]:FOR[SETIctt] { @RESOURCE[ElectricCharge] { @amount = 200 @maxAmount = 200 } }//---Probe Cores---\\ As it stands, that entry overwrites everything, which is probably fine for most... I have spent several hours trying to sort out where my maxEC kept loafing off to... and here I found it... I have spent more time trying to make sense of MM to try and present 'something' as a means to try and sort this, instead of the usual "why you broke my game fix it, wut are logs?." I pose this attempt at a solution, to keep the functionality, but be more forgiving on those of us who, for whatever reason, have 'Stored EC' values already on the cores we use: Add Electric Charge IF less than 200'] [*]:HAS[@MODULE[ModuleCommand]:HAS[#minimumCrew[0]],@RESOURCE[ElectricCharge]:HAS[#maxAmount[<200]]]:FOR[SETIctt] { @RESOURCE[ElectricCharge] { @amount = 200 @maxAmount = 200 } }@PART It's several hours past my bedtime now, so, I will test this on my install in the morn. This may not work at all... MM Nub here. Anyway, cheers and keep the SETI going! EDIT: It may require the use of [!Resource... or something like [!#maxAmount[>200]]... it confuses the heck out of me, especially this late at night...lol. I hope we can sort this as it shouldn't need to come down to having anyone with existing 'Stored EC' on their probes having to make zManyMods:FINAL Patches:FINAL to patch SETI Patches:FOR[sETIctt]. Surely, that can be avoided with just adding a further filter in the @PART search.:FINAL:!important See... just being silly now... I need sleep, good night all!!

Given the amount of time it takes to 'incubate' the Data into Science in the Lab, you are correct; however it's not 'the hard way' at all, more like 'the long way.' I still prefer driving over dying to my pathetic flying ability... So, while yes, it takes a LONG time to open the tree this way, with enough 'different' experiments, I can unlock the tree, in time, and not leave the ground... I leave the role-play to my daughter and her friends... (Still tweaks my nerves that she landed on Minmus first try and I collided into the moon on my attempt... yes, minmus was behind it, perfectly aligned...for her...) Edit: upon rereading this, I feel I should clarify that the 'role-play' comment I made was in pure levity, i see how some may take it as an attack...it is not. Kerba-Cola's on me!!!

Better Science Labs Continued and this should team up! I love making Science Buses out of Labs to cruise biome-to-biome (Short Bus)... BSL has a Mk3 Lab used in that .craft i drive... ok, well MechJeb drives, untill i get a Mountain warning...then I crash..err, take the wheel..yeah...

sorry for late reply, been fussing over the Win10 debacle...lol to be honest, I just placed the 1.3 Mk3Lab folder and... one sec looking... yeah, just the Mk3Lab Part folder from 1.3 into the 1.2 install and it works too... (1.2 didn't have all the comments on the SNACK Experiment MODULE in the .cfg's) I think I added the 1.3 version file as well to keep it from getting overwritten by Ckan (shame on me, i know). But the 1.2 was working fine for me. here's my list and all is well: { "kind": "metapackage", "abstract": "A list of modules installed on the default KSP instance", "name": "installed-default", "license": "unknown", "version": "2015.08.01.05.56.15", "identifier": "installed-default", "spec_version": "v1.6", "depends": [ { "name": "ActionGroupManager", "version": "1.4.1" }, { "name": "ActiveTextureManagement-x86-Aggressive", "version": "5-0" }, { "name": "AlternateResourcePanel", "version": "2.7.2.0" }, { "name": "AsteroidDay", "version": "1.0" }, { "name": "Chatterer", "version": "0.9.6" }, { "name": "ContractRewardModifier", "version": "2.0" }, { "name": "StockBugFixModules", "version": "v1.0.4b.1" }, { "name": "DockingPortAlignmentIndicator", "version": "6.2.0" }, { "name": "USITools", "version": "0.4.2" }, { "name": "EnhancedNavBall", "version": "1.3.6.0" }, { "name": "SETI-CommunityTechTree", "version": "0.9.1.4" }, { "name": "FerramAerospaceResearch", "version": "2:v0.15.4.1_Goldstein" }, { "name": "ForScienceContinued", "version": "1.0.4" }, { "name": "HyperEdit", "version": "1.4.1" }, { "name": "KerbalEngineerRedux", "version": "1.0.18.0" }, { "name": "KerbalJointReinforcement", "version": "v3.1.4" }, { "name": "KSPX", "version": "0.2.9b" }, { "name": "MechJeb2", "version": "2.5.3" }, { "name": "MechJebFARExt", "version": "1.0.0" }, { "name": "MechJebForAll", "version": "1.2.0.0" }, { "name": "MenuStabilizer", "version": "1" }, { "name": "NavballUpDefault", "version": "V0.1" }, { "name": "NavHud", "version": "1.2.1" }, { "name": "PreciseNode", "version": "1.1.3" }, { "name": "QuickGoTo", "version": "v1.20" }, { "name": "QuickStart", "version": "v1.12" }, { "name": "FilterExtensions", "version": "2.4.1" }, { "name": "SAVE", "version": "1.0.1-672" }, { "name": "SCANsat", "version": "v14.1" }, { "name": "ScienceAlert", "version": "1.8.9" }, { "name": "ScienceFunding", "version": "1.1.1" }, { "name": "DynamicDeflection", "version": "1.1.3" }, { "name": "SETI-Contracts", "version": "0.9.3" }, { "name": "ShipManifest", "version": "4.4.1.1" }, { "name": "SmartStage", "version": "v2.6.2" }, { "name": "StageRecovery", "version": "1.5.7" }, { "name": "StarTrekTOSSpaceSuits", "version": "1.2" }, { "name": "ContractsWindowPlus", "version": "5.3" }, { "name": "ContractConfigurator-AnomalySurveyor", "version": "1.2.2" }, { "name": "CapCom", "version": "1.2" }, { "name": "TacFuelBalancer", "version": "v2.5.1" }, { "name": "TCShipInfo", "version": "0.3" }, { "name": "TweakableEverything", "version": "1.12" }, { "name": "TweakScale", "version": "v2.2.1" }, { "name": "TWR1", "version": "1.21" }, { "name": "Toolbar", "version": "1.7.9" }, { "name": "TweakableEverything-EngineStagingToggle", "version": "1.12" }, { "name": "TweakableEverything-FairingStagingToggle", "version": "1.12" }, { "name": "ContractConfigurator-ContractPack-SCANsat", "version": "v0.5.2.1" }, { "name": "ModuleManager", "version": "2.6.6" }, { "name": "ModularFlightIntegrator", "version": "1.1.1" }, { "name": "RoutineMissionManager", "version": "013" }, { "name": "KerboKatzUtilities", "version": "1.2.10" }, { "name": "CommunityTechTree", "version": "2.1" }, { "name": "ContractConfigurator", "version": "1.6.1" }, { "name": "ExtensiveEngineerReport", "version": "v0.4.2" }, { "name": "TextureReplacer", "version": "2.4.7" }, { "name": "FirespitterCore", "version": "v7.1.4" }, { "name": "ToadicusTools", "version": "15" }, { "name": "EVAManager", "version": "6" }, { "name": "ContractConfigurator-InitialContracts", "version": "1.0.4" }, { "name": "FieldExperience", "version": "1.0.2" }, { "name": "WaypointManager", "version": "2.4.2" }, { "name": "FuelSwitchtoeverytank-default", "version": "0.3" }, { "name": "JettisonFuel", "version": "1.01" }, { "name": "KerbalHistoricalInstitute", "version": "Kerbal_Historical_Institute_3.3" }, { "name": "KerboKatzSmallUtilities-AutoBalancingLandingLeg", "version": "1.0.0" }, { "name": "KerboKatzSmallUtilities-DisableTempGagues", "version": "1.0.0" }, { "name": "AdjustableLandingGear", "version": "v1.2.0" }, { "name": "BDAnimationModules", "version": "v0.6.2" }, { "name": "ContractConfigurator-FieldResearch", "version": "1.0.6" }, { "name": "ContractConfigurator-KerbinSpaceStation", "version": "2.2" }, { "name": "ContractConfigurator-Tourism", "version": "1.1.8" }, { "name": "CrowdSourcedScience", "version": "v3.0" }, { "name": "CustomBarnKit", "version": "1.1.1" }, { "name": "EditorExtensions", "version": "2.12" }, { "name": "FinalFrontier", "version": "0.8.6-1370" }, { "name": "ProceduralParts", "version": "v1.1.7" }, { "name": "LightsOut", "version": "0.1.4" }, { "name": "ContractConfigurator-KerbalAircraftBuilders", "version": "1.1" }, { "name": "RCSBuildAid", "version": "0.7.2" }, { "name": "TakeCommand", "version": "1.1.4" }, { "name": "TransferWindowPlanner", "version": "v1.3.1.0" }, { "name": "VenStockRevamp", "version": "v1.8.1" }, { "name": "StockPlus", "version": "v1.0.4b.1" }, { "name": "CrossFeedEnabler", "version": "v3.3" }, { "name": "FilterExtensionsDefaultConfig", "version": "2.4.1" }, { "name": "FilterExtensionsStockRework", "version": "2.4.1" }, { "name": "KerbalFoundries", "version": "Beta_1.8g" }, { "name": "BetterScienceLabsContinued", "version": "0.1.3.0" }, { "name": "SpacetuxSA", "version": "0.3.6" }, { "name": "AutoAsparagus", "version": "v1.0" }, { "name": "SelectRoot", "version": "2015-05-17" }, { "name": "AnimatedDecouplers-x86", "version": "1.1.4" }, { "name": "LayeredAnimations", "version": "1.1" }, { "name": "AmazingCurveEditor", "version": "1.1.0" }, { "name": "PartMapper", "version": "0.3.0" } ] } My CKAN List.ckan and My alter of BSLC. I did go through some of the .cfg's and look after you mentioned 1.2 not working and uncommented the experiments to test because they 'were' working for me... I took out a LOT of 'newline/linebreak' in the middle of MODULE {something = x something = y this = z linebreak/newline one = 3 linebreak/newline linebreak/newline two = tango three = company} but I don't think i messed with anything to 'get it workin' it just worked, on my install at least.... I read somewhere 'official/unofficial' that linebreak/newline were ignored so, meh... just me and my uniformity from military...lol I did do a personal ModMan Patch to add the experiment to all probes and crewed spaces... cheaty? maybe... but i have fun so, it's ok! Fun is the game, no? But that was after it was workin' so I don't think it will help you. Actually, i think i can zip the BSLC that is in my KSP and just drop it in the GD too with the .CKAN. That may help you even more... It might have been the cure, but, alas, it was working fine for me before i did the .cfg cleaning or added the Mk3Lab... 1.2 worked a peach as stated previously... it just hit me the username, if you prefer another compression, i may be able to oblige, i can do .7z, .zip, .rar.. others i think too, iirc linux users prefer somethin' other than .zip, no? (Oh, noes!! 50 posts! someone reset my account!! I wish to remain a shadow in the background!!! that lurkin' hooligan who only appears when inappropriate and then quickly vanishes into the crowd...)

no, pls don't rep...lol... but if it was the answer, please pay it forward

Alt-F11, iirc. should be a black window with ModuleManger in the title bar, 3 buttons. (As it appears on mine) confirmed just now in-game: Alt+F11 Nice that it has the version of the .dll in the title bar too for quick at-a-glance check.

I'm sure this has been answered, but my search-foo is weak this evening... my goal: find all parts that are probe and all that hold crew will this return probes, command pods, AND/OR ( | ) crew spaces (ala Hitchhiker, Science Lab, etc.)? @PART [*]:HAS[@MODULE[ModuleCommand]][B]|[/B]:HAS[#CrewCapacity [*]] Is the [*] correct to return cores {ModuleCommand{minimumCrew = 0} as well as ( | ) anything with PART{CrewCapacity = 1,2,3...}(I've seen pods/cocpits with integrated cores for on-board Autopilot, in case Jeb suffocates or something) by itself? @PART [*]:HAS[@MODULE [*][#minimumCrew [*]]][B]|[/B]:HAS[#CrewCapacity [*]] Am I correct to assume that passing [#CrewCapacity [*]] will return any items that have the CrewCapacity listed under the root node PART (won't give fuel tanks or non-crewed fuselages)? wow, vertigo from trying to make sure i had laid it all out the way 'i think' i understand it. And the more I try to clarify what I'm asking, the more confused I seem to be getting so... I don't envy you that do this for a living...hats off to you!

So... KIS not KAS. I been skipping over this in CKAN because it is listed as "KAS Portable Science Container" and not "KIS PSC"... Just sayin' Other than that, good work!

Going back to 0.1.2.0. The S.N.A.C.K Experiment worked a peach for me. I lost 2 hours trying to sort out what happened to make it disappear. Didn't occur to me that it was because I habitually 'Mark all updated' in CKAN before I start KSP.

I take the Lab with me. 2 Scientist in the Lab, 2 Sci and 2 Engineer in the Hitchhiker. If You could get Kerbal XP for each role specific action, all my crew would be 5-Star and never seen suborbital.

Awww... what would the world be without bugs IRL... we need them, really. What's a few digi-bugs between users... come on...let us have 'em. Doesn't mean you can't still work on it! lol I'll even sign a waiver/NDA if need be!

I want your test files for that collider dust/gravel/sand... I was drooling when I was reading about it several posts back. I promise I won't come back here complaining 'it don't work' or 'this/that/other looks weird/acts funky'. The kick-up from the wheels would top it! OHHH! and variable wheelspin on mass / wheel wxh / torque...ZOMG! The possibilities.... Surely, you've all thought of that and is on some back-back-back-burner somewhere...