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

[Gaalidas]

The APU also has the advantage of having, at least to me, a more aesthetically pleasing look to it. It looks like something designed to generate power in an atmosphere. It's also a great addition to aircraft where you need power for certain applications without producing a significant amount of thrust from your main engine, like while you're trying to land while using reaction wheels to keep the plane steady.

-snipped stuff-

It's not throwing out the Fuel Cells because it can't make electricity without oxygen, but it means you're not lugging around oxidizer on your Laythe Exploration Rover, which means less overall weight in your ship to get it there.

I wanted to weigh in on this. Yeah, it does look great (needs its base to be assigned a texture though) but there is one problem with it: the thrust. Granted, it produces an extremely small amount of thrust, however I have had some trouble with several flight assistance mods where I had to disable certain features because the APU was being taken into consideration when calculating the thrust of the craft and was limiting the rest of the engines to match. This fact alone is a good reason to at least switch out the module within it to something that runs independently of the engine module. It shouldn't be too hard to assign a sound, and even a tiny little particle to an exhaust pipe or something, to run along with the fuel-to-power conversion. It also shouldn't be too difficult to add an intake air/atm requirement for a fuel-cell style module attached to the APU model for the up side of not needing oxidizer.

[Space Scumbag]

Hey guys,

can someone of you elaborate the current state of this mod? I try to keep up and read the latest comments/conversations from time to time, but here in this thread is happening so much. Too much if you don't have the time to read all of it. So, maybe you can add a new, updated FAQ in the first post? What features are you currently working on, what will be the biggest changes in the next update, any estimation for the next release, what's up with DustFX, a final release? etc.

This would be really nice of you and could probably help others to stay up to date.

[lo-fi]

Good call, actually! Reading the thread would be quite a gargantuan task to be fair, and most of it is dev stuff that most won't necessarily be interested in. I'll do a little status update when I have a few minutes

[Gaalidas]

Think we're ready to do a thread in the release board for this next update? I also wonder how large a specific thread should be before we try to lock it down and start a fresh thread for the dev stuff.

Edited July 23, 2015 by Gaalidas

[lo-fi]

Yeah, it's getting a little out of hand, isn't it! Given the major changes, I'd like to keep the up coming release as beta - there will be bugs to iron out. Once that's settled, let's release at 2.0!

[*Aqua*]

Hey guys,

can someone of you elaborate the current state of this mod? I try to keep up and read the latest comments/conversations from time to time, but here in this thread is happening so much. Too much if you don't have the time to read all of it. So, maybe you can add a new, updated FAQ in the first post? What features are you currently working on, what will be the biggest changes in the next update, any estimation for the next release, what's up with DustFX, a final release? etc.

This would be really nice of you and could probably help others to stay up to date.

What's on the agenda for now:

- All wheels and tracks configs need to be updated for balances and new features.

- Code clean-up.

- KSP's part loader calculates wrong sizes for some parts.

I think we don't have a list of what to change/add in future. There'll probably a big brainstorming session after the next release. This is also necessary because we want to change the development process a bit.

There's no release date for the next version because we only put work into this mod when we've got some free time. We just don't know when it's ready.

DustFX is finished and will be included in the next release.

@lo-fi & Gaalidas

Maybe we should start a release thread in the add-ons forum where users can download the latest stable version, ask about specific stuff and report bugs. This dev thread we'll use just for coordinating development, helping each other, etc. just like we did till now.

But that also means we'd have to watch an additional thread.

Edited July 23, 2015 by *Aqua*

[lo-fi]

Thanks *Aqua*.

I made a little headway on the reported part sizes. I managed to grab a value for the size of the craft before the tracks are attached in OnAwake(), and was hoping to use this to pass to GetModuleSize(). However, the value gets cleared when the part is attached, presumably because an instance of the part prefab is instantiated when it's actually attached, or some some jiggery. (I was being an idiot) Annoyingly, if you just zero the craft size, two things happen: It won't launch because it says you need the size to be calculated, and the icon for the vessel in the load menu gets huge. This is actually quite good, as it tells me that this is governed by the reported craft size for that icon, rather than anything else.

I was thinking of looking into the OnEditorAttach() method to see if I can grab a sensible pre-attach value there. but I've not got round to it yet. The other possibility is to make our own method for determining the craft size and passing that back to GetModuleSize, after zeroing the silly value it gets from the stock method. I don't know how hard this will be, though.

I think it's probably about time for a release thread, yes. Granted, it does mean monitoring two threads, but lots of stuff gets buried quite quickly here.. I guess I'll go make one!

The other thing that probably needs figuring out is whether to split the parts up into motive, structural and utility. Wheel, tracks, landing gear & legs and repulsors certainly live together as they share commong modules in the plugin. Rover bodies, rollcages, trailer hitches and other shenanigans I've got planned maybe do not. I'm favouring splitting in two, with the motive stuff and util/structural separate.

Edited July 23, 2015 by lo-fi

[lo-fi]

OK, I've got a handle on the vessel size thing. See latest commit. Needs testing to make sure it's robust (it's truly game-breaking if we get it wrong as it won't let craft launch), but at least that's something.

I know that incorrect values will occur if the tracks are attached, taken off, more parts added, then placed again. Have a look and see what you think, anyway. But at least that's some kind of progress on a nasty bug :/

[*Aqua*]

Ah, so that's what the commit was about.

I'm currently replicating what the PartIconFixer mod does. Maybe we can use that approach to fix the reported part sizes too. But it'll take more work until I can show some results.

Spliting the parts up is a good idea! Didn't Gaalidas want to write a config for Filter Extentions? I'm not sure if I remember correctly.

Edit:

Ninja'd again. ^^

I'll quickly have a look at the new commit.

Edit 2:

Ok. It's a small commit and I'm not sure if that's really a good approach to fix that bug. IMO we should fix the size values ASAP which would be at the end of the loading scene just after the PartLoader messed up. Everything which comes after that (editor etc.) would (hopefully) use the corrected values. That means we don't have to use the IPartSizeModifier interface.

Edited July 23, 2015 by *Aqua*

[lo-fi]

Did you find where the actual size values are stored in the part prefab? I couldn't figure that out... Lots of other things, but not that!

[*Aqua*]

It seems the Bounds object represents the size (get it through GetComponent() or similar). If that's true we need to replace it with a corrected one. I didn't investigate that yet but it seems likely.

Edit:

I just discovered PartIconFixer needs .Net 4.0 but our plugin and KSP use .Net 3.5. *sigh*

I wonder why the mod works. It uses methods which aren't provided by Mono.

Edited July 23, 2015 by *Aqua*

[lo-fi]

Actually, I've never tried compiling it! xEvilReeperx is and evil genius, that's why

Certain things do work with later versions of .net, but not all. Hit and miss! Which IDE are you using?

[*Aqua*]

I use Visual Studio 2012 Professional (I have a DreamSpark Premium account provided by my university).

When I get a new computer somewhere this or the next year I'll probably switch to VS2015 (not sure which editions I'll have access to at that point).

Edit:

Ok, it wasn't difficult to replace the .Net 4.0 methods with something .Net 3.5 allows.

Edited July 23, 2015 by *Aqua*

[lo-fi]

I use VS 2012 Express.

OK, I think you're onto something.

            print(_trackSurface.GetRendererBounds());
            List<Bounds> bound = new List<Bounds>( part.GetRendererBounds());
            for(int i = 0; i < bound.Count(); i++)
                print(bound[i]);

yields this for the medium track (in KFTrackSurface):

[LOG 16:26:06.030] Center: (-0.5, -1.3, -1.1), Extents: (3.8, 14.5, 4.6)
[LOG 16:26:06.030] Center: (-0.8, 9.4, 0.1), Extents: (0.3, 0.3, 0.3)
[LOG 16:26:06.031] Center: (-0.5, 9.4, 0.2), Extents: (0.1, 0.2, 0.2)
[LOG 16:26:06.032] Center: (-0.8, 10.0, 0.1), Extents: (0.3, 0.3, 0.3)
[LOG 16:26:06.032] Center: (-0.5, 10.0, 0.2), Extents: (0.1, 0.2, 0.2)
[LOG 16:26:06.039] Center: (-0.8, 10.6, 0.1), Extents: (0.3, 0.3, 0.3)
[LOG 16:26:06.040] Center: (-0.5, 10.6, 0.2), Extents: (0.1, 0.2, 0.2)
[LOG 16:26:06.041] Center: (-0.4, 10.0, 0.3), Extents: (0.1, 1.3, 0.2)
[LOG 16:26:06.042] Center: (-0.8, 8.9, 0.3), Extents: (0.3, 0.2, 0.2)
[LOG 16:26:06.042] Center: (-0.8, 11.1, 0.3), Extents: (0.3, 0.2, 0.2)
[LOG 16:26:06.043] Center: (-0.5, -1.3, -1.1), Extents: (3.8, 14.5, 4.6)

But can they actually be set? If I'm reading it correctly, PartIconFixer uses calculated bounds to set some calculations up, but it doesn't actually attempt to pass the values back to the GO that got baked.

[*Aqua*]

I'm missing a "SetBounds" method, too. In that case we should modify the bounds which are already there. A Bound object has a few methods for that.

[lo-fi]

Wait a minute. Think I've got it:

http://docs.unity3d.com/ScriptReference/SkinnedMeshRenderer-localBounds.html

[*Aqua*]

How and where do you want to use that?

[lo-fi]

The track surface has a component called SkinnedMeshrenderer which handles the dynamic animation of the track surface. The thing the caught my eye was "It is recomputed every time when updateWhenOffscreen is enabled, but in this case it would be exactly the size of the mesh at that frame."

Promising... Testing now...

[*Aqua*]

Whoops! Small (or rather big) mistake.

[lo-fi]

Got it. I'm sure KSP used to over-write the values set in Unity as I tried this before - they can be set in that component from the inspector - but doesn't seem to now. How strange. Anyway, the values are always ~10x out. We can force them in code if needed as they are setable. I think we might have a solution!

EDIT: That's hilarious! Having fun?

[*Aqua*]

New commit is out.

We just need to add "IconOverride {}" to all part cfgs which have that bug.

Look at the code. KFPersitenceManager.FixPartIcon() might be a good place to fix the other size issue, too.

Edit: The scale display is wrong. I don't know why.

Edited July 23, 2015 by *Aqua*

[Gaalidas]

Spliting the parts up is a good idea! Didn't Gaalidas want to write a config for Filter Extentions? I'm not sure if I remember correctly.

Already did. the "Filter Extentions" config is in the "Parts" folder, and the two icons for it are in the "Assets" folder. I did the research and discovered that I don't need to give the entire icon path to the config as long as KSP loads it up as a completely unique texture, which I believe that are right now. This allows us to distribute it within uor own folder without needing to supply a "Filter Extentions" folder in our release package. The parts themselves are categorized in the same way that KSP does that itself: by the category assignment. The category for KF will be a stand alone category (that is, not within the manufacturer category only, though it is in there.) and will contain subcategories mimicking the stock categories. To split the parts up further, you simply need to decide what kind of part they are and set the part configs up accordingly. I am unsure if there is an easy way for me to add a completely new category, or split the parts up further than stock category assignments, but I'll look into it if required.

EDITS:

Icon Scales... That's promising. However, I'd be curious as to how that will work alongside the icon fixer mod, if the end user has that too. Also, I'm unsure if it actually fixed it, but I was pretty sure the scale visualizer was working right under PartIconFixer... can anyone confirm this? If so, it should be possible for us to fix it as well. It just seems like we are reinventing the wheel (okay, lo-fi already did that, granted) by implementing it ourselves and, considering PartIconFixer doesn't even need an entry in the part configs, it feels like a step backwards. If the two mods start to conflict, then we'll at least need to do some reflection work to make sure that the offending mod does not interfere.

I'm going to reiterate this as I think it got missed due to posts after my last edit... Just something to consider.

I had an idea a while back and I keep forgetting to mention it. Your rover body is pretty good (not counting the super oversized texture of course, which really needs to be resampled or something. I'd hate to see it simply resized and loose details) but it's pretty limited as far as it's size. I was thinking, if it could be separated into three parts (a front part, a middle part with the cargo bay, and an end piece) then it could be made to any size needed for someone's rover needs, and different middle pieces could be made to suit different needs then. Sorta like a simplified version of the other rover bodies you were working on a while back. If the cargo bay portion lacked end pieces too, then the cargo bay could be stretched to suit the user's needs. You could even provide half-length portions and such. The great thing about all this is that since you'd simply be cutting up the model you should be able to use the exact same texture for all the parts, thus reducing any need for extra texture memory consumption. I don't want to add this to the next release obviously, since we're rather close, but it would be something to add to the to-do list for afterwards. I might even tackle it myself if I ever learn how to do unity.

- - - Updated - - -

KFPersitenceManager.FixPartIcon()

I'm unsure if the place for that is in the persistence manager, since that was supposed to house save and load routines, wasn't it? I'd have made a new class to handle part icons.

Edited July 23, 2015 by Gaalidas

[*Aqua*]

Oh you already wrote a config for that? I didn't noticed it.

I don't know if the scale works correctly in PartIconFixer. Must check that. I literally just copied the important parts of that mod. I added some checks so that only KF parts with that new node in the cfg will be fixed*. I believe it will run after PartIconFixer and overwrites what it did to KF parts. That should be no problem because both do the same.

* That way we can specify which part icons will be fixed. PartIconFixer processes all parts it thinks must be fixed.

Edit:

It must read the part cfgs and it must run at the end of the loading scene that's why I've chosen KFPersistenceManager.

Edited July 23, 2015 by *Aqua*

[SmashBrown]

Does anyone have a .cfg that they could provide me with to put the anti grav stuff into experimental motors in the ctt? Please.

[Gaalidas]

Oh you already wrote a config for that? I didn't noticed it.

I'm not even sure "wrote" is the correct way to say it. I basically copied another config and renamed a few things. I've had it for quite some time too, just never got around to sharing.