Gaalidas

Or they could just keep an eye on the release site (KerbalStuff) and read the change-logs there. This is a development thread after all. I figure we'd want to do something like that for a release thread definitely though. So, lo-fi... I know you're wanting to take a step back for a while, but I'm running into some major hurdles in attempting to expand our non-KF part conversions. The biggest of these hurdles comes from the lack of documentation as to what each of the parameters in the various modules does exactly. Some of them are self explanatory, such as the "Name" fields (susTravName, colliderName, etc.) but fields such as "moveColliderBy" in OverrideWheelCollider are not quite so easy to figure out, and "spring", "damper", and "mass", while not exactly hard to understand, don't come with any matching values in the standard part in which to make a guess with a new part conversion. In KFWheel, we have several axis fields which are a bit of a mystery as well. Any light you could shed on those would be awesome. The most confusing to me at this moment is the moveColliderBy field. I'm looking at these models and the wheel collider seems to be positioned exactly where the physical wheel is, which begs the question: "Why would I ever want to move it away from the wheel itself?" - - - Updated - - - Awesome, glad at least one person is benefiting from my update.

...IF using dds that is. DXT5nm causes it to become a pinkish-hued normal map and removes a lot of details from the map as a whole... at least in most cases. There are some outlying cases where the resulting normal doesn't get a hue change at all. I've found that highly-detailed normal maps, especially with vertical-line details in it, will loose a lot of those details in the conversion. You might get around that by making the normal map with the original texture already inverted, and using higher-detail filters like the Sobel 3x3 may also help. For some normal maps, I've had to resort to leaving them in png format to keep the finer details alive. However, if doing it the manual way like you described works best for you, all power to you. You can still save in the DXT5nm format, you'll just want to make sure your y-axis of the normal is properly oriented like it does when inverting the Y axis in the normal map plugin. I honestly don't understand it enough to explain it here.

I intend to. As for KerbalStuff... The mod page shows an accept/decline for co-authorship, but either it's my phone or the site won't do anything when I select "accept" so, I'll try again when I'm home again. Either way, I intend on packaging the mod up for an update relatively soon which should put most of the recently reported bugs to rest. EDIT: I now have the power! Well, some power anyway. Alright, time to sort through this package and get some stuff updated. Okay, I've released a new version of KF to KerbalStuff. This should be the most bug-free of them all... at least that's what I'm hoping for.

You've discovered the hidden Kerbal Ejection System. It was hidden for a good reason too... - - - Updated - - - That was one of my major turn-offs for the Honeybadger command pod. I like the immersion, even if I rarely actually pilot anything from IVA.

Who knew? alright, I'll look into it... Alright, I am now publicized. Bring it on you crazy world... -dives for cover-

Ugh, not again... -runs after it-

Actually, I never did register... at least I don't think. I never found much point since I didn't need to publish anything. I'll look into that. I as well have a hard time finding a reason to launch KSP these days at all, but the coding side of this stuff still nags at me to try and push the limits more and more, so I continue to struggle with it. Edit: Registered, same name as here. If you can do that co-author thing, I'll keep this baby fresh for a while longer. I've got a mental list of things I've seen done elsewhere that would be awesome to implement here, plus a lot of time on my hands to mess with code and what not. If it can't be done, I can always simply start offering update packages via dropbox or something.

That is really weird, and I was afraid that it might come down to that. I know I'm able to scale them on my install, so the problem isn't reproducible on my end. I sure hope you figure it out, and let us know what you find if you achieve anything. I might be able to compensate for a specific mod that somehow is disabling it for that part. The only other thing that might fix this is a new update of KF with my most recent upgrades to the scaletypes. I will continue to bug lo-fi about doing another maintenance update.

Gotcha, thank you. I'll look at the latest release package and get back to you here. I was pretty sure everything was set up properly, but mistakes do happen. One thing you can do to help, in the mean time, is to go into the KerbalFoundries mod folder and look for the "WheelSmall.cfg" in the Parts folder. Open that up and look for a module in that part that looks like this: MODULE:NEEDS[TweakScale] { name = TweakScale type = KFWheelSmall } If that is not present in the file, then that would be our problem. If, however, you do see that in the file then there's more going on here than a simply module definition and this all becomes just a tad more complicated. Update: I checked both the latest KF release, my local install, and even my MM cache and, in all instances, the TweakScale module remained intact on the part in question. Given these facts, there are only a few things that could be happening on your end. First off, the module could be somehow missing from your small wheel config. In that case, you could simply add the module with the code in the above code block into that part's config and you're good to go. Secondly, somehow the "NEEDS" check for the module could be evaluating false on your system. Changing ":NEEDS[TweakScale]" to ":NEEDS[scale]" would be more accurate and less likely to evaluate as false if you have TweakScale installed, but the folder name isn't being registered quite right somehow. Alternatively you could simply remove the entire ":NEEDS[TweakScale]" part of the module definition, since you obviously have TweakScale installed already. The third option, which is a very hard one to track down, is that there's an MM patch being run somewhere after it checks the part config's "NEEDS" field which is removing the module from a wildcard search of part names. If this is the case, there's nothing i can really do about it except urge you to inspect any configs that may have MM patches, and may contain wildcard searches within those patches, and of which may be removing the TweakScale module within any of those matching parts that it finds, and... well, disable them or find a way to exclude the KF parts from it. I really hope it's not the third option however, cause those are annoying as heck.

Actually, a few of the parts from Karibou might even be competition with Konquest, especially considering Konquest doesn't even have any WIP releases. Potentially one could call Karibou a hybrid mobile/stationary base of a sort with the landing legs and all.

Fair enough. It was just a thought. Either way, this mod could potentially (after it is renamed properly at the project level and in the module name itself) implement an option to run the animation simultaneously and then be released, along with any parts packages that come about (if they come about at all), as an optional "replacement" for your older mod via an optional MM patch that would simply swap out the module names. If, after a time, the mods that use your module were to switch to use this one explicitly, then you could pretty much pass the torch on and focus that effort somewhere else, keeping the source on the back burner in case this developer goes AWOL on us and a future KSP update breaks it. All just ideas though. My brain is always going on and on like that. (Disclaimer: the above paragraph is not actually geared towards the quoted individual completely, for an explanation, see the following paragraphs.) Also, you are correct to question if the entire post was directed to you. I tend to write my posts in such a way that the first paragraph after the quote is 99% geared towards the quoted individual, with a reduction of that percentage by roughly 33% of the previous percentage for each additional paragraph. Roughly speaking, that is. With each additional paragraph, the chance that anything I say has anything to do with the quote or, indeed, anything at all will continue to cruise towards an asymptote of zero... about 50% of the time anyway. If, by this time, you are becoming extremely confused by my above statements, then you need not worry. This is the intended result... well, about 24% of the time anyway. The other 76% is a random factor that I have yet to make sense of, but can find no reason to account for. What was I talking about again? I think I just lost my train of thought.

Oh I'm not sure that was the biggest mistake ever. While it worked out well in the end, the biggest mistake was probably letting me commit to the repository. I've surely complicated things a ton since I started contributing to this project. Anyway, I'll put the controller vessel module on hold for the time being, but I've still got this nagging idea in my head of how to better control when, where, and how any dynamically added module/component is used on a vessel and/or in its parts with a single vessel module that actively tracks the state of the vessel and reacts accordingly. So, I'll definitely be playing with that over time. It's probably born from a common trait amongst geeks known as a "god complex" which urges us towards a goal of "ruling the world" in which I am helplessly drawn. As for the unity animations and such, I'm way too lazy to figure all that out. I figure it should be able to simply set that up itself when the asset is imported into the project, just like blender is able to import it from the .mu file. Anyway, Unity didn't show me anything that I wasn't getting already in blender, I'm just too lazy to do all the work of trying to figure out what I should set everything to for your module to make it interact with a part that makes no sense to me.This is especially true if RoverDude did use some of your tricks. I could never make much sense of your parts either. I suppose we all have our specialties. Mine definitely is not in the modelling. - - - Updated - - - Give me a little more detail on the problem. First off, are you using the absolute latest release of TweakScale? What is it you see in the part context menu? For example: Do you get a blank spot where the TweakScale controls would normally be in the part context menu (as in an actual space that has nothing in it), or is there simply no option for it on the part at all?

Perfect, now all questions are answered. The question remains now: is it really necessary to have both mods that do the exact same thing in existence? Perhaps a merger is in order, along with some new development into a series of decouplers based on stock decoupler parts with animated parts to be released alongside the plugin. This would effectively transform this from a developer-mod to an end-user mod. - - - Updated - - - Perhaps there could be a boolean field made available to make the action happen simultaneously. That way this module could effectively be a replacement for the previously developed animated decoupler module while adding the extra feature to wait for the animation before decoupling.

This thing really needs to be made usable with the JSITransparentPod module. I really wish I'd held on to that hood ornament. Now I have no idea where to get a hold of it.

Actually, that part went in a while back, when we did our first 1.9 release. I'm hoping for another release soon to address some final bugs and introduce a few more useful features/fixed features I've been developing. So, lo-fi, just I wanna get you on the same page really quick. I decided, locally, to extract the two classes in VesselTools into two files named after the classes in it. This has made it a bit easier to keep track of what is doing what, which in turn made it a lot easier to keep track of what was happening with the water slider. I'm still unsure if it's still spawning a new slider in mid air for missiles and such from BDArmory since I really don't use most of the features of that mod on a regular basis. If that little bug is actually not present in the current code then I won't need to continue with my vessel module experiments quite so seriously right now. Otherwise, I think I may be close to a way to regulate what is running on what vessel at all times with little chance for errors. So, if there's no objection to splitting those classes into their own dedicated files, I'll go ahead and commit that part at least.

Please note that we are in no way saying you aren't going blind. For that you should seek the professional help that only a certified medical practitioner can provide.

I had no idea I could actually do that. Huh. Interesting... Scratch the interesting part... at least in blender I can see the animation. Can't hold on to that when I bring it into unity. Otherwise, unity actually makes it harder due to the camera controls and such. Still doesn't help much at all. RoverDude sets up his parts in a completely different manner than I've seen any other parts set up, and it definitely doesn't make it easy to figure out what is what.

I would say this is awesome... but without an example part that makes use of this, it's hard to really see the awesomeness of this thing. I can imagine anything from a simple set of clamps being decoupled before the stage is separated, all the way to a complex set of animations such as a petal fairing opening up, the payload being raised out from the rocket with a series of arms, and then the arms detaching from the payload, followed by the official separation. Most addons are built for a purpose however, and usually in response to a need that isn't being met with the stock modules, which means you likely had an example part that assisted in the development of the added functionality. This part, if it exists, would be useful in showing off what this addon is made to do.

With some work someone might be able to implement a stand alone unity-based tool to edit a craft visually outside of the entire KSP package. An outline-style would be more realistically doable though. I know that other tools in the past have been able to parse the craft files and/or the persistence file to offer a "directory structure" type view for each part/scenario/module present in the appropriate file/node. I can't remember any names though, and they'd all be older than "Jeb's stash of snacks in the basement" in kerbal terms. For reference, he started hoarding snack boxes when the KSC was a wooden shack with a rocket nose-cone sticking out of the roof. Come to think of it, there was a fire that destroyed that building. No connection could be made with the recent rocket launch from within that building could ever be discovered by investigators though. Anyway, it's all doable, just not all that "easy" in any form of the word. Part replacement would definitely be an awesome feature. I find myself wanting to swap out wheels for different models all the time and with the relatively newer offset editors it becomes very easy to fix positioning issues from differently shaped parts.

"nawball" = new prop for rovers that acts as a form of "stress reliever" wherein a Kerbal can relieve his/her stress by chewing on it. Optional taste-enhancers are available with tasty flavors such as Hearty Meatball, Veggie Surprise, and our brand new Kerbal Snack flavor.

I had a look at his model via import to blender. Compared to even the ERS wheel, this thing is crazy complicated. I simply do not have the brain power to sort out what objects in his model would correspond to what in a stock wheel, and thus no clue how I would set it up compared to the configs that already exist for the stock wheel conversions. As for any animation hiccups, I have not experienced them. Either he already fixed it, or I'm just not picky enough. I also noticed something not quite right about the ERS wheel conversion. In all the other stock wheels you always destroyed the broken wheel object, but in the ERS wheel you didn't. Not that it really matters, however. The busted wheel object isn't really visible, and KF wheels don't get damaged.

Just discovered a new wheel we need to look into converting: the USI Karibou Expedition Rover wheel. That wheel looks awesome, but I can't bring myself to ever use it with the stock wheel modules.

I would think there might be a way of detecting the kerbal ... and applying a modifier to the positioning via a plugin, but no clue as to how at this moment. Not that this has anything to do with the original topic...

Overall it looks promising. Controlling whether or not it happens from a part module is also something I could see working rather well. How I would do it, however, would be to create two modules (technically anyway) where the first would be a part module containing KSPField variables for the varying settings that could be applied to this new camera. That would allow you to define the module in the part.cfg (or whatever it's called for that specific part) and apply any part-specific settings, or add some context menu sliders. This would also make it easier to make the camera override-able from an action group, in case you were using this part on a craft that was exploring a non-atmospheric and/or non-oceanic body with landmasses that dipped more than 5m below what would be called "sea level" for that body. The fact that such things could be detectable in code later is irrelevant here since we want to leave control in the hands of the user when selecting how they want to view their craft. This first module would also be in charge of monitoring the current situation and whether or not the camera should be in underwater mode. Finally, you would need to add a detector for the current body which finds out if the planet has oceans and, if that returns false, to remove the second module from the root part dynamically to eliminate it from taking up system resources constantly checking that the camera is being properly manipulated. The second part module would be one that is added dynamically to the root part of the vessel, if the body checks out to be oceanic, by the previous part module and will then call forth the settings from its creator module and apply them to the camera, including whether or not to make the switch to or from itself based on whether or not the override action group is active. I might also add the override action group to this module as well, just in case the controller module/part is detached from the ship in flight. This second module will handle all the actual camera work and the maintaining of the camera angles. Looking at the stock KSP code (using something like ILSpy to decompile it into a C# format and doing some digging) you should be able to find out how they calculate the Center of Mass, but I believe KSP probably already provides a method somewhere that would do that for you. If neither of those searches reveal anything, you could always look at the source for other mods that deal with CoM, such as mechjeb or RCS Build Aid (I butchered that name I think). You should then be able to make the camera look at that target with "cameraname.transform.LookAt(vector3 lookat_target)" where "lookat_target" is then the vector3 of the center of mass for the current vessel. In fact, looking at the code just now, I discovered a stock vessel CoM detector in "GetComponent<Vessel>().CoM" which returns a vector3 for the current vessel's center of mass. It's all quite complicated, but also rather powerful if you just do some digging around in the stock DLLs. That's just the approach I would take. You could also use a vesselmodule instead of a partmodule for the camera code, but vesselmodule objects are then added to every craft no matter what, so you'd still want some form of controller part module on a part, or added to control parts/command pods/Kerbals (when sitting in a command chair) to set an active/not-active field somewhere. If you managed to get everything stable enough with the code to auto detect if we are indeed under "water" and not simply below the reference body's "water level" then you might be able to simply eliminate the part module and run it as a vessel module, added to every craft from the get go, and make it more or less seamless. For end-user options you could then either use a GUI like we do in Kerbal Foundries, coupled with a config file in our mod's root directory (and an entire Persistence class that was ingeniously built by *Aqua* (the asterisks are part of his name, not punctuation)), or you could re-add a part module that could optionally override default settings in the vessel module if the part is detected on the craft at startup. Eventually you'd want to see about making it compatible with any other camera manipulating mods, the easiest of which would be to simply set an override to disable your mod's camera modification if any other camera modifications are currently active, but still monitor the vessel situation so you can re-active when the custom camera is toggled back to the standard camera. You have been the victim of one of my famous "walls of text." It's an honor, really... if you survive it.

I suffer from thick-headedness as well. Eventually things will fall into place and you'll experience that euphoric "enlightenment" phenomenon which, unfortunately, will pass quickly and probably never return.