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

[Gaalidas]

Crud, you're messing with my logging utils? That class name was a feature you know, and if you didn't specify a class name it would simply not include it. Everything was optional.

Though, to be fair, I was considering scrapping them since lo-fi doesn't use them at all and they're a pain to set up all the time. I really wish it was easier to simply set them up so we could call them from any of the other class in the project the same way you use the simple "print" method. Oh well.

Also, I never really got the main planned feature of the utils created, which would have allowed for any log entry being sent to the console to be put in a separate log that could b e put either in KerbalFoundries\Logs, the root directory of the mod, or in KSP_Dir\Logs like I've seen some mods do. I got too busy with DustFX to finish the logging system.

Edited July 25, 2015 by Gaalidas

[lo-fi]

Pure laziness, I assure you! Most of my debug messages tend to be a quick program flow indicator, so I tended to bing them in without even thinking.

Motor cycle wheels ought to be possible, yes. I'll add to the idea pile. TT track is unlikely to see its way to release, having been superseded by the simple track, which just needs texturing. BV track needs texturing also.

By all means have a go at the DDS conversion. I could never get it to look crisp, no matter what I did. Mark those with borked normal maps as a bug in the tracker and I'll fix!

We're getting close, guys.

I'm quite looking forward to getting back down to some modelling! Some nice stuff in the pipeline that I've just not had time to work on. V8Jester is kindly helping with the rollcage IVA.

Edited July 26, 2015 by lo-fi

[*Aqua*]

Though, to be fair, I was considering scrapping them since lo-fi doesn't use them at all and they're a pain to set up all the time. I really wish it was easier to simply set them up so we could call them from any of the other class in the project the same way you use the simple "print" method.

I find the logging utility very useful. I'll use it nearly everywhere. And now it has some extra flavour like logging into a separate log file.

It still needs a proper shutdown method.

So... what broke the part icon fix?

Edited July 26, 2015 by *Aqua*

[Madrias]

I wouldn't mind some thinner Repulsor Wheels (more in the style of the Small Rover Wheels) that use the Gimballed Repulsor system, if you're up for it, Lo-Fi. Gimballed repulsors have become my standard in repulsorcraft, and I've found the standard Repulsor Wheels are just too different for me to build around. Either they're way too wide, or they're not big enough in diameter. The wheels that have the suspension in the hub (not the flexi-wheels, but the other ones) would work pretty well, I think.

[Gaalidas]

Pure laziness, I assure you! Most of my debug messages tend to be a quick program flow indicator, so I tended to bing them in without even thinking.

Motor cycle wheels ought to be possible, yes. I'll add to the idea pile. TT track is unlikely to see its way to release, having been superseded by the simple track, which just needs texturing. BV track needs texturing also.

By all means have a go at the DDS conversion. I could never get it to look crisp, no matter what I did. Mark those with borked normal maps as a bug in the tracker and I'll fix!

We're getting close, guys.

I'm quite looking forward to getting back down to some modelling! Some nice stuff in the pipeline that I've just not had time to work on. V8Jester is kindly helping with the rollcage IVA.

I'll include my modified normals with the rest of the textures if you don't mind. I've been using them in-game for a while not without issue. I'll also include a few alternate textures I created however, without enough knowledge about what object names to use for the FS texture switcher, I was unable to set them up for use properly. Mostly they consist of darker versions of certain things.

What's wrong with the part icon fix, Aqua? I didn't see anything messed up there.

- - - Updated - - -

I wouldn't mind some thinner Repulsor Wheels (more in the style of the Small Rover Wheels) that use the Gimballed Repulsor system, if you're up for it, Lo-Fi. Gimballed repulsors have become my standard in repulsorcraft, and I've found the standard Repulsor Wheels are just too different for me to build around. Either they're way too wide, or they're not big enough in diameter. The wheels that have the suspension in the hub (not the flexi-wheels, but the other ones) would work pretty well, I think.

The repulsor wheels never really made it out of dev status as far as I'm aware. I always envisioned an advanced set of animations where a thinner, but larger, wheel would turn in place, a series of curved panels would wrap over the tires, the entire wheel would then be pushed outward slightly, and then the repulsor plate would descend from the center of the wheel and begin doing its thing. But, that's beyond my ability at this time.

[lo-fi]

Go for it, Gaalidas, all sounds good. Just do post an issue in the tracker to remind me to fix the UV where needed. All models are on another repo, should you need, btw.

Last I checked the icon fixer was working? Can't see how the module change would have affected it... I'll double check when in front of the PC.

The repulsor wheel module needs some love, but I do intend to get them going. Thanks for the suggestions, will see what I can do.. I have some new ideas...

Logging stuff sounds great! You guys are doing fantastic work

[*Aqua*]

What's wrong with the part icon fix, Aqua? I didn't see anything messed up there.

All the part icons with IconOverride{} are supersized.

You don't have that problem?

[lo-fi]

I'll check as soon as I'm in front of the PC... I'd have noticed last time, though, I was checking the descriptions. How very strange.

[*Aqua*]

My harddrive bugged out while I was trying to commit*. This looks serious!

It'll take a while until I can fix that. But for now I'm unable to contribute further.

* My last commit includes completely wrong code. Someone please revert that.

[Gaalidas]

All the part icons with IconOverride{} are supersized.

You don't have that problem?

Actually, I have yet to really test out that. Nothing's been changed as far as those are concerned, unless those model updates that lo-fi has been doing to fix the arrow showing up in the icon are making the icons get larger.

On that note, I've been meaning to ask you how the heck you managed to get a node to respond from the part file like that without having to define it as a module. As far as I was aware, before seeing this, unless it was a module definition the node/parameter had to be a part of the "PART" list of supported parameters/nodes, otherwise it would bug out on you.

- - - Updated - - -

My harddrive bugged out while I was trying to commit*. This looks serious!

It'll take a while until I can fix that. But for now I'm unable to contribute further.

* My last commit includes completely wrong code. Someone please revert that.

What kind of code was that?

Also, quick question for you, in the case where the log call is intended to go to the separate file (should not default to that, by the way) where is that log file going to be placed?

Edited July 26, 2015 by Gaalidas

[*Aqua*]

This one: https://github.com/KerbalFoundries/KF_plugin/commit/50460c634b366534903f1ee5335b1d74902c27ad

Somehow Visual Studio didn't display it as an error before but static deconstructors don't exist in C#. You'll only need to remove the method.

I already have finished an alternative but I can't access that right now. (I currently get multiple disc errors per second. I hope I can save the harddisk somehow.)

On that note, I've been meaning to ask you how the heck you managed to get a node to respond from the part file like that without having to define it as a module. As far as I was aware, before seeing this, unless it was a module definition the node/parameter had to be a part of the "PART" list of supported parameters/nodes, otherwise it would bug out on you.

KSP automatically creates config nodes for everything it finds in a part.cfg. You just need to access it via part.GetValue("nodename") (or similar) and interpret it.

If there's a class (like PartModule, KFRepulsor, etc.) which fits a config node, the class will be instantiated as an object and filled with the values of the config node.

Also, quick question for you, in the case where the log call is intended to go to the separate file (should not default to that, by the way) where is that log file going to be placed?

Current work directory. If you compile and start the project inside Visual Studio, the log is in KF_plugin\bin\Debug\KF.log. If you directly start KSP it's located beneath KSP.exe. Edited July 26, 2015 by *Aqua*

[Shaggygoblin]

I searched the thread with: speed, top speed, max speed... And got an enormous amount of returns that were, irrelevant to my reasons...

1) Is Max speed derived from some convoluted calculations of mass, torque/torquecurve, rolling resistance, EC rate, etc...

What values in the .cfg do I need to change to raise/lower the speed? anything I fudge with using MM patches causes no response from the wheels whatsoever. No steering, no rolling. The brake light works! I was trying to set the maxRPM to 625 (250rpm/40topspeed=6.25 * 100targetspeed=625rpm) no luck. torqueCurve Keys bumped up to K1=0,100,0; K2=50,50,0; K3=100,0,0. Nadda. looking at the KFModuleWheel.cs showed me a few max values, i think, but alas, i am sticking my fingers in the toaster here...

2) Also, I would like to be able to alter the spring and damper in the field, as we can do with gas suspension on the Stryker I crewed in the Army. I think just setting the

[KSPField(isPersistant = true, guiActive = false, guiActiveEditor = true, guiName = "Spring Strength")

and

[KSPField(isPersistant = true, guiActive = false, guiActiveEditor = true, guiName = "Spring Damping")

to

guiActive = false

for the gui while in flight. but again, toaster + fingers...

I use 2 mirrored symmetry KF Large Wheel on a bus comprised of a Stock Science Lab with a Hitchhiker and a 2.5m end cap fuel tank for braking ballast. Other small things like probe core, fuelcells, experiments/scanners, bats/SP's and antennae add negligible mass compared to the core structure. I've managed to size the wheels and pitch/wedge the suspension so that it floats realisticly... but dat wheelstand on acceleration and braking... there's only so much you can do with the slider in the right-click menu while on mission. I set front to .75 and rear to .5 and this keeps the tail out of the dirt, but the front still leaves the ground. On steep inclines (mountains w-nw of KSC) I have to set front to 1 and rear to .25 or I will back slide. The suspension is trimmed to horizontal (front 70, rear 85(fuel in the rear causes more squat)) front and rear springs are at 5, damper is halfway on both.

YOUR MOD is a must for anything I build with no intentions of leaving Kerra-Firma (sans some rock crawling ending in mountain cartwheels...lol)

TL;DR: What value to fudge for more Top Speed and Easier Braking, while not utilizing the torque slider? Will gladly toss more EC at it if it will take it!

Here's the .craft in my GD. I think it broke KerbalX Part Mapper's site...lol ShortBus.craft

[Gaalidas]

Current work directory. If you compile and start the project inside Visual Studio, the log is in KF_plugin\bin\Debug\KF.log. If you directly start KSP it's located beneath KSP.exe.

Good to know. So now, when we have something that we're working on and is still in the testing phase, we can put a bunch of the log calls into a separate log file and get all the information we want, even if it's a spammed message or something, without cluttering up the standard KSP console log. That could definitely expedite finding information about something that's getting really screwy. I might even think that anything logged under "debug" (as in KFLog.Debug, or however you're calling it) could be defaulted to go into the separate file and could probably omit the mod name from the formatting. In fact, anything going to KF.log could leave out the mod name completely. Anyway, you take care of your hard drive and we'll talk about enhancing this stuff later. For now it works well enough to leave it alone until we release 1.9.

- - - Updated - - -

I searched the thread with: speed, top speed, max speed... And got an enormous amount of returns that were, irrelevant to my reasons...

1) Is Max speed derived from some convoluted calculations of mass, torque/torquecurve, rolling resistance, EC rate, etc...

What values in the .cfg do I need to change to raise/lower the speed? anything I fudge with using MM patches causes no response from the wheels whatsoever. No steering, no rolling. The brake light works! I was trying to set the maxRPM to 625 (250rpm/40topspeed=6.25 * 100targetspeed=625rpm) no luck. torqueCurve Keys bumped up to K1=0,100,0; K2=50,50,0; K3=100,0,0. Nadda. looking at the KFModuleWheel.cs showed me a few max values, i think, but alas, i am sticking my fingers in the toaster here...

2) Also, I would like to be able to alter the spring and damper in the field, as we can do with gas suspension on the Stryker I crewed in the Army. I think just setting the

[KSPField(isPersistant = true, guiActive = false, guiActiveEditor = true, guiName = "Spring Strength")

and

[KSPField(isPersistant = true, guiActive = false, guiActiveEditor = true, guiName = "Spring Damping")

to

guiActive = false

for the gui while in flight. but again, toaster + fingers...

I use 2 mirrored symmetry KF Large Wheel on a bus comprised of a Stock Science Lab with a Hitchhiker and a 2.5m end cap fuel tank for braking ballast. Other small things like probe core, fuelcells, experiments/scanners, bats/SP's and antennae add negligible mass compared to the core structure. I've managed to size the wheels and pitch/wedge the suspension so that it floats realisticly... but dat wheelstand on acceleration and braking... there's only so much you can do with the slider in the right-click menu while on mission. I set front to .75 and rear to .5 and this keeps the tail out of the dirt, but the front still leaves the ground. On steep inclines (mountains w-nw of KSC) I have to set front to 1 and rear to .25 or I will back slide. The suspension is trimmed to horizontal (front 70, rear 85(fuel in the rear causes more squat)) front and rear springs are at 5, damper is halfway on both.

YOUR MOD is a must for anything I build with no intentions of leaving Kerra-Firma (sans some rock crawling ending in mountain cartwheels...lol)

TL;DR: What value to fudge for more Top Speed and Easier Braking, while not utilizing the torque slider? Will gladly toss more EC at it if it will take it!

Here's the .craft in my GD. I think it broke KerbalX Part Mapper's site...lol ShortBus.craft

I think you mean to use "guiActive = true" so that it shows up in the flight scene, right?

Also, it's starting to drive me nuts. What does "TL;DR" refer to?

As for brake lights, I used to love setting up those tiny B9 surface lights to a red hue and mapping their toggle state to the "brake" instead of the "lights" group they default to. Works amazingly well.

Edited July 26, 2015 by Gaalidas

[Tyren]

back from vacation. did something. funny happen?

[Gaalidas]

Depends, how long have you been away?

[lo-fi]

Sorry to hear about your hard drive, Aqua! Hope you get it fixed soon.

No doubt about a hundred pages of crazy, Tyren Welcome back!

@ShaggyGoblin: Max speed defined by the float curve for motorTorque. First value is speed, second is torque for that speed. Also, MaxRPM gives a rev limiter and defines something to calculate the sound effects pitch from.

No-can-do with adjusting spring values in flight I'm afraid: they're like that for a reason. Namely, that you can update the values in the wheel colliders, but they will only take effect after contact with the ground is broken. This is a Unity limitation - sorry!

Next version has a little more finesse with the control inputs and far better TweakScale support, so you ought to struggle less. And thanks!

TL;DR = Too Long; Didn't Read. Surprised you've not heard that a lot from your gargantuan posts, Gaalidas </cheeky>

[Gaalidas]

I see it a lot, but never bothered to figure out what it meant. You'd likely be amused to find out how long it took me to figure out what "brb" meant back in the days when that three letter shorthand made its first appearances. From what I remember, I spent at least two weeks trying to figure it out before I finally asked someone. On top of that... when they told me what it meant I thought they were telling me, literally, that they would "be right back" and would explain it to me when they returned. Great Jebediah... I'm getting old... that was a long time ago.

Edited July 27, 2015 by Gaalidas

[lo-fi]

Ah, happens to the best of us.

And: WOAH! Yeah, the icons are broken. Running my commit ffbcf9 (Fixed an issue with mirror module) all was fine. Sync, recompile, broken. It's not the module changes, then. I haven't touched the parts repo.

Playing with the line factor /= 40f; changes the sizes. Though I've no idea why this would need changing when it was working before. As far as I can tell, that method has not been touched since the meter scale bug was fixed. Very strange indeed.

Edited July 27, 2015 by lo-fi

[*Aqua*]

I fixed the part icons.

In KFPersistenceManager.CalculateBounds()

boundsList.ForEach(b => bounds.Encapsulate();

was replaced by

boundsList.ForEach(bounds.Encapsulate);

in an earlier commit.

I changed it back. It really was a tedious task. I switched between revisions to find the first commit where the icons broke. And then I went through all the changes, reverted them back and forth until I found the culprit.

[lo-fi]

Excellent, that's a relief!

I'll check out revisions to the repulsor EC later. The calc is used to figure out the sound effect too, so may need further adjusting.

[Gaalidas]

Sorry about that, I'm the reason for that. SharpDevelop said it would work perfectly, but I guess it was wrong. I actually intended to simply suppress that suggestion instead of committing it.

Maybe it's time to see if SharpDevelop has been updated again...

In other news, the first pass of updating the assets to DDS has been committed. Give them a try lo-fi, see what you think. The rover body has mips on it, since the texture is so huge, though I think it also got cut by 50% of it's total dimensions in the process as well. I was actually thinking about it while trying to go to sleep last night and thought that maybe a smaller texture that makes use of a more brushed metal look for the main hull of the rover body might be a better look for it, cause right now if you resize the texture down to reasonable dimensions some of those small lines disappear and the diagonals become aliased. A few of the normals were left in PNG format because the DXT5nm format also reduces the detail to the image along with the vertical flipping and the color bashing into that pinkish normal map.

Edited July 27, 2015 by Gaalidas

[lo-fi]

Regarding the DDS textures:

Compared to this:

Is that an acceptable compromise? I don't think so. That's nothing to do with mip-maps; DDS is just horribly lossy. Also, whichever method you've used has stripped the alpha channel (which is used for specular) out of all the textures, Gaalidas. Granted, you don't always tend to be close up in KSP, but that looks like something out of 1991!!!! I want to do better than that, or I'm just not going to bother to texture anything - it just isn't worth the time.

The texture sharing has chopped a lot down already, and I can probably be a little less generous with some of the others or create a texture atlas that's used for several parts, which might be nice. DDS: No.

[Gaalidas]

Well that's total ... kerbal excrement... (do kerbals even poo? never mind....) Alright, we've gotta revert that stuff. One thing though, the one part you decided to test out is the one part that I kept the mipmaps on because it's too freakishly huge of a texture. what about the other parts?

Anyway, the alpha channel still exists, it's just not as easy to view when previewing DDS files. It's still there, however.

EDIT: oh wait... I think I know why the rover body lost it's alpha channel... oops. I always strip out the alphas from textures (especially those with pure white alphas covering the entire image which are completely useless) unless they're required for the part to look right (such as launch clamp tower transparency between the bars) to increase my performance.

Anyway, if we can get that rover body texture down to at least 1024 in it's original format, it'll make it easier for everyone to use it. Remember all those ATM users having lock-ups when loading it for the first time?

I think we do need to go back to mainly PNG again though if they're all going to get that bad.

Edited July 27, 2015 by Gaalidas

[lo-fi]

Ah, OK. Didn't seem to be showing up in game, but maybe because it got mashed!

Other parts aren't quite as bad - that's maybe the worst example. Though they still look like poor quality jpgs... I think I can maybe do the rover body at 1024 if I redo from the source files. Rescaling the finished image is never as good, and you should never rescale a bump map. The ATM bug was because the first rover body texture was 80meg @ 4096

As I understand it, they get converted when loaded if not already, so I don't get why they look so pants when pre-converted. Maybe I'm missing something.

Edited July 27, 2015 by lo-fi

[Gaalidas]

Or maybe the converter tool is missing something. Or... maybe you're used to higher quality than I am because your system is more beefy than mine. Hard to tell. Lets just revert the whole batch then. I'll still include my modified normal maps for some of those track surfaces if you'd like, but it looks like DDS isn't going to work out. What I don't get is why all the other mods using DDS look awesome still.

As for normals, I scale those all the time. Locally anyway. I really have to watch my performance and the more a normal map is being used to change what is rendered, the more my performance drops.

Those results in your game could be due to your graphics device as well, but if you're running anything modern-ish then it shouldn't cause such a dramatic reduction.

Edited July 27, 2015 by Gaalidas