Gaalidas

Members
  • Content Count

    1,716
  • Joined

  • Last visited

Community Reputation

278 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. 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...
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. 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...
  8. 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.
  9. 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.
  10. 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.
  11. Goes to show how many people actually use that part, doesn't it? Sad really...
  12. 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.
  13. And, I assume, you've attached stock gear to it to be sure it doesn't happen with those?
  14. 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.
  15. 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.