• Content Count

  • Joined

  • Last visited

Everything posted by Gaalidas

  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. Gaalidas

    Anyone remember Kerbal foundries?

    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.
  16. On that note... The first versions of DustFX used a form of ground-region and/or location and/or biome detection method to specify high and low color ranges (though I pretty much stuck with non-ranged values for them at the time of working on that). Now we use, primarily, a camera that doesn't see the vessel and just averages the texture colors it's getting. That aside... you could use a combination of biome-detection and texture-color-range detection to set up an approximate slippage scale that could then be adjusted along with the dust colors. In fact, that would allow for dust densities to be adjusted not only on the speed of the craft relative to the terrain but also based on the estimated density of the terrain. Obviously there wouldn't be any perfect setup unless we could get access to the stock terrain/biome stats if they even have any form of terrain density/stability statistics. I seem to remember there being a setting in the game detail settings that had some form of density setting for planetary features, but I don't know if that means anything when you interact with the planet in the end. Of course, the code could be revived, which handled complex persistent settings for the old KF, to store pre-generated stats for some estimated terrain locales which could be updated on the go to create a slow-built database of estimated values for this sort of thing. It shouldn't be too hard to re-implement considering all it did with KSP specifically was integrate with the config node system which, while frustrating at first, turned out to be easier to use than expected. Another variable that could be used in estimating slippage would be the estimate temperature range of the planet as a whole, and then of the latitude of the craft vs the equator. Warmer material would likely be muckier than colder surfaces except when dealing with concrete (so, an exception in the case of anything with an estimate color of gray but not if it's blue-gray so ice doesn't become super stable... could be tricky to code). It would be so much easier if the actual texture could be detected under the camera so you could make overrides for specific texture names on the surface. I'm rambling again I think... I suspect that most of this would be impossible using the stock game implementation of planets. Using the code from planet expansion packs might allow detection of such details directly from the planet comfig files included with supporting mods. As far as I'm aware, however, these mods do not replace the stock planets with their own configurations so it wouldn't be too useful to us for stock surfaces. Either way, I foresee a lot of interaction between mods we don't control to make it all work. I could estimate things based on the sampled color of the terrain, but that's pretty much it without reviving and overhauling code form other sources. I won't say it's impossible though.
  17. On that note, I did at one time extract the texture swapping portion from Firespitter.dll into my local KF project with the intention of digging out useful code to make a part of KF... but never really took it anywhere after migrating the basic functionality. I actually didn't really like how it was implemented in the part configs and was going to alter it for ease of configuring and, possibly, integrate with the existing KF model swap mechanics at the time (used for non-symmetrical tracks that needed to be able to be attached in symmetry modes such as the Screw, aka hypnodrive, and one of the larger tracks.) It's just another of my abandoned projects from when I took over KF a long time ago. if someone were to analyze how it's done in one of those other mod packages and then modify a copy of the existing texture used on the current model, creating a patch with MM wouldn't be difficult. What can be difficult, however, is if the model is extremely complex and has multiple texture calls for different objects and textures. I remember a few complex models that called up a copy of the same exact texture several times and using firespitter was nearly impossible because you needed a separate module for each object that needed to be specified exactly and couldn't be multi-specified. Again, that's why I wanted to rewrite it. KF already had code to find the model object names for use in other calculations and I figured I could integrate with those modules to make object and texture matches auto-populated (or auto enumerated, in coder-speak).
  18. If i get a chance, i'll try to add some stuff for the shadow to put into his next release to expand the action group functionality. Either that or I'll put them in an add-on for KF that I'm mulling over. My plan right now is to try and create an add-on rather than integrating directly into KSPWheel. That way I can add the vessel-aware steering and expand on the module action groups without modifying the original code. This will also let me get around my lack of ability to compile with C#6 features using SharpDevelop (I prefer that to VS due to the fact that VS takes several years longer to load everything up than SharpDevelop does. Something to keep an eye of for the wheel/repulsor group functionality: if you're using symmetry and decide to use an action group to update the like-grouped parts, you cna easily end up activating something twice or more for all the action-grouped parts under that symmetry. I know we did a lot of work in the original mod to counter this possiblity, but I have yet to check on that in the current code. This was more apparent when I had the action groups available to increase or decrease the height on the repulsors by a set interval. If I activated the action group on one repulsor I could then iterate through the rest of the group to update them all. However... if I action grouped a symmetric part it would then activate the command on both parts in the symmetry resulting in double the increment/decrement. That's the trouble with adding action group commands to parts that also have their own settings sharing system, such as the wheel/repulsor groups.
  19. Gaalidas

    What did you do in KSP today?

    To be fair, I created the Dust and some of the action groups for the original mod... which is pretty much nothing like the current one except in the parts. Oh... and, if any of the parts have retained their stock nodes for optimal placement, you can blame me for those too. Only other thing I did was inspire the smart people to add Tweakscale support to it.
  20. I've been trying to look over ways to integrate the old code, but somehow my copy of the source got really screwed up. Gonna re-download a copy and get back to it. I still have to figure out a way to get around the fact that I can't properly evaluate the "nameof" calls... but I can easily revert that to the old method for testing purposes I think... I make no promises, but I'm definitely giving it a hard look.
  21. Except I think you pretty much imported the dust system directly, didn't you? Either way, I think the old KF code needs to be looked at again for features that could be included with the new code. lo-fi had them very customization while still allowing a user to just slap it on and make it happen.
  22. I thought the mod, under lo-fi's code, already did some of that in the background. KSPWheel must have changed a lot of the back end stuff. Then again, I never totally understood most of this stuff.
  23. Hmm... I'd need to see a shot of the problem happening... but right off the bat I can think of a few things that might cause this. First off, I'd make sure the wheels are truly attached the right way up. Beyond that, I could imagine that something has been borked on the scale implementation, which would be a configuration problem and totally not something you could fix yourself. I would also do a test with a craft layed out the same way except with the normal sized wheels to see if the problem is with the wheel itself or whatnot. I do know more recent work on this mod has implemented damage states and, if the wheels are being overloaded then they could be breaking upon trying to turn. Either way, it sounds like a bug.
  24. Just hoping this thing is still compatible with 1.2.2 before I start telling the streamers I watch about it. Don't want to cause issues with those guys.
  25. So... I was watching a mod spotlight of this mod that Kottobos did recently and discovered some issues that I'd like to address at this time. I took a dive into the source code and added something that I think would benefit the end user. This is related to the information about each size of part in this mod from the editor. Right now there's not a lot of information provided outside of a giant wall of text in the description. This can be displayed in a better way in similar fashion to the fuel tank amounts that are shown in the part info panel. After going through the code and making some adjustments, I came up with this little bit that you can add to the top of the "ModuleMassAccelerator" class just above the "armNetwork" method: public override string GetInfo() { // Adds a part info entry to the part details. string result; result = string.Format("Mass Accelerator Module.\n{0} {1} used for every 100kn/second.\nLoading Distance: {2}m.\n", resourceAmount, resourceName, loadDistance); result += master ? "Control Unit" : "Extender Unit"; return result; } This will enable the said display and stick that formatted information into it, I believe. It's been some time since I compiled a plugin for KSP but, as this worked back when I was working on Kerbal Foundries, so it should be fine now. It should also be noted that this technique works for any module added to a part config, and the string can even be put into a "KSPField" and returned in the above method so that extra descriptions cna be defined inside the part.cfg under the module in question. Note: the line with the "string.Format()" in it should all be on one line, and should paste into the code properly if copied as one line. In case it doesn't, I would suggest altering it to be on one line again. Most IDEs will likely be able to figure out what you're trying to do either way, but better to be safe. Anyway, that's my little contribution to the future of this mod. Take it or leave it. I think the end user will thank you for adding it though. Edit: Another thing I noticed in the display of the context menu (right click when in flight) is that the unit of measurement is displayed right on top of the number without any spacing. This is because the units display in KSP assumes it's displaying an abbreviation of the unit. I would suggest changing it to this: [KSPField(isPersistant = false, guiActive = true, guiName = "Accelerator force", guiUnits = "kn")] public float acceleratorDisplayForce; //in kilonewtons This will display it as, for example, "1107kn" instead of "1107KiloNewtons" or some such thing. Much cleaner. One additional thought... though this would require some code rewriting and such... would be to simplify the construction of these drivers by eliminating the different parts for the Network and Control nodes. On launch, you could have the module check to see what order they are attached in and automatically select the proper node type. You could also add a context menu option to allow the user to select which part to use as the control node which would then reset all the others to act like network nodes. If you're interested, I could look into modifying the code for you to allow this to happen. I would also think that adding a remote control unit that could be attached to a craft would be awesome. This would be a small box-like part that could allow a user, on the craft that wants to be shot out, access the mass driver control unit remotely. The code would simply search for a control node on a mass driver enabled craft within the range of the launch range plus a little leeway, and then pass commands to it. I'd be interested in doing this as well if you'd like.