[Plugin/Parts] Kerbal Foundries - Continuation [Latest: 1.9g]

[Shadowmage]

20 hours ago, lo-fi said:

A few thoughts:

The new Squad wheel system won't handle tracks or any of the other more advanced features and parts I put in KF.

U5 wheel colliders are "odd", according to the reading I've done. But can be made to work.

Eddy's Vehicle Physics is, apparently, only $60. It's a tempting purchase to see what fixes he's made and squad will have bundled into KSP. Maybe a donation button to help cover the cost of this might be an option?

Working directly with wheel colliders in U5 to get used to the new behaviour may be fruitful. Dev cycle in KSP is so painfully slow, it's worth spending a little time on.

As I think I said before, I'm happy to handle this side of it. GUI, dust, release, support etc. I'll leave up to the rest of the team, if that's OK?

From what I can see most of the base EVP classes are present in one of the new KSP .dll files;  you shouldn't need to purchase EVP if your only intent is KSP modding.  (I could be wrong though...if so, please correct me )

They are located in the Assembly-CSharp-firstpass.dll, in the default namespace; titled such as 'VPWheel', 'VPWheelCollider', 'VPXXXXX'; 15-20 classes from a quick glance; seems the whole package is there.  I have not yet tried referencing those classes/imports in a custom PartModule, but it seems like it should be possible.

That said; I have no idea how to link that .dll into Unity Editor so that you can do out-of-KSP debugging and development (which I often do myself for the more Unity-Engine-related stuff; procedural meshes, wheels, legs, etc).  Last time I tried it there were so many errors...

[nli2work]

18 hours ago, lo-fi said:

Well, so far so good. I've made a crude (but working) car in U5 that approximates a KSP craft in its construction... which seems to be more than a lot of people before me have managed in U5.... Suspension behaves, it drives back and forth under command and the RPM readout seems to work fine. I'd even suggest that the grip model works much better than it used to! 10 (nameless units of torque) applied to a wheel of .5 radius accelerates much faster than with radius of 2, which is a step forward too.

I did have some funnies to start with, but that seems to be because the default values (particularly for suspension) are insane. No wonder people struggled. I may yet fall flat on my face, but I'm heartened by what I've seen so far.

Yeah, the default values are totally bonkers. I blame half of that on the lack of physics material in KSP. It doesn't take much tweaking to get uber sticky wheel like earlier KSP though, but that's not really any better, worse far as I'm concerned. If you can include something that lets one strictly control how fast the wheel spins that would be stellar. 

Edited April 6, 2016 by nli2work

[damerell]

On 05/04/2016 at 11:38 PM, lo-fi said:

Well, so far so good. I've made a crude (but working) car in U5 that approximates a KSP craft in its construction... which seems to be more than a lot of people before me have managed in U5.... Suspension behaves, it drives back and forth under command and the RPM readout seems to work fine. I'd even suggest that the grip model works much better than it used to! 10 (nameless units of torque) applied to a wheel of .5 radius accelerates much faster than with radius of 2, which is a step forward too.

U5 does specify the units of torque are Nm, I believe (and in general that all the units are the obvious metric ones, eg spring springiness is in N/m) - because the U5 documentation fooled me until I realised I was looking at it.

[lo-fi]

On 4/6/2016 at 6:27 PM, Shadowmage said:

From what I can see most of the base EVP classes are present in one of the new KSP .dll files;  you shouldn't need to purchase EVP if your only intent is KSP modding.  (I could be wrong though...if so, please correct me )

They are located in the Assembly-CSharp-firstpass.dll, in the default namespace; titled such as 'VPWheel', 'VPWheelCollider', 'VPXXXXX'; 15-20 classes from a quick glance; seems the whole package is there.  I have not yet tried referencing those classes/imports in a custom PartModule, but it seems like it should be possible.

That said; I have no idea how to link that .dll into Unity Editor so that you can do out-of-KSP debugging and development (which I often do myself for the more Unity-Engine-related stuff; procedural meshes, wheels, legs, etc).  Last time I tried it there were so many errors...

I was interested in the source  I'm not sure at this stage I even intend to use the EVP classes. From what I've read so far, it just does a lot of stuff I'd built into KF anyway, and adds a wrapper to simplify wheel collider config for those that don't understand how it actually works.

On 4/6/2016 at 7:26 PM, nli2work said:

Yeah, the default values are totally bonkers. I blame half of that on the lack of physics material in KSP. It doesn't take much tweaking to get uber sticky wheel like earlier KSP though, but that's not really any better, worse far as I'm concerned. If you can include something that lets one strictly control how fast the wheel spins that would be stellar. 

I've been working in U5 directly with the default physics material and looks good so far. We could actually create a physics material to apply, but that could also be dangerous... Wheel speed is indeed already controlled in KF

19 hours ago, damerell said:

U5 does specify the units of torque are Nm, I believe (and in general that all the units are the obvious metric ones, eg spring springiness is in N/m) - because the U5 documentation fooled me until I realised I was looking at it.

Ah, I missed that. The values are so different from U4, it seems like they've made an effort to get it using sensible units

[nli2work]

god thsi new forum editor suck ass...

I spoke a little too soon. I was referring to how stock wheels tend to spin out a lot during acceleration. But that's fixed by increasing adherent friction. Side effect of it is overall tendency to roll when making sharp turns, not unexpected, but something to deal with. 

Edited April 7, 2016 by nli2work

[lo-fi]

Perversely, what's causing that behaviour is the grip model being *fixed*!! The old model was fundamentally flawed, didn't actually do anything like it claimed to. and had ever increasing grip after slip occurred. You had the extremum, which is the peak before slip, the the asymptote value, which is what it drops to after you've exceeded the grip and serious slippage is happening. Real world, this is always less (other factors like tyre heat not withstanding). In U4, rather than staying steady after exceeding the extremum value, it dropped to the asymptote and merrily climbed steadily back up. Infinitely. So a little slip occurred, then was brought back into check as the grip (incorrectly) built again.  There was a forum post I can no longer find which contained a lot of experimentation, graphed the results and explained in depth. The new U5 collider behaves correctly, in that once grip is lost, it never builds again and the wheel runs away. It's the torque application model that's flawed now (enter @damerell). This we can definitely fix! The KSP method of calculating torque based on vehicle speed (which I stupidly copied) is another reason for wheels running away. It should be based on the RPM of the wheel (or wheels).

From what I can gather so far, the new wheel colliders are more correct in their behaviour, but this has not been well understood in the Unity community at large, particularly when we've had a flawed but benign system to get used to.... That's my take at the moment. It may change as I delve deeper. Exciting times!

[lo-fi]

Well, the U5 wheel colliders are a little sensitive. If you fluff the settings, you'll get odd results. Fair enough, IMHO - I don't see a problem.

A few interesting things I've noted:

• In my U5 testbed, the mass of the attached rigidbody(s) affects acceleration. If this carries over to KSP, we can ditch the vessel mass calculation.
• Grip can be a little shaky if the settings are wrong. It's easy enough to get "drift mode" that people have been mentioning happens in KSP (see fluffed settings comment above).
• Settings are not wildly different from U4. I doubt there will be much of a rewrite needed.
• Tank steering using motor torque (rather than braking the inside) works much better. I believe I can simplify the track steering config!
• Repulsors will be fine. Probably better behaved than before.
• Note how all the above is positive!

 As and when 1.1 drops for us mere mortals who bought through the KSP store, I'll set about getting it all updated. I don't anticipate any serious issues, assuming nothing totally daft is happening in KSP that gets in my way.

[*Aqua*]

I've got bad news. My computer just broke down. I turned it on and got a RAID error. It turned it of to check the cables and after turning it on again the screen just stays black and there's no "everything's alright"-beep. *sigh*
No beeping means that the mainboard and/or the CPU doesn't work. They are almost 7 years old, there're no compatible replacement parts on the market anymore.

It'll take me months to save up for a new one. Damit! Months without a computer will make me go crazy!

[lo-fi]

Dude, that's a real blow! However, as I run an IT support business, I have stacks of old spares knocking around. What do you need?

Also, faults like that are often just a blown electrolytic capacitor on the motherboard. Very common on older kit. Look for tops of cans that are no longer flat: they are most likely the culprit. Easy, cheap fix.

Edited April 9, 2016 by lo-fi

[*Aqua*]

55 minutes ago, lo-fi said:

What do you need?

A new computer. ^^
I'm done with my broken one. Only am month ago I had to replace the psu because the old didn't work anymore. The system has so many quirks and got so many temporary solutions (which became permanent solutions over time)... for me it doesn't make sense to revive it. I already had plans to buy a new computer in summer.

Fortunately I just got a new job so money's rolling in. Though it'll just take a few months to save up enough.

My old one:
AMD Phenom II X4 955
Gigabyte something UD5 (or so) mainboard
AMD Radeon HD6970 2GB
4x 2 GB RAM
3x 32 GB SSDs (different brands, RAID 0, for OS)
4x 1.5 TB HDDs (1 defect)
Asus sound card (has an amplifier )
bequiet 500 watts psu

Planned new one:
Intel Core i5 6500 or 6600 (or 6600K but then I'll need a different mainboard and something better to cool it)
Gigabyte GA-B150-HD3P mainboard
my graphics card if it still works
16 GB RAM (or 32 GB, not sure yet)
128 - 256 GB SSD for OS
512 GB - 1 TB SSD for games, dev and other stuff
my sound card if it still works
my psu if it still works

=> 550 - 800 €
 

I couldn't find blown capacitators. They are advertised as "all solid capacitors", I believe they can't blow up like the other ones or can they?

[politas]

Hello, lovely KF people! Really not meaning to hassle you at all, but I'm wondering if you're planning on uploading the last working KF to Spacedock at any stage, so that entry by "RichardKerman" can be removed? I'd really love to get things set up so that as soon as you push out a 1.1 release, your users can install it using CKAN.

[lo-fi]

You'll find much discussion in the old thread and this one regarding CKAN. My opinion is I'd rather the mod wasn't even there, and for one simple reason: If you can't read some install instructions, unzip some files into the correct folder and check for occasional updates, you should not be modding a game. Fair play to the guys that set it up, but I don't see CKAN as a good thing. Sadly there's no opt out, but it's nothing some odd version numbering doesn't successfully spanner (and it's sadistically amusing watching the advocates run around like headless chickens when you innocently move a decimal point)... Other members of the KF team - who are actually in charge of that side of things now - may have other views though, and it's their discretion on this one.

 

[damerell]

OK, the new forum has just eaten my entire reply to that, maddeningly, so here's a potted summary. Sorry if it's a bit more vigorously put; of course, I've just been utterly exasperated.

As a user I like CKAN: with over 100 mods in my Elcano install it would not have been a trivial matter to know they all existed (as in the old days of grobbling around Add-On Releases), a royal pain to unzip them all (given that modders are not remotely consistent about packaging, alas), and updates? Once you'd got a set that worked, forget checking for updates.

As a user of non-Windows OSes, it seems obvious to me that when you have a lot of packages, you want a package manager. No-one would suggest that people shouldn't use Debian if they can't compile everything themselves.

I'm not a developer, but I also think CKAN is best for developers. Get the CKAN metadata right once, and every user can install the package correctly, rather than facing a trickle of "bug" reports from bogus manual installs repeating the same mistakes over and over - just as every part includes a part configuration file rather than a set of general guidelines and an invitation to the user to write their own.

[nli2work]

ran some tests to get a handle on stock suspension behavior, might be helpful for you guys on KF.

 

[lo-fi]

1 hour ago, damerell said:

snip

All fair points. What I like about keeping it *off* CKAN is it acts like a barrier to entry and keeps the kind of *HELP!!!! WHEEEELSS NO WORK PLS HELP" idiots that would otherwise not have got hold of it - were it not for that nice, simple little check box - away. I don't have a problem with people using CKAN, I just don't want to be a part of it. It's the same as having some software that requires compiling from source, rather than with a package manager: it keeps those that can't from, well, doing. Remember that mod devs get paid the same if 1 person or 100,000 people download and install  making it too easy gives me no benefit whatsoever, and actually makes life harder in other ways. Yeah, it might save one or two install issues.. Big deal.

 

2 minutes ago, nli2work said:

ran some tests to get a handle on stock suspension behavior, might be helpful for you guys on KF.

 

.Thank you, that's really helpful!

[lo-fi]

I've been very kindly gifted a steam access code for KSP, so got 1.1 pre-release on the go. Stock wheels are weeeeeeiiiiird. I know they're still playing with them, but wow.

Took me a few minutes to get the KF plugin updated with the new references, fired up KSP, slapped some KF wheels on and BOOOOOOOOIIIIIINNNNNNG............. BOOOOOM. Guess I'll be working on the suspension settings, then 

 

[SpannerMonkey(smce)]

15 minutes ago, lo-fi said:

I've been very kindly gifted a steam access code for KSP, so got 1.1 pre-release on the go. Stock wheels are weeeeeeiiiiird. I know they're still playing with them, but wow.

Took me a few minutes to get the KF plugin updated with the new references, fired up KSP, slapped some KF wheels on and BOOOOOOOOIIIIIINNNNNNG............. BOOOOOM. Guess I'll be working on the suspension settings, then 

 

Ah yes perhaps that,d be the stock colliders spring rate being 3000 or something daft, mine did exactly the boooiiing booom action too, all the settings seem a bit squiffy and the example kindly provided by @nli2work is set way too soft for our type of suspension, currently running spring at 5 with damping at 1.2 is much better, I've found so little lateral grip that a stiff setup isn't an issue

[lo-fi]

I haven't yet unpicked what brand of bodgeification the stock modules do, so I'm steering well clear and will be working up from scratch using my unity test bed as a basis. I ought to export the parts using new part tools, really, and I know the mass settings will be all over the place. Still, I didn't get scrolling null refs after bashing the plugin for five minutes, which is a massive bonus, and the wheels did at least activate, even if they turned into pogo sticks!

[Seeker89]

1 hour ago, lo-fi said:

I haven't yet unpicked what brand of bodgeification the stock modules do, so I'm steering well clear and will be working up from scratch using my unity test bed as a basis. I ought to export the parts using new part tools, really, and I know the mass settings will be all over the place. Still, I didn't get scrolling null refs after bashing the plugin for five minutes, which is a massive bonus, and the wheels did at least activate, even if they turned into pogo sticks!

Come to think of it. Would be kinda funny to see...

[lo-fi]

I was too busy laughing to think of screen capping

 

Apparently it's not to do with suspension settings.... Even held off the ground, the moment you launch it shakes itself to bits and heads for orbit. Oh what fun.

Edited April 15, 2016 by lo-fi

[lo-fi]

I've no idea what the pogo was about... Anyway, I've got the plugin working fine with wheels in 1.1, which gives me a good basis for experimenting with suspension, grip and all that sort of stuff. I quite like Squad's idea of adaptive suspension, so I'm going to pursue my own method. I'm crossing fingers the new colliders will allow on-the-fly spring and damper updates, which would open up a load of cool possibilities. Tracks are not playing ball so far - getting a nasty explosion and Collision Enhancer Punched Through Terrain messages the moment physics starts.

 

EDIT: alright, tracks are working. We have the classic problem of runaway RPM caused by the correct grip models now being implemented, which I think I can see a neat way to fix. This is all detail stuff, though. TRACKS WORK IN 1.1, BABY!!! I used the long tracks for testing, as these have the most wheel colliders in a single part. I have to say, I really like what I'm seeing in the new colliders.

Edited April 16, 2016 by lo-fi

[V8jester]

You're freaking amazing @lo-fi!

Thank you for code bashing KF back into existence once again  can't wait to see what comes out of the foundry next!

[SpannerMonkey(smce)]

2 hours ago, lo-fi said:

EDIT: alright, tracks are working. We have the classic problem of runaway RPM caused by the correct grip models now being implemented, which I think I can see a neat way to fix. This is all detail stuff, though. TRACKS WORK IN 1.1, BABY!!! I used the long tracks for testing, as these have the most wheel colliders in a single part. I have to say, I really like what I'm seeing in the new colliders.

Award for best edit of the week

 

[lo-fi]

Thanks guys. It's still not without its challenges, and there's a lot of work to do to get things working as well as I'd like. I suppose the worst thing is the grip/mass settings that cause either bouncing or drift mode when approaching anything reasonable, and I can't figure out why it seems like the brakes are slammed on when motor torque returns to zero, which doesn't happen in my U5 test rig. I'll figure it out eventually

[damerell]

On 16/04/2016 at 5:59 PM, lo-fi said:

and I can't figure out why it seems like the brakes are slammed on when motor torque returns to zero, which doesn't happen in my U5 test rig. I'll figure it out eventually

Is that perhaps an artefact of the very high rolling resistance in the KF plugin?