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

[Madrias]

Geez, I look away from here for a few days and you guys launched it past 300 pages!

By the sounds of things, I need to go do another update on Kerbal Foundries before I launch KSP again, then see if I can find something to break and give you guys something to do.

[lo-fi]

*grin*

There's lots of stuff to break... And to address a point made above that I forgot about, the mass of a vessel is now correctly passed to the wheels, so they don't accelerate at the same rate regardless of how heavy a vehicle they are propelling. Strap powerful wheels to a light vehicle with the default torque settings, and chaos will ensue. Or strap small wheels to a heavy vessel and you'll go nowhere fast. The config stuff all needs balancing, as it's now all over the place, though. Suggestions welcome! Tracks should just about be OK - I haven't even touched wheels.

[Tyren]

Suggestion: hint about the approx. vessel mass/size wheels should be used, maybe in the part description.

Is it possible to get them to break if you overdo it?

[lo-fi]

Yeah, it's going to take a bit of figuring out. Makes a heck of a difference to the dynamics, though. No damage model as yet.

[Tyren]

Yeah, i know. Can be delayed as well, just gives some more immersive feeling.

[*Aqua*]

@lo-fi

I always wondered if we can get access to the current dev version. I've no problem compiling the source myself. I just wonder how you did some things.

[Gaalidas]

You know what I find entertaining? When lo-fi commits 8 times to github, in a row, and manages to mess things up, fix them, mess more things up, fix those, and end up with a few messed up things as a grand finale.

[lo-fi]

It happens "Work fast and break stuff"

[Tyren]

Nonetheless, it wouldnt be that entertaining if everything went fine, wouldnt it?

[Gaalidas]

*grin*

There's lots of stuff to break... And to address a point made above that I forgot about, the mass of a vessel is now correctly passed to the wheels, so they don't accelerate at the same rate regardless of how heavy a vehicle they are propelling. Strap powerful wheels to a light vehicle with the default torque settings, and chaos will ensue. Or strap small wheels to a heavy vessel and you'll go nowhere fast. The config stuff all needs balancing, as it's now all over the place, though. Suggestions welcome! Tracks should just about be OK - I haven't even touched wheels.

I think something needs to be done about the super-flipping when trying to move forward under the influence of the handbrake. I also wonder if a clamp could be created that will limit the power of a wheel/track in the case of them being used on an extremely light vehicle. All this should also respond to the TS corrector.

As for the biome color stuff, I suspect maybe it has to do with something between the naming changes I made when merging with KF and the references being called up in the code. If any of the code refers to something else in a string format instead of by object, then the renaming system may not have discovered it and made the change. It's really strange though, because all of my tests have been successful. It doesn't actually change color until you touch the planetary surface though, since the edges of the runway are still part of the static model. If we could get some sort of camera-color-picker working, then you'd get a change immediately upon rolling off the pavement. There's also the chance that some biome names have been altered in the latest update to KSP, in which case the config file would need to be updated. I don't know how the original was generated though, since I've tried launching the game without a config file and the code does have a config writer in it somewhere, but no default file was ever generated. Overall, from what I've seen in other mods, the complexity of this config node loader is a bit baffling. Granted, I'm using an absolute ton of sub-nodes, but it's still pretty crazy. I get the feeling sometimes that I picked a really messed up project to take on all those months ago. Why couldn't I have done something so much simpler?

[lo-fi]

I've not had the flipping over bug?

Now you know how I felt when I was first trying to mess with wheels: I didn't even know that PartTools didn't export the scripts I was creating in Mono, and that I needed to get something to spit out a .dll to get loaded as a plugin.... As Tyren says, wouldn't be fun if it was easy!

There's some code knocking about to iterate over pixels in a textures - I can probably adapt that. We could use the new VesselModule to aim a camera at the planets surface for each vessel, take a snap, average the colour and leave DustFX to grab that.

Code here takes care of how to get the camera to grab an image. We'll get away with quite a small grab, and it'll be quite nice to have some variation in the colour as a small sample will average quite differently to the next. I was going to explain, but I might as well just get on and do it...

[Tyren]

Sounds annoying to me...maybe clean out the code from ground up? I dont want to know how much time you squeezed into it, but imho it might be a consideration to scrap and rewrite the plugin in a clean way instead of patching it up...

Well, i dont know what is faster or more efficient.

- - - Updated - - -

Honestly, ive been thinking lately if i should change my job in RL to programming...

[xEvilReeperx]

There's some code knocking about to iterate over pixels in a textures - I can probably adapt that. We could use the new VesselModule to aim a camera at the planets surface for each vessel, take a snap, average the colour and leave DustFX to grab that

That's likely to be too expensive. Copying texture data back off the GPU is a slow process. You'd either want another terrain rendering camera feeding its output into a custom pixel shader that does the averaging, or come up with the UV coordinates of the terrain mesh point you're driving over, sample that texture and then set your color manually if you want to go from the CPU side.

I thought about it while I was working with Gaalidas on the original problem and decided not to try to convince him to change his design since both are going to be a little more complex than looking up values in a dictionary

[lo-fi]

To the rescue again! Thanks for the tips, though probably a little out of my depth... GPU seems to get less of a hammering that CPU, so I guess it would make sense to attack it from that angle. How difficult are pixel shaders to work with? Seems like a promising avenue to pursue if it can be made to work - I guess I better do some reading!

[lo-fi]

Awwww, look! I can create tiny, pixelated screen grabs with dynamically created cameras:

This may be a long road ahead....

[Tyren]

GPUs are way more effective in slamming down serious performances, rendering a vast cpu capacity almost redundant^^ Imho x64 + dx11 should be task one in development of KSP stock...this would give modders even more capacity in creating ridiculous awesome stuff

- - - Updated - - -

Awwww, look! I can create tiny, pixelated screen grabs with dynamically created cameras:

http://i.imgur.com/qo9U77x.png

This may be a long road ahead....

Kawaii

[Gaalidas]

Awwww, look! I can create tiny, pixelated screen grabs with dynamically created cameras:

http://i.imgur.com/qo9U77x.png

This may be a long road ahead....

Hey, it's a start.

- - - Updated - - -

That's likely to be too expensive. Copying texture data back off the GPU is a slow process. You'd either want another terrain rendering camera feeding its output into a custom pixel shader that does the averaging, or come up with the UV coordinates of the terrain mesh point you're driving over, sample that texture and then set your color manually if you want to go from the CPU side.

I thought about it while I was working with Gaalidas on the original problem and decided not to try to convince him to change his design since both are going to be a little more complex than looking up values in a dictionary

I wouldn't have understood anything you were telling me anyway, so it's better for all of us that you didn't try to explain it to me.

[xEvilReeperx]

Well, your solution also has some possibilities that auto-selecting colors doesn't have such as being able to dynamically scale various parameters of the dust based on the kind of terrain you were driving over and maybe down the road, affecting whether or not wheels leave tracks and things like that.

I didn't want to take a solution that you'd already invested a ton of time and effort into and then move sideways to a different solution that isn't particularly better in my eyes. There may be some unforeseen obstacles in it, like for example dark shadows or lights affecting the look of the dust in a negative way. I didn't mean to imply you couldn't have made it work or that what you have isn't every bit as good as the others, just that there may be more working parts and that I couldn't even be certain it would work as well as yours so why toss out perfectly good, working code?

I'd rather see lo-fi implement his solution as an extension of yours and let a modder override the auto-picking so you get the best of both worlds.

Edited June 24, 2015 by xEvilReeperx

[Gaalidas]

Well, as time goes on and I learn more about C#/KSP coding, the future users of this mod will have more and more options available without having to recompile anything. If there's one thing I do well, it's giving the end user a lot of power over the configuration of things. I really hate to hard-code anything at all. what I'd like to see in the far future is the option to use a camera-grab for unknown locations (such as static models where the terrain system won't recognize the difference between pavement and grass), with a global override to disable that if the user has performance issues... which turns back to a biome-config list (like we have now) for PQS collisions which, in turn, can be overridden in the part config itself with either a user-specified list (maybe a config-defined definition file to look for?) or a single color to use in all situations. I'd like to see base emitter strength, density, size, etc. definable per-color-definition, and for those to be modified by weight of the craft, slippage, material, speed, etc. and I'd like to see a global particle emitter implemented much like smokescreen has for the global number of particles allowed to exist from a DustFX effect. Can I make this happen now? Not a chance in heck, but it'll keep me busy for the next few years at the least.

On to another subject though...

So, a long time ago I went over all of the KF parts with a mod called NodeHelper. This is a very old mod and, needless to say, does not function anymore... at all... and the author had a cultural/personal issue a while back and withdrew his stuff from the world forever. Not to be daunted, however, I found a github repository with the source for that mod and attempted to recompile it. In the recompile I was successful (after disabling the part highlighter, since the old functions for doing that are no longer available and the current version required AA, which slows my machine down a bunch.) However, the mod window still fails to load and I do not have the icon source for the toolbar implementation. Easy fix, I'm sure, but without the window opening up, I'm sunk.

So... I'm looking into other ways to alter the positions and orientations of attach and stack nodes. One way I discovered is to import the models into Blender and use a tool from the utility release board that can turn blender-based coordinates into KSP attach node coordinates. But... the blender importer fails to read the KF parts. Another way is to use transforms from unity, but I have no clue how to add new transforms and would probably have better luck entering random values into configs and reloading KSP every 5 minutes until I get it right (I'm not going to do that, it takes longer than 5 minutes the load KSP each time.) So, I'm in a bit of a conundrum right now (did i even use that word right? I've never used "conundrum" before! That was awesome.)

So, I have a few requests that don't have to be done right now, but would be awesome for the future. And... not all of them need to be fulfilled at any time, since they all produce the same end result: my ability to adjust the nodes to better fit the parts we're working on. The first choice is to possibly provide some basic exports of the parts (don't have to be functional, just a model will do to use for reference) that will load in basic blender. The second option is to make sure that all the unity stuff in the KSP422 repository are all up to date with the current parts so I can learn how to add the transforms I can use to define nodes. In the mean time, I intend to continue seeing if I can revive Nodehelper from the dead. Anyone know of a good physionecrological specialist I can talk to? (aka, bringer of "dead things" into "not-dead things")

So yeah, I'm out now to crawl around on the floor of our church tracing wires! Fun times ahead (and possible rug burn).

Edited June 24, 2015 by Gaalidas

[ZodiusInfuser]

Re: the node thing, the best and easiest way to go about this is either for lo-fi to do it or for him to give you the raw models. No need for some in-game utility to eyeball the position when you have the exact XYZ coordiate of a vertex/edge/plane. I've set up many nodes for the IR Model Rework and its honestly one of the easiest phases of setting up a part.

Also, I'm not sure if you're aware but if you change node positions in the cfg and reload the database, then they'll get applied in-game without having to reload KSP fully (this was a revelation for lo-fi when he first discovered this on-stream )

[lo-fi]

So I've got some really rough POC code with a camera:

    public class ModuleCameraShot : VesselModule
    {
        private bool takeHiResShot = false;
        private int resWidth = 128;
        private int resHeight = 128;


        public static string ScreenShotName(int width, int height)
        {
            return string.Format("{0}/screen_{1}x{2}_{3}.png",
                                 Application.dataPath,
                                 width, height,
                                 System.DateTime.Now.ToString("yyyy-MM-dd_HH-mm-ss"));
        }


        public void TakeHiResShot()
        {
            takeHiResShot = true;
        }


        //[KSPEvent(active=true,guiActive=true,guiName="Take Shot",name="Take Shot")]
        public void Update()
        {
            takeHiResShot |= Input.GetKeyDown("k");
            if (takeHiResShot)
            {
                var _vessel = GetComponent<Vessel>();
                var _cameraObject = new GameObject("ColourCam");
                _cameraObject.transform.position = _vessel.transform.position;
                _cameraObject.transform.LookAt(_vessel.mainBody.transform.position);
                _cameraObject.transform.Translate(new Vector3(0,0,-10));
                Debug.LogError("created camera");
                var _camera = _cameraObject.AddComponent<Camera>();
                RenderTexture rt = new RenderTexture(resWidth, resHeight, 24);
                _camera.targetTexture = rt;
                Texture2D groundShot = new Texture2D(resWidth, resHeight, TextureFormat.RGB24, false);
                _camera.Render();
                Debug.LogError("rendered something...");
                RenderTexture.active = rt;
                groundShot.ReadPixels(new Rect(0, 0, resWidth, resHeight), 0, 0);
                _camera.targetTexture = null;
                RenderTexture.active = null; // JC: added to avoid errors
                Destroy(rt);
                Destroy(_cameraObject);
                Color[] texColors = groundShot.GetPixels();
                int total = texColors.Length;
                float r = 0;
                float g = 0;
                float b = 0;


                for (int i = 0; i < total; i++)
                {
                    r += texColors[i].r;
                    g += texColors[i].g;
                    b += texColors[i].b;
                }


                Color averageColor = new Color(r / total, g / total, b / total);
                print(averageColor);


                takeHiResShot = false;
            }
        }
    }

I'm sure it could be more efficient, but it actually does what's required. I see what you mean, xEvilReeperx. The current code does what it's supposed to, but it's not in my nature to leave well alone, so I feel compelled to see where the other path takes me, even if it turns out just to be an intellectual exercise.

As Zodius points out, it's far easier poking about in the Unity model to finalise the node positions. I usually (if I'm not just guessing) just plonk an empty GameObject under the root of the model and take the relative position from that. The stuff in there doesn't change often - certainly not enough to affect the node positioning.

[Gaalidas]

I'm glad you think it's the easy part to do nodes... However, I have never made any parts from scratch, so it's still a real pain for me. Also, MM hates database reloads.

I just need a way to experiment with node positions and visually see the result quickly so I can fine tune it. This is both for attach nodes and the stack nodes I like to to put on the wheels for use with things like the ERS rover body which uses stack nodes for wheels. They need to be very precise.

[lo-fi]

You'll get used to it, Unity really isn't difficult for the tiny bits we use making KSP parts.

By the way, this actually works!

That's using a camera set to render a 6x6 texture. I'm currently wondering if just setting it to a size of 1x1 makes Unity do all the hard work averaging for us.... I'll experiment. I'm kinda leaning towards mixing this method up with the biome colours. The "live data" could be mixed with the master biome colour, which could lead to some awesome effects. Either way, I'll need to optimise and smooth the updates somewhat, but I think we're onto a winner

Any tips on optimisation welcome...

[Tyren]

hmm thats pretty neat

Anyway, like i suggested some pages back, if possible scale the color of the thrown dust slightly different from the ground its been thrown up (darker/brighter?).

Imho that would look even better.

Edit: is it possible to lock the dust behaviour to the color brightness? Lets say the brighter the color, the more dust gets thrown up? Assuming the sand particles in the desert and the pole ice are extremely tenuous.

Edited June 24, 2015 by Tyren

[Gaalidas]

That's why we keep a biome settings file in the plugin, to define biome-based materials and their hardnesses. I need to look into expanding the information we can define in each node in the biome color config.

As for varied colors in the dust animator... Currently the color is applied to an array. There are maybe 5-6 index levels that all get the same color. I haven't looked into applying a variance to it, like is done for the relatively untested impact sounds, but I bet it's doable.