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

[*Aqua*]

@Gaalidas

Nice to see you again. Have a look at the GUI, I changed some bits of it. ^^ The window size and position calculation code IMO looks bad but it works. Maybe you want to try different numbers or a different approach to calculate that stuff.

I also had a look at the dragable window thing but couldn't get it working. Atm my best guess is that we're overwriting the target coordinates of the dragged window during OnGUI(). If that really is the case then we've got to move the the Rect-creation out of OnGUI() (OnGUIReady() and SetupAppButton() might be suitable places).

[Gaalidas]

The draggable thing was just a theory in that area. BDArmory uses a similar setup, but there is one difference in his layout: he's using automatic layouts instead of specific layouts. it could be that dragging works better with an auto-layout.

lo-fi, I noticed you re-added the DustColorFileWriter.cs, however this file is no longer necessary since the dust colors are handled in a completely different format now. It would be best to remove the unnecessary and obsolete file in this case.

UPDATE: I just merged my own tweaks to format and whatnot, but otherwise it looks good. I'm calling the GUI complete for the time being then. It's been a big enough pain that I don't want to touch it again for a long time. My next line of research would be to find out how to implement some form of stack-node switching without coding it into the mod and without giving us a hard dependency. I'm thinking about implementing it in a similar fashion to how TS in implemented into our parts, simply by adding a module to the part configs that will function only if they have the other mod installed, which most people will have if they use ERS or B9. It shouldn't be too difficult to figure out, since I shouldn't need to code anything.

So, lo-fi, do we have any ballpark values for the updates that need to be done to the parts that would work as a default starting point? Or are these config updates needing to be done completely on a per-part basis?

Edited July 20, 2015 by Gaalidas

[*Aqua*]

Ok, I closed the issue just now. Only 4 issues open until 1.9 is complete. However, they need quite a lot of work.

[SmashBrown]

ok, another one i forgot to add to my new modded career. hehehe

[lo-fi]

Sadly, yes. I did squash a lot of bugs last week, but the remaining ones are decidedly less tractable... I've just been looking at the PartInfo stuff. I have a nasty feeling it's calculated when it's needed...

There was a spreadsheet that Riocrokite made with cost, mass etc values. Getting those updated would be a seriously good piece of work out of the way. The rolling friction and load coefficient values will require some more work, as they will need a little experimentation. Most tracks have default values (I think). Wheels need that creating, which I'll get to ASAP.

Edited July 20, 2015 by lo-fi

[Gaalidas]

Another small question for you lo-fi... at this time the Eye part has no modules in it to indicate that it is a required participant in the hitch. Is this accurate, or is that part still needed? With the renaming of it's associated module with the suffix of "OLD" and the more recent commenting out of the module in the part config, I've been wondering what the point of that part is for some time.

In other news, I put a module in a few of the parts for local testing which implements the JSIPartUtilities module called "JSIPartComponentGroup" and set it up to allow toggling of the stack node on the wheel parts. From what I can tell, from the sample configs I used from the ERS rover system, if the user has the mod installed then the stack nodes will start out disabled with the option of enabling them in the context menu for that part. If the user does not have the mod installed, they'll have the stack node enabled as it is now.

A better way for handling this might be to make it a global option, but we'd need to implement our own node toggling code. I'd like there to be an option to keep the nodes around, since I've found them very helpful in my designs, but I can understand that they might cause problems with others.

A third option for the nodes would be to include an optional MM patch that, if the user enables it (renaming the file extension from... say... .txt to .cfg), would add a stack node to each part, otherwise leaving it blank. I might even know of a way to add the stack node to each part with a single patch by copying the value of the attach node, but I'll have to do some MM syntax research.

[lo-fi]

It's there for the hitch to hitch to. I implemented some limits in the joint, so orientation of the transform it looks for is important, as is the name. I was play with a module for the eye because... I have no idea. It's still there for no good reason. Yet. The hitch simply does nothing without the eye model to hitch to, though. Well at the moment, anyway. The last major hurdle to overcome with the hitch is orbits outside physics range with vessels packed. Without the hitch running its part module, the tractor and trailer drift again just like they used to in timewarp. I'll need to take a look into how to fix this - BD may have the answer again.

Option 2 may be good. I'l have a look at the node toggle code.

[Gaalidas]

I definitely like option 2 as well, even if it is the heavier option as far as work load. It'd sure make it easy to toggle on and off per user. We'd just add that option to the editor setting-menu configuration. One thing that would need to be taken into account however is that it isn't the node itself being turned on or off, but simply it's visibility to the user. If a user attached some of our parts using a stack node, then turns them off to attach others by radial attachment, then launches the craft after our code has disabled the nodes that were still being used, you could have issues with the cohesion of the parts in flight. We simply want to make them invisible and, in the editor only, non-functional.

What would be nice is if the hitch could be made to work off of the same model. That way you'd only have to add a hitch part to the crafts you want to get hitched (there's a pun in there somewhere) and wouldn't have to decide beforehand exactly which one would be the hitch and which would be the hitched.

I think I'm confusing myself with all these hitches getting hitched to hitches and hitch-hitches.

Edited July 20, 2015 by Gaalidas

[*Aqua*]

I think I'm confusing myself with all these hitches getting hitched to hitches and hitch-hitches.

I've no idea what you want to say. Sounds funny to me (not a native English speaker). ^^

In my language there's: Zwischen oder und und und und und und und und oder ist immer ein Leerzeichen.

It translates roughly to: Between or and and and and and and and and and or are always spaces.

...

I just discovered this works in English too.

Don't ask me how often I counted all the "and"s. ^^

[smjjames]

Theres a part called an 'eye'?

Ok, I closed the issue just now. Only 4 issues open until 1.9 is complete. However, they need quite a lot of work.

Good to hear.

Edited July 21, 2015 by smjjames

[lo-fi]

It's complicated A long way to go with the hitch. The way they are, allowing two hitches to get hitched would be total disaster (look at the code).

I've almost cracked the track sizing. Or at least found a super hacky method that looks kind of promising....

        public override void OnAwake()
        {
            base.OnAwake();
            Debug.Log("Track Surface Awake");
            if (HighLogic.LoadedSceneIsEditor)
            {
                Debug.Log("Awake and in editor");
                Vector3 size = ShipConstruction.CalculateCraftSize(EditorLogic.fetch.ship);
                Debug.LogError(size);
            }
        }

This grabs the vessel dimensions when the part it picked and before KSP messes all over them when the tracks are attached. Great. But then when I try to use the value later in OnStart, it's zeroed. On the other hand, I can effectively zero a crafts dimensions. Which is pointless.

[smjjames]

It's complicated A long way to go with the hitch. The way they are, allowing two hitches to get hitched would be total disaster (look at the code).

I've almost cracked the track sizing. Or at least found a super hacky method that looks kind of promising....

        public override void OnAwake()
        {
            base.OnAwake();
            Debug.Log("Track Surface Awake");
            if (HighLogic.LoadedSceneIsEditor)
            {
                Debug.Log("Awake and in editor");
                Vector3 size = ShipConstruction.CalculateCraftSize(EditorLogic.fetch.ship);
                Debug.LogError(size);
            }
        }

This grabs the vessel dimensions when the part it picked and before KSP messes all over them when the tracks are attached. Great. But then when I try to use the value later in OnStart, it's zeroed. On the other hand, I can effectively zero a crafts dimensions. Which is pointless.

Wouldn't it literally be a pointless particle if it had no dimensions? lol Although maybe it'd be a hyper-singularity or something.

What happens if two if those hitches connect? Krakenbait?

[lo-fi]

Yeah, pretty much! Two set of joints would be created and all hell would break loose...

The size we're on about is just the reported size, not the actual size. The method used to keep track of it is a little crazy!

[Gaalidas]

I've no idea what you want to say. Sounds funny to me (not a native English speaker). ^^

In my language there's: Zwischen oder und und und und und und und und oder ist immer ein Leerzeichen.

It translates roughly to: Between or and and and and and and and and and or are always spaces.

...

I just discovered this works in English too.

Don't ask me how often I counted all the "and"s. ^^

That's hilarious. I think I broke the translation system.

- - - Updated - - -

It's complicated A long way to go with the hitch. The way they are, allowing two hitches to get hitched would be total disaster (look at the code).

I've almost cracked the track sizing. Or at least found a super hacky method that looks kind of promising....

        public override void OnAwake()
        {
            base.OnAwake();
            Debug.Log("Track Surface Awake");
            if (HighLogic.LoadedSceneIsEditor)
            {
                Debug.Log("Awake and in editor");
                Vector3 size = ShipConstruction.CalculateCraftSize(EditorLogic.fetch.ship);
                Debug.LogError(size);
            }
        }

This grabs the vessel dimensions when the part it picked and before KSP messes all over them when the tracks are attached. Great. But then when I try to use the value later in OnStart, it's zeroed. On the other hand, I can effectively zero a crafts dimensions. Which is pointless.

Nothing is pointless. No really, it is quite pointless. But that cannot be pointless. It is simply without a foreseeable point in the near future. You never know when you might want to zero out the size of something.

I have a feeling it zeros out many values that are only used in the editors with the stock modules to clean up after itself. It's irritating, but at least it's clean.

Maybe you could create a temporary file that is saved to the disk which handles values like that which are not saved between the editor and the rest of the game so you can retrieve them when they are zeroed out, sorta like we save the state of the configs when the settings GUI gets closed either deliberately or by changing scenes. Yeah, sounds like a bad idea...

Edited July 21, 2015 by Gaalidas

[smjjames]

Have you guys looked into the heat generation of the auxillary generators? Because they generate a LOT of heat. Just a thought that came up.

[Gaalidas]

In the last release, I believe the heat production while running was still set to something like 450, which was a pretty normal average amount for a full size engine. Obviously something that produces no thrust and is as small as the APU is should never be generating enough heat to explode nearly so fast especially since it's just an auxiliary unit. I have a custom MM patch I run which corrects some of these things for my own game, but I'm unsure what the end result should look like.

You'd better take over answering this one, lo-fi. It's your baby after all.

[lo-fi]

Oh, I think it's been tweaked down in the latest config? Have to check that..

[*Aqua*]

Do we still need the APUController class? The game has now a fuel cell which does the same.

[lo-fi]

Actually, I haven't messed with it. Is it any good?

[Madrias]

Been using the APU myself, actually. It's great for those occasions where you have atmosphere to burn your liquid fuel, allowing you to travel without using any of that awful oxidizer stuff. Also, if that's not quite good enough, it's a lot more fuel efficient because it throttles up and down according to your power draw.

As for how I know, I drove a rover about 75% of the way to Kerbin's North Pole before I screwed up a jump off of a mountain and landed upside down.

Also, thanks for the new, much nicer sound. I can tolerate the quiet roar much better than the tea-kettle whistle it used to make.

[*Aqua*]

It feels good. It tries hold the vessel's ElectricCharge level at 95% (configurable in the part.cfg, activates/deactivates if necessary). And there are two sizes of it. It uses a ModuleResourceConverter which we can use to replicate the APU.

The small cell converts 0.0016875 LF & 0.0020625 OX to 1.5 EC per second.

The big cell converts 0.02025 LF & 0.02475 OX to 18 EC per second.

The APU converts 1 LF & 15 AirIntake to 20 EC per second. (not sure if I read the cfg right)

The 95% rule is a good idea. If you've got solar panels and they are powerful enough to power your vessel the fuel cell will never activate and use fuel.

Edited July 21, 2015 by *Aqua*

[lo-fi]

That's pretty much what the apu does controlling the engine and alternator. No idea what maths was with the consumption...

Glad you're liking the sound!

[Madrias]

I've found that the 95% rule also seems to be perfect. They're not spooling up wasting fuel when you're at a comfortable power level, a good handful of solar panels (or an RTG hiding somewhere in the belly of the beast) can keep you topped up, and they have an ability to go into a manual over-ride where you can force them to run at a constant rate to make full power (like if you know you're going to be sending a lot of data home from your Science rover and want to avoid the whole "Not enough electric charge to send data" hiccups. 100% power, manual override, and you won't run out of juice.) or to save the last gasps of fuel for when they're really needed.

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.

All in all, I think it's the right device for the job. 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.

It also has the advantage of at least doing something when working, in this case, it makes smoke, alerting the user that the APU has just had to step up to charge your batteries. Which, at least to me, means I drive my rovers more efficiently because I want to minimize the huge clouds of smoke in favor of the occasional light puff.

[damerell]

The old On-Demand Fuel Cell mod recommended 5%. It depends on the application. If you have plenty of Electric Charge in reserve and the APU can meet overall demand, you want 5%, so that it only fires up as a last resort, giving a demand spike a chance to end before burning any fuel. If your EC reserves are more modest and the demand spike will draw more power than the APU can produce, you want 95%.

[Gaalidas]

I think we'd probably want something higher than 5% if we're using it to power repulsors. Depending on the power storage capacity of the craft, you could easily burn off 5% of your power reserves in a second or so. I would likely configure mine to kick in at 20% at the least. I'd really like to be able to program small solar panels to activate and start powering the craft at a 40% mark if not already active, which would make the APU truly a last ditch effort. If you're using near-future capacitors as well, it would be awesome to configure those to automatically discharge when reaching 5%.

But, that's all independent of this mod. Just things I wish for sometimes.

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

Edited July 22, 2015 by Gaalidas