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.

Sup boys. Been thinking about getting into KSP again. Nice to see this old thing is still being worked on. In fact, I've already re-familiarized myself with the code. Looking good... other than a few cringe worthy moments where I noticed some sub-optimal method naming convention issues. Still, seems to be working rather well. Unfortunately I haven't launched KSP is so long and I'm so out of the loop on the mod scene, I'm having to play catch-up.

I can confirm that those configs were all about the functionality of the KF wheel system, not necessarily sound or dust related but, back in those days, the KF modules were set to add the dust module to the part, if not found, and sound was part of the KF wheel module itself. As for the dust itself, technically, the original implementation I made, back in the day, was not based solely on KF. It was a heavily modified CollisionFX module. It was later added to KF and integrated into it when I became a more active member of the development team for KF. A version could be made for the stock wheel system with very little overhauling needed for the module itself. It could even be shipped with KF. However... if couldn't easily be made into the current dust module. It could use the current camera color sampler, but it would be a duplicate module for handling the dust itself due to the differing parameters for the two wheel modules (KSPWheelBase vs. ModuleWheelBase, free-typed without looking at the actual module names.) Making this might be considered a waste of time, however, if shipped with KF. A better option might be to alter the configs for the base wheels to use the KSPWheel module instead which would eliminate the need to use a different dust/sound module.

Goes to show how many people actually use that part, doesn't it? Sad really...

The KF thread is still rather active and I'm still working on it in my rare spare time. It's under new management though, so there have been a lot of changes. The sliding, however, is not unique to KF. I've witnessed it with completely stock rockets sliding around after landing vertically on Kerbin.

And, I assume, you've attached stock gear to it to be sure it doesn't happen with those?

I really didn't see a lot of changes that really needed to be made on the Catapult mod's side to make it work really. They would just need to use a bunch of reflection stuff to maintain compatibility with non-KSPWheel setups. It would take a little testing and manipulating... but it most likely can be overcome. Anyway... I don't have any time to really dig into it so... that's how it'll be until someone can convince the other party to look into it. On the topic of the bouncing and spinning... and video does show it off nicely. Some bounce when landing is pretty normal for a plane, but that flip was crazy.

I had a look at it and it could be modified to work with KSPWheelBase... but that's not on our end. One things that is on our end is the fact that the ModuleWheelBase "isGrounded" boolean is called "grounded" in KSPWheelBase instead. If that were renamed to "isGrounded" like the stock module, then altering their code to work for either the stock or the new module would be extremely easy I think. I didn't look at al lof the code though, so there's still a chance there would be some conflict somewhere. I just caught the last method in the Catapult class where it looks up all the modules on the parts.

I highly doubt that would fix it really. It's likely locking into a specific transform on the models that are used for stock landing gear and/or modded landing gear under the stock modules. I'd need to dig into the source for the catapult to know for sure.

I would prefer to not make you do any extra work to make this function... and it really would be better to have this as a separate sub-mod for KF/KSPWheel so I can update it at my own pace and/or add other new features to various modules. Thanks for the tips though... I'm going to continue fiddling around with various ideas and see what I can come up with. I hit these coding-blocks in my brain from time to time that make it hard to see the right path to take... or even see what it is I'm trying to make happen. My biggest block right now is in the way the steering limits are implemented (your high and low limit vs. the old steering ratio that lo-fi used) and which of those limits I should be modifying for the desired effect. I would have thought there would only be one limit, with the other limiting factor being the default position of the wheel when not steering any which way. I need to dig into the part configs a bit to see what you've set them all to, as well. Is there are single value that best represents the overall steering ratio in the current steering module? Another thought that I need to put into action is to disable the auto-calc when the wheel type is a track, since it has really no point (except for with the surface track, which has wheel-style steering I think?) when track steering is in play, unless a part uses both forms of steering together. I think best case scenario is to not replace the class entirely with a derived class. That would make more work for me if/when you update the steering module with some new feature or whatnot. Would cause the end-user to get some strange results. The best plan would be to alter the way the module is working though another module. Delegates... oi. When the class I took covered them, the idea, from what I could figure out, was that it allowed you to input an unknown function as a parameter instead of just a data type. This differed from providing a data type using a method like we do all the time, but rather providing the method itself for the parent method to use. I suspect I have it all wrong though and the teacher was just condensing it. This all being said... in the process of making this I have discovered several ways the existing code could be updated for some efficiency bonuses. I'll probably have some coding recommendations for you in the future. I also managed to implement a few features that you had in To-Do comments. I'll include those when I make any recommendations. As for now.... there are floors to vacuum and I'm the vacuum technician (glorified carpet janitor really) so... off I go.

I literally noticed you use virtuals and such just after writing the last comment. Anyway, they're new to me... so still exciting stuff. I will look into that. I hadn't thought of looking into the submodules considering my only experience is in simply modifying public variables in other stand alone modules. I'll have to mess around with that. One thing that may be a bit problematic is that you have a low and high limit setting for steering while, in the old code, we simply had a single variable for max steering angle. It turns out lo-fi's code is deceptively simply. It really just counts out all the wheels of a compatible type are on the craft and gives them a position in an array of sorts, then uses a curve to set their optimal angle. That's simplifying it, but that's it in a nutshell. So, the current plan is to simply make it a toggle option in the wheel's configuration. If any single wheel has the option set, it will take the other wheels into consideration when setting up the angles for that one wheel, but will only update and disable the manual configuration for wheels that also have that setting applied. Thus you could have steering that only uses the front wheels, but they'll take the rear wheel positions into account when setting the angles. That's the idea anyway. It would be a lot more efficient, of course, if the detection and settings could be run from a vessel module instead, keeping it form being repeated for every wheel with that setting applied, but I'm unsure as of yet how that might be achieved while still allowing for per-part toggling of the option. I'm still playing with it though. As for delegates... I really hate those. Mostly for the reason that I simply can't seem to wrap my brain around them. Morning-after update: So, I guess I'm going to have to launch KSP with KF installed and do some fiddling around. I don't actually know how most of these settings are applied or what they do. I did take a look at hooking into the submodules class, but I can't just add my module in there and do things, I need to override things that are happening in other modules. This is all getting really complicated and I wonder if I should just make some modifications to the original steering class in your project and submit them to you directly for integration.