Stone Blue

Yes, v0.7.1 *is* compatable with 1.3.1. Somwheres back on page 1 or 2 of this thread, Ser confirms 0.7.1 is ok for 1.3.1. There are few instances where plugins/mods break between minor versions of KSP. In the case of this specific mod, thats why there was no update specific for 1.3.1, and the next update only came for KSP 1.4.x

When Squad switched to the IPS (Invision) forum software, they barely tweaked the stock "theme", which is what we have now... If you want to see some nice examples of what can be done with this same exact software, you can use Google and search for Invision Community forum software, or take a look at some of TakeTwo's other community forums, specifically GTA:V and Red Dead Redemption. (Incidentally, both of which are in a dark theme ) In many cases, game community forums are *not* controlled or affiliated with the actual game developer, tho ... Such as XCOM, which is also a TakeTwo tiitle... Heck, customized themes can even be purchased from Invision themselves... But in any case, it seems Squad adding resources for maintaining/updating the forums, was seemingly *not* part of the TakeTwo takeover deal.

I havent looked into it lately, but yes, the forum software is highly customizable, and a beautiful nice looking dark theme could very well be done... Getting Squad to actually do it, is highly unlikely tho. So, like the game itself, we either have to extra measures to make things work the way we want, or just deal with things as they are

I cant remember the specifics of Dx11 over Dx9... But I have been using Dx11 with KSP forever... Since the Unity 2017 update in KSP 1.4.0, Dx11 needs to have Textures Unlimited plugin installed to fix issues the Unity udate caused. Thank Electrocutor for the fix... Details in his thread OP here: I beleive this also worx for forcing Dx12 on Windows 10, as well?.. vOv

I recently made some changes to one of the versions for my DarkBlack theme thats on Userstyles.org. (I go by user Joe Shmoe)... I was hoping to do moar testing and possibly moar changes, so I havent updated Userstyles.org yet... I use the Stylus extension on Firefox... Stylish, and a few others can be used if they accept raw CSS. I switched from Stylish to Stylus... Stylish has privacy issues, since the dev supposedly got in bed with some other company or something... i dont recall the details... Stylus is a fork of Stylish, by someone who didnt agree with the new "policies" of the Stylish dev. I have the recent changes on my Github repo, tho, if anyone wants to test and give feedback: https://github.com/StoneBlue/KSP-Forum-Dark-Theme/blob/master/KerbalForumDarkBlackStylishNoTagsNoStreamer.txt

Sorry SpaceKadet... this is meant for Jade... stoopid forum wont let me delete your tag from the quote Jade, I'm *very* sorry to hear that Again, i am having RL and computer issues, so my motivation and ability to keep trying with KSP "stuff" is also kinda low right now... I feel bad that I havent finished those OPT parts yet .. They are always on my mind tho... And to anyone wondering or considering of taking up the mantle of "continuing" OPT: Know this... While OPT is an *awesome* mod, and K Yeon did wonders with it... It is also, a *HUGE* rabbit-hole behind the scenes... While not wrong, or incorrect, and possibly just "dated", many of the ways he created the parts is now kind of unconventional or not-quite the way many other devs would do things for current version of KSP. And it takes a huge amount of work to "change/fix/optimize/modify/add to" OPT... not only the models and textures, but as shown with the awesome job Jade has done with balancing/functionality/adding support for several other mods, that i am sure has also been a *ton* of work and time to do... Several people have optimistically jumped into doing things with/to OPT under the hood... and then realised how deep the rabbit-hole goes, and the time involved... and have somewhat burned themselves out on it... I have poked around, and tried to modify many old mods... and I have been consistently told over and over by many *very* experienced mod devs in the KSP community, that the best thing for a new or inexperienced modder, is to start fresh with something, rather than trying to revive an existing mod. (NOT that I have ever listened :face_palm:) In most cases, there is only madness in going that route, especially for someone who is not experienced. I'm *not* saying NOT to contribute or poke around with OPT... I'm just trying to offer advice and my own, as well as others seeming experience, so people wanting to "pick up the mantle" so to say, can tread a little moar cautiously before jumping in feet first... Lets say OPT is the "deep end" of the pool... Looks very inviting, and people want to head to that end before the "kiddie-pool"... Ideas for great things abound... but if you jump in before having at least some ability at intermediate swimming... You can end up driving yourself mad trying to figure out/fixing the way someone else did something... or picking up their bad habits... or burning out your interest of trying out modding quite quickly. OPT is a beast of a wonderful mod... But for "new" people, I would recommend lesser, simpler mods to attempt to learn with...

Yup... I'm not saying STRICT shouldnt be displayed, or discounted, its moar that I dont agree with _MAX not being displayed or _MIN/_MAX considered...

Ok, my first impressions of 1.3.0.1... 1) Always Compatable - I like it... This seems especially suited to parts only mods, which are moar rarely affected by KSP updates (usually due to Unity upgrades) 2) As *both* a user and a wannabe modder, I *LIKE* that VERSION_MIN/_MAX are shown and considered. While it *is* nice to know exactly what version of KSP a mod was compiled against, for archival/time reference, its generally *NOT* very useful at all. Especially for mods that dont even have dlls to be compiled. Rathere than using a STRICT version, of such short-lived KSP versions, such as 1.1.1, 1.1.2, 1.4.2, 1.4.3., 1.5.0, 1.6.0, etc ... tells us nothing substantial, except that the mod *might/should* be compatable with the later, longer-lived (final) KSP versions such as 1.0.5, 1.2.2, 1.3.1, 1.4.5, 1.5.1, 1.6.1 ... but not as definitively as if the dev adheres to using _MIN/_MAX... and using those gives that much moar reassurance and definitey (is that a word?) straight from the mod dev's mouth *EXACTLY* what versions they saying something works with, and in so doing, what they should be willing to support. It also eliminates a whole percentage of guesswork for users... *at least those that can READ...* ... Imagine how many moar posts and pesterings there would/will be asking if things are compatable between specific patch versions, even from those who *can* read, and are willing to investigate before posting, if _MIN/_MAX are not shown or taken into account? 3) Arrow buttons to right in center, Incompatable Mod section... I guess I dont see the point in these, the way they are setup... vOv They currently seem to do the same exact thing as the radial buttons in the Compatable Version Override section... especially for *every* other mod, that is the *same* version or *later*... I would rather rather (and would expect) it would toggle each mod individually for an override... Also, kinda weird, toggling a 1.3.x mod, seems to only affect pre-1.4.0 mods, ignoring all post-1.4.0 KSP versions, yet toggling a single 1.4.0 mod, toggles *ALL* mods for *ALL* post 1.4.0 versions... vOv Also, toggling a mod that shows _MAX, toggles everything greater, but misses what should be included STRICT versions... ie toggling a visible 1.4.99, does *NOT* toggle a 1.4.0, 1.4.1, ... 1.4.5 STRICT version... So I'm gueesing _MIN is not considered at all? granted, I have a limited number of mods, as this is in my dev install, and not my typical play install, which may include ~100-200 mods, so my testing data is limited Since toggling one of these arrow buttons, enables the override for *all* other mods with a greater version, (basically which you can do with the buttons in the Override section, then i would rather see these arrow buttons in the center section, *EXCLUDE*, or override the override enabled, for the specific mod... ie what if you have 10 mods that *are* ok to override from 1.4.0 to 1.6.1 ... but you have that one mod, that will *not* work in 1.6.1? How do you easily, in the UI, disabled just that specific mod from the general override you've just enabled? I am also seeing inconsistent orrides being applied using these buttons, that should/should not be enabling/disabling the version overrides... Hard to explain... I'll have to add moar AVC-supported mods over wider range of KSP versions to get a handle on the weirdness I'm seeing... 4) Version Override section ... Currently showing version numbers strictly how they are selected and toggled... ie a line each for 1.4.99 -> 1.6.1, 1.4.0 -> 1.6.1, 1.4.5 -> 1.6.1, etc... Would it be too difficult to add some code that could could do live comparison, and combine the _MIN/_MAX/_STRICT versions, into a *single* line where applicable, that would basically cover the _MIN/_MAX range... even when only implied, where any of the three fields are not present? Also, when added, the displayed entries are not displayed numerically in order... nor even in order of when they are selected... vOv I guess thats enuff of a wall of text for now... I may have moar to add later

oh... are you making changes *other* than CBT? Cuz I have been resizing toolbar icons where I can, for mods that are not using 24x24 and 32x32, to eliminate log spam that they are throwing... and I already did the ones for Notes...

Thank VERY much @linuxgurugamer I'll keep an eye out, and be sure to test when ever you're able to get it done oh, and yes, I have the freshest releases of all three mods

Ahhh... gotcha... I was just wondering that, and was about to check... Unfortunately, CBT isnt working on Notes for me then... I'll be back in a few... 99% sure all three mods are up to date, but I'll recheck... I'll also get logs.

Wait... is CTB *already* a required dependency for Notes?...its not mentioned as such in the OP (only ToolbarController is...) and if CTB *is* already supported by Notes, then I have to report that click-thru blocking is *not* working for me... vOv

Idk... its working for me in 1.6.1 vOv I guess recheck install of both mods, to begin with. @agises I guess I have a couple "feature" requests... Sorry if they have already been discussed.. i admit to not scanning back thru the thread First, any chance to make the UI size user-adjustable? i could swear I have seen a mod that had a button in the lower right corner of it's UI, that if you click-held on it, you could drag the bottom-right corner of the UI to resize the whole thing... even independently along either axis... vOv And second, since this now depends on Toolbar Controller, and since Notes is, by nature, a pretty good-sized UI window, is there any chance to add Click Thru Blocker support? From what I can tell, LGG has a pretty good, simple instructions in the CTB readme.md on how to add support for mod devs. As always, THANX for this mod tagging you @linuxgurugamer in case you'ld like to look at this, (just the CTB addition), since you provided a recent PR for Notes, and also the fact that CTB is your mod, and if *anyone* is familiar with CTB code, it would be you

@PocketBrotector I see what you are doing Too funny... I was about to inquire if it might be possible, and youre already on it... Thanx!

Is current version not working for you?... what issues are you having?

Kewl... :thumbs_up: that was a quick, passing thought I had, also...about toggling the button text and color based on state... but forgot to mention it during the ten minute struggle I was having with getting my imgur link to work in this damn forum software...

@4x4cheesecake the issue that MOARdV saw about some mods highlighted yellow, with issues, but with nothing showing in UI, was the first thing i also noticed on my first run of the beta... and while I only got to load KSP once since the new beta, that is the reason I posted that I wasnt sure I liked the new UI... I was immediately confused a bit, as the UI was ompletely blank in each section...but didnt have the time to investigate. But take that with a grain of salt, from me, at least, till i play with this moar. I agree with DStaal... it seems the enable button is a little bit moar, immediately important than the rest of the buttons... I agree, moving it somewhere moar prominent might be good... How about to the top right, next to the "Version Overide" title? ... I assume thats the pertinent section the button deals with?

Yep... it did *mine* Hmm... I almost like the old UI I'll have to play with it moar tho... I think as long as, eventually, there is a little good documentation blurb about the interface for people like me who tend to absorb things slowly, it should be fine

Yeah... you want to *merge* the unzipped/extracted GameData folder with the /GameData folder in the main KSP folder. Windows will ask if you want to do this, check the box for "all folders", the "Yes" OR, alternately, go into the *unzipped* GamData folder, and copy everything *inside* it, *into* the /GameData folder in the KSP install. I *almost* wish the community "standard" for packaging mods, had *NOT* had the GameData folder level, and had just the specific mod/dependency folders at the top level in the package, instead... seems it would have helped eliminate soooooo many install issue with new modders... but either way, you'ld only please half the people... And yes, I followed the conversations discussing and settling on the mod packaging "standard" very closely, so I know all the pros and cons for doing it that way, so no need for us to elaborate on the "why" it is, and de-railing this thread. Despite my whining above, lets stick to the "how" to implement it.

Maybe, whenever you get a chance, or when you see someone posts about current version seeming to work with future versions of KSP, just updating the thread *title*, and making a note in the reason for editing the thread, that current version works with x.x.x version of KSP, would be enuff to head off the questions from people who can actually read? ... vOv I've seen many other mods do this Just a suggestion... I know you are busy and you *do* have quite a few mods to wrangle

O...M...G... :face_palm: Cant beleive no one (myself included) thought to use B9 that way for this... especially since I've known, like, forever, that B9 could *do* node switching :side_glances_@_: @JadeOfMaar ...

A few posts above yours: https://forum.kerbalspaceprogram.com/index.php?/topic/155056-142-kerbal-foundries-continued-tracks-wheels-and-gear-04-10-18/&do=findComment&comment=3552607

So, in other words, parts *have* to be *only* stack attachable, and *cannot* be both surface and stack attachable , for mirror symmetry to work? I know MOARdV fixed mirror symmetry with AviationLights, but they *are* only surface attachable... So in other words, i assume stack parts can be mirrored properly, and surface mount parts can be mirrored properly... but if the part uses *both* methods, theres no way to have mirroring work?

@Shadowmage Hey, thank you... That landing leg is perfect for filling a niche that I have found sadly lacking for a long time. I'm sure you are aware of these old things, but i have been using them forever as my favorite set of legs. The problem with them (for me), is that they *are* big... and the only way to adjust them for ground clearnace is to slide them up or down the part they are attached to. Which means, lots of times, they overlap the joint of two stacked parts... or they hang ridiculously off the top or bottom face of the stacked part they are attached to. Plus, when stowed, there is no "case", so, aesthetically, they can detract from overall look of a craft in some cases. But anyway, just thought i would mention them, as in case you plans for a second set of legs like that latest, but designed for "moar" ground clearance, i for one would like to see something similar to these leggs of Alex's... Then maybe I could retire them as my favorite leggs, and go back to *solely* using KF

Does it not work? vOv