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

[lo-fi]

I'm having a poke at it right now. use the .csproj from GitHub and the source from the .zip (GitHub seems to still be the 2.1 version for some reason). Though it seems that the target framework needs to be set to 3.5. I think I can see where it's all gone wrong, will update shortly. The spheres are there because you've been compiling it in debug mode, at which point the code in the #if DEBUG regions gets added. In this case, spheres to show positions.

Edited February 1, 2015 by lo-fi

[Gaalidas]

I noticed that just recently and commented out those regions since I am having a hard time figuring out how to determine if I'm compiling in a standard vs debug mode. I also redid my refactor so that it's only cutting out the sparks if the spark parameter is false AND my new dustEffects parameter is true, and letting it produce the whole field of effects if any other conditions are found. That way I can specify when I want the sparks to be turned off and dust turned on specifically. As for the framework stuff, SharpDevelop always insists that 3.5 is not valid and I usually have to upgrade to 4.0 to stop the warnings. It says something to the effect of "targeted framework mismatch detected."

Anyway, I just did a brand new compile and I'm going to see what happens when/if KSP ever finishes loading.

Still, it might be a much better solution if we could implement our own version of the dust effect in the KF plugin and not have to depend on a third party modification. Would his license allow for copying that portion of the code out and integrating it, or would we have to rewrite it in a sufficiently altered format? I say "portion of the code" when I know it's probably everything except the specific spark and light effect code.

- - - Updated - - -

use the .csproj from GitHu

Wait... what? I never found a github for this project. I'm working off the source in the download. Had to hack up my own project file from scratch.

I was just thinking... now that I know about "#if DEBUG" stuff, I should use that in my next overly-complicated C# class homework. Wonder if he'd approve? Only one way to find out...

EDIT: Alright, I've had enough of this screwed up code. I can't make it emit dust without sparks. It either emits everything or nothing at all. I try and add one little check to a certain function that might be stopping it from functioning and the compiler tries to tell me that not all the functions are able to return a value. It's the same freaking return statement, just with an if/then check on it so I can insert a different value into the return which, if the if/then resolves, will output the exact same freaking stuff. All I want is some stupid dust for the love of... I think I'm having a miniature stroke. Huh. I kinda like it... I'm going to go lie down now.

Edited February 2, 2015 by Gaalidas

[lo-fi]

It does tend to jump around a bit, but I do have it fixed. License is GPL2, so no reason there not to redistribute, but a fork/pull request is probably more polite if we can get hold of pizzaoverlord. As for rolling a version into KF? There's a lot of stuff I don't fully understand, so maintaining it myself is going to be problematic. Oh, and I noticed the MM patch is still not right either.

[riocrokite]

lo-fi,

One idea that might be interesting for you (for future development):

wheel wearing out concept

driving a wheel (track) especially with too heavy load, heavy bumps and jumps wear it out and then it changes look and make weird sound at i.e. 10% life left (and at 0% it goes into damaged state).

For track/wheel maintenance you would need a small amount of spare parts (depending on the wheel size and tech).

However if wheel/track is broken you can fix it only by hauling spare wheel or track elements (KAS storable and movable for smaller tracks/wheels and larger ones could only be attached outside and moved by i.e. robotic arm).

For wheels and tracks you could see while rightclicking on them current mass and compare it to their operating limits, you could also see their state (i.e. in %). I can also see nice plugin for IVA showing wheels and their state in color (green - ok, red - bad)

Since wheels would always wear while moving the idea would be to introduce a button that can raise spare axles when they are not needed (like in trucks). I think something like this (up/down functionality) is introduced in TT wheels mod.

It would make for a nice planning phase since you would need mass calculations for different planets while planning loads, wheels numbers and such. Aand of course don't forget about spare wheels/tracks hehe:)

[Gaalidas]

It does tend to jump around a bit, but I do have it fixed. License is GPL2, so no reason there not to redistribute, but a fork/pull request is probably more polite if we can get hold of pizzaoverlord. As for rolling a version into KF? There's a lot of stuff I don't fully understand, so maintaining it myself is going to be problematic. Oh, and I noticed the MM patch is still not right either.

Can I get a copy of your fixed up source? I'm curious as to how you did it, and I would like to mess around with it (yeah, I'm easily amused).

I still don't understand all the license stuff. From my point of view, if humanity could get over this whole issue with "This is my property, and it shows just how awesome I am... now pay me for it!" mentality, we could advance as a technological species at easily triple our current rate. Just give credit where due, and release your secret so we can learn from it. It drives me nuts how everything is locked up tight under heavy regulations and high price tags. Anyway... moving on.

Good to know it's not very restrictive. I figure we could eventually integrate it when we reach the point where special effects are necessary. Right now, the only special effect stuff being modded are in clouds and exhaust trails. People have yet to jump on the bandwagon for tire tracks and dust trails, especially with the stability of higher-bit-rate processing in such turmoil.

I gotta say this though, my little mini-stroke did get me to bed at an unheard-of time (before midnight, can you believe it?) and, if you hadn't been messing with that stuff, I'd have been all refreshed to tackle that code again... if I didn't have to go to classes now. So give a cheer for mental breakdowns and miniature medical emergencies. They sure work wonders.

- - - Updated - - -

lo-fi,

One idea that might be interesting for you (for future development):

wheel wearing out concept

driving a wheel (track) especially with too heavy load, heavy bumps and jumps wear it out and then it changes look and make weird sound at i.e. 10% life left (and at 0% it goes into damaged state).

For track/wheel maintenance you would need a small amount of spare parts (depending on the wheel size and tech).

However if wheel/track is broken you can fix it only by hauling spare wheel or track elements (KAS storable and movable for smaller tracks/wheels and larger ones could only be attached outside and moved by i.e. robotic arm).

For wheels and tracks you could see while rightclicking on them current mass and compare it to their operating limits, you could also see their state (i.e. in %). I can also see nice plugin for IVA showing wheels and their state in color (green - ok, red - bad)

Since wheels would always wear while moving the idea would be to introduce a button that can raise spare axles when they are not needed (like in trucks). I think something like this (up/down functionality) is introduced in TT wheels mod.

It would make for a nice planning phase since you would need mass calculations for different planets while planning loads, wheels numbers and such. Aand of course don't forget about spare wheels/tracks hehe:)

And I thought I was nuts with my wacko ideas. You have defeated me. Keep it up. I like this idea a lot, though I'm the kind of player that would cheat and disable most of that fucntionality so I don't have to worry about all that maintenance shi... err... poop. Even with that, though, I'd probably be interested in looking into something like that. You'd probably want to first look into the RPM/vesselviewer plugins (not the screen-shot grabbing one, the in-flight 2d-ship-modelling one) to see how things like this can be tracked. Then, you'd want to look at how the physical gadgets are put together for tracking information in the B9 package IVA setups. as for the actual wheel wearing out, I'd think something like the deadly-reentry plugin and it's "ablative shielding" resource would do the trick.

[Quiana]

Can I get a copy of your fixed up source? I'm curious as to how you did it, and I would like to mess around with it (yeah, I'm easily amused).

I still don't understand all the license stuff. From my point of view, if humanity could get over this whole issue with "This is my property, and it shows just how awesome I am... now pay me for it!" mentality, we could advance as a technological species at easily triple our current rate. Just give credit where due, and release your secret so we can learn from it. It drives me nuts how everything is locked up tight under heavy regulations and high price tags. Anyway... moving on.

Good to know it's not very restrictive. I figure we could eventually integrate it when we reach the point where special effects are necessary. Right now, the only special effect stuff being modded are in clouds and exhaust trails. People have yet to jump on the bandwagon for tire tracks and dust trails, especially with the stability of higher-bit-rate processing in such turmoil.

I gotta say this though, my little mini-stroke did get me to bed at an unheard-of time (before midnight, can you believe it?) and, if you hadn't been messing with that stuff, I'd have been all refreshed to tackle that code again... if I didn't have to go to classes now. So give a cheer for mental breakdowns and miniature medical emergencies. They sure work wonders.

- - - Updated - - -

And I thought I was nuts with my wacko ideas. You have defeated me. Keep it up. I like this idea a lot, though I'm the kind of player that would cheat and disable most of that fucntionality so I don't have to worry about all that maintenance shi... err... poop. Even with that, though, I'd probably be interested in looking into something like that. You'd probably want to first look into the RPM/vesselviewer plugins (not the screen-shot grabbing one, the in-flight 2d-ship-modelling one) to see how things like this can be tracked. Then, you'd want to look at how the physical gadgets are put together for tracking information in the B9 package IVA setups. as for the actual wheel wearing out, I'd think something like the deadly-reentry plugin and it's "ablative shielding" resource would do the trick.

Would the wearing out thing be much better tracked with a mod designed for failures? A Dang-it link might be a better use than that, rather than making something like its own wear-out resource. It tracks the MTBF, so you could have it feed in 'damage' events over time from particularly rough incidents that decrease the MTBF, with maintenance increasing MTBF. A complete break would probably need a small event for replacement rather than spare-parts repairs, but it might be doable in that method with a lot less hassle than tracking your own resource in the plugin.

EDIT: Also, it would give the option to leave it non-breaking for more casual use, or have something like Dang-it to add that functionality in rather than having to handle it yourself. A few simple MM checks can make it function either way and leave it outside of your wheel/track plugin.

[lo-fi]

lo-fi,

One idea that might be interesting for you (for future development):

wheel wearing out concept

driving a wheel (track) especially with too heavy load, heavy bumps and jumps wear it out and then it changes look and make weird sound at i.e. 10% life left (and at 0% it goes into damaged state).

For track/wheel maintenance you would need a small amount of spare parts (depending on the wheel size and tech).

However if wheel/track is broken you can fix it only by hauling spare wheel or track elements (KAS storable and movable for smaller tracks/wheels and larger ones could only be attached outside and moved by i.e. robotic arm).

For wheels and tracks you could see while rightclicking on them current mass and compare it to their operating limits, you could also see their state (i.e. in %). I can also see nice plugin for IVA showing wheels and their state in color (green - ok, red - bad)

Since wheels would always wear while moving the idea would be to introduce a button that can raise spare axles when they are not needed (like in trucks). I think something like this (up/down functionality) is introduced in TT wheels mod.

It would make for a nice planning phase since you would need mass calculations for different planets while planning loads, wheels numbers and such. Aand of course don't forget about spare wheels/tracks hehe:)

Crieky, that sounds like a lot of work! Some of it is there already - you can raise wheels from RCM. Damage, I've not even looked into, but it's a nice idea.

Can I get a copy of your fixed up source? I'm curious as to how you did it, and I would like to mess around with it (yeah, I'm easily amused).

I still don't understand all the license stuff. From my point of view, if humanity could get over this whole issue with "This is my property, and it shows just how awesome I am... now pay me for it!" mentality, we could advance as a technological species at easily triple our current rate. Just give credit where due, and release your secret so we can learn from it. It drives me nuts how everything is locked up tight under heavy regulations and high price tags. Anyway... moving on.

Good to know it's not very restrictive. I figure we could eventually integrate it when we reach the point where special effects are necessary. Right now, the only special effect stuff being modded are in clouds and exhaust trails. People have yet to jump on the bandwagon for tire tracks and dust trails, especially with the stability of higher-bit-rate processing in such turmoil.

I gotta say this though, my little mini-stroke did get me to bed at an unheard-of time (before midnight, can you believe it?) and, if you hadn't been messing with that stuff, I'd have been all refreshed to tackle that code again... if I didn't have to go to classes now. So give a cheer for mental breakdowns and miniature medical emergencies. They sure work wonders.

- - - Updated - - -

And I thought I was nuts with my wacko ideas. You have defeated me. Keep it up. I like this idea a lot, though I'm the kind of player that would cheat and disable most of that fucntionality so I don't have to worry about all that maintenance shi... err... poop. Even with that, though, I'd probably be interested in looking into something like that. You'd probably want to first look into the RPM/vesselviewer plugins (not the screen-shot grabbing one, the in-flight 2d-ship-modelling one) to see how things like this can be tracked. Then, you'd want to look at how the physical gadgets are put together for tracking information in the B9 package IVA setups. as for the actual wheel wearing out, I'd think something like the deadly-reentry plugin and it's "ablative shielding" resource would do the trick.

I've got one annoying issue I need to iron out before I do: somewhere in the convolution, it throws an IndedOutOfRange exception, which I don't think it did before. Still working on that, but battling with persistence, KSP vessel loading and general C# == != .Equals() tomfoolery. And you think you've had a mini stroke!

Would the wearing out thing be much better tracked with a mod designed for failures? A Dang-it link might be a better use than that, rather than making something like its own wear-out resource. It tracks the MTBF, so you could have it feed in 'damage' events over time from particularly rough incidents that decrease the MTBF, with maintenance increasing MTBF. A complete break would probably need a small event for replacement rather than spare-parts repairs, but it might be doable in that method with a lot less hassle than tracking your own resource in the plugin.

EDIT: Also, it would give the option to leave it non-breaking for more casual use, or have something like Dang-it to add that functionality in rather than having to handle it yourself. A few simple MM checks can make it function either way and leave it outside of your wheel/track plugin.

Actually, that's not a bad call. Don't want wheel failures? don't install DangIt (or the MM patch). Nice to give Kerbals something to do..

[Koosmonaut]

I was wondering if the Part Icon Fixer still works in 0.90? Of course I've tested it myself and as far as I can see it works, but it would be a shame if it causes errors that I can't spot as a newb.

[Gaalidas]

I know that there are missing-module errors being reported for the KF parts that specifically define the module. The icon fixer itself seems to be okay and working though. I'm not so sure that the module definition is actually required though, considering my attempts to fix this by renaming teh module to match what's in the PartIconFixer DLL still resulted in a missing module error. It may be that the mod works without being defined specifically.

Hope you figure it out soon lo-fi. In the mean time, I may continue to fiddle with my own edit to see what I can come up with.

[lo-fi]

No, actually the module definitions are not needed since the latest version. Yes, it still works in 0.90, Koosmonaut I'll update the OP.

Almost got the persistence thing working thanks to a little help from the plugin dev forum.

[Gaalidas]

aye, them forums are amazing things.

[lo-fi]

It does work remarkably well so far. One thing I need to test is what happens when time warped in orbit. Obviously, it works fine on the ground with physical time warp, and doesn't allow you to time accelerate if the craft is in motion. Great. But in orbit, you can be moving, but time accelerate when not under thrust. What happens if there's a slight difference in velocity between the two craft? I suspect the Kraken upon returning from time warp. presumably there's a mechanism KSP uses to keep craft together in the same fashion (they are just connections of parts connected by joints, after all), but I've no idea what that mechanism is or how it works. Or maybe I'll be pleasantly surprised! Will dive into CollisionFX code again when I have some time, it's bugging me that it throws those exceptions.

[ZodiusInfuser]

It does work remarkably well so far. One thing I need to test is what happens when time warped in orbit. Obviously, it works fine on the ground with physical time warp, and doesn't allow you to time accelerate if the craft is in motion. Great. But in orbit, you can be moving, but time accelerate when not under thrust. What happens if there's a slight difference in velocity between the two craft? I suspect the Kraken upon returning from time warp. presumably there's a mechanism KSP uses to keep craft together in the same fashion (they are just connections of parts connected by joints, after all), but I've no idea what that mechanism is or how it works. Or maybe I'll be pleasantly surprised! Will dive into CollisionFX code again when I have some time, it's bugging me that it throws those exceptions.

As I posted in the other thread, dont even try untangling that web, just have the joint not be recreated on exiting time warp, if the craft have moved apart X amount.

[Gaalidas]

Ideally one would not be using the hitch as a primary means of connecting two craft in orbit, but rather dock them together in some other fashion. I'd just a trailer hitch after all, not really meant as a permanent connection. If something goes wrong out there in the cosmic fish bowl, that's what you get for using a trailer hitch.

[lo-fi]

I think that may be how things have to be. Though it's maybe possible to do some clever trickery while on rails checking relative positions - I'm not sure. There's a big sign here saying "here be Krakens"

Oh, btw, if you try it, don't whatever you do use the manual "hitch" button. The Kraken will surely strike, as it bypasses some of the correct object and orientation checks XD. It is, however, hilarious.

Damn, is it cool, though! I've had two trailers coupled one behind the other, hacking around the KSC. The dynamics are perfect, you even get sway if you have the hitch mounted too far back, just like towing a real trailer. Next things up are configurable limits in flight, EC sharing via the coupling and trailer brake/steering/motor control. Considering a toggle for screen messages or a little gui that reads out how close you are to coupling. And, of course, a hitch animation.

[Darren9]

I tried to load a quicksave that had seven trailers hitched up to a tractor and all the trailers vanished If you're wondering you get some quite extreme snaking pulling seven two-wheeled trailers - it was hard to get above 10m/s. I saved the LOGS just encase it'll help, there's a lot of other mods in that install though.

[lo-fi]

Doh! Sorry about that. Now, this is an interesting one. I've been testing with trailers with command pods because it makes things easier. By the look of it, you caravans don't have one? Lots of log to wade through (and thanks for that, makes life so much easier!), but what struck me was this:

[FlightPersistence]: Vessel Caravan not saved because it was debris cluttering up KSC.

So even though they were hitched, because they weren't controllable (and not docked to a controllable craft as far as KSP is concerned), KSP thought they must have been debris and didn't save them to be loaded again. Now, you could say that's an edge case, but for those that have debris management turned on, that means a lot of disappearing caravans! As a temp workaround, try adding a probe core to the caravan, it should sort that out. I'll look into adding a command module to the trailer couplings in a way that doesn't make them rovers in their own right. Or maybe there's some other way or marking stuff as 'not debris'?

Cheers dude, that's really helpful!

EDIT: the swaying is interesting, isn't it. I need to see if I can add some damping to the joints to counter-act that. It's fascinating that it's a true-to-life behaviour!

PS: can't wait to see what you're doing with caravans

[Darren9]

Doh! Sorry about that. Now, this is an interesting one. I've been testing with trailers with command pods because it makes things easier. By the look of it, you caravans don't have one? Lots of log to wade through (and thanks for that, makes life so much easier!), but what struck me was this:

[FlightPersistence]: Vessel Caravan not saved because it was debris cluttering up KSC.

So even though they were hitched, because they weren't controllable (and not docked to a controllable craft as far as KSP is concerned), KSP thought they must have been debris and didn't save them to be loaded again. Now, you could say that's an edge case, but for those that have debris management turned on, that means a lot of disappearing caravans! As a temp workaround, try adding a probe core to the caravan, it should sort that out. I'll look into adding a command module to the trailer couplings in a way that doesn't make them rovers in their own right. Or maybe there's some other way or marking stuff as 'not debris'?

Cheers dude, that's really helpful!

EDIT: the swaying is interesting, isn't it. I need to see if I can add some damping to the joints to counter-act that. It's fascinating that it's a true-to-life behaviour!

PS: can't wait to see what you're doing with caravans

Ah, so it could be not you then. The caravans are probes but it's an Ubizor weld with the probe core welded to structural panels as a single part, they drive around and are controllable as individual vehicles. I'm not sure why they'd turn to debris but it could be down to Ubizor, I'll try without it.

[lo-fi]

Hmm, that's they should be marked as debris then. I've just issued a config bodge, which might sort it out. Let me know, anyway. What are your debris settings, btw?

[riocrokite]

hmm, where's the dev download to try new hitch out?

below unity hinge joint reference, maybe it can help:

http://docs.unity3d.com/Manual/class-HingeJoint.html

and question from another topic:P lo-fi, do you use anything from FireSpitter for your wheels mod?

[Darren9]

Debris is set to 0 because a lot of my crafts ends with an amount of it I was attempting jet powered caravan racing, it ended badly at the ramps by the VAB and that's when I tried the quicksave, what seems strange though is I left the scene and went back to the SPH seven times to get all the vehicles and hitch them up OK.

[lo-fi]

hmm, where's the dev download to try new hitch out?

below unity hinge joint reference, maybe it can help:

http://docs.unity3d.com/Manual/class-HingeJoint.html

and question from another topic:P lo-fi, do you use anything from FireSpitter for your wheels mod?

I'm using configurable joints, which can have damping applied, but I think not between the limits IIRC. I think I may have found the limitations of even the mighty configurable joint

The only thing I think I brought from FS was the idea to use scalar products to figure out part orientation in the vessel, and a few coding hints on how to access some of the wheel collider stuff initially. Other than that, it's all shiny and new!

Debris is set to 0 because a lot of my crafts ends with an amount of it I was attempting jet powered caravan racing, it ended badly at the ramps by the VAB and that's when I tried the quicksave, what seems strange though is I left the scene and went back to the SPH seven times to get all the vehicles and hitch them up OK.

http://i.imgur.com/4DXd2x7.png

Haha, same here!! That's hilarious, I love how the caravans are merrily doing their own thing! A more stable design would put either the wheels at the back, or the hitch point nearer the axles (I guess it amounts to the same thing), like you see on the larger lorries that tow a trailer in this fashion rather than the articulated type.

[RainDreamer]

-post-

Rocket train. I didn't think it could happen.

[Darren9]

I think it was my messing with Ubizor that was the first problem I made a cleaner install and the trailers stay. I'm getting another problem though, I hooked 8 up and I'm not able to load a quicksave with them all connected, one or two drop the link, it seems a bit random, I connect them all up again, drive a bit, do another save/load and a different link is dropped. Maybe because I'm using a two wheel trailer and not lowering the third wheel before I save? Just encase again More_KSP_Logs.zip

[lo-fi]

OK, was the dropped link right before you screen shotted and exited? I'm just working through the re-hitch method now, think I can make it more robust. This is a huge help!