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

[lo-fi]

Cheers dude thanks for keeping an eye in my absence!

[Gaalidas]

No problem, it's just what I do. I keep an eye on things whether you want me to or not. It's in my nature.

On that note, I haven't updates github yet, but I've started transferring many of your comments in the code into XML documentation blocks. I don't actually know a lot of what things are used for, but at the very least I have plausible placeholders entered for most things in the code and will have the rest completed when I get my next break from school-related coding.

I just can't wait to see something new from you. Any chance of that happening in the near future? I tried to get Zodius... err... however his name goes... to try and make the new IR model rework wheels use your steering/suspension modules, but he believed their base orientations and such wouldn't work with your system. I have my doubts that your system is that rigid, but i really don't understand how anything really works behind the scenes so I'm not arguing just yet.

[riocrokite]

hey guys,

I'm thinking about a MM mod that ups considerably EC usage of your tracks/wheels so one need some kind of heavy EC generator or nuclear reactor to produce energy needed for large tracks/wheels.

First of all are you guys okay with the idea? I cannot find it in part .cfg I guess it's currently hardcoded into .dll (chargeConsumptionRate) and it's dependent on torque exclusively?

------------------------------------------------

Short comparison to real life assuming 1 EC = 1kW:

------------------------------------------------

M1 abrams gas turbine = 1100 kW (62t)

Hauling truck engines power in kW compared to weight moved:

edit: how goes work with hitch?

I have a nice additional idea for how to use it (at least for hauling heavy cargo). Currently stock wheels have very limited mass that can be hauled on them. I was thinking about introducing some kind of wheels without motor and steering however as a trade-off they could hold on and not break much heavier weight.

So truck-trailers setup with hitch could be very legitimate gameplay setup in this scenario.

Edited April 23, 2015 by riocrokite

[Gaalidas]

Excellent idea if you want to suffer... or like realism. It's the sort of mod that makes me want to go kill something... fuzzy... slowly...

But good idea anyway. Realists will love it.

[riocrokite]

I'm glad you like it Gaalidas, hope lo-fi is okay with that too. You can take a look here :

http://forum.kerbalspaceprogram.com/threads/107791-0-90-Mobile-Frame-System-MFS-%28v0-3-0%29-04-04-2015?p=1854051&viewfull=1#post1854051

From gameplay perspective your big vehicle will have to be few tons heavier to account for power generator so not that much of a problem. Since I plan machinery that also uses lots of energy you could have interesting choices: drive then stop to process stuff (so you don't overload EC generator), drive slower (lower torque) to conserve energy, use small generator and huge EC storage (flywheel) for medium distances if you want light vehicle or recharge vehicle at your base etc.

The one thing I have to ask you is whether it's possible to modify Kerbal Foundries .dll to move chargeConsumptionRate to .cfg so it could be modified from part to part.

[lo-fi]

Comment blocks sound like a great idea!

I did run through it with Zodius; that stupid attach node symmetry bug means I would either have to change the code and remodel all my parts (which will break every single game using the parts), create a fork just for his stuff, or recode things so the orientation is configurable. None of which I'm keen on doing, as that part of the code is like the gunnery from Nostalgia for Infinity (some may get this reference - I bet most won't).

Yeah, feel free, Riocrokite! chargeConsumptionRate is indeed what you want. It's not specified explicitly in configs as it defaults to 1 in code.

Non powered wheels are easy enough; I think there is even a config field for hasSteering and hasMotor, though it's months since I looked at my own code. If not, just set the curves to zero. Suspension stuff... Not sure there's an easy way to up that without other stuff. Could use the tweakscale field maybe?

New stuff? Lacking time and motivation I'm afraid. V8 land rover project, new lady, summer horse stuff and a healthy business kinda get in the way of grinding KSP into submission :/ I may get a flash of inspiration at some point, but more likely come winter! Mostly, its more perspiration than inspiration at this point though, which is why I've moved on to other things I guess.

[Gaalidas]

Well, that's a shame (for us anyway, not so much for you). I'm not giving up hope that eventually I'll be able to take apart your code and try to make things more flexible. I continue to see more of your parts in more videos and screenshots all over the place. If you're lacking inspiration, i may try to put together an updated unofficial release at some point. I do hope, however, when KSP 1.0 comes out, that you'll return to make sure nothing gets severely broken.

On other topics, I've been messing with the suspension settings using tweakscale but haven't had a chance to test anything out due to some strange memory usage issues and whatnot. I'm also going through my own burnt-out stage again. As for modifying the code to allow more config-level parameters... well, that's actually easier than you might think. In fact, part of my modifications to lo-fi's original code is not only to move comments into documentation nodes for VS/#Develop/whatever to pop up when hovering over the code, but also to move more and more of the hard coded stuff into KSPField objects and add range-checks to the methods and functions that make use of those fields directly.

Edited April 25, 2015 by Gaalidas

[riocrokite]

stuff....

Well, RL is most important so it's great to hear about exciting things happening in your life:) I guess, in the long run, you'll be glancing from time to time at forums to check out 'your KF baby'

[fatcargo]

I have found a craft steering/driving bug when using a KF Large Wheel ALPHA attached to IR rework part "Hinge Pivotron - Basic".

I have attached a KF wheel to hinge which is in 0 position. Hinge itself is attached and rotated onto a tweakscaled M-beam.

Parts/mods used : stock, tweakscale, quantum struts, KF wheels, IR rework, IR parts reworked by ZI.

Here is the craft file to test it out.

Strangely, this craft, which uses stock TR-2L wheels, works right when launching in stowed form, then deploying.

[riocrokite]

Couple of observations from wheels/tracks balancing front:)

Balancing tracks is quite entertaining task with most difficult thing being finding right total friction from track as compared to wheels. What I've found is this, test is based on towing tracked or wheeled tractor at low speed with engine shut off:

source

so not suprisingly tracks are worse on hard surfaces (50-100% more drag), however on ground are equal or better (dependenet on muddiness)

Taking into consideration planets' surfaces on average the rolling friction should be the same for wheel and for track or even smaller for track than for wheel (assuming number of wheels <> tank wheels) are the same .

However efficiency of track are determined additional factors:

- travelling speed of the tank (higher speed = greater power loss in the track)

- transmitted power efficiency (smaller with increase of transmitted power)

- track tension (friction in the track joint, dependent on the tension of the track, or weight put on track)

- length of the track (longer track = greater power loss)

- track design

- other more fine variables like track design, track wheel diameter and others

From gameplay standpoint I can account of all those things (maybe except ground type) by fine-tuning rpm/torque curve and rollingResistance.

Ideally rolling resistance could be defined by curve but I can live with it being constant:) (I just tweak torque curve to account for that).

However I feel that KSP/Unity has a shortcoming that it doesn't account for weight. In other words wheels/tracks have same max speed / acceleration no matter what weight I put on them. So it's like there's constant inertia force no matter what mass vehicle has. Which I guess cannot be changed easily since it's embedded in Unity physics:/

This somewhat defeats the purpose of larger wheels/tracks needing more energy, in other words why do I need larger wheels/tracks when smaller ones give me comparable acceleration and top speed no matter what weight do I carry.

Edited April 27, 2015 by riocrokite

[fatcargo]

Update : i have built a new frame for my drill rig with additional IR parts that orient wheels on vehicle spawn, even when vehicle is in stowed position. This way, KF wheel orientation is maintained in respect to vehicle. Now it is wheels work correctly.

Parts/mods used : stock, tweakscale, B9, IR plugin rework, IR parts ZI rework, KF Wheels, Quantum Struts.

Here is craft file for demonstration how to bypass the aforementioned bug. Note the landing legs as support for launch, IR servo group to deploy wheels and action group 1 to lock wheels into position once deployed.

Edited April 27, 2015 by fatcargo

[lo-fi]

Well, that's a shame (for us anyway, not so much for you). I'm not giving up hope that eventually I'll be able to take apart your code and try to make things more flexible. I continue to see more of your parts in more videos and screenshots all over the place. If you're lacking inspiration, i may try to put together an updated unofficial release at some point. I do hope, however, when KSP 1.0 comes out, that you'll return to make sure nothing gets severely broken.

On other topics, I've been messing with the suspension settings using tweakscale but haven't had a chance to test anything out due to some strange memory usage issues and whatnot. I'm also going through my own burnt-out stage again. As for modifying the code to allow more config-level parameters... well, that's actually easier than you might think. In fact, part of my modifications to lo-fi's original code is not only to move comments into documentation nodes for VS/#Develop/whatever to pop up when hovering over the code, but also to move more and more of the hard coded stuff into KSPField objects and add range-checks to the methods and functions that make use of those fields directly.

Feel free to tinker! I'm just seeing if I can get 1.0 to download so I can see if I need to update. If I can remember how to code..

Well, RL is most important so it's great to hear about exciting things happening in your life:) I guess, in the long run, you'll be glancing from time to time at forums to check out 'your KF baby'

Cheers dude. You're right, I couldn't just leave it without checking in at least now and then

Couple of observations from wheels/tracks balancing front:)

Balancing tracks is quite entertaining task with most difficult thing being finding right total friction from track as compared to wheels. What I've found is this, test is based on towing tracked or wheeled tractor at low speed with engine shut off:

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

source

so not suprisingly tracks are worse on hard surfaces (50-100% more drag), however on ground are equal or better (dependenet on muddiness)

Taking into consideration planets' surfaces on average the rolling friction should be the same for wheel and for track or even smaller for track than for wheel (assuming number of wheels <> tank wheels) are the same .

However efficiency of track are determined additional factors:

- travelling speed of the tank (higher speed = greater power loss in the track)

- transmitted power efficiency (smaller with increase of transmitted power)

- track tension (friction in the track joint, dependent on the tension of the track, or weight put on track)

- length of the track (longer track = greater power loss)

- track design

- other more fine variables like track design, track wheel diameter and others

From gameplay standpoint I can account of all those things (maybe except ground type) by fine-tuning rpm/torque curve and rollingResistance.

Ideally rolling resistance could be defined by curve but I can live with it being constant:) (I just tweak torque curve to account for that).

However I feel that KSP/Unity has a shortcoming that it doesn't account for weight. In other words wheels/tracks have same max speed / acceleration no matter what weight I put on them. So it's like there's constant inertia force no matter what mass vehicle has. Which I guess cannot be changed easily since it's embedded in Unity physics:/

This somewhat defeats the purpose of larger wheels/tracks needing more energy, in other words why do I need larger wheels/tracks when smaller ones give me comparable acceleration and top speed no matter what weight do I carry.

Thanks for the info, that's really interesting. I'll get back to you when I've had a bit more time to absorb.

Update : i have built a new frame for my drill rig with additional IR parts that orient wheels on vehicle spawn, even when vehicle is in stowed position. This way, KF wheel orientation is maintained in respect to vehicle. Now it is wheels work correctly.

Parts/mods used : stock, tweakscale, B9, IR plugin rework, IR parts ZI rework, KF Wheels, Quantum Struts.

Here is craft file for demonstration how to bypass the aforementioned bug. Note the landing legs as support for launch, IR servo group to deploy wheels and action group 1 to lock wheels into position once deployed.

Ahhh. So the wheels look at their orientation in relation to the craft at start of flight to determine which direction the motor needs to go, and their relative position for steering. I've not looked at the craft, but it sounds like you're foxing that with your retract/deploy method. I suspect a save/reload once deployed ought to fix as a workaround, but there's not a lot I can do apart from maybe adding a "reconfigure" button which would be of limited use to most people.

Looking at 1.0 compatibility now...

[Gaalidas]

gah! I was just about to get my game stable again and then they release 1.0 and now everything is going haywire again.

[lo-fi]

Such is life

I checked out a few bits in 1.0 - seems like everything will be OK for this mod so I've updated to reflect. I didn't try TweakScale, though, I have to admit!

[teepee2345]

Maker of this mod, congrats on having it work fine in 1.0 without any update.

[fatcargo]

Lo-fi thanks for reply and a workaround. As for "reconfigure" yes it is mostly useful to IR / kOS folks, so adding it to be visible only to kOS as event should suffice for now. Backburner stuff anyway. One mystery remains though - how are stock wheels able to find proper orientation ?

[lo-fi]

Maker of this mod, congrats on having it work fine in 1.0 without any update.

Cheers! No great secret - its just that I don't tend to use much of the KSP API, so when they change It, theres no impact

Lo-fi thanks for reply and a workaround. As for "reconfigure" yes it is mostly useful to IR / kOS folks, so adding it to be visible only to kOS as event should suffice for now. Backburner stuff anyway. One mystery remains though - how are stock wheels able to find proper orientation ?

No drama. I honestly have no idea what the stock modules do I'm afraid. The KF modules require far more information than stock, in that they need to know position in the vessel relative to each other as well as their orientation to enable the advanced steering features, groups etc.

It's complicated trying to cover all the bases in a sandbox environment where just about anything is possible and nothing is fixed, though. I'll keep that particular situation in mind and see if I get any bright ideas. Thanks for the info, and a sensible bug report!

[Gaalidas]

Such is life

I checked out a few bits in 1.0 - seems like everything will be OK for this mod so I've updated to reflect. I didn't try TweakScale, though, I have to admit!

You're thinking too much like a developer, and not enough as a tester. The Dev says "heck, it worked before, so surely everything is fine." and the tester says "Your baby is ugly and smells funny, go fix it!" and the battle of the lost staplers begins. Many deaths.

As for stock wheels, I don't think they even worry about orientation. That's why you can place wheels are strange angles and still have them work the way you expect (within reason). KF wheels are much more finicky about where they are initialized and if you move them, they get cranky. I believe some sort of "reset" would be a good idea for many of the problems we've faced with KF products. Included is the issue with repulsors within physics range only functioning on the last vessel to be launched. If a reset could be activated when such issues arise, you might be able to get around those issues without having to reload the scene. Eventually, with some testing, we might even be able to automate the reset process for certain situations, such as when a vessel change is detected.

It seems to me, you could export all the scene-load initializations into a separate function and call it from the scene-load event, but also be able to call it from a GUI item labeled "Reinitialize" which would, when activated on any KF part, redo the initialization process for the current vessel. Sorta like the current actions for applying steering settings, or applying all wheel settings which are available now.

Edited April 28, 2015 by Gaalidas

[lo-fi]

Now them there are crazy thoughts.

The repulsor physics range thing is a pain, as is just about everything to do with vessel packing, start routines and all that shenanigans. Experience trying to get the hitch working taught me one thing about KSP, and the three letter W, T and F pretty much sum it up.

Also, just seen the dds support in 1.0. Will look at converting textures as soon as I can.

Edited April 28, 2015 by lo-fi

[lo-fi]

Update:

Conversion to DDS seems to trash texture quality, so think I'm doing something wrong. Will keep hacking at that.

Quietly delving into the murky world of IVA's (yes, I'm teasing...)

[V8jester]

Update:

Conversion to DDS seems to trash texture quality, so think I'm doing something wrong. Will keep hacking at that.

Quietly delving into the murky world of IVA's (yes, I'm teasing...)

Are you using the ksp .dds conversion tool? I recall reading on the forum, it will flip the texture. Not sure if that's horizontal or vertical. Could this be the issue?

[lo-fi]

Yeah - it seems to spit out the texture the right orientation (I have a feeling it was dds loader that flipped them, but I could be wrong), but the quality is shocking after. I'll have to do a little research into what it's looking to be fed, as I'm sure it's my fault. Not blaming the tool at this stage!!

In other news:

Yeah, I couldn't stay away forever Progress will be slow, but bits and pieces will appear here and there eventually. That's a proper command pod using JSITransparent, by the way. Not an external command seat.

[Gaalidas]

A note: I don't think DDSLoader is necessary anymore. Squad wouldn't make their own content dependent on a mod, so I have a feeling they've integrated DDS loading into the stock loader.

The vertical flipping is actually very necessary. When you export DDS files from the asset files, which are loaded before DataFiles, you have a DDS file which is upside down. If you use a generic image viewer (such as IrfanView) to view the DDS and then re-save it as a PNG, you will need to manually flip it vertically for the PNG to be loaded into the game correctly. When converting to DDS, you need to not only change its format, but also flip it again in the vertical axis for KSP to use it correctly. I don't know why it works that way, but it does. The DDS conversion utility that was mentioned does this automatically for you.

As for quality, DDS is actually quite accurate if you use the correct DDS format. Some formats will screw up different images in different ways. I don't pretend to know what format is best for each case, but the utility does a lot of that for you and has been very good at it. However, the real culprit is mip-mapping. Unless you generate mip-maps using Gimp (in which case you can specify the filter to use and what not) then the mip-map generator will simply do what it does by default and KSP will then load those mips instead of the full resolution file based on whatever logic it uses to determine what the texture resolution for each instance is supposed to be. Sometimes that first mip-level will be a major reduction in quality. Some tricks I've found while modding games like Skyrim is to manually delete a mip-level from the file (I used utilities specifically made for those mod flatforms, so not much use here at this time) forcing it to re-adjust its mip-levels to compensate for the lowest quality level being a different mip-level than it expected. Other tricks were to simply replace the first mip-level with the full resolution texture. This bloats the DDS file a bit, but tricks KSP into thinking that it's loading a lower resolution version of the texture than it really it.

How I do it: I make sure that the texture isn't overly large (I do a lot of resizing before I install due to running KSP on a laptop that wasn't specifically designed for games) and then I launch the utility and I unclick the box that tells it to generate mip-maps. KSP will load the full resolution every time it needs the texture. Even at extreme distances. Yes, this has an impact on performance for large textures, but it also reduces the situation where a very close proximity texture is being loaded under a mip and is appearing lower in quality.

I'm really hating that mods are now distributing in DDS format because it makes quickly editing them for performance a bit of a pain. I'm going to need to find a way to add DDS->PNG conversion to my mod unpacker batch files that I use to extract all of the mod archives and process their various files for unwanted readme files and textures in a over-sized format.

Addon: By the way, KSP still loads up all the other texture types that it did previously (no idea if they fixed the TGA issues, however).

EDIT: So, you liked my comment about the staplers. That was a moment of pure randomness.

- - - Updated - - -

In other news:

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

Yeah, I couldn't stay away forever Progress will be slow, but bits and pieces will appear here and there eventually. That's a proper command pod using JSITransparent, by the way. Not an external command seat.

I want it. Badly.

Edited April 29, 2015 by Gaalidas

[lo-fi]

Ahhhh, mipmaps make perfect sense. Thank you! Yeah, I guessed the DDS loader mod is now obsolete (not that I ever used it). I'll do some further experimentation and benchmarking to see what the deal is. Hope you find something to do easy conversion.

The comment was too genius to be left to be forgotten in an obscure forum post!

Patience, my young padawan, patience...

[0111narwhalz]

If ever you run out of ideas, how about a simple, "bolt-on" leg? Kind of like BahamutoD's CritterCrawlers, except only one leg. Chances are, you could simply make a wheel with the appropriate animation. That'd be good enough for me, at least.

Seperately, how about changing the sound on that blasted generator? It's way too loud; I wanna hear the repulsors.