Jump to content

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


lo-fi

What to work on next?  

1,282 members have voted

  1. 1. What to work on next?

    • More wheels
      123
    • More tracks
      453
    • Rover bodies
      241
    • Landing gear
      137
    • Landing legs
      108
    • Something completely different
      193


Recommended Posts

_should_ be available in the editor. Which parts are you on about?

In-flight has been tricky as there is a bug/feature that has been preventing update in flight - options were left in for investigation only and are intentionally disabled in the release.

I've now overcome the limitation, but it's going to need a lot of testing before I declare it safe for release.

Link to comment
Share on other sites

Interesting. Research this morning reveals that the problems I've been having are Unity/physX specific rather than anything KSP related.

The pulling to the right is a well documented Unity issue, and updating the spring property dynamically is just as funny without any stock KSP stuff applied (though I do, at least, have a workaround for this one). Fixing the pulling under acceleration is going to be fun :/

Link to comment
Share on other sites

What happened to the height, strength and damping tweakables?

I can't replicate, even on a clean install with the .zip downloaded from the repo (either dev or alpha). Check you've not got two versions of the plugin lurking, delete previous KF stuff and grab fresh from the repo.

Link to comment
Share on other sites

Comes from spending years trying to see into small spaces using mirrors, if your experience of engineering is like mine, i could read it fine also.

It took me a few reads to figure out what you meant and not where my mind went. Although there was probably engineering to do that too.

I'VE CRACKED IT!!!!!

This probably won't mean a lot to most of you, but it opens up a great many possibilities and lots of limitations are lifted. Testing team, expect some crazy stuff to start appearing :D

Lots of work ahead to recreate the stuff ModuleWheel does that I want to retain (rotating the wheel mesh and moving suspension helpers, for example), but it will be worth it to have complete control, and I can _possibly_ set up the anti-roll how I want now.

I know that feeling of figuring out something that no one else will even know was a problem :D It's part of what keeps me modding. And if you want new eyes on the anti-roll I volunteer to take a look.

Link to comment
Share on other sites

It took me a few reads to figure out what you meant and not where my mind went. Although there was probably engineering to do that too.

I know that feeling of figuring out something that no one else will even know was a problem :D It's part of what keeps me modding. And if you want new eyes on the anti-roll I volunteer to take a look.

Hehe! Yeah, I kinda went there too..

I'm glad someone understands. :) Thanks, feel free. The code is in place to detect wheel pairs, that pretty solid. The catch is this:

Anti-roll bars on vehicles connect the hubs each side via a sprung rod, suitably set up so it lets the wheels move up and down collectively but resists differential movement. Effectively it transfers some of the load from the loaded spring to the unloaded spring, so they behave as though the are weaker and stronger respectively.

This can be modeled by calculating differential movement of the suspension either side and scaling the .spring parameter of the wheelcollider accordingly.

Great! However... Updating an enabled collider does not result in the spring parameter being modified - it tends to sit there and ignore it, then it may or may not update 30 seconds later.

I've seen it modeled (incorrectly) by simply adding forces to either side of the vehicle, but this gives some seriously weird dynamics because it unloads the wheel that should be doing the most work. Needless to say, I was not happy with it.

I can hack a way to update the spring by disabling and enabling the collider, but this cannot be run in the update routine as it wrecks the rest of the simulation. I'm stuck!

Thsnk you, any input would be most gratefully received.

Link to comment
Share on other sites

I think I've got Ackerman correction well on the way, it's actually not difficult. An approximation, but so is most in real life. Not bad for a morning with a hangover.

For anyone that's interested.

http://www.rctek.com/technical/handling/ackerman_steering_principle.html

Making no apologies for using the dev thread a bit like a blog, I'm hoping it may help out anyone looking through the sources in the future trying to figure out why I did what I did in the code and rigging. Code comments only go so far.

Link to comment
Share on other sites

I found this mod yesterday, it's just awesome. I've waited a long time for this. Now I can make Repulsorlift crafts, like from Star Wars Luke's Landspeeder and Podracers. Will post my work when it's finished. Thanks for doing this.

Link to comment
Share on other sites

Love to see peoples creations, please do! You'll find someone (I forget who) already made a beautiful pod racer and posted a YouTube if you look back earlier in the thread.

Glad you like the mod, early stages yet :)

Link to comment
Share on other sites

I took a quick glance at the code, and I have some general performance comments: creating lists of wheels and updating that list periodically rather than searching through the whole vessel each time (force update when vessel.Parts.Count() (I don't think this is a real parameter :D ) changes?), storing the partner RepulsorWheel as a variable (maybe a list if more than one?) in the RepulsorWheel class. This second part would make debugging this much simpler.

So instead of

float partnerSuspensionTravel;
string partnerID;


public void doSomethingWithPartner()
{
RepulsorWheel partner = find(wheelID => wheelID == this.partnerID);
partner.suspensionTravel = this.partnerSuspensionTravel;
}

you get this

RepulsorWheel partnerWheel;

public void doSomethingWithPartner()
{
this.partnerWheel.suspensionTravel = someFloat;
}

It might save some RAM because instead of saving a float for partnerSuspensionTravel for each wheel, it saves a reference to a RepulsorWheel with partner. Or maybe not. I really don't know. A List<RepulsorWheel> with a length of 1 would only save a reference though.

Anyway, I found what looks like the area of interest @ ~line 360 in the RepulsorWheels class.

[FONT=Consolas][SIZE=2][COLOR=#0000ff][FONT=Consolas][SIZE=2][COLOR=#0000ff][FONT=Consolas][SIZE=2][COLOR=#0000ff]foreach[/COLOR][/SIZE][/FONT][/COLOR][/SIZE][/FONT][/COLOR][/SIZE][/FONT][FONT=Consolas][SIZE=2][FONT=Consolas][SIZE=2] ([/SIZE][/FONT][/SIZE][/FONT][FONT=Consolas][SIZE=2][COLOR=#2b91af][FONT=Consolas][SIZE=2][COLOR=#2b91af][FONT=Consolas][SIZE=2][COLOR=#2b91af]RepulsorWheel[/COLOR][/SIZE][/FONT][/COLOR][/SIZE][/FONT][/COLOR][/SIZE][/FONT][FONT=Consolas][SIZE=2][FONT=Consolas][SIZE=2] st [/SIZE][/FONT][/SIZE][/FONT][FONT=Consolas][SIZE=2][COLOR=#0000ff][FONT=Consolas][SIZE=2][COLOR=#0000ff][FONT=Consolas][SIZE=2][COLOR=#0000ff]in[/COLOR][/SIZE][/FONT][/COLOR][/SIZE][/FONT][/COLOR][/SIZE][/FONT][FONT=Consolas][SIZE=2][COLOR=#0000ff][FONT=Consolas][SIZE=2][COLOR=#0000ff][FONT=Consolas][SIZE=2][COLOR=#0000ff]this[/COLOR][/SIZE][/FONT][/COLOR][/SIZE][/FONT][/COLOR][/SIZE][/FONT][FONT=Consolas][SIZE=2][FONT=Consolas][SIZE=2].vessel.FindPartModulesImplementing<[/SIZE][/FONT][/SIZE][/FONT][FONT=Consolas][SIZE=2][COLOR=#2b91af][FONT=Consolas][SIZE=2][COLOR=#2b91af][FONT=Consolas][SIZE=2][COLOR=#2b91af]RepulsorWheel[/COLOR][/SIZE][/FONT][/COLOR][/SIZE][/FONT][/COLOR][/SIZE][/FONT][FONT=Consolas][SIZE=2][FONT=Consolas][SIZE=2]>())[/SIZE][/FONT][/SIZE][/FONT]
[FONT=Consolas][SIZE=2][FONT=Consolas][SIZE=2] {
[/SIZE][/FONT]
[/SIZE][/FONT][FONT=Consolas][SIZE=2][COLOR=#0000ff][FONT=Consolas][SIZE=2][COLOR=#0000ff][FONT=Consolas][SIZE=2][COLOR=#0000ff]if[/COLOR][/SIZE][/FONT][/COLOR][/SIZE][/FONT][/COLOR][/SIZE][/FONT][FONT=Consolas][SIZE=2][FONT=Consolas][SIZE=2] (st.thisPartID == partnerID) [/SIZE][/FONT][/SIZE][/FONT][FONT=Consolas][SIZE=2][COLOR=#008000][FONT=Consolas][SIZE=2][COLOR=#008000][FONT=Consolas][SIZE=2][COLOR=#008000]//find my paired wheel[/COLOR][/SIZE][/FONT][/COLOR][/SIZE][/FONT][/COLOR][/SIZE][/FONT]
[FONT=Consolas][SIZE=2][FONT=Consolas][SIZE=2] {
partnerSuspensionTravel = st.suspensionTravel;


[/SIZE][/FONT][/SIZE][/FONT][FONT=Consolas][SIZE=2][COLOR=#008000][FONT=Consolas][SIZE=2][COLOR=#008000][FONT=Consolas][SIZE=2][COLOR=#008000]etc.[/COLOR][/SIZE][/FONT][/COLOR][/SIZE][/FONT][/COLOR][/SIZE][/FONT]

Am I in the right area?

Edited by kujuman
Link to comment
Share on other sites

The list[] method seems to be how it's done in a lot of mods. I'm a C# newbie though (first project, first time I've touched the language or Unity), so I haven't quite figured out how to set up the list and have confidence it will work. The catch-all nature of the foreach loop is somewhat comforting too, as I know it's not something I can mess up easily while I'm worring about other things. It does need changing for performance, but the ability to reference an named collider is going to become important very soon too! Pointers greatly appreciated :)

Yep, that's the one. So having established which wheel its partner is, each wheel stores its own suspension travel every physics frame (to be later queried by its partner) whilst also querying its partners (stored) travel and running the calculation itself. I have had it set up so each wheel queries its partners travel along with itself, rather than using a stored value, but there seemed to be no advantages in accuracy. The current method runs half the calculations, so that's what I went with.

You'll find the anti-roll KSP field that displays the calculated value in the gui. Like I say, though, I can't implement without being able to dynamically update the .spring value, and that's the sticking point. The colliders just won't play ball no matter what I do - even a gui button which zeros the .spring value and passes back to the collider shows the same behaviour. Such a pity..

Just having some discussion and talking it through makes it clearer in my head, as well as leaving a little extra informal documentation for future mod-makers, so this is really helpful in lots of ways.

Edited by lo-fi
Link to comment
Share on other sites

The list[] method seems to be how it's done in a lot of mods. I'm a C# newbie though (first project, first time I've touched the language or Unity), so I haven't quite figured out how to set up the list and have confidence it will work. The catch-all nature of the foreach loop is somewhat comforting too, as I know it's not something I can mess up easily while I'm worring about other things. It does need changing for performance, but the ability to reference an named collider is going to become important very soon too! Pointers greatly appreciated :)

Yep, that's the one. So having established which wheel its partner is, each wheel stores its own suspension travel every physics frame (to be later queried by its partner) whilst also querying its partners (stored) travel and running the calculation itself. I have had it set up so each wheel queries its partners travel along with itself, rather than using a stored value, but there seemed to be no advantages in accuracy. The current method runs half the calculations, so that's what I went with.

You'll find the anti-roll KSP field that displays the calculated value in the gui. Like I say, though, I can't implement without being able to dynamically update the .spring value, and that's the sticking point. The colliders just won't play ball no matter what I do - even a gui button which zeros the .spring value and passes back to the collider shows the same behaviour. Such a pity..

Just having some discussion and talking it through makes it clearer in my head, as well as leaving a little extra informal documentation for future mod-makers, so this is really helpful in lots of ways.

After some testing it looks like the colliders only get their values reset after they leave contact with the ground. Which...is weird.

As to the apply-a-counter-force option not working out for you, it does seem like this should be a proper way to do it. I think you were getting weird forces because of the " suspensionTravel" variable not staying where it's supposed to.

suspensionTravel = (-mywc.transform.InverseTransformPoint(hit.point).y - mywc.radius) / mywc.suspensionDistance;

When I was testing the medium wheel, this line would return values between something like 1.06 and -0.06, and I think it should only return 0 -> 1?

I've not been able to actually test applying forces myself, but I hope this is promising research.

Link to comment
Share on other sites

I lke the new skin and angle of the alpha repulsor

http://i.imgur.com/pmmhmnd.jpg

i think a sci-fi effect under the repulsor would be nice, like a blu ray, or just a light under the repulsor, or is it too much?:huh:

this skin is very nice, I like it ! Except the wireframe style on the bottom (at least static like this).

Link to comment
Share on other sites

Thanks for the comments on the alternative skin, I didn't really do much more than colour up to the edges after lo-fi's modeling and Justin Kerbice unwrapped it so most of the time and effort was theirs, and I'm hoping to get the UV templates for the other models to try some more in the same style (Please Justin :)).

The wireframe on the bottom came from me forgetting to hide the template when I exported and well, it looked better than what I had before :) I'm open to any suggestions to improve it and also anyone taking the .tga and changing it themselves in any way, just be sure to show us what you do.

Link to comment
Share on other sites

Well, if no one has mentioned this for you before, I can confirm that the mod does work in 64-bit Unity just fine. I also ran it with Firespitter without problems.

Unfortunately, having 64-bits to work with doesn't make me any better at building control systems for anti-grav rovers, but I don't think player incompetence counts as a bug :P

Link to comment
Share on other sites

Do these use electricity?

Also, maybe add a nice low humming noise, that has a higher over tone, like those new all electric harley davidson motor bikes. Some sweet noises, maybe if you could have them set to propel in any direction and you drive them like wheels, so you don't have to worry about RCS? Maybe even make a similar thing to them that uses the fuel RCS has, that gives them more oomph, so you can temporarily fly, but also use fuel, but if you don't fly too high/far the repulsors should keep you safe.

Also, just from judging the video, they seem a bit instant. Maybe if there was a 100-200ms delay, or some gradual force constantly being applied that took a slight amount of time, was to keep them up, it was seem more natural.

Not criticising this, it's beautiful, and amazing. Just adding some ideas :)

Link to comment
Share on other sites

Great, good to know about the 64 bit - thanks for that.

We've discussed adding propelling forces, but consensus (and my firm opinion) is that its a stage too far. Nice effects ideas - some sort of hum would be good. Yes, they use electricity when on. But limited on how the physics objects work, so that's the dynamic for the moment. Someone would have to be really brave and write a custom collider to change much. You can already fly safely over craters on the Mun ;)

I'll add my hyper-RCS to the repo, it makes things a little easier. Though liquid fuel works rather well with a small engine.

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...