Jump to content

Gaalidas

Members
  • Content Count

    1,723
  • Joined

  • Last visited

Community Reputation

287 Excellent

1 Follower

About Gaalidas

  • Rank
    Capsule Communicator

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. 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.
  2. 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.
  3. 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.
  4. 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
  5. 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
  6. 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 s
  7. 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
  8. 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.
  9. 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 textu
  10. 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 ha
  11. 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
  12. 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 ea
  13. 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
  14. 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 momen
×
×
  • Create New...