Gaalidas

Digging through the code didn't come up with much I'm afraid. I found this in both ModuleEngines and ModuleEnginesFX: [COLOR=#0000ff][B]public[/B][/COLOR] [COLOR=#ff0000][B]bool[/B][/COLOR] staged;This is set up as a persistent field in both modules, and defaults to false as evident by the lack of an initialized value in the code. Ordinarily, by adding to the config a line with "staged = false" i would think you would eliminate it from the staging; however, because the variable defaults to false, doing so would not actually do anything that the default setting isn't already doing. So... back to the drawing board I guess. Perhaps the staging toggles available in TweakableEverything's staging toggle plugin might produce more helpful information.

You call that "minor" damage? Half of its wings are gone at least, and it's lost all aerodynamics... minor damage my ... uhh... rear-end-of-a-mule... I don't know why, but I want to call it the "gaseous buzzard on acid." I know, I'm a bit weird sometimes.... most of the time... well, okay... all of the time.

I believe if that isn't set in the config, then a default is used if the part contains a staged module. I say this because there are a number of staged engines that do not specify a specific icon and still show up in staging controls. There may not be any way around the part showing up in the staging system without a plugin to force it to ignore your part. If there is a way to turn off staging in the stock system, you may need to grab a managed assembly decompiler and dig around in the stock modules to find it.

... you mean his **colorful metaphor referencing the rear end which relates to the word used to describe a mule/donkey in the old world** ? I would have thought it would have been somewhere between his keyboard and the relative direction of his ears... aka the gray matter... aka "the man upstairs"... aka "the ol' noggin"... aka the... okay, you get the picture. I do not recommend using your mule to design your vessels; they end up flying like an obese pregnant yak.

"But.... all the buttons are red. How do I know which one will authorize you, and which one will end all of existence in a huge purple ball of death? Hey... that gives me an idea... -pushes a random button- hey y'all, watch this!" - famous last words of an unknown KSC intern.

Me smurt! Me can speelll, me can fly... or do dat call "fall", hmm? ya, big gud brain me gotz! Oh, and son-of-a-motherless-goat those shots look awesome!

What he said... IF all of the things I mentioned are ironed out of course, which is all on the designer's end.

hey, everyone has their own definition of fun. Some of us aren't happy unless we're suffering. I still think my translation is pretty accurate though... at least, that's the story I'm going to stick to. After all, how could I be wrong when I'm just so awesome? All thanks to my great brain... ...Yeah, maybe I should have stopped after filling my head with hot air the first time. Oh, by the way... I'm not totally sure he was talking about "space engineers" but rather "space engine." Either way, I don't think "space engine" has a whole lot to offer in the way of actually flying spacecraft around (at least, not several years back when I looked at it) and "space engineers" is too block-based to ever have anything as smooth as this beauty. No, this is something that will only really work, for the time being, in KSP.

Hmm... one thing to pay attention to is whether or not the repulsors can actually reach the ground. We've seen cases where the repulsors were placed too high up on the craft and couldn't repulse high enough to work. Also, the extend/retract functions are poorly named, since all they do is increase/decrease the height. Also, the repulsors will draw energy if any of them are actually turned on, regardless of repulsion activity (I'm pretty sure of this, not entirely though) and with no regard for what parts of the graft might be having collision issues with the ground. You are right, however, that the repulsor field does mimic wheel suspension in that it responds not only to the height setting, but also to craft weight. Another thing to keep in mind is that even if a repulsor is as zero, there is still a collider under it that can still collide with the ground and, even when not actively repulsing, may scrape the ground even if the appearance is that the craft is hovering. so, check the repulsor attachment positions to make sure they aren't too high (if not using the surface attached repulsors) and, when in doubt, add more power and repulsor units to the mix and try again. You might also see if your logs are pumping out any errors while attempting to hover, but I have a feeling this is not an error with the plugin's function here.

Well, then... I guess they should have had one. If they'd has an APU on board, then the facts would fit our much-more-plausible illusions of what actually happened, which is obviously more entertaining than what really happened. Now that the truth is out, we're going to have to go through all the trouble of inventing a time machine, going back in time, and convincing the designers of the Apollo program to put an APU on board so that the tanks can blow up for the right reasons again. There goes my summer.

The Jack-O-Lantern has been done already, and so has Christmas-themed stuff. This is the Easter edition. Having those other parts in this release would be... well... down right wrong.

So, I love the alternate colors... but I really dislike having to choose. Perhaps a little research into texture switching would be a good option when you get back.

That's.... really nuts.... there are no more words applicable here.

Yeah, so I'm just a vocal supporter and side worker for this mod. I don't have any power over the distribution of anything. It's just an idea. I can't necessarily get you the source myself, but lo-fi has been rather cooperative with other addon developers in the past. Even without the model source, however, you could probably pull it off using the current configs and models as a reference. I believe they're not all that much different from a wheel, except that there's simply some form of transform instead of a wheel fixture. It may be more complicated than that, however, since I also know there are ray-casts involved in the KF modules. I honestly don't understand it well enough to explain it further. As the very least, though this is rather hacky, you could likely create your own part, then weld it in the config with a current repulsor model, then use a combination of the standard repulsor module along with lo-fi's object removal module to basically leave the repulsor functionality available while removing the visual aspect of the original model, allowing your own model to be the primary visual element. I'm not sure all of that even makes sense to me, but you can look in my signature for my standard disclaimer which applies to just about everything I say.

So, to translate... the final stage of the easy part is done, and soon you get to do the export/import and game configs... which is where the real hellish work begins. I don't think I'm being very encouraging with these words... but it's all I've got. Have fun... maybe....

Hah, I do tend to write big walls of text. The trouble with a patch that was amde months ago is that isn't probably way out of date as to the current state of KF. Modules and parts have been renamed and modified, etc. I'll have a look at it and see, though. My wall of text was more an introduction to what I am in the process of doing that will more or less fix the issue with wheels once and for all, without simply eliminating their potential for effects.

That was my plan all along. I really suck at landings, so one way to keep Omicron from landing too hard is to cushion the impact with some small repulsors. Besides, hovering a flying car over the terrain at a specific height is too much work with standard thrusters. What we need, really, are custom modeled repulsors that would fit the Omicron style and give them a specifically intended attachment spot on the hull of the vessel itself.

Indeed, I would agree that it's unlikely that KAS is interacting with the functioning of the repulsors on multiple vessels within physics range. I had a look at the source (from the source currently available on github) and I noticed that the repulsors seem to be taking stock of themselves and initializing the repulsion system when the flight scene is loaded, and not specifically when the vessel is set as the active vessel. This would likely lead to only the most recently loaded vessel (launched, or when loading from outside physics/visible range, I'm not sure if it's exactly physics range we're looking for, but whatever range defines the vessel unloading distance) having functioning repulsors. However, I also looked at the code for the wheels and they seem to initialize all of their settings in the same way so this isn't necessarily the root of the problem here. It's just my feeble attempt at finding something that could be an issue. EDIT: Had a look at the log posted above, and this caught my attention: NullReferenceException: Object reference not set to an instance of an object at KerbalFoundries.Repulsor.OnStart (StartState start) [0x00000] in <filename unknown>:0 at Part.ModulesOnStart () [0x00000] in <filename unknown>:0 at Part+.MoveNext () [0x00000] in <filename unknown>:0 Seems like this might be a problem. I believe that was one of the goals... that and making easy-to-control pod-racers.

I want to chime in on the tweakscale issues and mention that I have also noticed this and it's really annoying.

Right, camera angle is always a problem when figuring out what's going on in there. Looks like some promising progress it being made.

You'll want to leave a little room in case the engine has some gimbal action, but having the end close in around the nozzle really cleans things up a ton. I like to use procedural fairings on my rockets to encapsulate most of the engines on my rockets, leaving just enough room for the nozzle and some gimbal room.

I like the configuration of those engines. Certainly beats just having a few holes with some nozzles sticking out of them.

It's not meant to be a jet-ski simulation. In fact, the threads of the screw wouldn't propel you very fast at all, land or sea. - - - Updated - - - Ah, I thought I was seeing the awesome suspension stuff from the other KF wheels... but then they did seem a bit too stiff to be a KF suspension system.

Most likely you've discovered a bug in the way the repulsors are initialized into the flight scene. Interesting. So, let me get this straight... if they're within physics range, only the last craft to be launched/loaded functions. If outside physics range, they work as expected. Anything missing? My thought, without looking at the code, is that the initialization process takes into account all of the repulsors attached to the active craft when figuring out how to handle everything, but any repulsor not attached will not get initialized because the method cannot detect them as active repulsors. When a craft outside of the physics range is switched to, the game has to effectively re-initialize the flight scene and so the repulsors on that craft are then initialized as well. However, when a craft within physics range is switched to, there is no reload of the flight scene and so the repulsors on the other craft are not initialized fully. In this case, we need to add a check to detect if the active vessel has been changed within the same flight-scene instance, and reinitialize the vessel's repulsors when that happens, instead of waiting for the flight scene initialization. lo-fi will be able to diagnose this further, but I'll take a look at the code to confirm my suspicions. By the way, you've gotta share some of those designs. They look awesome. The first image, if I didn't already know the scale of those parts, looks absolutely massive without anything else to use as reference. It's not until you get to the second image that you realize it's a compact little thing. EDIT: I took a look at the source, and I think I was right. The repulsors for the active vessel are only initialized when the flight scene is loaded, or reloaded. That means only the last active vessel will have working repulsors for each scene instance. The instance is not reinitialized when changing the active vessel within physics range, so the repulsors fail to repulse. I'm not confident enough in my coding to fix this, so it's in your court lo-fi.

Alright, this has been a long project for me but i may be very close to a conclusion. A few months ago I began working on the CollisionFX source in the attempt to expand the dust system into its own class and also expand the dust color definitions for other worlds and biomes that the hard-coded values are not set up to handle. Primarily, the goat was to gear this new module towards wheels... specifically Kerbal Foundries wheels, but any object with a collider which is meant to scrape (or roll over, in the case of wheels) the surface, of a planet or object, will in fact work. In this I have been completely successful, thanks to a lot of long, painful, headache-laden days and the some out-sourcing to other modders. The result is a new plugin I call "DustFX" which, I am sorry to say, is not quite ready for release. What's holding me back? Excellent question; intelligent question... you've got a good brain in there somewhere... indeed, there are a few things to work out still. First off, I have yet to configure good color settings for all of the planetary bodies and their appropriate biomes for every body in the Kerbol system. Secondly, there is the issue that, at the core, this mod is mostly code from its parent mod "CollisionFX" and I am unsure if I can release it without approval and/or permission from the author of the original code that this is derived from. There is also the fact that I would like to apply my enhancements to the original mod so that dust can be emitted from collisions in the same enhanced manner. Other enhancements that I have made are that you can now customize the strength, speed, and every single one of the variables used to calculate the emission of the dust, all from the module parameters in the part config. Every one of these values has a default, so you can still reference just the module name and be good to go, but you can also specify each and every value if you so desire. New body and biome settings can be defined in a complex, but easy to get the hang of, configuration file which I will define once I merge the code over. This means that a new planet added by a mod pack, if the modded planet is able to return a value from the isPQS system, or if the original methods to determine the body SOI or "landedAt" methods are returnable with this new planet's name, this system can be expanded to define a custom color for the dust of the new world. If no color is defined, the default for all undefined situations will still be used. Other miscellaneous updates include new ModuleManager patches that correctly identify what should and shouldn't be emitting sparks, dust, or other emissions. Limitations: There are a number of things which cannot be worked out without overhauling how the particles are emitted in the first place. The first is only an issue when moving very fast over the terrain, or when there is a very thick cloud being thrown up. When moving from one color-defined region to another, the trail of dust changes color as a whole. This means that dust which is still dissipating in the distance will suddenly change color to match what is being emitted at the source. I have countered this by changing the alpha values for the colors so that the dust is not a giant cloud, but a rather subtle effect that, under some circumstances, is hard to even make out if you're not specifically looking for it. Another issue is that certain areas do not have correct biome settings. For example, if you launch from the KSC runway, turn around, and travel straight out towards the darker green terrain just outside the flat-space in which the KSC is placed, there will be a moment or two when the dust will turn very white. This is because the vanilla biome definition, for a small area of land within the flat KSC land-plot, is tagged as a "tundra" area. It is rather beyond the scope of this mod to detect errors in the biomes and adjust accordingly. For that, you'll need a plugin that aims to overwrite and/or expand the biome definitions, while still allowing the vanilla method of returning biome names intact. If a viable and widely accepted plugin comes along which does this in a way that makes the old biome name definitions obsolete, I'll gladly look into hooking into a better method of gathering the biome information. That said... The merger of this new power with the old CollisionFX source is underway and, I've gotta admit, it's pretty powerful. I'm still unsure if the best plan of action is to merge DustFX back in with CollisionFX or if it should be released separately. If released as a major overhaul to the original mod, then only one configuration file for planetary body and biome settings needs to be created. Otherwise, the end user would need to make sure both mods have similar definitions so that everything stays consistent. A third option would be to have a separate directory with the configuration file in it that both mods reference separately, which eases the continuity issue, but still ends up loading up the entire configuration set into memory twice. A fourth option would be to create a dependency to a separate DLL which would be responsible for retrieving the configurations for any mod that wants to use this data, and then have both plugins reference that separate DLL. That way, configurations get loaded into memory once, and any other mods made in the future can tie into it to make use of the same data. I am open to thoughts and suggestions. Anyway, I wanted to give you all an update on what's been happening behind the scenes and, hopefully, attract the attention of the author so that I can start working out the best way to get this stuff out to the public. I'll return to post an update on the merger into CollisionFX when I have more to show.