Gaalidas

Indeed, our new fearless leader has kept up the mod really well despite other more demanding projects he has up his sleeve. You and your locomotives... it's gonna take you out of this world someday. Mark my words. Ah ha! I see what's going on here... the "legs" are just wheels that have their "turning" animation tuned to a sequence that imitates "walking" across the landscape. Well played! Almost had me fooled.

So... it's a mod to make my eyes bleed as I strain to see the blurry areas with any clarity. I am impressed. Total bleed time is off the charts, and time to bleed start is incredibly short compared to other eyes-bleeding mods available. Maybe I'm missing the point... good work though.

My only use for it is in the area of C# not being able to return anything to the process that runs it. You'd have to export something to a file and read it from the calling process, like a batch file or something. So, when i try to expand my batch files to use C# methods... I can't provide any success or fail feedback without a bunch of work.

Nice. Always enjoyed these parts.

Not finding a lot of details... reading code and deciphering it are two different skill sets. Stills at it though. It appears that parts do load in with their mod directory logged somewhere. You might be able to specify a part category, or a part author in your specifications. For instance... some patches I see in the list specify this: "@PART[*]:HAS[#category[Engine]" to specify a certain category. If the parts in that specified set you want to alter all have a shared category, you could use that to specify it. I imagine you could use that to specify other part parameters. For example: ":HAS[#author[author_value]" or ":HAS[#manufacturer[manufacturer_value]" I imagine one could even specify based on the part tags, but I stopped playing KSP before they added that to the part configs, so i wouldn't know how that all functions with MM.

Gotcha. Yeah, the syntax is a little confusing at first. I'm not gonna say you get used to it quickly either. It's also been several years since my last self-made patch but I don't think it has changed a lot. You might need to specify part names directly instead of using the asterisk. You can also use partial wildcard for the part name. for example "@PART[*cabin*]" to, in this example, grab anything with the word "cabin" somewhere in the middle of the part name. The trouble with directory filters is that MM doesn't actually run on the files themselves as they are on your drive. It runs on the configurations after they are loaded into KSP. This way none of the original configurations are altered permanently. As a result, it doesn't actually know what specific directory the parts are in. It can, however, detect what mod it came from which is a feature I do not, at this moment, understand how it determines. I do, however, have the source on my drive somewhere which i intend to loo kat after posting this. I'm super curious now as to how that works.

I suppose, if you added a :FOR[Mod_name] to it, you could do a patch to every part in a specific mod. I am unsure if you could specify by directory. I have theorized that you could add a bogus module to a bunch of parts to specify that they are part of a part group for the purpose of later finding them all, removing the bogus module via a patch, and then doing things to them based on the name of said bogus module. However, taht may be beyond the scope of what you're wanting. I don't beleive you can specify a patch to run only on a specific directory unless you move those parts into a separate top-level mod directory. It's been a long time since I've done anything in this scene though, so who knows.

Either way you go... I wouldn't suggest anyone export into DDS from gimp. There have been a lot of reports, mine as well, of nasty artifacts on some Gump exported DDS images. That's why I export to TGA first, then go to DDS from there. I'd do PNG, but it's quicker to export to TGA and, this ay, my batch files can differentiate between png files that I'm allowing to remain like that, or haven't yet vertically flipped, with those that are ready for conversion. Then I can just iterate thought the entire directory structure. Anyway, yeah... I'd like to go code-only at some point but it's proving a bit difficult to do at my current knowledge level. Even some of the other tools I've used before were simply calling up an external command line utility to do the actual work. I'm gonna look at that github repo you posted though... very interesting. Also.. I agree, C++ is ugly. C# is the future... maybe...

Or, at the very least, split the camera stuff into a common library for ease of handling cameras in mods. I hope this camera thing hasn't affected the color sampling camera I put into Kerbal Foundries way back in the day... now integrated into KSPWheel.

Dunno what tools you're using or speaking of... but I do a lot of texture modification, daily, and I've developed a few tricks to handling DDS. First off... if you're using GIMP or another tool with outdated plugins for DDS, I suggest converting any texture you intend to edit into a TGA format first. I found that the GIMP plugin left artifacts on any exported DDS image, and PNG takes a lot longer to export to than TGA in the same image when I timed it. Then, to handle DX11 texture formats, I had to get creative. There are multiple command line utilities out there for handling texture conversions and I've discovered one that works in about 95% of the cases I run into. I'd called "DirectXTex" or, just "texconv.exe" and it's pretty powerful. Unsure where I got it originally though. I've spent the last few years developing a set of complicated batch files to handle all of my texture formatting and converting needs. Even went as far as you write one to separate the filenames from extracted unity textures for easy editing, and then restitch them together. Helps a lot when you want to update texture IDs for new versions of games without re-editing all the files by hand. I'm a bit of a mad man with batch files... so titled by my old school buddies. Anyway... if you can find that converter, it can handle just about everything you'd need including a few obscure cases where there isn't a specified format or compression in the file. I've only discovered a few different types that I couldn't use this tool on, and in those cases, the batch-processing utility in Irfan-View did the job (if I could live with the alpha channel disappearing). I've even handled 8k BC7 textures with relative ease, and those usually don't even import into a DDS handling program except for the higher end ones.

I wonder if, within Unity, you can get access to the source of the created GUI and, at the very least, be able to copy the script code for the positioning of the elements and such into VS after using the Unity tools to do it. I haven't done anything in Unity itself in years, so I'm unsure what I'm talking about really. Just a thought. I'd bet someone out there has built a good library for translating what you see in a GUI designer into what KSP would understand. You might try asking around on other major GUI-using mod topics for information on how they did it. In the meantime, I've had some people contacting me (as if I know anything at all... shh! don't tell them the truth)... about various ways around the stock code oddities. So I'm gonna try my hand at redirecting some things around with them. I'll get back to looking at our little problems here later. By the way, I did some sifting through old posts here and I am absolutely loving what you've done with the models and textures of the mod. Beautiful stuff. The code, for the most part, ain't too bad either. Looks like lo-fi agrees too, and he's a rare visitor indeed.

Yup, I'd say that's pretty much spot on. Those were the old glory days of KSP modding. GUI development, for me, has been a love-hate thing. I only managed the old settings GUI in KF by a lot of trial and error. The Unity GUI creator wasn't a thing back then. I had a look at the IR source today and that mod is a pure mess of chaos and damnation. It's a wonder it even compiles at all, much less work. Yet, it does... mostly. So... I'm afraid I'm a dead end in that area. On another note, I've been going over a lot of mod related code lately and have found some really odd stuff in the KSP DLLs related, especially, to part resources (as in fuel, EC, etc.). For instance... apparently the method of requesting a resource using the resource ID (an integer) and a float (for usage I think) in tagged as obsolete. However, the method which uses the resource ID and a double instead is not obsolete. To make it stop throwing warnings at me, I've had to do some strange stuff such as changing the variable to a double, casting the usage as a double, and then re-casting the result to a float later down the line. I don't get at all why they would tag the method as obsolete in the first place though. Also, apparently the WWW class is obsolete, but there doesn't seem to be any clear way of translating what we would have used for those WWW calls into the new method suggested in the resulting message. Things made a lot more sense back in v0.23.5.

This is an interesting one. A while back (like years ago now I think) there was a mod I used that implemented an anti-lock braking system... sorta. When activated it would pulse the brakes so you could slow down without just slamming down and flipping over. Very useful in low-gravity environments. I also remember that the old KF code had curves to control the amount of acceleration/torque/whatever it is that I don't fully understand, the stuff applied to the wheel at certain speeds. With these two things in mind, I imagine you could implement a feature like what is described pretty easily while limiting the chances of killing your Kerbals via sudden slamming on the brakes. Whether this is a good or bad thing is up to you.

OH... holy crud... are you mad? Silly question, of course you are. Oh god... I my head hurts just thinking about coding something like that in Unity. Okay... so thinking out loud, so to speak... In order to make all those settings able to be grouped independently... at the moment I would think they would all have to go from being fields, in the current modules they belong to, to being sub-modules of their own that feed their settings into the parent module. Then, I could imagine, you could set a certain option to be synced between different parts without needing to add a group selector for each individual settings in the context menu. Then again... you'd still have to have a group selector for each individual setting. That's where a separate UI would come in handy though. No... my head is hurting again. This could be a challenge. I still think each option being a separate sub-module would be ideal. Otherwise the code for the parent module is goingt o get very long with a group number for each and every field and a ton of utility methods to keep it all straight. Might need a new vessel module to make them all talk to each other between the parts... You are indeed mad aren't you? Oh god this is bad...

If you haven't removed the feature, already we should have a wheel group setting which previously allowed the user to modify a setting on one wheel and have to update to the others in the same group. However, I never figured out a good way to make those settings visible without looking into the context menu for one of the wheels. Also, the settings in question only auto updated when changed via action groups. Manual updating was possible with a context menu button I think. I imagine a copy and modification of the IR configuration GUI might be useful, but that's a bit beyond me at the moment. I haven't done anything with Unity menus since that first config menu I made before my long sabbatical. That thing was clunky as heck.