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

[lo-fi]

It's still knocking around somewhere on my pc... I never got to fixing the persistence issues. Other than that, it worked well.

[XOC2008]

5 hours ago, lo-fi said:

 

Sadly, it was a frame-rate munching monstrosity. The best place for it would probably be in the Kerbal Terrain System... Code is all in the old KF dev branch, though

The handler was probably more relevant to KF, I think:

 

That's cool. I was just curious if it was going to be available maybe as just a greeble. I could use that dozer blade on anything without the animations. I know nothing of coding and the like though, so I doubt I'd do anything with it myself.

[TiktaalikDreaming]

7 hours ago, lo-fi said:

From experience, modeling with the rigging in mind is a HUGE advantage. Get the orientations, hierarchy, pivots and positions right, THEN send it over to unity is the way to retain your sanity...I could rig a set or tracks in minutes with my workflow, and if you don't break the prefab connection, updating is so simple. I even used to export dummy objects with the models!

Agreed.  Having the orientations,emtpy transforms, colliders etc all part of the blender (or whatever) set up is a massively better way of working.  Having done that, and early on, not done that, I think I can say that with conviction.

Not breaking that prefab is a powerful tool.  :-)

[V8jester]

@Shadowmage You asked us to test KF in "strange" ways..... Here ya go

 

[Shadowmage]

On 2/17/2017 at 7:21 AM, V8jester said:

@Shadowmage I was working on resurecting my LCAC from 1.0.5 last night. And I realized the repulsers (work much better / are much more powerful) do not have any AG buttons available. In old KF there were options to turn off as well as raise / lower ride hight with an AG. Could this please be added in a future release?

Adding the on/off is certainly doable.  Adjusting height through action groups..... less easily doable.  Will see what I can come up with though.

 

On 2/17/2017 at 9:45 AM, lo-fi said:

From experience, modeling with the rigging in mind is a HUGE advantage. Get the orientations, hierarchy, pivots and positions right, THEN send it over to unity is the way to retain your sanity...I could rig a set or tracks in minutes with my workflow, and if you don't break the prefab connection, updating is so simple. I even used to export dummy objects with the models!

 

I was referring more to the fact that I could be sent raw geometry, do the rigging setup in blender myself, and handle all of the Unity end of things as well.  Easier for me to do all of the rigging than to try and explain / teach someone how it should be rigged; I'm terrible at teaching complex subjects.  At this point I've re-imported enough .mu models into blender and re-rigged them from essentially scratch... that it really doesn't take me too long.  It certainly would be faster if they came to me at least mostly rigged correctly, but I'm willing to compromise a bit

 

16 hours ago, V8jester said:

@Shadowmage You asked us to test KF in "strange" ways..... Here ya go

 

Interesting.  Obviously there are some problems regarding multi-rigidbody interactions (the jittering), but looks to be working better than I had expected considering that kind of stuff is completely untested by me.

If someone can come up with a (set of) otherwise stock craft(s) that exhibit those problems I'll do some investigation for potential fixes in one of the future releases.

Edit:

Strangely this contraption does not experience any of the jittering.  It does expose a few other problems with vehicle-on-vehicle setups (solvable problems), but is otherwise quite stable:

Definitely interested to see how your LCAV turns out under the new version

Edited February 18, 2017 by Shadowmage

[XOC2008]

I've found I have to lower spring/damper numbers to get a handle on the jitteriness when loading onto a vehicle or, much like Jester, working with a bridgelayer. (We were working on one simultaneously, his beats mine!) sometimes have to lower it to zero. Most vehicles I have are at around .75 each until I need to adjust, on 20t+ vehicles.

[V8jester]

Hey @XOC2008 I still wouldn't have built one if we weren't tossing ideas back and forth

I'll have to try that. That video was my very first attempt, mistakes and all. I'll have to play a little more with the settings and see if I can't calm it down on any future videos. - Thanks!

Edited February 18, 2017 by V8jester

[V8jester]

@Shadowmage Along the lines of "weird" testing. I am reviving my LPD along with my LCAC. This is perfect as it tests interaction of a tracked vehicle docked to a repulsor vehicle on water going to land

I doubt you can get much weirder than that. So after reassembling everything. The repulses will not remain in a powered off state from the SPH. The LCAC and the LPD will repel each other with spectacular force upon loading. I managed to get it to launch to the grass next to the runway one single time so far. (Still tinkering) So something I can say is docking a vehicle with repulses is like balancing the empire state building on a ball point pen. It will work but it's a delicate procedure. I think this will become drastically easier once we can launch unpowered  repulsors and toggle them in flight though. I will continue working on this one and one I get it working I plan on doing a Military type of a video. Been wanting to do it for some time now. Just been fairly limited on vehicle diversity / quantity until more recently  On the bright side when I did get a successful launch I was able to undock the hovercraft and drive it right into the water with properly working repulsors. Old KF could not do this. I had to load a new scene with a working LCAC on one of my videos. So this looks very promising.

 

Edit

I am having better luck when this setup:

 Repulsor craft (The LCAC) is the root vessel. So the LPD (boat) is a sub assembly attached in mass to the underside of the hovercraft.

Edited February 19, 2017 by V8jester

[V8jester]

11 hours ago, Shadowmage said:

....

Definitely interested to see how your LCAV turns out under the new version

Well it's working. I just have a lot of tinkering to do. The toggleable Repulsors will absolutely make a difference (whenever you get around to it man) I'm just happy to have KF back again

 

 

[Vanguard-Warden]

O_O

 

I need that!, how did you do that?

[TOMMY (JEB 2.0)]

neeeeeedddddddd on/off repusers !!!!!

[V8jester]

9 hours ago, Vanguard-Warden said:

O_O

 

I need that!, how did you do that?

Lots of Hot Pockets and Zena tapes

[Shadowmage]

I am pleased to announce that @TiktaalikDreaming has offered to help create new part models for Kerbal Foundries.   Might take a few weeks to get things moving up to speed, but hopefully there can be some new parts in the near-to-mid term.  Not quite sure what will be coming up first, but whatever it is, I'm sure it will be great     Please do not bother him with problems related to configs or plugin / code bugs, or anything regarding the existing models or assets; those are entirely on me to maintain/fix/work on.

Will be spending a bit of time this week to talk through future plans, set out a bit more of a concrete roadmap, and general organization and project cleanup.  Will likely be using the github-wiki for most of this information, so feel free to check by there to see where things stand and where they are going.

(sorry, meant to do this over the weekend, but had a bit of a crazy schedule)

[Svm420]

@Shadowmage

If I may ask. What is left that you  want done before the next release? 

Thanks! 

[Shadowmage]

27 minutes ago, Svm420 said:

@Shadowmage

If I may ask. What is left that you  want done before the next release? 

Thanks! 

In a word: Testing.  Lots and lots of internal testing on the new features, mostly on the zero-suspension-collider stuff, but also on the recently reworked motor mechanics, reworked ALG rigging, and on the as-of-yet-completely-untested water propulsion module.  Gotta check for proper functioning of the new features, gotta check for regressions and recurrences of old bugs, gotta check for new bugs in the new features, need to check for conflicts between the old and new features, and need to check about a thousand different vehicle setups for every little plugin change.  And as it is just me doing it all... it can sometimes take awhile (especially when I'm busy at work and have little patience for 'testing things' when I get home).

There is also a bit of 'work' to be done on the water-mode for dust-effects, linking it in with the water propulsion module; but the latter needs testing before the former can be worked on.

What would help would be someone who wouldn't mind doing regular testing of the dev branch.  I lack the time to package up releases that are intended only for testing, but the KSPWheels dev branch most often has a usable plugin ready for download that contains all of the recent development updates.  Might also need to hook into the KF dev branch to grab the updated configs/models/assets that correspond to the plugin that is in-use.

[rasta013]

1 hour ago, Shadowmage said:

What would help would be someone who wouldn't mind doing regular testing of the dev branch.

I haven't got as much time for testing as I used to but I will definitely help out where I can.  Is there any specific setup you want tested, as in stock+KSPWheel+KF only or do you want testing across the board against other mods?  Just want to know how to setup my install to test specifically what you want and to be sure to avoid anything that may be of a concern.  Just as a basic setup for testing I would usually have KER/MJ installed for diagnostic readouts and TweakScale for mods supporting it (like KF).  Other than that I'll run anything you want or remove any of those 3 if you don't want them in the way of results.

[0111narwhalz]

I'm pretty sure KF handles its scale-tweaking in-house, so Tweakscale might be unnecessary.

[Shadowmage]

2 hours ago, rasta013 said:

I haven't got as much time for testing as I used to but I will definitely help out where I can.  Is there any specific setup you want tested, as in stock+KSPWheel+KF only or do you want testing across the board against other mods?  Just want to know how to setup my install to test specifically what you want and to be sure to avoid anything that may be of a concern.  Just as a basic setup for testing I would usually have KER/MJ installed for diagnostic readouts and TweakScale for mods supporting it (like KF).  Other than that I'll run anything you want or remove any of those 3 if you don't want them in the way of results.

Excellent, thanks for the offer.

The specific setup that needs testing is the dev branches from both KSPWheel ( https://github.com/shadowmage45/KSPWheel/tree/dev ) and KerbalFoundries ( https://github.com/shadowmage45/KerbalFoundries2/tree/dev ).  Specifically the updated plugin is needed from KSPWheel, and the updated models and configs from KF.  If you have any further questions or need detailed instructions on which files / how to set them up, please let me know.

What other mods you use in testing is up to you; my standard in my dev install is MJ (and/or KER), VesselMover and/or HE, and usually not much else.  Please keep in mind though that I often request craft files when working on tracking down bugs from bug-reports, and it is pretty much necessary that they are stock+KF only (no tweakscale or other parts-mods used).  The one exception would be if there is a specific conflict between KF and another mods parts or functions, in which case I'll need to know what mod and which parts and/or functions; these get moved down the priority list though as the time investment needed is often quite substantial even for minor conflicts.

One thing that could use continued testing is compatibility with FAR.  I don't personally use it, so am about the worst choice for someone to test it; I wouldn't even be able to tell if something was broken (unless it is blatantly obvious).

[rasta013]

Ok - I test the same way generally as well.  No extra frills and all stock parts for testing to be able to Keep It Simple Stupid.  I'll just begin by banging the crap out of the modules and parts themselves to try and find any quirks I can track down and then will move into testing them against other mods, specifically ones that integrate into functionality that may require interfacing with rovers/wheels.  Unfortunately, I'm in the same boat as you are in re: to FAR.  I haven't used it since .90 days and even then I was only lightly using it.  Do you want issues reported here or opened on Git?

 

[Shadowmage]

@rasta013

I would suggest using github for issue tracking (probably on the KF repository - https://github.com/shadowmage45/KerbalFoundries2/issues ) - though I would open only a single issue titled 'dev-testing issues - versionNumberHere', and placing all reports and updates in that single ticket / thread.  Will help keep the tracker organized by keeping all of the dev-version related issues in the same place.  If it turns out a bug/problem exists in the current release versions a proper ticket for that problem can be opened, so that the known-issues are kept up-to-date for the current release.

Good things to test from the current dev branch(es) are:

• Adjustable Landing Gear - all of them, all features.  The models and plugin in the dev branches are entirely new/re-rigged, so all of it needs testing.
• Motor Power Mechanics and Balance - How does the power output and power draw feel on all of the KF wheels, at both default scale and rescaled (up or down).
• Repulsor action groups - power on/off and height action groups are new and could use a bit of testing.
• Scaled part balance - how do the stats feel on wheels at different scales?  Mass, cost, max speed, motor power, and load handling can all be balanced/configured based on feedback.  Even adjusting the balance on the base scale is an option if needed.
• Should be ready shortly - water propulsion for wheels and tracks, as well as the water dust-effects being linked to it.  In order for water propulsion to work at least part of the visible wheel must be above water.  Force output needs testing for various wheel types and scales, and how viable it is for various craft designs.

 

Edit:  Water propulsion working, will probably see a few more updates before finished, but works as is, including linking in the dust-effects as water spray.

Edited February 21, 2017 by Shadowmage

[rasta013]

Excellent sounds good!  I've pulled the latest dev version updated 5 hours ago so will start banging away on it.  Github is my preferred method to track issues also so joy to all !

[DocMop]

@Shadowmage

It should be considered that the screwdrives have no technical need to be partly over water for propulsion. Unfortunately no time for testing interesting stuff right now

Edited February 21, 2017 by DocMop

[SpannerMonkey(smce)]

6 minutes ago, DocMop said:

It should be considered that the screwdrives have no technical need to be partly over water for propulsion.

I second this thought

if anything they should be more efficient when fully submerged, but we wont quibble over that well I wont ...

 then again there'd be some losses for the massive support brackets and associated drag that would likely nullify any submerged advantage.  If i recall all that time ago the screw drives were quite effective for small rover marine travel with fairly decent propulsive force

Edited February 21, 2017 by SpannerMonkey(smce)

[DocMop]

For ease of use and extendibility I would suggest a part config value like "waterPropulsionLevel". That would be a float value which works like this:

0.0 = No water propulsion
>0.0 to 1.0 = maximum percentage of part immersion depth for water propulsion to work

I guess that would catch all possible use cases.

Then, for propulsion effectiveness you can do the following:

//immersion = percentage of part immersion in water
//toDeepFactor = ineffectiveness factor of too deep immersion
float getWaterPropulsionFactor(float immersion, float toDeepFactor)
{
  	float propulsionFactor = 0.0;
	
  	if(immersion <= 0.0) //above water
    		return 0.0;
	if(waterPropulsionLevel <= 0.0) //no water propulsion
    		return 0.0;
  
  	if(immersion > waterPropulsionLevel) //to deep -> reduced propulsion
    		propulsionFactor = waterPropulsionLevel / (toDeepFactor * immersion);
  	else //not deep enough -> reduced propulsion
    		propulsionFactor = immersion / waterPropulsionLevel;
  	
  	return propulsionFactor;
}

Disclaimer: Just a fast prototype, no actual KSP coding experience.
Warning: toDeepFactor can not be 0.0 because of DBZ!

Edited February 21, 2017 by DocMop

[Shadowmage]

7 hours ago, DocMop said:

@Shadowmage

It should be considered that the screwdrives have no technical need to be partly over water for propulsion. Unfortunately no time for testing interesting stuff right now

Good point.  I had written the module to explicitly check for submersion level, using 50% submerged as the 'max force output' point, with zero force output if the wheel was fully submerged.  Shouldn't be too hard to add a config field to specify the max submersion depth.  Will also have to no longer early-out when the wheel is fully submerged, but instead always check if it is within or greater than the 'max' specified in the config.

In short -- absolutely solvable, but will require a few code changes to accommodate it.