[1.8.x] Kerbal Foundries -- Continued - Tracks, Wheels, and Gear

[Svm420]

37 minutes ago, Beetlecat said:

The auto alignment was borrowed from firespitter, I believe. The effect was that you could slap the gear on (almost) any-which-way, hit F2, and it would rotate the wheel joint to face exactly down and forward.

It also showed lines in the VAB indicating how far from 0 degrees they were in each direction.

It may have been that or the button you could press to have the wheel auto level instead of having to manually adjust them. FYI I tried the FSAlignment module and it either broke in 1.2 or the wheels are so different it doesn't work. I think it is broken though as I had a ton of NRE  in my log when I pressed F2

[Virtualgenius]

I

2 hours ago, Beetlecat said:

The auto alignment was borrowed from firespitter, I believe. The effect was that you could slap the gear on (almost) any-which-way, hit F2, and it would rotate the wheel joint to face exactly down and forward.

It also showed lines in the VAB indicating how far from 0 degrees they were in each direction.

This was an awesome feature and unfortunately I cannot code so I rely on the fantastic work all the modders do 

[Eskandare]

I am ecstatic that this is working again. I promply went to work building amphibious wheeled vehicles.

Question, if I wanted to build air cushion style hovercraft parts, would the rigging be essentially the same as the anti-grav parts?

Edited January 30, 2017 by Eskandare

[Space Kadet]

Im so happy!

 

[vardicd]

Is anyone else having a the issue where if the anti-grav units lose power or are turned off for some reason, they won't turn back on?

[SpannerMonkey(smce)]

6 hours ago, Eskandare said:

I am ecstatic that this is working again. I promply went to work building amphibious wheeled vehicles.

Question, if I wanted to build air cushion style hovercraft parts, would the rigging be essentially the same as the anti-grav parts?

Hi, simply yes, use the basic TR2l  type set up, with empty transforms instead or meshes Or if you fancy it a similar rig  to the LoFi repulsors , I can supply unity hierarchy images of working parts for guidance.  Some annoying things happen when animating wheel colliders in the unity player (as the collider is only parented to the base mesh the collider drops off when  rotated by animation, this doesn't reflect what happens in game)   and it can take a little bit of trial and error to get the retraction etc right in game

[Shadowmage]

49 minutes ago, vardicd said:

Is anyone else having a the issue where if the anti-grav units lose power or are turned off for some reason, they won't turn back on?

Have you tried pushing the power button on them to turn them back on?  They don't turn back on automatically...

[lo-fi]

Great to see this so active again can't wait to see some hovercraft parts!

Also, if someone wants to make a nice model with rubber skirts, I'd be happy to lend a hand skinning them so they move when the load changes like the tracks. 

Edited January 30, 2017 by lo-fi

[Shadowmage]

7 hours ago, Eskandare said:

I am ecstatic that this is working again. I promply went to work building amphibious wheeled vehicles.

Question, if I wanted to build air cushion style hovercraft parts, would the rigging be essentially the same as the anti-grav parts?

Yes, but they would function just as the repulsors do.

I have plans for some ground-effect hover-craft engines in the near-ish future, that will use proper engine mechanics rather than suspension magic.  Basically a low thrust engine that gets a thrust multiplier whenever it is within X meters of the ground and aligned at the surface (multiplier increases with decreasing distance, up to a maximum at ~0 distance).

[vardicd]

14 minutes ago, Shadowmage said:

Have you tried pushing the power button on them to turn them back on?  They don't turn back on automatically...

yes I did, turned them on and off several times. craft was splashed in the water, if that makes a difference, was using it for an ocean recovery.

[Shadowmage]

2 minutes ago, vardicd said:

yes I did, turned them on and off several times. craft was splashed in the water, if that makes a difference, was using it for an ocean recovery.

If the repulsors themselves are underwater, they will have no force-output; they have to be -above- the surface of the water.

If that is not the case, would you mind providing pics of the craft in its resting place, along with one of the repulsor right-click menus open?

[vardicd]

3 minutes ago, Shadowmage said:

If the repulsors themselves are underwater, they will have no force-output; they have to be -above- the surface of the water.

If that is not the case, would you mind providing pics of the craft in its resting place, along with one of the repulsor right-click menus open?

yeah that'd be it, when I set the craft down on the water, the repulsors went underwater. Water rescue craft going to need a re-design

Edited January 30, 2017 by vardicd

[Shadowmage]

1 minute ago, vardicd said:

yeah that'd be it, when I set the craft down on the water, the repulsors went underwater. Water rescue craft going to need a re-design

Yeah, that'd do it.  I haven't quite decided how I want repulsors to function underwater, so currently they do nothing.  Can think of it as the water interfering with its gravioli manipulation or w/e...

It seems that there are three options to handle under-water operation:
1.) Do nothing.
2.) Always push towards surface regardless of orientation.
3.) Always push in the repulsor 'up' direction.

#2 & 3 though have unsovled problems regarding how to calculate the force to output.  And neither really makes a whole lot of sense.

(Does anyone know how they worked underwater in prior versions?)

[vardicd]

1 minute ago, Shadowmage said:

Yeah, that'd do it.  I haven't quite decided how I want repulsors to function underwater, so currently they do nothing.  Can think of it as the water interfering with its gravioli manipulation or w/e...

It seems that there are three options to handle under-water operation:
1.) Do nothing.
2.) Always push towards surface regardless of orientation.
3.) Always push in the repulsor 'up' direction.

#2 & 3 though have unsovled problems regarding how to calculate the force to output.  And neither really makes a whole lot of sense.

(Does anyone know how they worked underwater in prior versions?)

I'm not sure that they did, in previous versions I don't think underwater was a thing.

[Shadowmage]

18 minutes ago, lo-fi said:

Great to see this so active again can't wait to see some hovercraft parts!

Also, if someone wants to make a nice model with rubber skirts, I'd be happy to lend a hand skinning them so they move when the load changes like the tracks. 

That would be an interesting effect, though I'm not sure how to setup the parts in any sort of lego-like way; it seems any hovercraft skirt would have to be a single-piece with a pre-set shape (e.g. pre-built fuselage piece).

If nobody else takes you up on that offer, I just might (in a few weeks=\).  I really would like to have some more 'hover-craft' style parts available (something a bit more realistic than repulsors ).

[vardicd]

So @Shadowmage I was already recording a video to show you what the repulsors were doing before you explained that underwater they wouldn't work, but in the making of the video, I discovered something interesting right at the end. your repulsors are going to need a new warning on them....   

 

Edited January 30, 2017 by vardicd

[Gaalidas]

On 1/28/2017 at 2:05 PM, blowfish said:

nameof is a language feature included in C# 6.  You will need Visual Studio 2015 or higher to use it (not sure what the requirements for MonoDevelop are).  My understanding is that it's evaluated to a string at compile time.

That explains it.  SharpDevelop, last I checked, didn't handle the C# 6 stuff at all.  I did really like some of the C# 6 stuff I saw back a while ago, such as running "using" directives as static and whatnot.  I just really dislike Visual Studio for its massive loading time compared to other software.  For instance... in most IDEs will show the XML comments when hovering over a method that has them.  With SharpDevelop those are loaded up right off the bat with little to no delay even in large projects.  in Visual Studio I have waited over 5 minutes and still received "still loading" messages instead.  Very irritating. 

On 1/28/2017 at 2:01 PM, Shadowmage said:

Indeed, I want to go back in and manually adjust the colors a bit when water mode is enabled.  Probably keep the base color of the water, but ramp up the color and/or alpha channels proportionally to bring it closer to white and make it more pronounced; possibly even adjust a few of the other parameters to make it more spray and less dust.  I also intend to use that water mode effect for wheels in general as several will have water-propulsion enabled as soon as I can write up the code for it.  One other bit I was thinking on was using a second particle effect for water mode like the stock spash down effects, replacing or in addition to the existing effects.

[snipped a bunch]

Let me know if you run into anything puzzling in the code.  I try to add comments where needed, but sometimes they get skipped on prototype code and forgotten about later.

Other than the "nameof" stuff, it's all pretty easy to understand.  Well, code-wide that is.  The math is gibberish for the most part... but I'm used to that.  Some of the formatting isn't really my style but, as it's your code, I won't complain too loudly.

It would be great of the water spray could, especially under slow speeds, keep some of the original water's color.  I also fear that the camera sampler is going to clip through the water and pick up the under-water shader effects or the ground under the water instead of what we're wanting it to grab.  We'd also need to adjust things differently for under-water.  For wheels, I would stay stick with the ground texture when hitting the ground under-water but, for repulsors especially, I would move the origin of the effect to just below the repulsion plate (or the back of the wheel if the user has them on the craft and still spinning) and make it a very subtle ripple of some sort if it were possible.

On the note of wheels in water... I originally wanted to make them work like the hypnodrive in that they would produce a small amount of thrust when in the water depending on a setting in the module for the wheel that would define it's tread depth for this purpose specifically.  If totally submerged, however, spinning the wheel would cancel out any thrust produced by said wheel unless it's configured like the hypnodrive.  My humorous side was going to make a special Boolean field named "screwed" so that the hypnodrive could override the under-water-nullification of the thrust.  (So it would read "screwed = true" and complete the really bad joke.  Sick eh?)  Anyway... in the end this would allow a user to, potentially, make a large paddle-boat using an insanely deep-treaded wheel positioned with its center just above the water line for maximum thrust.

This all looks great on paper... so to speak... but making it actually happen is another thing entirely.  My brain is full of ideas but I have a lot less drive, so to speak, to make it happen.

I'm just glad this thing isn't my responsibility.  It was cool being the lead programmer on a mod, but another thing entirely to actually put in the work for it.  Especially when I was just getting a bit burned out on KSP.  I'm trying to find the time to get back into it but I can't ever go back to pure vanilla parts.  The modding is going to take some time to get fully fleshed out before my first KSP post-U5 launch is possible.

[Gaalidas]

2 hours ago, vardicd said:

So @Shadowmage I was already recording a video to show you what the repulsors were doing before you explained that underwater they wouldn't work, but in the making of the video, I discovered something interesting right at the end. your repulsors are going to need a new warning on them....   

THAT... was awesome.  I know what's happening there too I think, depending on the current implementation of water-repulsion.  In the old days we used an invisible plane that would be kept under the craft (within reasonable speeds anyway... I never got around to adjusting the re-positioning-rate based on craft speed).  Under extreme circumstances the repulsor could skip under that plane and get stuck since, technically, it was really just a wheel collider that had no visual model associated with it.  Think of it as a wheel that's reacting to a flat panel clipped just above the top of the stock collider, but below the suspension.  The stock wheel will fight that panel a lot and often glitch out completely.  Repulsors, however, have extremely strong suspensions and, upon reaching land and no longer needing the slider plane, they will react violently, like a spring-loaded jumper-toy, when the water-slider gets removed and the colliders are free to do their job.  My only solution, in theory, was to make water-logged repulsors not actually function at all.  However the repulsors in your video were not under the water so technically, if re-booted, they could be made to re-initialize the water slider and slowly re-elevate the craft properly.

An alternate solution could be to temporarily reduce the suspension height to zero when the water-logged situation is detected, remove the water slider completely, and then either re-initialize and slowly raise the height back to the set value by the user or have them remain unusable under the colliders detect the planet surface and then reinitialize the repulsor and slowly step up the height.

Either way, the kracken gets a real kick out of people trying to go from under water to land with repulsors.

Edit: one more note... I think that a repulsor could still work under water if the craft is near the planet surface... but I don't see that being a necessity unless someone is sinking a super-heavy craft that totally overwhelms the buoyancy of its parts.  End edit.

 

In previous versions of KSP and KF there was no stock underwater behavior.  It was all due to camera bugs and workarounds that anyone got under water at all.  There wasn't any stock buoyancy interaction with water either... if buoyancy was even a thing in KSP.  I took over KF when under-water had just become a thing and did some preliminary work on it before I had to close up shop.  I never got anywhere though really.  I was still working on the water spray effect when that update came and, at the same time, KF started nullreffing anyone who paused the game or entered a menu during flight and I got overwhelmed.

 

By the way... with the hovercraft skirt idea, you could just build the parts as if they were single inflatable air-bag like parts.  When placed side-by-side they could, as bad as it is, clip through each-other slightly to give the illusion of simply being a bumpy skirt.  If the parts then changed shape slightly with compression and movement, then the multiple parts would creat an interesting effect similar to how the tracks react to being on the edge of an incline with each section of the suspension reacting to the shape of the terrain independently.

Alternatively you just have a set of basic shapes and make use of tweakscale integration to make them fit to the craft the user wants.  Procedural shapes for KF-based wheels have been discussed, but the complications were always a bit too part-specific to allow for procedural lengths to correctly spawn a dynamic number of colliders to match.  On paper, so to speak, it was very possible but, under Unity, not so doable.

 

EDIT: one last little thing before I finally shut up for the next hour (at least, after that no promises).  I saw on the last page a question about turning the dust effects off.  My original GUI had that option and I put it in specifically with low-end rigs in mind.  Actually, it had two options: one for turning off the camera sampler (which does have some performance drop to it) in favor of hard-coded values that were never fully updated with actual color data, and another for turning the entire thing off globally.  I may have also had a slider for capping the effect thickness, but I don't remember if that ever got released to the main distribution or not.

I was also experimenting with the ability to have a craft with lots of wheels self-limit the dust to a certain number of emitters per a certain unspecified unit of measurement and/or if another wheel part was detected in close proximity in the backward-vector of the part/craft orientation.  As you can imagine, the code got really complicated and hard to keep track of.  I never got anywhere with detecting the proximity of parts in real time like that without totally revamping how the dust module was applied to any specific part.  My most successful attempt basically made use of a dummy module attached to the part itself which would allow setting part-specific parameters for the dust on that wheel.  When the craft was loaded into the simulation ("flight scene" I believe) a vessel module would scan the parts on the craft for the existence of this dummy module and then dynamically add the real dust module to those parts, if the vessel module detected that they were worthy of it after looking for proximity and/or position on the craft of the wheels in question, and load in the data from the dummy module into them for use in fine-tuning the specifics of that part model... and then apply any global settings that had been set in the GUI and/or the config file.

It's all quite headache inducing, but I was on a roll back in the day... then the water buoyancy patch came out and I was screwed over.

Edited January 30, 2017 by Gaalidas

[Shadowmage]

@Gaalidas

The repulsors no longer use 'water sliders' or any other physical colliders (yay!).  It is now just a 'bunch-o-math'(tm) to determine their 'hit point' on the surface of the water, and then feeding that hit-point into the wheel-collider for it to use for its suspension calculations.  ( https://github.com/shadowmage45/KSPWheel/blob/master/VSProject/KSPWheel/PartModules/KSPWheelRepulsor.cs#L159-L194 )  (specifically it uses a ray-plane intersect check to see if the suspension ray would intersect the plane defined by the ocean surface)

The problem from the video, if I'm understanding it correctly, is when the repulsors move from underwater -> above water/detecting ground contact; they go from seeing zero compression to nearly full compression in a single tick, and proceed to launch things into the air.

As I'm already checking for ground-contact in the water code, I think I merely need to keep checking for ground-contact even when underwater; this would allow the repulsors to see the surface of the ground underwater, and would be using that surface for the repulsion as they were brought to the shore.  However this might still cause some 'pop' when the repulsor breaks the surface of the water, as now the water will be what it uses for raycasts (rather than the ground, which may be several meters underwater).

Hmm... Seems like it might be necessary to add a timed / lerped / smoothed term to the spring calc for when returning from underwater status.  So, yeah, perhaps your idea of setting spring length to a very small value when underwater is the best way to handle it.  The spring would then slowly return to normal as soon as normal ground/water-surface contact was detected.

 

Edit:

Yeah, what is happening in the video is this:
Repulsors are just a bit too submerged to see the surface of the water (it must be just barely too submerged; I bet if they were 0.1m higher on the craft they would float just fine).
They get driven towards the shore.
As they approach the shore, they start to see the ground underneath the water and push up a bit.
Now they are ~0.01m above the surface of the water, and they start to see -that- as the new surface, and start to push up from there.  Since they are based on a linear spring, and are seen as being at max compression, they exert put out maximum force, and things go flying.

I've got an idea on how to handle this, but need to think on how it would work with repulsors not aligned downwards (I don't want to turn them into underwater propulsion devices...)

 

Edited January 30, 2017 by Shadowmage

[lo-fi]

2 hours ago, Shadowmage said:

That would be an interesting effect, though I'm not sure how to setup the parts in any sort of lego-like way; it seems any hovercraft skirt would have to be a single-piece with a pre-set shape (e.g. pre-built fuselage piece).

If nobody else takes you up on that offer, I just might (in a few weeks=\).  I really would like to have some more 'hover-craft' style parts available (something a bit more realistic than repulsors ).

Please feel free to  Yes, a limitation might be that you have fixed configuration part like the tracks. Hovercraft parts would fit well in the mod, though.

And very cool that the new colliders don't need the water slider any more - that thing was a pain at times!!

[SpannerMonkey(smce)]

31 minutes ago, Shadowmage said:

The repulsors no longer use 'water sliders' or any other physical colliders (yay!). 

 

30 minutes ago, lo-fi said:

And very cool that the new colliders don't need the water slider any more - that thing was a pain at times!!

I second that yay,  I recall much hilarity ensued when testing the very first water colliders, not sorry to see  the water plane go.

[Shadowmage]

With regards to ALG -- I'm considering giving it a new suspension mechanic that would probably be a bit more stable for most aircraft.  Probably best explained through pictures.

Currently the wheels work like this when compressing, with compression along the line of the suspension strut (this causes wheels to move inward/outward with compression changes, changing the width of the wheel-base with suspension compression):

The new proposed method would use both angle of the main strut and suspension strut extension to keep the relative position of the wheel while compressing upwards, all while keeping the actual collider aligned with the ground:

This would require entirely new rigging for the wheels (both hierarchy and active constraints), and new code for proper positioning and setup of the wheel collider position and orientation.  However I feel that this new method (if implemented) would give much better looking and more stable suspension for most aircraft setups.  Yes the rigging and new code would be a bit of a pain, but I think it would be worth it in the end, and I'm fairly confident that I can figure out the rigging and math needed for it.

(note that this would not change anything when the main strut is aligned straight with the ground, and would only effect cases where the main strut was angled; the more angled the main strut, the more it would rotate and the less it would compress)

Thoughts?

Edited January 30, 2017 by Shadowmage

[StereotypicalBrit]

@Shadowmage

I don't know much about coding/animation, and am assuming what you are proposing is going to be tough to implement. However, if the resulting system is both more stable and better looking (in terms of aesthetics), go for it. Even if it doesn't quite work the way you hoped it would have, who knows, it might provide the basis for another part of modding for KSP.

Keep up the fantastic work! 

[Beetlecat]

@Shadowmage -- I totally agree with your plan. It's in-line with how planes like the F-16 (though there's a physical armature there, as well) and f-104 do it; both planes that have distinctly angled gear. F-18 sorta does, but it uses a cool knee joint instead to keep the wheel straight and level.

I'm really glad you're finding this an engaging challenge. Really inspiring.

Edited January 30, 2017 by Beetlecat

[KodiaksFury]

For me its stuck in the loading screen on KerbalFoundries/Parts/ALG-Large/KF-ALG-Large