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

[ZodiusInfuser]

What show were you listening to? Btw, cool!

[lo-fi]

Spooks! Few things to tidy up, then I think it's ready.

[V8jester]

Oh now that looks cool! So they only support on the upper and lower faces correct? They would I assume crash on there sides correct? And how is that trailer hitch idea you had coming along? Have you messed around with it at all lately?

[lo-fi]

They _always_ repulse towards the planet. Doesn't matter what angle you're trying to lithobrake at, they'll do their best to save your Kerbals asses

Nothing on the hitch I'm afraid; I got stuck on the persistence and time warp issues. May need some serious help with that if it's ever going to get solved.

[V8jester]

They _always_ repulse towards the planet. Doesn't matter what angle you're trying to lithobrake at, they'll do their best to save your Kerbals asses

Nothing on the hitch I'm afraid; I got stuck on the persistence and time warp issues. May need some serious help with that if it's ever going to get solved.

Well I'd offer my help but your abilities far surpass my own. And regardless of what happens with the hitch. You have made some really great additions to KSP.

[Mekan1k]

So, I've been playing with another repulsor design. These ones are truly omni-directional:

http://youtu.be/5O8aAQeFha0

Gaalidas, over to you with the dust effects configs

I love this! Where is the cockpit from?

[lo-fi]

Thanks guys Wasn't quite sure about them, but I had fun making the effects and glad you're liking the new repulsors.

Cockpit is from nli2work's Space Tug. The IVA is not complete yet as far as I know, but it's awesome anyway.

[smjjames]

Ok thanks.

Btw, just a heads up, looks like the next version of KSP will break everything with physics and wheel colliders: http://forum.kerbalspaceprogram.com/threads/122159-Devnote-Tuesday-Back-to-Work%21

That might not even be in 1.1, this won't be the only one. Hell, anything that has physics will probably break, which is, well... everything....

[lo-fi]

Ok thanks.

Btw, just a heads up, looks like the next version of KSP will break everything with physics and wheel colliders: http://forum.kerbalspaceprogram.com/threads/122159-Devnote-Tuesday-Back-to-Work%21

I missed this somehow. Thanks for the heads up, I'll have to see what happens when they release it. Could be good!

UPDATE:

Unity 5 will limit to 20 wheel colliders per rigidbody (vessel). Not good :/ The long tracks, for example, use 9 wheel colliders each, so adding more than two units per vessel will no longer be possible and will probably just lead to random failure of some of the wheels. $%&£

Edited May 20, 2015 by lo-fi
:

[riocrokite]

spreadsheet updated, there are 2 sheets, first with original values, second with suggestions:

https://docs.google.com/spreadsheets/d/1Xuo5LediKls2P91sudoXpxwhubX39Pp1fw01bDyEyfI/edit?pli=1#gid=2063330958

New stuff from Zodius added.

I haven't touched techs and stuff that isn't there (like overSpeedDamage nor impactTolerance) since it requires broken track/wheel model (would be nice to have though )

edit: wheel coliders unity limit is ridiculous, so docking more than three vessels with 6 wheels on each will break your stuff

Edited May 20, 2015 by riocrokite

[smjjames]

I missed this somehow. Thanks for the heads up, I'll have to see what happens when they release it. Could be good!

UPDATE:

Unity 5 will limit to 20 wheel colliders per rigidbody (vessel). Not good :/ The long tracks, for example, use 9 wheel colliders each, so adding more than two units per vessel will no longer be possible and will probably just lead to random failure of some of the wheels. $%&£

Wha? That wheel limit makes absolutely no sense, I hope SQUAD finds a way around that.

[ZodiusInfuser]

UPDATE:

Unity 5 will limit to 20 wheel colliders per rigidbody (vessel). Not good :/ The long tracks, for example, use 9 wheel colliders each, so adding more than two units per vessel will no longer be possible and will probably just lead to random failure of some of the wheels. $%&£

Not good. Four mecanum wheels alone use 32 colliders . Are you sure rigidbody is vessel in the case of KSP? I thought each part was its own rigid body?

[lo-fi]

spreadsheet updated, there are 2 sheets, first with original values, second with suggestions:

https://docs.google.com/spreadsheets/d/1Xuo5LediKls2P91sudoXpxwhubX39Pp1fw01bDyEyfI/edit?pli=1#gid=2063330958

New stuff from Zodius added.

I haven't touched techs and stuff that isn't there (like overSpeedDamage nor impactTolerance) since it requires broken track/wheel model (would be nice to have though )

edit: wheel coliders unity limit is ridiculous, so docking more than three vessels with 6 wheels on each will break your stuff

Excellent, haven't had a chance to have a proper look yet.

EDIT: Looks great, thank you so much!

Ought to look at power, braking and steering too I guess!

Agreed, the wheel limit is ridiculous.

Wha? That wheel limit makes absolutely no sense, I hope SQUAD finds a way around that.

I don't think Squad will have much of a say. It's not even a Unity thing as far as I can see: it's a physx thing. Possible we will still be able to use legacy colliders, though. I hold out hope!

Edited May 20, 2015 by lo-fi

[riocrokite]

Excellent, haven't had a chance to have a proper look yet.

EDIT: Looks great, thank you so much!

Ought to look at power, braking and steering too I guess!

Agreed, the wheel limit is ridiculous.

I don't think Squad will have much of a say. It's not even a Unity thing as far as I can see: it's a physx thing. Possible we will still be able to use legacy colliders, though. I hold out hope!

I had a small chat in #kspmodders forum and it seems that rigidbody =/= vessel so there might no such limitation at least to vessel as a whole. This might mean that limitation is per part.

[lo-fi]

I had a small chat in #kspmodders forum and it seems that rigidbody =/= vessel so there might no such limitation at least to vessel as a whole. This might mean that limitation is per part.

Hmmm. I'm trying to recall how KSP implements rigid body. I seem to recall each part having its own - it has to for joints to work - but had a feeling it did some weird reparenting shenanigans inside the vessel. Let's hope all is not lost. Besides, it hasn't happened yet, and the wheel colliders may be a lot better!

[Overlocker]

Maybe the next movement for this mod, appart from that awesome new repulsor, is to convert the textures to DDS, because most of the normal size mods out there don't go more than 30-40 Mb and this one is about 80 Mb

[lo-fi]

I would if I could get them to look anything other than hideous as DDS. I have yet to work out if I'm doing something wrong, or people are just happy with textures that look like up sampled jpegs so they can run fifty mods..

[Beetlecat]

Not good. Four mecanum wheels alone use 32 colliders . Are you sure rigidbody is vessel in the case of KSP? I thought each part was its own rigid body?

That's my understanding as well -- Plus it wouldn't make sense for unity 5 to be *more* limiting, right?

So what this means is that treads in U5 can be ENORMOUS! I fully expect someone to mod the crawlerway crawler for VAB launches.

[lo-fi]

Not good. Four mecanum wheels alone use 32 colliders . Are you sure rigidbody is vessel in the case of KSP? I thought each part was its own rigid body?

I'm not sure. I did a lot of digging while messing with the hitch joints. KSP is.... Weird in that respect. Will require some research! Certainly seems to be a lot of bitching going on about it on the unity forums...

[riocrokite]

Maybe the next movement for this mod, appart from that awesome new repulsor, is to convert the textures to DDS, because most of the normal size mods out there don't go more than 30-40 Mb and this one is about 80 Mb

yah, btw lo-fi / gaalidas,

have you thought about making your mod more modular?

For example core pack with wheels and tracks. Then separate pack with extras (roverbody, and exotic drives like skid, screw and repulsors + other stuff (hitch))?

It would help to declutter editor (+ save some ram) for people that don't need whole package.

[lo-fi]

Thought about it, but people are easily confused :/

The rover body I thought about spinning off as it doesn't have a plugin dependency, and there will be a few more to come eventually.

[Gaalidas]

I'm sure confused easily. That's not to say I don't like modularity, but whenever I modularize something, I confuse myself. It's a confusing conundrum of confusion-inducing confusion. Are you confused yet? I sure am.

Something confusing to me right now is the fact that, when using DDS textures, even the stock unmodified ones, the game seems to want to selectively not load some of them properly and display the default white texture on the parts affected. It's apparently a completely random occurrence, and even affected my own conversion of the KF parts into DDS. I've been reverting to using PNG on all my modified textures for the time being. My latest theory is that KSP is not forcing mip-map levels instead of only using them if they are present in the file. Because KSP is forcing the mip-map levels, if the level is not present in the file it will display a null texture. Because KSP has a setting for less-then-full resolution textures on load, then it detects the lack of certain mip-levels when loading the assets and outputs a "texture not found at -insert url here, which can be confirmed to have that texture present and accounted for-" and displays the default white instead.

I'm working on proving this theory.

Back to modularity... it would actually cease to be all that necessary if we could just reduce the number of duplicate textures being loaded. Right now the repulsor diffuse texture is being loaded for every part that has a repulsor in it, including the model for the medium wheel which is based on the model that was used for the currently perpetual-WIP part "repulsor wheel" and the newer repulsor effects which include that electric texture, and its accompanying emissive. There's also that arrow texture which is being loaded several times for each part that uses it. I've talked before about texture sharing, but I suppose I'll need to reiterate it.

In short... there are two ways we can rectify this. First off though, that wheel which needs the repulsor texture for the deleted object within it could either be re-compiled without the need for that texture or the texture itself can be reduced to a 1kb dummy texture. For the others, we need to identify if certain textures can be unified. I suspect that a number of the tread textures could be reduced to one unified texture that would cover all of them, or at least a large number of them. Except for the RBI conversions, I've noticed that the treads are pretty much identical in a number of the more recent tread designs. The next step can be done it two ways: you can use MODEL nodes instead of "mesh" parameters to define the models for the parts in the configurations. This allows you to put the full resolution textures in a separate directory, then reduce the textures in the part folders to dummy texture sizes and use the following to redirect the model to use the full resolution versions such as in this example:

MODEL
{
    model = KerbalFoundries/partname/partmodel
    texture = texturename, KerbalFoundries/Assets/texturename
}

Where the first "texturename" is the local dummy file name, and the second "texturename" and it's accompanying path are the path to the full resolution texture in relation to the GameData folder. The model itself must also be referenced by its path from GameData onward (not including the model extension ".mu" in this case). This leads to an even better ay of doing this...

The second way of doing this is actually my preferred way. This is to emulate what is commonly done for mods in the USI line. While not done in all of Roverdude's mods, the practice is usually to have all models and textures in an "Assets" folder, with each model having a unique name instead of the default "model.mu" that Squad likes to use, and then to put the configs into a second folder called "Parts" without any extra subfolders, and each config to match the name of the part they are assigned to. You still use "MODEL" nodes, but you don't need to set a "texture" parameter because, from the model's perspective, it's loading all of its textures from the same directory as it is currently residing which is what most models in KSP do by default. You simply enter the location of the model in the "Assets" folder within the config and the game does the rest on its own. Each model can then use the same textures, assuming the duplicate textures are named the same. That's where the model-recompilation step takes place. If you have duplicate textures that have unique names, the models need to be recompiled with those referenced textures renamed so that they are the same. The major benefit to this second option is that no dummy textures need to be loaded into memory which, while the dummies are extremely smell (and thus not much of an impact on memory) they still need to be loaded which, in theory, slows down initial asset loading time when starting the game. The second option also makes the directory structure a lot less confusing and, since all the configs are in a single folder, editing the parts on the config level is a lot easier.

Now, I'm perfectly willing to re-assemble all the assets to accomplish this myself, but I cannot necessarily recompile the models if textures need to be unified. the one downside to all this is, of course, that modularity of the parts is reduced a bunch. However, if multiple parts can use the same textures, such as the case with those which use the generic brushed metal texture or whatnot which is used in a few of lo-fi's creations, then you can easily release mini-packs which re-use the same assets and don't need to bloat the game any more than a few more configs would do. Roverdude often makes use of the same textures for multiple parts, sometimes even in completely different models from completely different mods. The best example is where a texture is named something like "common.png" in which a lot of commonly used images are used in multiple models across all of his mods which gives them that unique look and feel that Roverdude likes to put in his models. He still has to distribute that same file with all of his mods, but it simply overwrites the old copy of it when installing and doesn't bloat the game with duplicates because he loads it from a common "Assets" folder.

I sorta miss this kind of unifying texture management from previous games I've modded. For instance... in the line of games made by Bethesda, most textures are loaded in relation to a "Data/textures" directory. In the models (they use the nif model format, very easy to edit after compilation because... well... they're not a compiled format) you can simply reference the texture by name, leaving out any path. If the texture is located in the root default for the game's search paths, then it uses that. If that is unavailable, then it searches for a possible like-named texture either in the directory that the model resides in, or in alternate locations such as within a compressed game assets file. It prefers the loose file in the root texture folder, but will use the alternate if need be. This is similar to how TextureReplacer will use a texture within its own folder if the texture is present, otherwise KSP will be allowed to use the texture located in its compressed assets. It makes texture management and memory management so much easier.

Okay, I'm done now... wall of text completed successfully.

Edited May 21, 2015 by Gaalidas

[ZodiusInfuser]

Thought about it, but people are easily confused :/

The rover body I thought about spinning off as it doesn't have a plugin dependency, and there will be a few more to come eventually.

I've gone for the modular approach with the IR Rework and it's proven good:

• Core Pack - Parts I consider to be essential to the mod
  
• Expansion Pack - Parts that are cool but that most players don't need day-to-day
  
• Utility Pack - All the parts with dependencies or that aren't robotic (e.g grippers, wheels, struts)
  

What I find interesting is the difference in number of downloads on KerbalStuff, the Core and Utility packs are far more popular than the Expansion pack (or they were before KSP 1.0 hit)

[Gaalidas]

Sometimes you get certain mods that show up on the first page, but the third in the series gets buried to the second page and people just move on to other things rather than go to the next page. KerbalStuff needs to allow the number of items per page to be expanded, or allow a mod entry to expand into a sub-list so modular modification packages can group their stuff together. Another nice feature would be to allow the parent entry that hosts the sub-list to have a "download the latest version of all sub-listed mods" button or something.

I'm definitely guilty of not checking out stuff that are buried and later, upon finding out they exist, I'm amazed I never saw it before. If only we payed more attention.

As for IR rework... yeah, it's pretty modular, but it also doesn't reuse a lot of assets. Granted, there is a part of it that uses dummy textures, but for the most part there's a ton of textures that are all identical to each other in separate folders. I will grant you that most users would not notice the memory impact, but I'm running on a non-gaming laptop and I have to grab every little bit whenever possible. This leads to me having to do some modifications to how the IR parts reference their models and textures whenever I update.

Edited May 21, 2015 by Gaalidas

[sharpspoonful]

Soooo....I did a thing.

Javascript is disabled. View full album