Gaalidas

This is just the beginning. You ain't seen "out of control" yet. Well, actually, you probably have if you've looked at Smokescreen... but we're more chaotic in that we're covering multiple subjects at the same time, where Smokescreen is just about particles. Still, I'm nowhere near the level of customization control that that mod provides. Still, I intend that anything I write for KSP will, in the end, be able to be overridden in almost every way possible at the part config level. It's an ambitious goal, but I think I've made excellent progress as it is. lo-fi... I wouldn't say all the "behind the scenes" stuff is out of the way. I've got some cool stuff going into the code soon. In fact, I already committed my changes to allow changing the interval by which the slider and action groups can change the ride height, and I have plans to add specific levels as action group options as well. So, in theory, if you wanted to hit one button and go from a height of 20 to a height of 80, you could accomplish that. Lots more little convenience stuff like that in the works.

More dust you say? Well, you're in luck. Many of the parameters in the code can be tailored to fit your style. I will list all the available fields now along with their default values: minScrapeSpeed = 0.1 This is the minimum speed that the craft must be going to produce dust. (float) minDustEnergy = 0.1 This is the minimum energy rating for the dust calculations. (float) maxDustEnergy = 1 This is the maximum energy rating for the dust calculations. (float) minDustEmission = 0.1 This is the minimum emission value. (float) maxDustEmission = 20 This is the maximum emission value. (float) minDustSize = 0.1 This is the minimum size of the dust particles. (float) maxDustSize = 1.5 This is the maximum size for the dust particles. (float) maxDustEnergyDiv = 2 This is an energy divisor used in the dust calculations. (float) maxDustEmissionMult = 2 This is an emission multiplier used in the dust calculations. (float) minVelocityMag = 2 This is the minimum velocity magnitude for the effects to occur. Magnitude refers to both the speed of the vessel and the speed of whatever the vessel is colliding with which, in the case of a planet, will likely be close to if not exactly the same as the standard "speed" rating. (float) dustEffectObject = "Effects/fx_smokeTrail_light" This is the actual effect that is used. An alternative that was used for a short time is "fx_smokeTrail_medium" which is now being used for some of the larger parts, though I have yet to test if this makes much of a difference. (string) isRepulsor = false Set to "true" if the part you are attaching this effect to is a repulsor. This enables some extra effects that are special for repulsors. (bool) isScrewDrive = false Same as the above, but for the screw drive. (bool) (This field is not yet ready for use.) In a future update to KF I intend to add something more specific to a few parts (mainly the screw drive) to create the effect of sparks flying out occasionally. This feature is not yet ready for the public, or even the rest of the development team, but that will also include a number of configurable fields for just about everything that goes into the calculations. Before I share what the calculation looks like, so you can get a better idea of how to use these fields, I want to talk about the rather vague particle emission fields from above such as Energy vs. Emission. From what I have gathered from testing the various variables in the particleEmitter class is that Energy represents the apparent "thickness" of the effect and Emission represents the maximum particles to produce per second (not real time, based on the time scale of the simulation which varies quite a bit sometimes.) Now, using all of these fields to tune the dust can be a challenge when you have no idea how they are used. So, I'm going to display the code that uses these fields below: maxEnergy = [COLOR=#004085][B]Mathf[/B][/COLOR].[COLOR=#191970][B]Clamp[/B][/COLOR](((speed / [I]maxDustEnergyDiv[/I]) * [I]tweakScaleCorrector[/I]), [I]minDustEnergy[/I], [I]maxDustEnergy[/I]); maxEmission = [COLOR=#004085][B]Mathf[/B][/COLOR].[COLOR=#191970][B]Clamp[/B][/COLOR]((speed * ([I]maxDustEmissionMult[/I] * [I]tweakScaleCorrector[/I])), [I]minDustEmission[/I], ([I]maxDustEmission[/I] * [I]tweakScaleCorrector[/I])); maxSize = [COLOR=#004085][B]Mathf[/B][/COLOR].[COLOR=#191970][B]Clamp[/B][/COLOR]((speed * [I]tweakScaleCorrector[/I]), [I]minDustSize[/I], [I]maxDustSize[/I]); "speed" represents the current vessel speed over the surface of the planet. "tweakScaleCorrector" represents the current scale value produced from the TweakScale mod. If Tweakscale is not installed, or there is an error produced, then this variable will initialize as its default of 1. In the Clamp methods, the various inputs are Expression, Minimum, and Maximum respectively. This effectively clamps whatever the expression puts out to the values specified or calculated in the min/max parameters. Hopefully this gives you all a better idea of how things are done right now. I hope to expose even more to the configs as time goes on and new features are added. I also still intend on making a version of the module that will work on non-KF wheels (as if any of us would go back after seeing these ones.)

It's definitely not a huge priority. Whatever offset there is seems miniscule.

So, it's sorta like making landing gear made specifically for a certain part shape and orientation, except that this "gear" is technically a separate object that, I would assume, properly configured and oriented parts could then settle down on, and be locked into place with, the "cradle" so to speak. Interesting. Providing, at the very least, a template model with an example config for a properly oriented and configured "module" for the rack would help other modders make use of this. From the image, however, it looks like orientation isn't necessarily required to be horizontal. For instance, the second building in the first image is oriented vertically (despite the height of it being almost identical to the width, which would beg the question "which is height and which is width?") and that will be the trick: how to configure the part to accept connections from differently-oriented modular... uhh... modules.

Wait a sec... You can do that? I always had to search for the root part and select that. This game really needs a manual.

Sounds to me like a memory problem really. KSP is somehow freaking out between starting the scene and moving your focus and/or craft to the correct launch position/vector. Reminds me of back when I was playing Morrowind and installing random mods all the time. There was a spot in the outside world that was considered the "center" of the massive collection of cells that made up the game world. If a mod tried to teleport you to a position in the world that the scripting system could not get a reasonable return from the locational awareness engine, then it would spit you out in that "center" spot. My guess is that KSP goes through several passes before it lets you see anything in the flight scene (abstractly in order: instantiate assets, get universal body params, initiate on-rails physics, set positions of said bodies (crafts & planets included), apply velocity vectors, apply lighting params, retrieve new ship params (parts, persistent params, launch vector and coords, etc), create said ship, attach camera center to said ship, sync vessel with assigned launch vectors for the assigned object (the static object that corresponds with the launch position/vector requested), activate local camera, call event that says "we're about ready to start", initialize physics/IU/control schemes and key assignments ...) Well, we all know what the rest feels like. If KSP runs out of juice (memory) during one of these operations, it may throw an exception and, if the operation is not flagged as a critical one, it may simply move on to the next operation that does not rely on the class that was running the previous operation. Instead of reaching your final launch position with everything active and working as well as your awesome (or pathetic) building skills allow, you end up in the middle of nowhere, with non-functioning UI and key assignments, and incomplete physics initialization. Game then starts trying to process new information from the flight scene that is not initialized (correctly, anyway) and wracks up a bunch of errors that it cannot express because it's out of juice and ... the picture is much like if you were to take an Egg in a sealed jar and increase the pressure inside said jar until a complete implosion occurs. Then burnt the remains... twice.

We can hope, but realistically it will likely only make memory management worse. With every major update, this "game" has become more and more memory intensive.

And... if you find a good balance of the tech availability that you would like to share, please do. My quick and dirty CTT hack-up could use some more attention.

Stock toolbar button is duplicating itself. You need to add game object destruction methods and add them to the various events that would lead to a scene change or scene reload.

At the very least, allowing Kerbals to walk on surfaces that are meant to be level with the gravitational center of a celestial body should be doable (considering someone already managed a long time ago to make floating craft walkable) but it looks like walking on the surface of space stations is going to be a long process. My suggestion would be to at least get the first part of the features working (that is, reproducing the effects of the sea-sickness cure mod which isn't actually available anymore from what I can tell) and work on the rest later.

Yes, I'm to blame... errr... I take the credit for the original implementation of the DustFX for the wheels, but in the end it has been a group effort. I'm not done yet with the dusty side of things though. I intend on slowly reimplementing various effects that already exist within CollisionFX, which is the mod the dust here is based on, and possibly a few new ones to further enhance the illusion of interaction between the wheels and the terrain. Lots more to come in the future, assuming I can pull any of it off. I just knew it was going to be a hit when it hit the public.

On the water slider thing, I was looking at the code and it's possible that the water slider is being activated somehow whether or not "isReady" or "isActive" is true. Either way, I don't see how it could ever collide with anything since it sits below the surface of the planet/water. In other news... A few features that I am working on which I may be able to get out in a future "bugfix" release include the ability to set the interval value for the slider and/or the action groups that control the ride height using a slider of its own. Also looking into adding some action groups that set ride height to some specific presets such as 0, 50, or 100. On the drawing board are functions that assist in smoothing the transition between ride height levels for the repulsors so that, for example, you set your ride height to 0 when you're currently at 100, it will slowly descend to 0 instead of just dropping the craft into the dirt. I'd like to equip the low-power cutoff with a slow descent as well, perhaps lowering the maximum height slowly as the power level of the craft reaches certain percentage-based thresholds. lo-fi might be moving on to models and textures mostly, but I'm still not bored with the code yet.

ModuleWaterSlider only runs, from what I can tell, when the craft has a part on it that contains the KFRepulsor module. It's basically this giant collider that updates its position periodically when the repulsor equipped craft is near/over water. We had to do this to make the repulsors able to work over water due to some weirdness in how KSP handles collisions with the water surface. If your craft has no repulsors on it, you shouldn't have any interaction with that. However, I wouldn't put it past having issues if you have another craft in the scene, possibly within physics range, which is equipped with repulsors. As developers, we are incapable of fully testing everything because we are blinded by the same thing that makes mothers love their babies no matter how ugly and smelly they are. That being said... I have no clue what the module really does under the surface so you'll have to wait for our fearless leader to explain it and figure this out. - - - Updated - - - Craft weight is now taken into consideration when dealing with torque and whatnot. That being said (I say that a lot) the balance of these things needs to be tweaked a bit here and there. That's why KF is still considered in Beta. You could try adding more wheels to the rig to help support the weight, but in the end we're going to have to do some tweaking to the part configs to make them all live up to their expectations. - - - Updated - - - Hah, you'll get it eventually. It's not the jump that's the problem, it's the landing that you gotta deal with. In the end, repulsors handle them about as well as wheels would. Wheels that are incredibly tall, have no wheel model, and contain lots of tricky code to make them behave.

Interestingly enough, I remember that the spot where the cannons appear is the place where the original had the small doors that opened to reveal the retro thrusters. You should create a pair of retro thrusters in the style of XanderTek's Landertrons using BD's animation plugin for auto deployment. Just need to create a little cutout in the front of the wing near the hull for them to fit into. Also, to be true to the orbiter original, you need to add the retractable radiators.

That's definitely a water tower.... or is it? mwahahaha...

That's appreciated. I hate having to go back to the space center to change options.

It's a situation where the fields are available to the PART node, but their default values are used when the config has no definition for it. So, technically, even if you can't see it, it's still there once the game compiles the part. - - - Updated - - - Lets see... without actually looking at this config myself... If there is an EFFECTS node, you could first try removing that. Of course you would also have to find the parameters in the engine config that reference the effect names that you are removing and comment/delete those lines too. As long as you don't remove anything that controls the function of the engine module you'll be fine. That all assumes the APU is still using the engine module to hack together the necessary throttle control for the APU to function.

So, I'm having a bit of an issue with the camera extender. When in the SPH, the camera jiggles when trying to adjust the height of the camera (usually with the mouse wheel). As such, I really can't use it. Unfortunately this is one of those issues that comes with absolutely no errors or anything because it thinks it's performing as intended.

Getting back on topic as ordered!

Unless he welded them manually, in which case those instructions are not really accurate.

KSP has two logs because it's weird that way. There's really no other explanation than that.

That's really weird. I have no idea. I know lo-fi did some model exports and such which could have theoretically bumped something in the wrong direction. I do know that I've fiddled with engine placement using RCS-alignment mod and took note that under certain circumstances it would show some odd miniscule torque that shouldn't be there under certain symmetry situations. Therefore, either this is a RCS-alignment mod error, or a KSP error. Both cases are uncontrollable by KF. I wouldn't put it past something else changing, but I have no way of tracking that personally. That would be for lo-fi to look into. I think he's gone into hiding though, so we'll have to wait for him to rise to the surface of the proverbial watering hole. Also, you don't actually need to use the APU, it's just there if you do. I rarely use it myself.

There's a 2015 beta for Orbiter? sweet. I haven't looked at that simulator since getting KSP... a year or more ago... I'm way out of touch.

One thing i just experienced. I had this rover which contained a regular Mk2 command pod on the front, but a pickup-bed type area with two command chairs. The two command chairs did not seat the kerbals properly. Instead, when the rover spawned, the command chairs were "containing" the kerbals within the generic IVA you stuck on them. I had to EVA them manually and set them on the chairs. It did leave to an awesome kerbal ejection though when I seated a kerbal on a chair that was containing another kerbal, then hit EVA on that kerbal. UPDATE: Okay, so now it seems that it's actually not working at all. Huh.

The first part with the hangar, if that was made into a complete craft alone, was giving me flashbacks from Wing Commander 3/4. It's about time someone other than the B9 devs made something huge out of those HX parts. I tried to make a giant space station out of them, but I still have yet to get it to launch without lagging up and crashing my poor laptop.