lo-fi

You will need a copy of 4.2.2.. try setting up another account? After its installed, create a new project, install part tools, follow the tutorials in the mod dev links sticky. The YouTube by tiberion is perfect for setting out what to do.

Indeed! The lights may not even make it, but the particles are going to look fantastic once tweaked. New wheels still need a lot of love in the texturing department too.

Ah, nice one V8jester. And thanks - you're too kind The repulsors do have emissives now I was just playing around really. I might force the lights into vertex mode, which is far less intensive than pixel. For that sort of thing, the light looking a little messed up can be no bad thing. And agreed, the config field is a great idea. For the UI, you could also look at HyperEdit. It's nice and simple. Really liking how this is shaping up!

Check out the "mod development links" sticky curated by Cpt Kipard. There shouldn't be stuff in there that's wildly out of date, so you're pretty safe. Steer clear of anything really old that suggests loading a .dae directly into the game. As long as the workflow involves getting the model into unity, then using part tools to compile the model into a .mu, it's still relevant as the process hasn't changed much since part tools came out. Sketchup is fine for making models, though I believe it doesn't give you a way to set up UV mapping for your textures, so you'll have to shift to something else like Blender to do that bit. But don't let that put you off rigging an untextured model up and getting it into the game to get used to the workflow before you invest the time in learning how to unwrap and texture. Good luck!

I lose track of what I've changed! And the torque, steering and braking has been tweaked. Though I could just implement ABS... Spanner did some smashing work.. I believe he used IR for those, but I'd just write a plugin to get proper control over the joints (see my trailer hitch video). That's the sort of design you can only make with joints. I'll have a bash one day

I'll look into it. So far, the starting velocity stuff hadn't quite worked as I expected... The RBI tracks are a bit different to wheels, in that the inverted colliders have their own suspension. You could do it that way, but you don't need separate parts. The important bit is having a physics joint between the wheel collider and the rigidbody of the part, which of course has to be scripted. Set it up as a linear joint with limits, zero the suspension on the collider and you've got a working wheel. I am tempted to try setting up some wheels this way, but it will need a totally new type of wheel module. Though it's overkill really. What we have works, and really it's good enough. Anyone that needs something more probably ought to have the skill to go make it!

The tricky part with that comes when you look at figuring out the suspension movement. Then you realise that's a no-go. A potential solution is to use sphere casts, point the wheel collider at the collision point and do some maths. But wheel colliders don't like simply being moved or rotated outside the physical simulation, so they go a little nuts. All of this is expensive in an already physics intensive game... I tend to take the view that it's a game with little squishy green aliens with impossibly large heads, so perfection is the enemy of "good enough", rather than the other way around

Sadly, wheel colliders are really a one dimensional raycast pointing in a set direction. Believe me, I wish it were different.

Haha! Grab the latest dev build. I've been busy Can't quite get the reoulsor dust to do exactly what I want just yet, but I'll get there eventually. One thought about racing over the water: I'm wondering if we can swap that particles to the water splash effect? Also looking at adding a light at the contact point. Should look really nice against the dust.

Ah, thanks for the pointer. I'll go a hunting... EDIT: thanks, my bad. Had a copy of the def config straying about All working now - biome colours and the camera stuff the camera method seems crude, but it's surprisingly effective. The repulsor module needs some attention now...

Right, that's got things up to date again. I've merged the dev branch back into master before the two get hopelessly out of sync. Hopefully I didn't lose anything in the process... I've just added a node to turn the orientation markers off and proceeding to the camera stuff. EDIT: Well. I say it's working like a charm. Trying to reactivate the biome stuff, I get this little gem: InvalidOperationException: Operation is not valid due to the current state of the object at System.Linq.Enumerable.Single[ConfigNode] (IEnumerable`1 source, System.Func`2 predicate, Fallback fallback) [0x00000] in <filename unknown>:0 at System.Linq.Enumerable.Single[ConfigNode] (IEnumerable`1 source) [0x00000] in <filename unknown>:0 at KerbalFoundries.KFDustFXController.Awake () [0x00000] in <filename unknown>:0 UnityEngine.GameObject:Internal_AddComponentWithType(Type) UnityEngine.GameObject:AddComponent(Type) UnityEngine.GameObject:AddComponent() KerbalFoundries.KFDustFXController:get_DustColors() KerbalFoundries.KFDustFX:DustParticles(Single, Vector3, Collider) KerbalFoundries.KFDustFX:Scrape(Vector3, Collider) KerbalFoundries.KFDustFX:CollisionScrape(Vector3, Collider) KerbalFoundries.KFModuleWheel:OnFixedUpdate() Part:ModulesOnFixedUpdate() Part:FixedUpdate() I've literally no idea where to start with that. It's something to do with "colorAverage = KFDustFXController.DustColors.GetDustColor(vessel.mainBody, col, vessel.latitude, vessel.longitude);" Well, OK. Why is it complaining about config nodes??? I assume that's to do with something in the KFDustContoller class, as it happens when the DustColors method is called. But I'm not even sure how to read that error message, so who knows what's going on!!!

OK, cool. I'd as global config fields for the orientation markers, camera stuff, maybe a few other bits I haven't thought of yet. Great work, thanks for sorting that out. I'll try and hit some of the other stuff on the to-do list this evening - - - Updated - - - Woah, dude, what an unholy mess!! Please stop jiggering the line spaces and formatting on WIP modules, it creates a nightmare merging them back just because a carriage returns and line spacing got removed :/ You can make them beautiful after it's all working and won't be messed with any more Otherwise I'm just going to keep messing all over it while I'm bug hunting, refactoring and generally beating stuff into submission. On the plus side, loving the summary into, logging stuff etc. Actually looks like proper code and everything!!

You can't make a concave shape convex.. does it genuinely need to be hollow, and if so, does it need to have an accurate collider? Add an empty GameObject. Zero it's position and rotation, apply part tools to it, add the model as a child and set up it's position correctly in relation to the parent object you just created - the top level object with part tools applied will be the centre of the object as far as KSP is concerned. This will fix the orientation, no matter what crazy stuff is happening in the model. What format are you exporting from your modeling tool? Dae? Fbx?

I think you're over complicating it.. a better way will be to simply put the camera further away and maybe do some clever trickery with culling masks. Can certainly test camera per wheel, but I think that'll get a bit much. Besides, it works rather well as it is I've modified so it doesn't break if the patch is not applied. Where did you put code to read from the global config file? I'll add some checks in to play with the camera activation. Also, an optimisation would be to move the biome colour stuff into the vessel module, which will save as many redundant lookups as there are wheels on the craft. Neat, huh? I'm working on the part size thing. Just worked out the IPartSizeModifier stuff, which is totally, absolutely bonkers. I will fix the assembly building size bug!

^ For future reference, this is generally good practice. Glad you got it fixed.

Woah there! Repulsors still need a lot of fixing, and should probably test a few of the other bits more thoroughly. I know Zodius has run into a nullref issue, so need to look into that I can do a little update to remove the need for the MM patch or config call - might cause less hassle. At the moment, it will likely lead to a nullref, which thinking about it is likely to be Zodius' issue... UPDATE: Got it fixed. Now adds the DustFX part module if it's not added by MM patch. Still a heck of a lot of stuff to finish and test before I can confidently release it! That, and new parts are barely finished, let alone textured. May end up a plugin only update with aprs to follow, as there are other modders waiting on the new features. None-the-less, a lot of configs still need updating.

If it was in a usable state, I'd release it Sadly not - stuff is literally in pieces as I've been messing about with various things.

I am alive! Will respond when I've got an hour spare to go through the wall of text as usual, I have a few ideas... Soon, Brusura, soon

Anything is possible, it just depends how much work you want to put into it More complex dust generation would be cool, but may be beyond the scope of KSP. Have a good look at the wheel collider hit scripting docs, Gaalidas. All the stuff you want to do is achievable by grabbing info from the wheel colliders hit point. At the moment, the only info I grab is the hit coordinate, but slip amount (both long and lat separately) and force are also available. The methods just needs expanding to encompass those. So much more is available to us this way than you can gain using the generic OnCollision method. Do consider my camera code a very basic proof of concept. It will need a lot of fleshing out for prime time, but it is fun to play around with.

Very cool Saw the updates in the parts repo, but don't forget to commit the code changes. Don't worry too much about the UI for the moment, I understand it's a frustrating black art, though you can probably grab a working set of code from somewhere. Global config will be really useful.

The crazy reported sizes are indeed to do with the skinned mesh. It's the same reason that the editor icons are tiny if you don't use the icon fixer plugin. Sadly not something I've been able to fix. The culling mask is cool, Gaalidas. I had a feeling there was something like that you could do, but hadn't looked that far. No idea what's been going on with my biome colour testing, so I'll have to do a little more playing around.

That usually means that PartTools didn't finish exporting the .Mu properly. Check that you've not got and mesh colliders etc without a mesh filter applied to an object, and remove that animator component - KSP doesn't support it.

Yeah, that's kinda what we have - just controls to implement. Kerrin is indeed the most complex - the rest are fairly simple.

I think we would be in lag central with one camera per wheel!!! One cam per vessel. It's positioned above the vessel, always looking at the center of the planet you're on. Individual wheels don't calc their own colour, it's whatever gets averaged out of the camera and will be the same for all wheels on the craft. Unless you're looking very closely, you really won't notice. Yes, this does mean that the vessel colour is counted in the average, but that actually works quite well and lifts the dust from being exactly the same as the ground. Have you changed any of the colors recently? Runway used to be grey, but change to brown when you got to the grass. No longer seems to change when off the runway. This was before I experimented with the camera stuff... I drove a rover over to the mountains to see what would happen, but dust still grey. Haven't tried any hyperedit somewhere else yet. Global configuration file would be good!

Now I need three days to read your last posts... The camera stuff is a vessel module, not a part module. This means one instance gets added for each active vessel in flight automatically. IIRC, the update routine checks if the vessel it's running on is active vessel. This is why it's done in VesselTools, and doesn't need an MM patch or anything to get it running. The repulsors will just need a similar mechanic to the wheels added in - it's no big deal. KFModuleWheel just searches for the camera module on the attached vessel and grabs the colours to pass up to the dust stuff, though the biome info needs adding back in and some benchmarking done on the camera stuff. Still need to work out what's up with the defaulting biome info, so I'll have to read through EvilReeper's plain English explanation and poke about. Going to be a busy week, though.