Jump to content

[1.3 - 1.2.2] Collision FX v4.0 (2017-03-09) Now with biome coloured dust!


pizzaoverhead

Recommended Posts

Please remove effects for Kerbals - it`s quite funny to see sparks when Jeb grabs ladder=))
That awesome, but remove kerbals effect

That's the plan. I need to do a pass on part-part interactions.

nice update!

tested on kerbin so far, how does it look like on other planets? (they‘re mostly big rock ball though)

There aren't custom colours for the other bodies yet, but it defaults to light grey dust, similar to what you see alongside the sparks when skidding on the runway. There are no sparks when not in an oxygen-rich environment. I'm planning on adding some debris fragment particles for collisions in space.

Not sure if this is supposed to happen: http://imgur.com/omndrc3

It's working as it's designed to (anything that collides with your craft that isn't planet terrain causes a spark), but will be changed in future.

Would there be a way to use this to add better exaust to your rockets when taking off? Hot rockets just never really got there...

This mod deals only with collisions. Check SmokeScreen and mods which use it (as Hot Rockets does).

just a thought; but woud it be possible to add an effect that kicks up dust/sand/snow/dirt Kerbal walk?

Probably, but kerbal feet are too small and slow to kick up much dust. Sliding down a hillside on their faces however...

Kerbal Foundries has been updated and this needs fixing for it as the wheels spark all the time

Thanks for the information. I'll have a fix for it for the next release. In the meantime, to disable effects for those parts you can change this line in ModuleManager_CollisionFX.cfg:

@PART[*]:HAS[!MODULE[ModuleLandingGear],!MODULE[ModuleWheel],!MODULE[CollisionFX],!MODULE[FSwheel],!MODULE[FSwheelAlignment],!MODULE[KerbalEVA],!MODULE[TTModularWheel],!MODULE[*Repulsor*],!MODULE[ModuleTrack],!MODULE[TrackWheel]]

to this:

@PART[*]:HAS[!MODULE[ModuleLandingGear],!MODULE[ModuleWheel],!MODULE[CollisionFX],!MODULE[FSwheel],!MODULE[FSwheelAlignment],!MODULE[KerbalEVA],!MODULE[TTModularWheel],!MODULE[*Repulsor*],!MODULE[ModuleTrack],!MODULE[TrackWheel],!MODULE[KFModuleWheel],!MODULE[KFWheel],!MODULE[KFTrackSurface]]

Link to comment
Share on other sites

Thanks for the patch, though I did find it hilarious with the sparks flying everywhere! You'll be safe to treat the KF module names as stable from now on and I'll try and remember to give you a heads up if I add anything new.

Lovely mod, btw :)

Link to comment
Share on other sites

One suggestion - as you've already got the code for positioning effects on surface, IMO it would be nice to incorporate dust streaks on landing on airless bodies, and dust clouds - on aired. Size should depend linearly - on thrust and quadratically - on Isp.

Watch from 3:11:

EDIT: Actually the effect starts appearing when they are a little bit below 150 feet.

Edited by sashan
Link to comment
Share on other sites

Thanks for the information. I'll have a fix for it for the next release. In the meantime, to disable effects for those parts you can change this line in ModuleManager_CollisionFX.cfg:

@PART
[*]:HAS[!MODULE[ModuleLandingGear],!MODULE[ModuleWheel],!MODULE[CollisionFX],!MODULE[FSwheel],!MODULE[FSwheelAlignment],!MODULE[KerbalEVA],!MODULE[TTModularWheel],!MODULE[*Repulsor*],!MODULE[ModuleTrack],!MODULE[TrackWheel]]

to this:

@PART
[*]:HAS[!MODULE[ModuleLandingGear],!MODULE[ModuleWheel],!MODULE[CollisionFX],!MODULE[FSwheel],!MODULE[FSwheelAlignment],!MODULE[KerbalEVA],!MODULE[TTModularWheel],!MODULE[*Repulsor*],!MODULE[ModuleTrack],!MODULE[TrackWheel],!MODULE[KFModuleWheel],!MODULE[KFWheel],!MODULE[KFTrackSurface]]

Or, if you want to save on doing checks for each individual KF module, here's a nice tidbit of info. All of the parts (in the Kerbal Foundries addon) which need to have the collision effect disabled have either "Repulsor" or "KFWheel" in them. In fact, the repulsors are the only parts without a "KFWheel" module. So, simply checking for that module will do the trick. This also maintains compatibility with a MM patch that will be included eventually (I hope) which I've been working on with lo-fi to apply the steering and suspension-handling to the stock wheels. So, if would be a lot better if that wildcard part search was run in the ":FINAL" stage.

Now, just one more little fix that you need. In the second patch in that file you see:

@PART
[*][B]:HAS[MODULE[ModuleWheel][/B],!MODULE[CollisionFX]][B]:Final[/B]
{
MODULE
{
name = CollisionFX
scrapeSparks = false
wheelImpactSound = CollisionFX/Sounds/TyreSqueal
}
}

You see the bold part? there's something missing from there that is essential for MM patches to function correctly. It's the @ symbol. That part should read ":HAS[@MODULE[ModuleWheel]" for proper functionality. I would also suggest running this one in the ":Final" pass as well to increase the compatibility chances with mods which might replace the wheel module in other parts, such as the patch I am trying to finish up for stock wheels using "KFWheel" stuff.

Edited by Gaalidas
Link to comment
Share on other sites

If its possible to get the dust without the sparks, then I think letting the stock and Kerbal Foundries wheels do so would be awesome. However it would probably be best if the wheels had some sort of rubbery sound for bumping.

Edited by BoomShroom
Link to comment
Share on other sites

The dust doesn't work for me, I'm on 0.90 and I'm using the latest version (2.2). The stock wheels and the kerbal foundary parts dont have the dust effect, as they should. I'm testing it on the grass around KSC. I also used the code to stop sparks for the new KF update. I have pretty high quality settings, but use half res quality to get better FPS with lots of stuff on screen, i.e. when doing videos with BDArmory battles. Can anyone help me out?

Link to comment
Share on other sites

The dust doesn't work for me, I'm on 0.90 and I'm using the latest version (2.2). The stock wheels and the kerbal foundary parts dont have the dust effect, as they should. I'm testing it on the grass around KSC. I also used the code to stop sparks for the new KF update. I have pretty high quality settings, but use half res quality to get better FPS with lots of stuff on screen, i.e. when doing videos with BDArmory battles. Can anyone help me out?

The lack of dust is because currently this add-on either has both dust and sparks or no sparks and dust, so it is possible to get the KF parts and Stock wheels to have dust but it will also make them have sparks too.

Link to comment
Share on other sites

The lack of dust is because currently this add-on either has both dust and sparks or no sparks and dust, so it is possible to get the KF parts and Stock wheels to have dust but it will also make them have sparks too.

Thanks, but It somehow fixed itself after some restarts :P Forgot to say I have it already. But thanks for the help anyway! IMO, there should be a way to set if you have sparks, dust, both or none. Like it is currently done for some parts, but with an additional "hasDust" boolean. Shouldn't be too ahrd to code, as long as separating the sparks and dust is possible.

Link to comment
Share on other sites

Any chance you could make a slider to edit the amount of smoke and sparks and noise everything makes? It would solve a ton of problems in the fact that you could turn off the effects when walking around EVA on things and even disable the effects when not in atmosphere. Also if they where separate sliders you could make the smoke tail visible on other planets but not sparks when on atmosphere-less bodies. Makes sense?

Link to comment
Share on other sites

I actually sent the author a message about the possibility of separating dust and sparks. I'm working out some memory issues currently, but once that clears up I will be testing a local compile of mine which might just accomplish this effect separation. Still needs an official run-over from the author though. The KF tracks definitely would benefit from the dust effect, and the repulsors might even be able to use them (especially if we can combine the repulsor code to detect when hover over water, which needed a lot of extra functionality added to work correctly without sinking, and produce dust that resembles water spray).

Link to comment
Share on other sites

  • 3 weeks later...
The dust doesn't work for me, I'm on 0.90 and I'm using the latest version (2.2). The stock wheels and the kerbal foundary parts dont have the dust effect, as they should. I'm testing it on the grass around KSC. I also used the code to stop sparks for the new KF update. I have pretty high quality settings, but use half res quality to get better FPS with lots of stuff on screen, i.e. when doing videos with BDArmory battles. Can anyone help me out?

It turns out that the "grass" around KSC is actually either green-painted concrete or a very thin layer of grass on top of either concrete or gravel. Regular grass away from KSC should have normal dust. I have no way of changing this at the moment.

The dust/spark issue has been fixed during rewriting the generation code for fragments in space, but isn't yet ready for a release. I've switched my focus to Atmospheric Sound Enhancement for the moment as it has become very outdated, but I'll be continuing to add fixes and features to this mod in future.

Link to comment
Share on other sites

If you're willing to merge in a new class into your project, pizza, I've been working together with some people on the KF thread to get just dust effects for KF wheels/tracks. I've managed a completely and utterly successful extraction of the dust generation code under a new module that I called (not in a very unique way) DustFX. It includes the ability to adjust the minimums/maximums for dust strength and emissions, and the multipliers/divisors for the equations used in generating the dust based on speed, all through module parameters. This also allowed me to scale the strengths along with the part size using TweakScale. Though not extensively tested yet, it hasn't caused any overly negative effects. Also untested is an extension to the settings to allow for a sandy color dust on Duna. i wanted to export all of those color settings to an external settings file, perhaps through a new node, but I've been struggling with the logic behind the code required for that.

As for the grass around the KSC, it's the grass that's part of the modeled landscape which causes the sparks/non-dirt-colored dust. Technically it's not grass, it's just a model which translates to the same material as concrete, or in fact any other "part" model in the game. Thus, you get the effects that would be attributed to another part that you're colliding with.

Edited by Gaalidas
Link to comment
Share on other sites

Anyone else still having problems with Kerbals causing sparks on ships? They really shouldn't do that. Here's the thing about these sparks. They are a bit too easy to make. Remember that sparks are literally bits of molten metal! You have to have a lot of kinetic energy to reveal that. Is there a way to tone down the speed needed for sparks? Additionally, can it be possible for parts to just completely ignore Kerbals brushing up against them? Because even though Kerbals themselves don't spark, parts do when you brush up against them. If this can be fixed, it opens up entirely new concepts of things like

:)
Link to comment
Share on other sites

  • 2 weeks later...
  • 4 weeks later...

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.

Link to comment
Share on other sites

LONG WALL OF TEXT!

okay I have a patch for KF that was merged a few hrs ago.

not sure what you mean but I heard of KF word.

I made a patch a few moths ago. So if you want an updated vrrsion of the patch. Pls go to github.

(Sorry if it out of point!)

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

  • 4 weeks later...
This thread is quite old. Please consider starting a new thread rather than reviving this one.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...