Stone Blue

Just make sure to install Kerbal Foundries *first*, then I would manually delete the /GameData/KSPWheel folder it installs, and then install the latest copy of KSP Wheel from here ... or wait a bit till that latest update of KSP Wheel further tested ... vOv

Yeesss

Kerbal Foundries has at least one ant-gravity/levitation "thingy", in it Theres also hovercraft parts in Fengist's Maritime Pack ...vOv

Manual install of 0.16.14.33 and KF v2.3.7.17 in a *very* lightly modded install, with MM v4.1.3 loads flawlessly for me... ....(other than 5 missing texture errors from KF, and warnings that KF and TU werent built for 1.8.1... lol ) Also took out two of the stock rover craft for a spin around the end of runway area.... No exceptions thrown, or anything... not a peep from KSPWheel... (I didnt try anything with KF gear, tho...) @Problemless Mods Wanter @ss8913 , i guess post up your logs, or wait and see if moar reports of similar behaviour roll in? vOv

Does anyone know if theres an existing way to parse the timestamps *inside* the output logs, (the ones at the beginning of *every* line), and if so, how to do it? Basically i just want the <time>, and to ditch the <yyMMddT> from them... vOv

Just FYI for anyone who reads the last few posts aboot DDS in KSP 1.8.+, to clarify, DXT1, DXT3, and DXT5 textures have been working in previous versions of Unity/KSP. With the new version of Unity 2019 that KSP 1.8.0 upgraded to, Unity dropped support of *ONLY* DXT3 format. Luckily, most mods have been using DXT1 & 5 all along... Its just a few odd mods that had used DXT3 for whatever reason. Those DXT3 textures just need to be converted to DXT1 or 5, and verything should be good to go. Generally, rule of thumb, is: 1) DXT1 is for simpler textures, that do *not* require an alpha channel, and are *not* normal maps... 2) DXT5 is for moar complex textures that have an alpha channel, as well as DXT5 should be used for normal map textures.

THANX BUNCHES, for the TC/CTB support.

No problem. No... i think i am clear now on the IR plugin/MSI folder. I think I've got IKRC shrunk down as much as I can at this point. Not including the /MagicSmokeIndustries folder, /IKRC folder is about ~22.7MB, vs ~300MB that would be installed from the current the master... Zipped file is about ~7.2MB. /MagicSmokeIndustries would still add ~17MB, if you still decide to distribute it in your release package. Going forward, if you eventually stick to similarly done 1k textures to replace the ~24 current placeholders, you can expect the /IKRC folder to grow by around another ~32MB or so.... So ~55MB folder size would still be a pretty good improvement over ~332MB. Currently finishing up sorting the Dextre parts, then should be ready to do a PR to the repo, Soon™... EDIT: Oh, also, @Trufiadok i see the CA2_LEE parts use MODULE[KASModuleMagnet]... Did you add that bit of KAS code into your own plugin, or would KAS mod itself need to be installed?

I'm guessing it jumped ship forum

First Cant wait to try this once Kop updates.

@Trufiadok So, i guess I am still not clear: is Magic Smoke IR a *required* dependency? I know the modified plugin is required, but is the *rest* of the Magic Smoke mod *also* required? Just trying to think if there is an esier way to handle/install your modifed version, instead of having to have the user deal with /InfernalRoboticsMod/ and /MagicSmokeIndustries/ folders. Are there hard-coded folder/file URLs in your modified plugin? If not, just thinking it might be better to package the /InfernalRoboticsMod in IKRC/Plugins... that way if the rest of Magic Smoke IR is *not* required to use IKRC, the modified plugin would be installed, and require no user interaction. Then if a user wanted to install the parts & stuff for Magic Smoke, they would *only* have to delete the /MagicSmokeIndustries/Plugins folder, and that would be all... vOv This is how I arranged all your other .dlls. I was hoping to be able to sneak the contents of /InfernalRoboticsMod/ in the /IKRC/Plugins/ folder, too: I dont know... packaging up a modified version of someone else's mod is always tricky ... I'm almost done with re-arranging things, and hope to throw up a PR on github in the next couple of days for you to look over. EDIT: Oh, also, I see ZiwKerman/SpannerMonkey did a v2.0.14 bugfix for a GUI issue...(I think youre using v2.0.13?) vOv Didnt know if mebbe you wanted to grab that fix, if you are going to do a 1.8.+ recompile for your modified version... vOv https://github.com/MagicSmokeIndustries/InfernalRobotics/releases

@Trufiadok So I read that post you linked about the modifications you made to the IR controller. A few of my questions are now answered, but now i have others ... lol Based on your post here, which I quoted the important part below, I was correct in some of my assumptions, and I had ended up combining the different .dll folders, into one subfolder of /IKRC. I dont understand these two, however: From what it looks like, you are saying you modified the IR plugin, and put it in the /InfernalRoboticsMod folder, and this *must* be installed with IKRC... *AND* the /MagicSmokeIndustries folder should be deleted, or not installed? *UNLESS* someone wants to use the whole MagicSmoke IR mod *along with* IKRC, then they should delete the /InfernalRoboticsMod folder, and instead use/install the /MagicSmokeIndustries folder? (Meaning they should *never* be installed/used together? use *one* or the other, *not* both?) Does this also mean, that the contents of /InfernalRoboticsMod are *duplicated* in the /MagicSmokeIndustries folder? Also, if you did modify the contents of /MagicSmokeIndustries folder, I'm wondering if you are updating/re-releasing the IKRC package any time that the actual MagicSmoke IR mod updates. I mean, what if the actual IR mod gets updated, do you grab the new version of it, modify it again, and release updated IKRC containing it? Also, since Sirkit dropped the original IR, have you or anyone else, tried IKRC with IR-NEXT?

Double check that you have the latest version installed that matches your version of KSP, as well as making sure you have proper versions of *both* Toolbar Controller and Click through Blocker mods properly installed Links for them are in the OP, under "Dependencies". If it *still* doesnt show up, then upload copies of both your Player.log and KSP.log files to a file hosting site, then come back here and post links, as well as stating what version of KSP you are running. Then people can start helping,, and bring up any other details/info that may be needed from you.

Hmm... I still have questions about how that should be installed then, if its a unique, moddified version. I'll read up on that, and tag you if I have further questions or thoughts Unfortuntely, no, just the opposite. By *not* stating a license, its automatically assumed to be All Rights Reserved, (to *you*), and to protect *your* rights, means its as closed a license as there is, and that *nobody* else can do *anything* with the mod... even just sharing or hosting unmodified copies of it. You can take a look at this thread on choosing licenses. Has really good info. It would probably be a good idea for you to skim thru the 1st post in the forum rules about AddOns/mods, too vOv Ok.. no problem Sorry i cant offer much help there, I'm an amateur at making textures. But in the meantime, if these are placeholders, I could shrink them down so filesizes are smaller for now. Right now, at 1k x 1k, thats roughly 1.2MB for every two textures. On a seperate note from what Slippyfrog posted, but also B9 PartSwitch related, I see you have many duplicate models and textures. I'm working on re-arranging the folder structure for those, as well as making edits to the part.cfgs, using stock methods, that will allow deleting most of those duplicate files, further shrinking the mod, and hopefully giving a tiny bit of a performance boost. I've already deleted 46 duplicate .mu files (7.32MB) from IKRC. I'll be going thru textures next, which is the majority of the filesize for the mod. Anyway, I see many of the actual parts use the same models/textures, and only have a couple of parameters difference in the part.cfgs. B9 PartSwitch can be used as a moar advanced (but similar) way to use the stock part variant system, by switching models and textures on parts, as well as *some* parameters in the part.cfgs, to end up with slightly different parts in the editor, without necessarily needing a seperate, unique part.cfg, model.mu, and texture for each part. Each part "variant" selected by the user in the right-click menu in the hangars, to "switch" between unique "variants" of similar parts, would end up *sharing* some, or all three of those files. So, less files to create/update/keep track of, as well as shrinking and optimizing the file size of the mod, and possibly improving the performance of the mod (less files to load and call to). Integrating B9 PS support into IKRC would be a bit of work, mostly just tedious .cfg edits. I dont think i want to go into that too much myself. Its not hard to learn or actually do, though. I would wait on that, however, until I see what I can do to organize/optimize the structure of the mod, to make sure it works as it is now, with no changes on your part. Then you can take a look at it, and see what I've done, and how I got it all to work with the basic part.cfg edits I will be making. And *THEN* you can see about adding B9 support. EDIT: So, with removing duplicate models & textures, and reorganizing folders, I *think* I have /GameData/IKRC down to around 31MB. Looking at what I assume are all placeholders textures, I assume they are just basic, single color, non-alpha textures? I notice the dimensions on them are mostly 1k, 512, or 256 ... Unless you already properly sized them to your models/UVs for a consistent pixel count across parts, they could probably be shrunk down to 4 x 4 textures while they serve temporarily as placeholders. If i do that, the mod size would most likely shrink to between 10~20MB total. Of course, that would increase if/whenever actual textures get made vOv ...

@Trufiadok I havent forgotten about this mod. Been poking at it here and there over the past couple of weeks. I was just wondering why theres an /InfernalRoboticsMod/ *and* a /MagicSmokeIndustries/ folders included? Also, did you have to actually make any changes to those files, or are they just there as included *unmodified* copies of mod dependencies, as some mod devs do with their release packages? Also, you havent stated a license for this mod. In this case, it would fall under All Rights Reserved, meaning *no one* else should be distributing it, or modifying it for distribution. Its fine if you want to keep an ARR license or choose a looser/moar open one instead, but you still should clearly state that in the thread OP, and also include a text file in the release package stating exactly what license you want. Technically, theres a forum rule for stating licensing. It would help clear up any confusion in the future, if you quit KSP, or arent available to get ahold of for any reason, and someone would like to continue, or do something with the mod... or even just use sections of it. vOv Also, I am not sure i am installing IKRC correctly, as it is currently packaged. I'm getting a lot of untextured parts and Subassemblies. Wondering if thats normal, or incorrect install? vOv

@Motokid600 This still seems to work: Except for anything on Curse/CurseForge, since they changed their API. but I've found very little thats on Curse, that isnt on SpaceDock. The nice thing about this app, is that it also uses forum links/threads, so it picks up LOTS of stuff that is *ONLY* available via Github, as well as stuff that is *NOT* on CKAN.

@Morse Just wondering if this mod is still relevant, and/or if it does anything differently than the latest version of World Stabilizer, that Jade linked above. I ask, cuz i was perusing your github repos, and saw a recent update for this mod.

I just tested it, by launching a sat using the stock Z Map craft, in IVA/Map view mode only. I had placed several ASET ExtRadialCams to do SpaceX-alike staging and event views. Everything went flawlessly, and all RPM MFDs *seem* to be working, except mebbe for the Orbital Map view. I havent actually *played* KSP in awhile, and I dont recall if "stock" RPM is supposed to display a planet map in this view or not. If so, that was blank. And if it *is* an issue, I would assume that would be an RPM/Tegmil's patch issue, *NOT* a PCR issue... vOv but overall, yeah, all the controls/buttons/MFDs, and even switching between the Flight Stations seem to be working. So no "deal-breakers" I guess, for not using PCR. I didnt *fully* test everything RPM MFD-related, but yeah I would say basic PCR works in 1.8.1, using Tegmil's 1.8.1 RPM patch. I think any issues peeps might have with Tegmil's patch, is *just* that: its a *patch*, and not a complete release. It needs to be installed on top of the last "official" RPM release (v0.30.6). It doesnt contain the required RPM .assetbundles, some other stuff included in a full RPM release, and any likely issues would be improper installation of RPM/Tegmil's patch.

I havent been on the bugtracker in quite awhile, but I would like to see Squad address as many remaining bugs as they can. There have been many bugs that have been around for a long time. I would like to see a "Bug Squashing" update of KSP before final development/maintanance stops, rather than any added features or aesthetic or texture revamps. I assume that will be happening in within the next year, since I assume KSP 2 release will draw most of the community away from KSP. I dont like that Squad has been overall, seemingly been mum about development, other than new features and aesthetic revamps, between update releases, over the past year or moar. I would like to see talk of bugfixes, and substantive feature changes/additions for upcoming updates, rather than marketing fluff and hype. Looking at past update history, minors have generally released mostly around a 1 month or less timeframe from respective majors and minors. Seems there were only two significant exceptions, with 1.3.1 and 1.0.5. I miss the mod dev pre-release access Squad used to allow to mod devs. Even tho there seemed to be a lot of issues with allowing community pre-release access, IMHO, I seem to remember at least there was moar transparancy about what was being worked on or at least considered for bugfixes and improvements. It also seemed to help keep the Mod-Update Scramble tolerable, quicker and easier. I would like to see Squad go back to that for KSP's final updates before EOL. IMHO, it would help extend KSP's legacy and playability, to have a final, really, solid-as-can-be playable game, that has the support of as many mods as can be. Unfortunately, thats counter-intuitive from a marketing/profitability standpoint, as it may holdback many people from spending $$ on KSP2 and future DLC's for *that* game. Anyway, my amateur guess would be, that if we dont see a 1.8.2 by end of January, there wont be anything until at least 1.9.0 in late February/early March.

Nice... Kinda surprised you havent gotten moar response, @AlmightyR Hopefully with an actual download available, you'll get moar interest. Also, just an FYI, per forum rules, you should clearly state your license selection in the OP, as well as add a text file in the .zip stating it as well Especially if you end up adding any different textures, or actual custom Unity materials in the future.

heh... are you sure?... that seems like it could be quite the rabbit hole

@pquade see my post here in the PCR thread. this may be your issue. Try deleting the /GameData/JSI/ folder, reinstall the official, but outdated RPM v0.30.6, *THEN* install Tegmil's patch on top, merging/overwriting everything. If thiings are still not working, you may have to repeat the process, while also deleteing these folders: /GameData/ASET/ALCOR_Advanced_IVA, /GameData/ASET/ExtCamRadialVert /GameData/ASET/ASET_Props (as well as /GameData/ASET/ASET_Avionics if you have that installed) Then reinstall the ASET ALCOR & Props mods. (ASET Avionics, as well, if you had that one before)

Ahhh... that explains a lot... I bet you downloaded the master or source from Github... vOv If grabbing from github, you want to make sure you're on the "Releases" page, (use the Releases link/tab in the top row, if you are on the main repo page) and the versions are listed newest to oldest (first to last)... There are usually at least 3 files listed under each. The release .zip is usually the first listed (the one you generally want, which generally gets installed into /GameData), a Source.zip (contains a snapshot of the master repo, and may/may *NOT* contain the proper release package, which inc. the stuff that goes into /GameData), and a Source.tar.gz... which is the same as the Source.zip, but packaged for Linux. Also, do *NOT* use the green "Download/Clone" button on the main repo page... that will give you a current snapshot of the master. (basically same as the Source.zip, but current to real-time). AGGHHHH!! ... I think i found the issue (at least as far as the RPM stuff...*IF* using Tegmil's version). Looks like Tegmil didnt put together a *complete* release package. But, yeah, the dropbox link you posted above is the correct one. Theres some MM patches, and other minor stuff missing, BUT THE MOST IMPORTANT part missing, is the .assetbundles files. So, I guess they really did do only a recompile on the .dll, and a patch release. Patch release generally means you install something, in this case RPM v0.30.6, *then* you install the patch release over the top (v0.30.7 (tegmil's .zip), merging folders and overwriting existing files. And yes, you drag the /JSI folder to /GameData. EDIT: yeah... i properly installed Tegmil's RPM patch/recompile, and PCR now seems to be working properly for me.

Hmmm.. are the RPM MFDs all dead/non-responsive/blank? Interesting, as I had that same exact issue with Probe Control Room... I dont know why the labels are all missing from eberything Is this different than what you had happening before? I'm now wondering if theres an issue with Tegmil's unofficial RPM recompile .. vOv

@pquade If you havent tried already, copy over *only* the stuff in the /ASET/ folder... Then do fresh install of the dependencies: v4.1.2 of Module Manager, and on the last page or two of the RPM thread, user Tegmil has a v0.30.7 RPM recompile for 1.8.1 Of course, you also want to make sure any of the listed recommended mods for ALCOR, are also updated or have stated 1.8.1 compatability. Give that a try.