Gaalidas

It looks like the issues are all visual in that video. What I'd like to know is why bug reports are coming in for an outdated version of this mod? We fixed that visibility issue a long time ago. There are still some kinks to work out, but the bugs that are being shown at that 9 minute mark and beyond are not something that we have a problem with anymore. The reason it spawned for all those parts is that we'd set it up as a vessel module, meaning is was not directly attached to a single part on the craft, but rather the entire craft. However, this also meant we couldn't restrict it to just crafts with a KF repulsor unit on it. Instead, we have now moved it back to a part module, but it is added to the root of the craft when the flight scene is initialized from the repulsor modules, so it should only affect repulsor enabled craft. - - - Updated - - - Granted, alright. Still, your issues confuse me a lot. Yeah, I get strange rotation sometimes, but the only time I ever had a wheel refuse to work right was when I had accidentally attached another wheel to the surface of it. Np, wait... there was one other time, but I attributed that to simply having too many wheels in strange configurations on the same vehicle.

How very vague of you. - - - Updated - - - You do realize wheels work better on a solid surface, don't you? Beyond that little detail, I have absolutely no idea why this is happening to you. I never have these kinds of problems with my builds.

That would definitely explain why I'm not getting the expected result from my Kerbals in command seats. Oddly enough, it doesn't always short circuit this mod. It seems to mess with it when there are multiple seats that need to be populated though. It might come down to timing of the activity when the scene starts, where AGX is trying to initialize something at the same time and causing Take Command to silently fail.

I'd also like to point out that the weird water slider collider thing when moving from land to water or the other way around is still present. We need to figure out how to keep that collider in a horizontal orientation during that transition. (Referencing that pic, posted a while back, of the visible collider sticking up out of the water on the shore.) As it is, every time I test a repulsor build I end up upside down once the turbulence of the transition from land to water settles down. In other news... I think I'm going to stick with a default of 2 for the smooth speed multiplier in the precision-mode toggle I'm working on. This will, of course, be a module setting for the configs so we can tweak it to fit each part specifically.

Ah, so you're experiencing that too? I thought lo-fi killed it, but it's back! The suspension step actually won;t be in the editor anymore in the future, but it'll be found in the KF GUI. This controls the amount that the suspension height is increased/decreased when using the action groups to change the suspension height. feel free to mess around with it, but know that in the future it will be a GUI option rather than a part option, and will be much more stable. Oddly enough, the rotation thing calmed down for me after a while and only seems to do anything in certain situations. I'll have a look at the commit history and see if I can figure out what lo-fi tweaked to fix it last time, but we're still at the mercy of lo-fi releasing another update. I was actually hoping that he'd address that before releasing again.

I wonder if that's also the cause of the strange rotation under power bug I've been experiencing again. Also, if speeding up the smoothing also increases the accuracy, then I have an interesting idea as to how to implement a toggle for it. As you already know, KSP has a precision mode for things like RCS and throttle control (supposedly, I'm unsure if I've ever used it myself). So, if we could tab into that and toggle a bunch of limiters/enhancers when KSP goes into precision mode, we could reduce the need for specific action groups. I'm not saying an action group to toggle a precision mode wouldn't be useful, I'm just thinking if the feature already exists we could easily just tap into it. The idea would be to boost the smooth speed, while reducing the turning speed so that slow and precise adjustments could be made when KSP is in precision mode. We could also add a GUI option to enable a precision mode override for the KF parts alone. This leads to another idea I had a while back for an "overdrive" mode which would basically increase resource consumption a ton while boosting the speed of the craft a ton for a short time, sorta like a nitro boost. That was also a reason to try and get a spark emitter integrated to simulate pushing the parts to their maximums. On that note, I tried to implement occasional sparks to the Screw drive like I was talking about, but could never get the sparks to actually emit. EDIT: I'm getting close to a workable precision mode toggle both by the stock precision mode and by an override via action group. Exactly how much to modify the smooth speed modifier by is the next question, but that will be definable per-part in the end. Currently working on fixing my stupid code that would double the smooth speed, but would keep doubling it until it hit infinity. On the up-side that test showed that a value of "infinity" would not spam errors and actually work still. I'll run another test when I get done later and commit it to github.

Oddly enough, I just looked at my gamedata directory and noticed I still have that old mod installed. I just don't do nearly enough docking procedures to see if it still works. Now, what would make this even better would be if the docking ports were remodeled for the appearance that the smaller docking ports would open up along with the larger port's "doors" (so to speak) when the docking procedure was complete. Also, if one could activate a docking mode for each of those specific sizes that would be accompanies with an animation where, if the size of the port was smaller than the others, it would animate outwards both providing a bit more clearance from the rest of the docking structure and visually differentiating itself from the rest of the possible ports on the part. But that's just me dreaming again...

So, I was doing some testing last night and that strange rotation while roving about still exists to some extent. It seemed to subside after a little while, especially when I got up to speed a bit more, but at slower speeds it was still noticeable. In other news, The debug options thingie works, but the debug option itself does not. I can set the variable for whether or not to show the collider for the water slider, but it doesn't actually become visible when setting that. While typing this, however, I started thinking... if I'm changing the value of something that happens in the startup procedure, then it would all make sense. I probably need to be changing things in an update procedure. That would make more sense. I think I re-fixed the repulsor lights turning off when the repulsor becomes inactive. Had to insert a check for the ride height of the repulsor into the on/off state of the light itself.

I really don't have all the answers myself, so we'll have to wait for lo-fi to give us the real answer. But, essentially, yes the numbers represent speed and angle. However, float curves are used in many different applications and so I have attempted to define them in more generic terms. For instance, if brake steering were a "speed to turn angle" type of thing, then it's basically saying that at zero speed, no turning, and the higher the speed the more turning you get. That simply is not the case. For torque steering, the more accurate way to describe it is "torque to turn angle" and not necessarily "speed to turn angle" and in the case of that curve, it doesn't account for both directions but simply uses the same angle for both turn directions. The reason for the extra detail in the brake steering I believe is because it needs to somehow balance the effect since, essentially, you're braking one side of the craft slightly to cause the craft to turn. I'm a novice at all this stuff though, so I make not be on top of things very well. I generally leave those curves alone. I've been known to dabble in the torque curves, but that's it. I'm absolutely clueless about the four-part curves. As for units... your guess is as good as mine. I always figured that it's all relative to whatever unit it's manipulating in KSP. For speed, it's a 1:1 relationship with m/s. For torque and braking force, again it's going to be a 1:1 relationship with the KSP defaults. To get a better idea of what is what, you'd have to look at what Squad put into the stock modules/parts and scale it from there. There's probably a detailed explanation of units and how they are represented in KSP and how they're scaled from the real-world counterparts, but I don't know where to look really.

It's not necessarily broken, and there's a toggle now for editor transparency since a lot of those IVAs were rather hard to work with in the editors. Frame rate goes from 30s to single digits with just one simply window transform and a bunch of RPM props, or it goes into the decimals with something like the ERS rover cockpit. I think it's part of the main RPM distribution now.

There are two types of steering curves: brake and torque. Under torque you have two numbers per key which represent craft torque and turning strength (correct me if I'm wrong lo-fi). The higher the torque, the lower the turning strength so you don't end up flipping your craft over. Brake turning is similar, except that you have a positive and negative side to the curve which represents a balance between the direction of steering. positive represents one way, negative the other. Which is which is a mystery to me. Either way, the effect is much the same. The first number would be the braking torque and the second would be the turning strength. So, if you wanted to increase the turning strength for higher torque ratings, you could simply increase the second number in the torque steering for each key's first number, and in brake steering you could simply increase the value of the absolute of each side of the curve (leaving zero alone in the middle) and that would likely do it. It's not the most intuitive thing, but it's not hard to figure out with some fiddling.

I think you mean the RPM mod's transparent IVA, right? Texture Replacer has no feature like that.

I used the MagicSmokeIndustries sound effect for it. Kinda strange downloading a sound-mod that doesn't even have a sample sound effect. I couldn't find anything for the other defined sound so I just set it to an empty sound file I had hanging around.

Okay, weirdness ensues! So, I got a working slider into the GUI that rounds itself to the nearest whole number (so we don't get change rates of 2.0012658701 or ride height, which would be nuts.) and it all works great... except if you select a number that isn't within the rule of fives (5, 10, 15, 20, etc...) in which case it does some really strange stuff. One such effect is that not all the repulsors will update. Another is that they will all update, but instead of changing by, for example, 2 they will instead change by 5. On one occasion I even managed to mess it up enough that instead of the repulsors turning off at height of zero, I had to hit the button once more so that all the height sliders reported -1 before they would shut off completely. I do, however, have a theory as to why this is happening and I think it has to do with the context slider that is attached to the ride height variable. Since the KSPField that contains the slider for the context menu is set to an interval of 5, then setting a requested interval of anything other than a rule-of-five will either fail or have varying results because it is trying to limit the end value to that interval. I thought, before doing this experiment, that the min/max ride height was a free slide between those two values and the interval would only affect the change rate. Instead it actually locks the values to that interval in relation to the min/max. That's why the old implementation of this feature worked, because the interval for the field was also changed to match on every part on the craft with that field present on it. So, I'm hit with a bit of an issue. KSPField sliders can be set to an interval like that, but GUI sliders don't have such a feature. I can set the value to round to the nearest whole number (nearest int to be precise, but it seems to work for any data type that takes numerical input) but I have no way of rounding to the nearest 5th int. Alternatively, I could change the context slider to take intervals of 1. Second alternative would be to actually set the sliders for every part on the current craft to match the interval in the GUI, or do the opposite and have every part check on their fixed update (or whatever is available) against the persistent variable and reset their sliders to match. in the end it may turn out to be more hacky than the original implementation, but with some fiddling I'm sure I can get it to work properly. If only we had a "Mathf" method similar to "Round(float x, float y)" to let me round the value x to the nearest y then this would be so much easier. That would also let me make your dust amount slider a little more friendly by rounding to the nearest 0.25 since the current huge decimal is a bit of an overkill. In other news, I couldn't seem to get the repulsor lights to turn off no matter what I switched on or off. I think something got broken somewhere down the line in our frenzy to fix that dusty bug. EDIT: Great Jebediah's Ghost (and he ain't even dead yet) I think I've got it! I'm not ready to share the details, cause the math is rather... for me anyway. Besides, I think I can merge my two extension methods into a single method... and that should fix all our problems... at least in relation to this post. UPDATE: It all works. I added a new method to the Extensions class that allows me to round to the nearest nth numeral. What this means is that we can round to the nearest 5th, 10th, or even the nearest 0.5, or 0.25, you name it. If the number to round to is between 0 and 1, then it simply multiplies that number by 10 and treats it like a divisor. Otherwise it treads the number (1 or greater) as a multiplier and then does the rounding process depending on which (divisor or multiplier) has been determined. So, to round to the nearest 5th, you enter 5 into the "roundto" parameter and it does something like "Math.Round(num / 5) * 5" which outputs the "num" rounded to the nearest "5" value. For a decimal round it's more complicated. You enter something like "0.25" for "roundto" and it first detects that we're dealing with a decimal level and it multiplies that by 10, which doesn't eliminate the decimal but it makes it easier to work with when dealing with the standard "Round" method which only rounds to the nearest whole number. 0.25 * 10 = 2.5. You end up with something like "(Math.Round((num * 10) / 2.5) * 2.5) / 10" which outputs the nearest "0.25" to the input "num." I've done each of these calculations with over a dozen input by hand (okay, not quite by hand, but using "calc.exe" step by step) with over a dozen different "roundto" targets with perfect results, so I've integrated the new method into the GUI sliders and, from what I can tell from testing it thoroughly, all is working perfectly. It's a relatively simple way of duplicating the functionality of the context-menu sliders (at least the interval/min/max parameters of them). I'll be committing the new stuff shortly. Work on an unfolding debug menu to attach to the GUI settings menu is still a work in progress, but I think I'm close to the solution.

I'll get to work on something like that as soon as I can and we'll get this on/off business buried. I'll do a little research on some of the mods I use which feature remapping for keys as well, which could help with your little numpad thing. - - - Updated - - - The repulsors currently generate dust without even moving, though that's just a hack where the speed is replaced with the repulsor force. Still, it can be done. Alternatively you could just put your own plugin together for it. I'm not super attached to the code considering it started out as a totally separate mod that I didn't even make. All of our work is based on interaction with the biomes of a planet and a wheel-like object though.

It actually is related to KF since those white boxes are the water slider colliders (helps us make the repulsors work over water since water doesn't have the same collision as the rest of the planetary PQS crud). The odd thing is that it shows up on a non-KF part and is positioned above the ground. Normally it would always sit below the surface of the planet and only be collided with when the altitude hits below sea level. we're working on trying to get that worked out. As of the most recent version of the mod, the collider should only be active if a KF part is present on the craft, and it should be invisible (theoretically). Work in progress.

Alright, lo-fi, I've revamped the suspension increment slider, and revamped the positioning for the GUI elements so that everything fits correctly along with labels for the sliders that include a readout of the current value the slider is sitting at. Hopefully the slider in the GUI will update the interval in which the action groups change the ride height for the incremental up/down actions in real time. I have yet to truly test that because it's all been about GUI positioning. I separated out the first few elements which were applying to two scenes at once, so that now all scenes that show GUI elements now explicitly define all of those elements separately. This makes positioning thing in the window a lot easier. I still plan to look at GUILayout to see if that would simplify things, but this is good for now. I've also restored some of the configurations in the parts relating to DustFX that got overwritten during the panic over that stuttering bug. That includes fixing one part that ended up with two DustFX modules in it. That magnetic arm thing looks awesome. How is it controlled? Using keyboard input, or did you manage some form of mouse control? Or GUI? - - - Updated - - - I wouldn't put it past BDArmory having some issue somewhere that could conflict. All I know is that we handled our side of the problem which occurred even with BDArmory not installed. One thing I noticed is that during all of our code merges, somehow the line that makes that collider visible keeps being set to "true" when it should really only be set to "true" if you compile with a debug argument (we still need to separate some stuff into debug defines so we don't need to comment them out or delete them). So, even with a more recent release of the plugin, you can't guarantee that the white box won't show up. Somewhere down the line we might even think about building some GUI elements to activate debug visuals/readouts if a "debug" toggle is switched on.

Honestly... my first reaction was "what the fu..." Is this related to your wish to make a canadarm type thing with more fluid controls? Cause that's the first thing I thought of when seeing the second video.

Also, 10^99999999999999 is way overdoing it. 10^99 is the usual replacement for the imaginary number "infinity" which means, basically, you're asking for "infinity ^ 6" which is just plain nuts. Anyway, I'm going to start working on revamping my change-of-interval feature for the action groups using a GUI slider, and try to get some labels and whatnot to go with the sliders installed as well. You brought up a good point with the "parts getting out of sync" thing which, even though i accounted for that, has a few holes in it that I started to think about recently. - - - Updated - - - That's what we need someone to work on: adding friction to Kerbals. Also, I had a moment of thought this morning (scary, I know) thinking about climbing those statics and such. The easiest fix for that is on the model design side of things where objects that could possibly be climbed by a large wheel of some sort should have a sloping collider that the wheel collider can interact with. So, when it comes down to it, we can't really do anything about the inability for large wheels/tracks to climb these low obstacles... unless we were to build a bunch of dummy objects (like the one used to make the VAB helipad launchable in KK by featuring a plane that side below the visual surface of the pad and a collider that sits just above it) with the various inclines in the colliders that we could embed into the structures/features that we want climbable. I'm doubtful that there's any way to do that without the tedious task of placing everything by hand (unless we build the collider dummies with the same origin as the object we want to make climbable, in which case we just set it's location in a config to be equal to the visible object's location). So it's all possible, just not something we can do easily.

Well, if you'd just bow to my superior formatting and get in line with the rest of the peons of this world.... ugh, there I go again revealing my plans for world domination... never mind, move along, nothing to see here. I'm sorry, I'm just super nuts about efficiency and consistency. It's a sickness. As for the module index stuff... KSP is super nutty about things like that. MM usually takes care of re-indexing stuff and making it work right, so if you're not running the latest MM updates then you'll get some strange errors in the log from time to time.

For a proper race track you will need to develop some road parts to facilitate the transition between flat roadways and angled roadways to counteract the momentum during high-speed turns. You'll also need to further modularize these parts so that two roadways can be placed side by side to create a wide road, and provide options for variable lengths of curve roads for the inner/outer lanes of the curve. This is going to get complicated fast unless you can get some sort of procedural lengths/shapes built into this stuff.

argh, I tried to do a final sync with github and it's failing on me... again due to some conflict. I see something like "guiActive = true" turned to false. That specific thing that was made false should not be made false because it's a label. I added a label above the slider because the text on the slider keeps getting truncated too much. I wanted to at least have something above the slider to tell what the slider is supposed to be doing. I really need a break now. I'm going to loose my mind.

For that issue, my only idea is that we need some secondary colliders set up at angles in front/back of the main wheel collider that are set up to detect collisions that are above the main collider and let us bump the main collider up to match the new collider's level if the difference lies between a certain range that represents the height at which the wheel/track can grasp that object and pull the craft up/forward onto it. But what do I know, I'm just a humble dust coder. Those mole tracks should at least be able to climb over barricades that are below half the height of the part itself (if the weight distribution of the craft allows for it, anyway). If KK supported destruction events for things like fences or small walls, along with "destroyed" models for those objects, we might even be able to hook into that and make the tracks able to crush these small obstacles. On that note, one of these days we should see if it's possible to make really heavy craft with large, powerful tracks, able to destroy parts on smaller/weaker vehicles they drive over, if we ever get them to drive over other stuff at all. That would be awesome.

I had something in there to figure all that out, but I forget how it all worked now. I've scrapped some of that right now, but I'd really just like to integrate the entire setting with a GUI slider now that we have something to work with. That way I can keep it synced between all the parts. I'll leave the context slider interval alone (at +/- 5) and make the change only affect the action groups. I'll work on that later. My recent commit won't be entirely stable in that area, but it's not going to hurt anything. I'm starting to breathe again now that I've got everything merged up and I just committed what I have right now. I've totally deprecated the unnecessary variable that simply stated whether or not the dust was activated in the KFDustFX module. That one was left over from when I was converting from CollisionFX in which there were parts of the module that would work even if the dust itself was not activated. I forget now what it was called, but it's gone now. I need to take a nap now. I'm exhausted after all that work to get things back in order again. Like I said, they will make legends out of days like these one day. By the way, love the tests being done with maxRPM. I never tried setting it to anything insane like 40k. Must have been rather entertaining. EDIT: One thing I've discovered from all of my testing and whatnot is that totally "breaking" a save is actually quite difficult. Granted, I've never tried any of this with a career save, but I've been running the same persistence since KSP version 0.23.5 without issue. Yes, I've had to manually edit a few things to keep everyone happy in it, and I recently added Val into it by starting a second save and copying over the necessary data from the roster, but nother was every "broken" by any of this stuff. If someone is having issues with lag due to a part like a repulsor, then updates the plugin with the fix, the parts seem to get updated with the new state of things when they are initialized and the game is back to normal more or less. What mostly contributes to "broken" saves is when a bug like this is encountered and the user simply deletes the entire mod, parts and all. Then things start to legitimately break.

I totally missed that post, and so now I'm dealing with a compromise fix between the two "fixes" we both did, independently during the crisis the other day, that is giving me nullrefs that I cannot trace for some errant reason. The trouble I had, which led me to committing changes that fixed things back to how they should have been, was due to the fact that you did commit a change that included what appeared, at the time, to be like doing an ice-pick lobotomy on it. (Which, by the way, is incredibly easy to perform. If anyone wants a lobotomy, I'd be happy to experiment on them in my home. No guarantees over survival of the victim... err subject.) Anyway, that's all great. I just need to get a hold of that state of the source to work with so I can try to re-add my color variance to it. By the way, I totally don't understand what you're trying to do with the dust size. The reason it's set with respect to "tweakScaleCorrector" is because it's supposed to scale with the size of the part. It's not clamped to an adjustable maximum because I wanted to make sure that there was a maximum that it could ever reach so we don't get rocket-booster-sized dust when TS reports an extreme scale value and sets our variable way too high. I already have the tweakScaleCorrector set to 1 if the part reports that it is a repulsor, since KFRepulsor doesn't use tweakScaleCorrector for anything, but setting that variable to 1 from the KFModuleWheel class as well completely circumvents any interaction with the TweakScale mod. Besides, the variable in the dust module that sets itself from tweakScaleCorrector (and is also named the same, which was only confusing for a few days when I first implemented that) automatically defaults to 1 before searching for any other value. Besides all that, when you renamed that variable to scaleCorrector (or something like that) it never got changed in the rest of the calculations and so you'd be left with it trying to multiply it's values by a nonexistent variable. As for the slider for dust size and whatnot, I did that a long time ago so I could understand the different variables and what they did. That's how I got the information for the summaries about what represents what. I'm curious though... what does FIFO stand for? EDIT: just watched the video... adding a slider to the GUI was totally not what I'd done before. That's awesome. That adds the possibility of all owing the end user to also limit the dust activity for more refined performance control. Oh, and I forgot to talk about the other slider. So, I've tested that system a LOT and it seems to work without issue. I made a number of modifications to the current set of action group related methods and it's all quite stable. Basically, this lets you set the amount that will be added/subtracted from the ride height with every hit of the action group and/or when you side it with the ride-height slider (though, now that I talk about it here, I think I'll remove the change to the slider itself. That could get awkward.) I've already added clamps to the values so that if you're at, say rideHeight of 12, and pick an interval of 20, then it will try to increment the value by -20 and will clamp that value to the minimum (which is zero). Same with the maximum of course. I've fully integrated this into the repulsors and the wheels/tracks along with all the "apply" methods for both "apply to all" and "apply only to a single part" situations. This means it also works when using action groups to apply the settings across all wheels. However, to make things even easier to work with, it also checks the slider value on the update method and sets the new value for the action groups and slider on that update interval so that everything stays updated. Now, I realize there's a lot that could go wrong in there, but I've tested it thoroughly (at least, I hope I have) and it all seems stable at the moment. However, now that I may have a working example of a GUI slider in action, I may remove all of that from there and make it into a KFPersistenceNanager variable with a slider which will then apply to all action-group related activity, but leaving the standard ride-height slider interval completely untouched. This seems like a better way to do it overall, reducing the number of sliders on each part's context menu. The whole feature was created simply so I could make each press of the action group I set for "increase height" to increase by a larger or smaller number than the default +/- 5. I've also added preset levels for action groups, though I'm nowhere near being able to create user-specified presets like we can do in IR. In time all shall come to pass. - - - Updated - - - Found the post! That's really odd. CollisionFX doesn't have that field, it sets the effect in a hard-coded way. I have no clue how that became constant, because I know for a fact that no field should ever be constant. I'm guessing it's a left over situation from before it was a field at all. I made that a field when I discovered one of the other devs (probably you) had experimented with a different effect model. The only part which makes use of that field right now is the Mole track, due to it's massive size I set it to use the medium effect instead of the standard light effect. I really have no idea if it has any affect on the final output of the particles though. It was an experiment I never tested fully. Okay, so we need to get our code synced up again. I use a separate development directory from the github synced directory on my system, so I'd like to get the master repository updated with your current working code and then I'll merge anything I've been experimenting with onto that. This will go into the history books when future generations look up "major blunders made when overreacting to errors in code" since, as all of us KSP loyalists know, one day KSP will be the only physical simulation entertainment program in the world and we will be controlling our live (so to speak) spacecraft remotely from this platform. They will call us the founding fathers of modern physical simulation. Or it'll all go south in a year or two and no one will remember any of this at all. I'm counting on the former ending.