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

[brusura]

I want 1.9 .... please

[lo-fi]

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

[smjjames]

I want 1.9 .... please

With all the new stuff, it sounds more like 2.0 than 1.9.

Anyways, yeah, got a beta that we can mess around with?

[lo-fi]

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.

[Gaalidas]

Just need to update all the part configs to handle the updated lookAt stuff, and whatever else you've done, and we're set for a release really. That's all that needs to be done to make everything functional.

I have a question about the new way we're handling DustFX on the wheels. It looks like the KFModuleWheel is now calling the DustFX up, instead of the DustFX calling itself up when the part collides and scrapes. What happens when the DustFX is called up and the part does not have the module defined in its configuration?

Edited July 4, 2015 by Gaalidas

[vardicd]

*Wrong thread

Edited July 4, 2015 by vardicd

[Gaalidas]

I don't see how it would be an artifact of Kerbal Foundries, honestly.

[vardicd]

I don't see how it would be an artifact of Kerbal Foundries, honestly.

I realize that, I've been up for about 19 hours now, had multiple windows open and posted in the wrong one, my bad.

[lo-fi]

Just need to update all the part configs to handle the updated lookAt stuff, and whatever else you've done, and we're set for a release really. That's all that needs to be done to make everything functional.

I have a question about the new way we're handling DustFX on the wheels. It looks like the KFModuleWheel is now calling the DustFX up, instead of the DustFX calling itself up when the part collides and scrapes. What happens when the DustFX is called up and the part does not have the module defined in its configuration?

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.

Edited July 4, 2015 by lo-fi

[Gaalidas]

I doubt there will be any issues with the module not being in the config, but it's something that could come up for future modders. My thought was to simply not make the call to DustFX if the part in question didn't have the module on it. That way a future wheel-maker could make that choice for themselves. Once I get something better working for the global on/off switch, I can safely add the module to all the parts in a more permanent way instead of relying on an MM patch system for it.

Another thing about all that, I would like to look into not having the camera even become active if the particles are globally turned off. This would further reduce a performance impact for a user with a weak machine. That is assuming that the camera is doing much for performance as it is. I would still like to hash together a test module that would implement a camera per-wheel fixed just slightly above that wheel and taking in the color just below the part itself and see what it does to the performance. I'm just curious as to how it would perform. I could probably just grab the code from the vessel module stuff and stick it into a part module, rewriting the positioning code to use the specific part as a point of reference.

That reminds me, I need to look into perhaps detecting the part size, both in relation to the stock size and the scaled size, so I can set a baseline for particle emission size without having to use MM and some good old fashioned guessing to set that. I want the module to be able to figure out how large the effect should be based on how large the wheels are, if possible, so that those tiny wheels don't start producing dust plumes the same size as a mega-wheel (or whatever).

Research into figuring out the craft size has hit a lot of dead ends. It seems that all the other mods that rely on figuring out the craft size all make use of those methods in the environment that they were originally supposed to be used in: the VAB/SPH. There doesn't seem to be anything in place already to determine the craft size in the flight scene. I'm now wondering if I'm going to have to try and determine the offsets from the center of the craft for all the wheels attached to the craft, and then keep the furthest discovered distances to use as a range in which to adjust the camera FOV. Anyway. that's all something to deal with in the morning. Time to rest this brain of mine.

Edited July 5, 2015 by Gaalidas

[lo-fi]

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!

[Gaalidas]

The look-up for the global variables is actually extremely easy. I added the config file to the "assets" repository and the config manager is in the plugin repository. You don't need to modify anything in that file though. For the globalDisableDust variable, I called it up using: -snipped, obsolete- from a locally defined variable. You simply have to make sure that the variable you're trying to pull exists in the config file, and you're good to go. However, I'm thinking about changing the name of the global variable to something like "isDustEnabled" to make it easier to work with. In fact, I'm going to do that now.

Also, yeah... I like the idea of moving as much as possible into the vessel module. I think there's a lot that this mod does that could be done at that level, reducing the amount of work needing to be done on every single part.

EDIT: Scratch some of that above, I wasn't awake yet. If you want to add a new variable to the file, you will want to add the variable to the config manager in a similar fashion as I did with the "isDustEnabled" parameter. The log part is optional of course. If the config was instead loading a list or a dictionary of everything in that node, then we could add/subtract variables at will. As it is we'll need to define them. For the Dust stuff, however, you shouldn't need to touch the config manager, just call up the variable with:

your_variable = [COLOR=#004085]KFConfigManager[/COLOR].[I]KFConfig[/I].[I]isDustEnabled[/I];

Edited July 6, 2015 by Gaalidas

[lo-fi]

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!!

Edited July 6, 2015 by lo-fi

[lo-fi]

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!!!

Edited July 7, 2015 by lo-fi

[xEvilReeperx]

It means you're trying to get a Single() item from an IEnumerable of ConfigNodes, but either there are no items or there is more than one. The code already checks for no items so you seem to have duplicate DustColorDefinitions ConfigNodes in your install

[lo-fi]

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...

Edited July 7, 2015 by lo-fi

[Gaalidas]

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!!

Sorry, I get carried away sometimes.

Actually looks like proper code? I'd better go fix that... -grabs a hand-blender and an old sock-

[lo-fi]

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.

[Sharpy]

A question about the wheels: how round and wheely are they? Do they behave like stock (skids with propulsion on the bottom, inert all around) or could I still drive a very flat rover upside down on them?

[lo-fi]

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

[Sharpy]

Technically, I can obtain something like a true wheel by clipping multiple wheels in radial geometry, so that their "active surfaces" point outwards, so it's not impossible in the engine - just give the wheel six or so such raycasts all around?

[lo-fi]

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

[Gaalidas]

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.

Hmm, that engine lighting mod comes to mind. Anyway, the effect should be swappable, if you can find the internal effect path. Of course, you'd need to swap out the entire color configuration as well. I thought about it myself, but abandoned it due to the lack of control over the splash effect itself. To get the effect you're going for in the repulsor dust, you might have to look at what the stock surface effects do. There's also the possibility that you could give the effect we're using now a starting horizontal velocity that moves away from the repulsor field's center.

Aren't those inverting RBI tracks capable of being driven on the inverted side? Not that it's very doable due to the size of the track itself, but I seem to remember someone making it happen in the past, pre-KF. In my mind, the only way to do Something like a true wheel with the suspension is to make it into two parts: one which has the suspension system, and another with the wheel, and do something similar to what MSI does to move objects with their associated attach nodes when the parent part is animated.

Edited July 7, 2015 by Gaalidas

[lo-fi]

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!

[Sharpy]

What about wheels without suspension - rigid axle?