• Content Count

  • Joined

  • Last visited

Community Reputation

266 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. 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.
  2. Goes to show how many people actually use that part, doesn't it? Sad really...
  3. 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.
  4. And, I assume, you've attached stock gear to it to be sure it doesn't happen with those?
  5. 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.
  6. 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.
  7. 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.
  8. 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.
  9. 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.
  10. So, i've done a little research on how addons for KSP can hook into the base part module's setup to set their own procedures and whatnot. It's something that never made a lot of sense in class mainly because it was never really necessary to use them. Virtual Classes. So, I'm going to do some fiddling locally and see what can be done here. The short of it is that I will likely propose that some of the base KSPWheel modules include a method that uses the keyword "virtual" in them. These methods can be completely blank as far as what's in them but, if called from somewhere in the other classes, it would allow me to inherit the class and then use the "override" keyword to hook into the parent module and modify some things. Again, I'm not ready to make a recommendation just yet, but I'll be looking into this in the next few days/week if I get the time. This would allow me to make a real add-on for KSPWheel to re-implement some of lo-fi's old code without having to modify the original modules at such an extensive level that I've been having to do to implement the code. A cool side note: this is how the "override OnAwake()" method works when inheriting "PartModule" in our own modules. Again, I'll keep y'all posted on my progress. I'm gonna get an auto-configure working if it kills me. Would you believe I don't actually play anymore... at least not right now? I just checked the configs cause I've been in the source code for a while now and noticed you'd renamed all the modules. The DustColors.cfg probably isn't slowing anything down, and it would make an alright fallback I suppose if it could be updated. Current KSP, however, has a bit more ram allowance than the old ones the camera was implemented on originally and I doubt it would cause much extra latency. You might just merge the camera disabler with a global dust disabler and take DustColors.cfg out of the loop entirely. It wasn't really meant to be a long term solution anyway, and would have no use outside of the stock planets as they are now.
  11. I'd like to point out a few things with the current release of this mod. In the KFCommunityTechTree.cfg file: - @PART[KF_*]:HAS[@MODULE[KFRepulsor]]:NEEDS[CommunityTechTree]:FOR[KerbalFoundries] This will have no effect at all considering the module in question is now called KSPWheelRepulsor - @PART[KF_*]:HAS[@MODULE[APUController]]:NEEDS[CommunityTechTree]:FOR[KerbalFoundries] This will also not have any effect because the module in question is now called KFAPUController Is DustColor.cfg even used anymore? If it is, I really don't see a point, at this time, of keeping it. At the very least it was never updated to reflect actual biome texture colors so I would either remove it from the process or give it an updated run. You might be able to update it on the move by detecting the biome a rover is in while rolling, and selecting an average color to attach to the config. I'd still just take it out though considering how easy it is to sample the terrain using the camera.
  12. A really good example is the surface track. That's basically a track, but with the mount on top. So, Yes... I think it would be reasonable to request a wheel where the suspension system is packed inside the wheel space. However, it would probably help any world-be-modeler if they had an example that you could provide for what you're looking for.... something either in another game or the real world that would fit what you're thinking about, before a solid assessment can be made as to what can and cannot be accomplished. I will say this though: I don't think new parts are really a priority at this time. I could be wrong, but this is what I've gathered from the activity lately. lo-fi had a special talent for making wheels, which work well within his original code, at record speeds. This is not a common trait... and his absence is a blow to this project. That being said, I've been wrong before so... yeah... The do-ability of a wheel that has mounting nodes on both sides is something we could actually accomplish now, but it wouldn't have quite the appearance you're aiming for without the source unity projects for lo-fi's models. The nodes themselves I could accomplish with some config tweaks if appearance wasn't an issue. The difficulty here is in the modelling of the part itself. Other problems that could crop up are related to part hierarchy and whether or not attaching more of the ship on the other side of the wheel is going to be stable. With the mod called "Recoupler" it might be alright, since it can attaching parts that would not normally attach in the editor if they have attachment nodes in the same location upon loading into the flight scene, but without it there might be some unforeseen issues. Keep in mind, I'm just theorizing and from a purely logical standpoint. I'm really jsut a coder, and not an amazing one at that. Yes, i did create all the original part's stack nodes back in the day, but I got lucky with those. On the note of suspension-only parts, I've been asking for those since I first started working with lo-fi a really long time ago. It has it's own set of issues though, since you're not just working with colliders, but rather IR-style movement of everything attached via that suspension node in the hierarchy. I didn't understand that way back in the day, of course, but I know now why lo-fi shot me down when I would talk about it. It's more in the realm of an IR plugin than a KF plugin. I always did think that IR and KF (or KSPWheel nowadays) would be capable of doing great things if coded for interaction between their modules and sharing of data. Finally... I've done some poking around in the current KSPWheel code, the old KF_plugin code, and some of my own code in an attempt to get lo-fi's deceptively simple auto-configuration code to work with it. I'm really close to a possible way to allow a user to select if they want the steering constraints to be auto-generated, but I've run into the block with how KSPWheel is currently coded. Specifically, it's not coded to be easily extended by an outside plugin. I really need some way to hook into it, or I'd need to simply integrate the old code directly into the current project. I'm cool with that, since it's not really my code anyway, I'm just making it function again... but it's requiring me to make some changes to the steering module in just about every method contained in that class. I ain't done working on this baby though... so who knows what I'll finally come up with. I still have a few tricks up my sleeve for overriding values in the main modules without having to alter the original code... long as the information I need to alter are exposed to the configs. Either way... progress is starting to be made. The goal is for the end user to be able to click a button on a single wheel's context menu and have it auto-calculate steering limits based on its position on the craft, within the wheel's group number or on all of the wheels on the craft. I'm also trying to find a way for the original values to be saved and for it to be a toggle where, while on, manual changes will be disabled and, when turned off, the original settings will be restored. I'll keep y'all posted.
  13. That I could see, possibly. Technically you can make anything appear to be anything, separate from the actual functionality of the part. A good example of this is the repulsor which, in it's very earliest design, was simply a wheel without the wheel visual geometry. It's a lot different now of course, but that's where it started.
  14. Early versions of the color sampler for the DustFX certainly could have handled the complex predefined values for such things. Before the camera came into play we even had a "landedAt" method that somehow was able to detect specific places such as the statics around the KSC. I imagine, with some looking at Kerbal Konstructs, there may be a good way of detecting a static vs. the ground and possibly even what static it is that we're colliding with. I keep running into things that keep me from spending a large amount of time in the code. It's irritating. On the subject of scaling... TS support was in the previous major iteration of this mod, back when lo-fi and I were the main contributors. Good times. In the end, however, there was too much custom code to handle different variables to pass to TS that it just made sense to pull away and implement it separately. TS was amazing for KF back in the day though. I built most of the old TS configs for KF. Heck, I remember when TS didn't exist as anymore more than an afterthought mod for a specific part mod. Good times indeed.
  15. I am so much of a multi-posting offender today... but you'll forgive me due to the size of my posts I'm sure. Otherwise... judge me as you will. As our host has iterated, this isn't something doable at this time. However... it would be so extremely easy for this to be a thing on the code-end that I'm shocked it wasn't made a thing from the get go. My philosophy in coding modules for KSP has always been to put the power in the part-config and, if possible, user's hands. I altered lo-fi's code to his great annoyance, I'm sure, to take away hard-coded values for resource usage and other such things and place them in the configs with a hard-coded default for non-specifying module definitions. Even then, some of thsoe defaults were put in mod-specific persistent config files in the dll directory so they could be configured outside of the running game. I even played around with the idea of expanding the config-panel I had in the old KF plugin to allow specifying a default resource to be taken up by the wheels by default, populated from the loaded resource types in the config nodes. I'm sure lo-fi secretly hated me for that, but I always felt that the person who might use my code in the future would want an asy way to alter things to work the way they wanted them to. As such, most (if not all) the original KF animation controllers came with an easy way to select whether the default state could be toggled, by scene or globally, as well as what it would start with and whether or not it could be reversed after animating. When possible I even tried to give the editor scene the ability to alter the speed of the animation. If I were doing it now, I'd probably try to add adjustable lengths of the extension-retraction animations too on a per-part, per-craft, or global scale. I guess I just figured it was my job, as the programmer, to think of all the ways a future user might want to configure the part module and then make sure that my code exported as many of those options as possible to the module config while still maintaining default values in case a config is missing something. It's much the same as if you look at the stock KSP part modules. You can leave a lot of things out of them and still have a working part because they have allowed almost everything to be specified per-part while maintaining default values for missing data. So... yeah... if no one else gets to it in the near future, you may see some new code hacked together from me. Otherwise... hop to it coders. Chop chop.