[1.0.x] [V1.9f] Kerbal Foundries wheels, anti-grav repulsors and tracks

[lo-fi]

The more I think about it, and having carefully re-read that post a few times, I realise squad are pretty much trying to recreate what KF does anyway. The modular approach is pretty much what I've gone for, though it sounds like they're taking it further, and all the gumpf about steering, vessel mass and the colliders was true with the U4 stuff. I downloaded U5 last night so I can set up a sort of mock KSP environment with rigidbodies strapped together with joints and some colliders, which ought to tell me whether there really is anything to be concerned about. Either way, its going to cause a lot of work and many headaches.

[smjjames]

I wont go as far as to say they are arrogant. They simply have their own way of doing things, so what? I stick with the mods i prefer in case stock isnt working out for me. If f.ex. FAR and DRE in their difficulty levels were implemented in stock, someone would cry "gimme old stock behaviour back"...etc. pp.

So i just sit there and alter my game thanks to that outstanding modding community exactly the way i like. That is how its supposed to be, desu ne?

- - - Updated - - -

I am working on some sort of mod too, but until now its just gathering ideas and trial and error in blender

Yeah, they have to strike a balance between realism and difficulty, realistic enough to satisfy some of those that want realism while not having too steep a learning curve.

The new stock aero is vastly better than the old soupisphere anyway.

[Temeter]

I wont go as far as to say they are arrogant. They simply have their own way of doing things, so what? I stick with the mods i prefer in case stock isnt working out for me. If f.ex. FAR and DRE in their difficulty levels were implemented in stock, someone would cry "gimme old stock behaviour back"...etc. pp.

The problem of FAR is les about the learning curve, at least the old one was very straightforward (didn't check nufar's planes yet), it's how it restricts construction, how aerodynamic damage works, how plane control takes constant attention (which is not to be confused with difficulty).

Not sure how much you tried 1.0.3, but it can be even more punishing for rockets than FAR. E.g. the latter gives you a lot more freedom of control during the

low mach stages of ascent.

Btw, i'm sure it would be appreciated if you stop infantilizing people just because they're not enjoying the game the way you do. That's just unnecessary.

Edited June 18, 2015 by Temeter

[smjjames]

The problem of FAR is les about the learning curve, at least the old one was very straightforward (didn't check nufar's planes yet), it's how it restricts construction, how aerodynamic damage works, how plane control takes constant attention (which is not to be confused with difficulty).

Not sure how much you tried 1.0.3, but it can be even more punishing for rockets than FAR. E.g. the latter gives you a lot more freedom of control during the

low mach stages of ascent.

Btw, i'm sure it would be appreciated if you stop infantilizing people just because they're not enjoying the game the way you do. That's just unnecessary.

I think you mean 1.0.2, 1.0.3 isn't out yet.

[lo-fi]

Got a major feeling a deja vu...

[smjjames]

Got a major feeling a deja vu...

About what?

[Gaalidas]

We've had these kinds of discussions before. It's an endless cycle.

On a happier note, I'm done with this quarter of school now, and I'm determined to, first off, get some much-needed rest and, secondly, really buckle down and get this particle stuff handled. I think I'm going to dig into the smokescreen plugin and see if there are any techniques I can use for inspiration. I'd like to be able to restrict the total particle numbers for the entire craft so that rovers with over 30 dust-emitting colliders don't cause a massive performance drop. I'd also like to look at what's going on with the surface effects that squad introduced for engines and see if there's anything in there that I could use. With ASP class out of the way, my brain is much more free to pursue these leads.

How's the new directory structure working for you, lo-fi? I didn't get a change to fully test it out myself, but I'm pretty confident that everything will work based on the same experiences with other mods doing that on their own, and my modification of some mods into that format by me for local use. I just worry that a few parts might scale weirdly, considering my failure when I set up the Endurance mod to use texture sharing. I ended with with a Ranger that had correctly positioned stack nodes, but smaller-than-normal models. It was a real mess.

[V8jester]

We've had these kinds of discussions before. It's an endless cycle.

On a happier note, I'm done with this quarter of school now, and I'm determined to, first off, get some much-needed rest and, secondly, really buckle down and get this particle stuff handled. I think I'm going to dig into the smokescreen plugin and see if there are any techniques I can use for inspiration. I'd like to be able to restrict the total particle numbers for the entire craft so that rovers with over 30 dust-emitting colliders don't cause a massive performance drop. I'd also like to look at what's going on with the surface effects that squad introduced for engines and see if there's anything in there that I could use. With ASP class out of the way, my brain is much more free to pursue these leads.

How's the new directory structure working for you, lo-fi? I didn't get a change to fully test it out myself, but I'm pretty confident that everything will work based on the same experiences with other mods doing that on their own, and my modification of some mods into that format by me for local use. I just worry that a few parts might scale weirdly, considering my failure when I set up the Endurance mod to use texture sharing. I ended with with a Ranger that had correctly positioned stack nodes, but smaller-than-normal models. It was a real mess.

Hey have you thought about looking at the Firespitter heli rotor? It emits dust particles when you are within a set distance from the ground. This could be adapted to tracks so when you go air born off a jump it stops emitting? Just a thought, I'm a bit out of my league on this one though for sure.

Edited June 18, 2015 by V8jester

[Temeter]

We've had these kinds of discussions before. It's an endless cycle.

True, and i'm not planning to repeat them either.^^

I'd just prefer to reach the state where we can stop throwing around insults.

[Tyren]

No one has been,insulted, no one has been particularily mentioned. I merely shared my impressions about major changes concerning gameplay in community forums, and it doesnt matter which one. If I accidently offended someone, i deeply apologize. As mentioned before, sometimes there is a lack of english expressions on my side. I am at fault. Anyway, lets see what squad comes up with.

One last thing: i like the newer stock behaviour, it was simply the most obvious example.

V8Jester: i am not sure yet, but i guess this emitted particles are somewhat like stock launch effects.

[Temeter]

Well, then lets put that one to grave, where it belongs.

[Scientist]

a couple of KF modules have hardcoded use of "ElectricCharge" resource, could you replace this with a field in the module to set a custom resource please? the default (if unspecified) value can still be set to ElectricCharge, and not break saves, yet still allow for custom value to be specified/override it

trying to create a cleaner looking custom install by renaming a few resources, and trying to make this work with the other mods that change how electricity is done

[lo-fi]

Sure, I'll bung it on the list, but can't guarantee I'll remember!

[Gaalidas]

Sure, I'll bung it on the list, but can't guarantee I'll remember!

I'll look into exposing more of those variables to KSPField usage. I'm all about providing flexibility to the config-level. Just about everything I use in anything I write is, at some point, exposed to the configs sooner or later.

- - - Updated - - -

V8Jester: i am not sure yet, but i guess this emitted particles are somewhat like stock launch effects.

I agree, it is likely that those effects are using the same module at the stock rockets. I will admit that the effect is interesting, but it lacks the vertical axis that I am attempting to make happen (and have succeeded in making happen). I just want to make it better. From what I understand, surface effects are just that: surface effects. This means they lack the ability to emit an effect out beyond that surface. I could be wrong of course, but it would actually make sense that the surface effect module would simply do that, and leave the other effects to the engines themselves.

That said, I will look at what Firespitter uses just in case it is something custom built that I may be able to draw inspiration from. I won't say that surface effects aren't soemthing to consider adding to the dust effects for an even better experience, specifically with anti-gravity repulsors, but it's not the primary focus right now.

[Scientist]

accually on that point, stuff like spring, suspension, etc, a default value is set, you can change it up to max value in vab, but all wheels have the same max limit, dif wheels should get dif max values, even if default is the current max for sake of less cfg work, just ability for me to override it would be nice ^.^

[lo-fi]

That would be nice, but I never figured out how to set the values for the tweakable sliders dynamically, which is why they're hard coded. There may be a way with KSPAPIext, but I hate dependencies, and it seems to get broken every release.

[*Aqua*]

Yeah, that's a bit weird at first but it's simple. From my small mod:

public class KerbalMassModule : PartModule
{
    /// <summary>
    /// Current crew number in the part.
    /// </summary>
    [UI_FloatRange(controlEnabled = true, maxValue = 1f, minValue = 0f, scene = UI_Scene.Editor, stepIncrement = 1f)]
    [KSPField(guiActiveEditor = true, guiName = "Crew", isPersistant = false)]
    public float crewNumber = 0f;

    ...

    /// <summary>
    /// Called once after the part is created or loaded.
    /// Perfect time to set up everything.
    /// </summary>
    public void Start()
    {
        // Update slider's max value
        if (HighLogic.LoadedSceneIsEditor)
        {
            UI_FloatRange slider = (UI_FloatRange) Fields["crewNumber"].uiControlEditor;
            if (isLimitedToEditor == false)
                slider.maxValue = part.CrewCapacity;
            else
                if (editorCrewCapacity > 0)
                    slider.maxValue = editorCrewCapacity;
                else
                {
                    // So the isLimitedToEditor is set to true but there's no
                    // useable value in editorCrewCapacity. Don't show the slider!
                    Fields["crewNumber"].guiActiveEditor = false;
                 }

    ...

crewNumber is a slider that's only visible in the VAB. When a part with my custom PartModule gets added, it checks how much Kerbals can have seat in there and updates the max. value of the slider. If the user messed up the config file the slider is turned off.

Doesn't have dependencies except for the usual ones (assembly-csharp.dll and unityengine.dll). Any questions?

Edited June 19, 2015 by *Aqua*

[lo-fi]

That's perfect, thank you!

[Gaalidas]

Yeah, that's a bit weird at first but it's simple. From my small mod:

-code snipped-

crewNumber is a slider that's only visible in the VAB. When a part with my custom PartModule gets added, it checks how much Kerbals can have seat in there and updates the max. value of the slider. If the user messed up the config file the slider is turned off.

Doesn't have dependencies except for the usual ones (assembly-csharp.dll and unityengine.dll). Any questions?

Holy Jebediah! I've been wondering about that for quite some time. (I swear, just this morning I was thinking about KSPAPIExtensions and wondering how I was going to convince lo-fi to accept the dependency.) I wanted to make the min/max suspension levels into variable fields so that we might reduce the number of ineffective suspension levels. Certain tracks do not effectively lower the suspension level beyond a certain point (typically at the 50% mark) and it would be awesome if that "lowest possible level" for the individual part could be defined. We could then refactor the min-max levels to reference that lowest possible value as "zero" and then, possibly, change the "change amount" to reflect the new rate of change that would be needed to maintain the previous level of control.

Of course, modifying the tracks themselves so that they could use all the levels of the suspension slider would be a better solution, but that's a lot of work compared to doing some testing and then setting a new config value to match. In theory, this could also be used to limit the suspension range if the model has the tendency to warp in an unpleasant way upon reaching the highest or lowest levels (referencing the way the tracks tend to have these little points on either end of the length areas when retracted fully. Overall, the goal would be to allow the slider to go from zero to full as far as the user is concerned, except that every level the slider goes to would have a visual impact instead of that 0-50 null-zone I've witnessed.

I'm excited now, can you tell?

Moving on...

I did some refactoring in the KFRepulsor and KFModuleWheel modules to try and change the resource consumption from a hard-coded "ElectricCharge" to a variable field. In theory, it should now be possible (once I find out if lo-fi has been messing with those files so I can make sure I'm all merged up and don't conflict when committing) to set a "resourceName" field in the config (defaults to "ElectricCharge") to whatever valid resource you have in your game. I have not yet added any checks to make sure that the resource is valid because, quite frankly, I don't know how to start yet. I'll look into that next. For now, I can only assume that it would cause some sort of fatal error and police would find your lifeless body... or what's left of it, smoking in front of your computer. They don't call them fatal errors for nothing!

On top of all that, the variable names themselves have all changed to reflect that it is now a "resource" request and not a hard-coded "charge" request. Status text for the "Low Energy" state has also been given a field, with a default equal to what it was before, so that an appropriate message can be created for that resource. I am unsure at this time if any of those changed variable names include any necessary config updates, but I'll be sure to check that out before committing anything to github. The goal is, of course, to make sure that, if not set in the config, that a default value is still used which is equal to what we currently use so that our fearless leader, lo-fi, does not have to change any of his WIP configs to match the new fields.

Of course, an option in the future to change all requests for resources from a wheel or repulsor, at a global level, would be awesome. I've had this long-standing idea of KerbalFoundries having a DefaultSettings.cfg (or something similar) that could be used to define, if not overridden in the part config, a default value for several of the commonly modified, but modified uniformly, variables. In this way a global multiplier could be implemented for all charge consumption (allowing for an "easy mode" setting which would allow the user to disable all resource usage on the KF parts) and a global string could be defined for what resource to consume. I would probably implement a boolean to define whether or not the part configs can override the global settings as well. It's an idea I'm working on anyway, and in the far future could even include a GUI to modify global settings in the game. This would especially be useful to me in the Dust emitters. I could then set a global variable to disable all of the effects without having to add a toggle to every individual part (though, I intend to make that possible for more control in the editor as to how the particles are emitted) and, possibly, a particle limiter similar to the one available in the debug window for smokescreen.

Wheels within wheels I say...

To wrap up... lo-fi... have you been meddling with your modules recently? If so, I'd appreciate it if you'd update github so I can merge these awesome changes in and get to work on the rest of this monstrosity. That or give me the go-ahead to commit and plan on merging the changes yourself. Unless you've gone and done it yourself, in which case I'll merge my changes anyway... 'cause let's be honest, I do it so much cleaner than you do... (feel free to slap me silly any time you'd like) and, having thus said, my code is surely superior to your inferior attempts at... (Okay, I'm serious... smack me before I say another word...) ... making code that anyone could call "beautiful code" and blah blah blah, blah blah... blah blah inferior blah blah, blahbity blahbity blah blah... (okay, I'm done now... I'll be here all week kerbals and kergals...)

EDIT: By the way, we're getting close to that 300 page mark, assuming you're using the default settings for your forum experience. We're gonna be a mega-thread when we do our next release.

Edited June 19, 2015 by Gaalidas

[lo-fi]

Hehe! Good luck with that one!

Probably most useful on the spring field, as I very much doubt anyone runs out of damping adjustment. Changing how the ride height gets affected is probably best done internally, rather than messing with the slider ranges, and would be quite a challenge in itself.

I'm in the middle or rewriting the repulsor modules, as well as the wheel modules. Please don't go correcting typos in the meantime - it plays havoc if I've forgotten to sync before firing up VS to mess with something quickly and then throws a few hundred sync conflicts at me!

Edited June 19, 2015 by lo-fi

[lo-fi]

I am INVINCIBLE!!!!! Lots of cool new stuff about to happen and everything is in chaos. Usual prerelease status...

[smjjames]

I don't get the point of switching to a custom resource for the KF wheels. I don't want to have to slap on a tank of diesel (actually, that'd be like liquid fuel only) or something every time I want to use the wheels from this pack.

[*Aqua*]

At the moment the ressource and the consumption rate are hardcoded in the plugin. I understond Gaalidas comment in that way that these values should be exposed in a config file. Modders and players could then change them to whatever they like.

For example there is KSP Interstellar which introduces a completely different mechanic concerning electric power. If KF exposes ressource type and consumption a modder can easily write a small patch to let KF adapt to what Interstellar offers.

[lo-fi]

Yeah, the idea is to default it to stock EC but allow patching to others.

[Gaalidas]

Hehe! Good luck with that one!

Probably most useful on the spring field, as I very much doubt anyone runs out of damping adjustment. Changing how the ride height gets affected is probably best done internally, rather than messing with the slider ranges, and would be quite a challenge in itself.

I'm in the middle or rewriting the repulsor modules, as well as the wheel modules. Please don't go correcting typos in the meantime - it plays havoc if I've forgotten to sync before firing up VS to mess with something quickly and then throws a few hundred sync conflicts at me!

Well, in the mean time I got the resource stuff exposed and I already patched a copy set of the part files... but I can keep those around in storage for when you get done doing your rewrite if you'd rather. I thought you'd only just rewritten the repulsors recently. Seems a bit early to be rewriting them again.

EDIT: So, I think I know why your repulsors were flinging you to insane heights. i was looking at the latest github updates and saw this in the KFRepulsor.cs file:

public float rideHeight = 25;
const float maxRepulsorHeight = 100;

Now, I'm no expert, but if nothing else has changed in how the maximum and current ride height is calculated and applied, then you've just set the default ride height to 25, and your default maximum to a staggering 100.

Another thing I noticed was your attempt to change the sound for the APU unit. I think you might be missing something in how you're trying to do that. The reason sound replacement doesn't use that simple sound definition is because that stopped working the way we expected to a long time ago. It used to be that you could simply put a sound file into the part directory, under a subdirectory named after the part config file, and then another subdirectory called "sounds" under that, and then call it up with "soundfilename = mode_that_calls_it" (for example "engine_low = running"). Squad made some changes to how that system works and now the best way to do sound replacement is either to replace the sound file at the source (for global replacement) or to use EFFECT nodes. Here's the way you set it up most recently in the APU config:

sound_jet_low = KerbalFoundries/Sounds/APU
sound_jet_deep = KerbalFoundries/Sounds/APU

Now, this is basically saying that when a running state of the engine reaches what it will internally call "KerbalFoundries/Sounds/APU" it will then play the sound named "sound_jet_low" which I know is a bit weird, but that's how the old system worked. The name of the sound file came first, then the engine status it was used on after the equal sign. For you to properly use different sounds in the APU, you should use EFFECT nodes like most other engines that are not based n the old stock behavior would use. Either that or write your own plugin to handle the sound effects in your own way. Trying to adapt the old sound definition system is really overly complicated as to where they have to be in the directory structure.

Edited June 20, 2015 by Gaalidas