[1.8.x] Kerbal Foundries -- Continued - Tracks, Wheels, and Gear

[adsii1970]

Just now, JadeOfMaar said:

Thanks for the motivation to return to Thor Tech. I can do this easily...And I want to.

Wow! I inspired you! That's incredible. Your mods are always awesome and I just wonder how you do not get discouraged with all you do. I am still trying to figure out how to make planet packs, but between my regular job and all that goes into it, research, the part-time job of reviewing college textbooks and other history-related publications, and the family obligations, I can only do when I get the time  - which isn't very much!

1 minute ago, JadeOfMaar said:

I'm well-versed in Core Heat now, enough to produce documentation for how to precisely tune it for a given converter and I can even use Core Heat just to spool the converter and cease to produce internal heat (never need a radiator) when it reaches its core temperature goal. This is amusing and somewhat appropriate for any power source that relies on revving up internal spinning parts such as turbine APUs.

This has a lot of applications - like ore extractors. As you know, they generate a lot of heat. I've always wondered why that heat could not be repurposed into producing electrical power instead of just attaching radiators. I know that in real-life, because of doing those pesky academic book reviews which wade into the history area, this technology (cogeneration) has been around since about 2008/2010. In a game like KSP, it has a lot of potential uses but not too many parts available.

 

[JadeOfMaar]

Sorry for derailing thread, Shadowmage.

@adsii1970 A few of us are aware of the wider possibilities for the use of Core Heat. Unfortunately, it was only implemented in KSP for one purpose-- to make the ISRU parts overheat and to demand cooling. By consequence this is the one job of the radiator system. Unfortunately there is no means (that I know of) for part or module A to tap into core heat produced by part or module B; neither is there any means to readily convert between regular heat and core heat; neither any means to readily use core heat as an input or output in other module functions so it's effectively a small, useless, walled garden.

If Core Heat was this flexible then we could have simplified forms for the awesome yet overbearing thermodynamics system in KSP Interstellar and achieve things like: solar thermal; parts having operating temp limits-- not just overheat but overcool; proper stirling engines/other thermoelectric generators.

[Shadowmage]

3 hours ago, JadeOfMaar said:

Sorry for derailing thread, Shadowmage.

No worries, I started it off anyway by bringing up the subject, so its not entirely off-topic.

I haven't personally played with the implementation of CoreHeat myself, so not entirely sure if it is the mechanic that would accomplish what I'm looking for, or if I'll have to come up with some customized system.

 

On a semi-related note, I made some modifications to KSPWheel that should clean up the display of 'max speed' and 'max load', only displaying those values if the KSPWheelDamage module is present (and in fact, the values have been moved into those modules and should be specified in that modules config; values will still load from the KSPWheelBase module if present for backwards compatibility).

This change reworks how the modules do their startup/initialization, forcing the modules to do full initialization during prefab loading -- which allows for module-specific data to be loaded, parsed, and displayed in the GetInfo() call (and thus, to display in the editor-part-list tooltips / 'more info' widget).  With this change in place, a ton of info that was previously not visible should now be added to the module-info for the parts -- all of the config values from all of the submodules; motor torque, max EC, steering deflection, etc.  Mostly minor stuff, but certainly useful.

Along with this change I've also added module-specific 'max speed' settings to KSPWheelSteering (for steering curve calcs), KSPWheelAnimation (for animation speed calc), and KSPWheelSounds (for motor/running effect max speed).  If these modules do not have values specified, they will load the value from the KSPWheelDamage module (if present), or will fallback to use the existing default-max-speed calculation function (which uses 400rpm as the max).

Fun stuff....

Edit:  Little preview of the updated part-tooltips, showing the additional info being displayed:

Still a bit of cleanup to do in some of the formatting (including the units symbols), but still better than it was

Edited February 20, 2020 by Shadowmage

[Azic Minar]

7 hours ago, JadeOfMaar said:

Sorry for derailing thread, Shadowmage.

@adsii1970 A few of us are aware of the wider possibilities for the use of Core Heat. Unfortunately, it was only implemented in KSP for one purpose-- to make the ISRU parts overheat and to demand cooling. By consequence this is the one job of the radiator system. Unfortunately there is no means (that I know of) for part or module A to tap into core heat produced by part or module B; neither is there any means to readily convert between regular heat and core heat; neither any means to readily use core heat as an input or output in other module functions so it's effectively a small, useless, walled garden.

If Core Heat was this flexible then we could have simplified forms for the awesome yet overbearing thermodynamics system in KSP Interstellar and achieve things like: solar thermal; parts having operating temp limits-- not just overheat but overcool; proper stirling engines/other thermoelectric generators.

What about regular heat? Also, I'll let you know in an hour about the sample load bearings for the suggested configs

[JadeOfMaar]

@Azic Minar Regular heat has some flexibility already. Not much, but likely equal to or greater than the amount that can be done with Core Heat. The ablator module can be customized to kick in at any temperature that a given part reaches, customized to use any resource that has a non-zero "hsp" value in its definition, and it has an alternator (typically used in RO to produce "CharredAblator"). This allows for the immediate use of special ISRU chains that depend on parts being heated externally in conventional fashions.

The great things I've done with the heating systems so far are:

• In Thor Tech, my intermediate super radiator draws nearly a megawatt of heat from around the vessel but doesn't have much capacity for thermal mass so it's like a heat exchanger/capacitor and it saturates very fast. It accepts a number of resources to convert any one of them at a time or in parallel into a pseudo resource "_Cooler" and then ablates this resource to quickly dump its gathered heat. Instead of costing lots of EC, it costs you in payload capacity to bring along its accepted input resources if you choose to use this part.
• In Thor Tech, my far future TCS (thermal control system, based on the real concept of EM shield ablator) adds the ablator module to nearly everything that doesn't have it already, with differing strengths depending on the use cases of each part, and feeds these ablators with the "_Shieldnir" pseudo resource. The protected parts don't need to hold this resource themselves. Shieldnir, by nature, is OP and is meant for use on landers and ascent craft on Eve and harder planets, not for use on Kerbin. The challenge of Shieldnir lies in: bringing along enough of the Shieldnir generators; dealing with their masses; avoiding exceeding their output capacities in the extreme phases of ascent and reentry; protecting your power sources from overheating while feeding the Shieldnir generators; protecting parts that get less protection as not all parts can be equally shielded.
• In Rational Resources, my implementation of a thermonuclear turobjet is that it uses a converter with Core Heat to produce ThermalPower resource to be consumed by the engine module. The part is configured such that when it runs for a long time at high thrust (or extreme thrust in thick atmo like on Eve) the converter's core temperature will rise due to the radiators being saturated by both core heat and engine heat production. As this happens the ThermalPower production capacity goes down (loss of efficiency due to overheat). When the engine reaches a certain fraction of its heat tolerance the converter shuts off and the engine itself gets to run for up to 10 seconds on its ThermalPower buffer before "cooling down rapidly" and having a flameout.
• In Rational Resources, there is a "blacksmith" system that simulates the science lab having a forge and its furnace inside, and the kerbals carrying motlen material with them on EVA (let's say, via industrial heat resistant hoses and spray guns) to refill Ablator on heatshields for interplanetary landers that try to use their heatshields more than once. The heatshields themselves receive a converter that accepts "work," ThermalPower and an input resource or two and generate Ablator within themselves for this since Ablator is non-transferable.
• In Rational Resources, not only the Blacksmith system... but the Restock MonoProp APU also uses CoreHeat primarily for its spooling effect. The APU is described as a turbine and has no real business with the "overheat" situations so the APU uses this only for the effect of revving up, not starting instantly, and never needs a radiator once it reaches its core temp goal.

 

Edited February 21, 2020 by JadeOfMaar

[Azic Minar]

3 minutes ago, JadeOfMaar said:

 

@Azic Minar Regular heat has some flexibility already. Not much, but possibly equal to the amount that can be done wit Core Heat. The ablator module can be customized to kick in at any temperature that a given part reaches, customized to use any resource that has a non-zero "hsp" value in its definition, and it has an alternator (typically used in RO to produce "CharredAblator"). This allows for the immediate use of special ISRU chains that depend on parts being heated externally in conventional fashions.

I do love what you've done with Thor tech.

Also, for @Shadowmage, the suggested configs suggested by @JadeOfMaar feel good. I could take a 33 ton rover down the runway with the KF RBI Track - Mole without them breaking before the tower. Now I still find the tracks get too much speed on dirt land and hitting failure time too easily, like on the way to the water once I bounce off the end of the runway. Is it possible to make a bar pop up on screen, much like heat does, so that when failure time gets above half way, we have a visual reference without having to keep the wheels pinned? If not that, a sparking animation or sound effect to play? If I ever figure out the bar, I'll share the code config since I'm just recently starting creating my own mods (by chop shop hacking).

Now when I used my joystick with throttle, its really easy to avoid this without having to pay really close attention. So is changing the gear ratio to 1.25. 

But this leads me to an other thought, could failure point be placed at 5m/s above the maximum speed of a part? 10m/s might be too high. Or does the maxRPM need lowered to fix?

 

Lastly, I've not experienced the issues I mentioned before thanks to the new release! Thank you

[JadeOfMaar]

12 minutes ago, Azic Minar said:

Or does the maxRPM need lowered to fix?

I assume you mean there's too much acceleration. My guess is to go after maxMotorTorque first. (I don't know better. I'm not much of a car parts enthusiast. But I assume this represents the raw power out of the cylinders and crankshaft.)

And thanks for the Thor Tech love.

[Azic Minar]

8 hours ago, JadeOfMaar said:

I assume you mean there's too much acceleration. My guess is to go after maxMotorTorque first. (I don't know better. I'm not much of a car parts enthusiast. But I assume this represents the raw power out of the cylinders and crankshaft.)

And thanks for the Thor Tech love.

Welcome, and after testing by raising max speed to 230 for the sake of driving around the hills between the launch center and the mountains, it wasn't that easy to hit 30m/s with a 1:1 ratio. Now it did pop up to a 35 on a steeper hill with just over 36, but is a bit high since 36 m/s is 80mph. Looking up tanks, I've found that some can go 60mph, even 70mph, but 25mph is typical. That leads me to thinking maybe you are on the right track, but instead of adjusting maxMotorTorque, to lower maxRPM or have the default gear ratio start at 1.25. More testing, but not tonight since work in the AM!

EDIT: 

I woke up early, so I got to work on testing lowering maxRPM. Lowering that by 25 and raising max speed to 30 actually felt about right and realistic. But I know that's subjective to a lot of different people and others will weigh in with different opinions. It leaves the normal achievable speed on flat land at 20, but allows you to pick up some speed on hills without going boom, or needing to watch the speed like you are in a school zone. I haven't tested that on all wheels yet, maybe tonight

Edited February 21, 2020 by Azic Minar
Testing Done!

[Gaalidas]

Sup boys.   Been thinking about getting into KSP again.  Nice to see this old thing is still being worked on.

In fact, I've already re-familiarized myself with the code.  Looking good... other than a few cringe worthy moments where I noticed some sub-optimal method naming convention issues.  Still, seems to be working rather well.  Unfortunately I haven't launched KSP is so long and I'm so out of the loop on the mod scene, I'm having to play catch-up.

[Shadowmage]

13 hours ago, Gaalidas said:

Sup boys.   Been thinking about getting into KSP again.  Nice to see this old thing is still being worked on.

In fact, I've already re-familiarized myself with the code.  Looking good... other than a few cringe worthy moments where I noticed some sub-optimal method naming convention issues.  Still, seems to be working rather well.  Unfortunately I haven't launched KSP is so long and I'm so out of the loop on the mod scene, I'm having to play catch-up.

Good to hear from ya    Yeah, we're still around, keeping things rolling.  I'm just coming back from a bit of a work-induced break myself, having spent the last ~year working up the corporate ladder and getting myself into an... interesting... job role.

Mostly the wheel simulation works well; it is definitely a simplified model, and it has a few quirks/edge-cases that I've never quite closed out... but they'll get you where you need to go with a minimum of fuss.  Can't say that the code is 'pretty' (my naming conventions have definitely evolved over time), but I tried to keep it free from hacks and workarounds, and it is organized and structured such that it is fairly easy to add new features through new submodules when desired.

The one thing that could still be really useful to implement would be a per-vessel wheel-controller system, allowing to group together specific functionalities of the wheels on the vessel in a new UI, so the player can both see what all the wheels are doing, and organize/control/adjust them without going to each individual part.  Never figured out how to do a good layout for this feature, but it is still something I would like to look into at some point.

[Shadowmage]

On 2/20/2020 at 7:23 PM, Azic Minar said:

but this leads me to an other thought, could failure point be placed at 5m/s above the maximum speed of a part? 10m/s might be too high. Or does the maxRPM need lowered to fix?

Sure; max motor RPM and max safe speed are tunable separately.  I generally tried to place the max motor speed 2-3 m/s above the max safe speed, knowing that the max motor-speed is an asymptote that would never be reached under normal conditions. Max safe speed probably could be bumped up a bit, but I would prefer to leave the max motor RPM unchanged.

 

On 2/20/2020 at 7:45 PM, JadeOfMaar said:

I assume you mean there's too much acceleration. My guess is to go after maxMotorTorque first. (I don't know better. I'm not much of a car parts enthusiast. But I assume this represents the raw power out of the cylinders and crankshaft.)

The motor/power sim is actually based on large electric motors, but torque is torque... so yes, that would be one way to do it.

[Azic Minar]

36 minutes ago, Shadowmage said:

Sure; max motor RPM and max safe speed are tunable separately.  I generally tried to place the max motor speed 2-3 m/s above the max safe speed, knowing that the max motor-speed is an asymptote that would never be reached under normal conditions. Max safe speed probably could be bumped up a bit, but I would prefer to leave the max motor RPM unchanged.

 

The motor/power sim is actually based on large electric motors, but torque is torque... so yes, that would be one way to do it.

True, electric motors in the real world are quite boss and have set land speed records before conventional have caught up. Wish I could remember the video I saw to give a link to. Now I'm wondering if its possible to write a mod that auto-applies the breaks once above a certain speed with a toggle on/off on the side of screen with other quick mod access.

[Gaalidas]

10 hours ago, Shadowmage said:

The one thing that could still be really useful to implement would be a per-vessel wheel-controller system, allowing to group together specific functionalities of the wheels on the vessel in a new UI, so the player can both see what all the wheels are doing, and organize/control/adjust them without going to each individual part.  Never figured out how to do a good layout for this feature, but it is still something I would like to look into at some point.

If you haven't removed the feature, already we should have a wheel group setting which previously allowed the user to modify a setting on one wheel and have to update to the others in the same group.  However, I never figured out a good way to make those settings visible without looking into the context menu for one of the wheels.  Also, the settings in question only auto updated when changed via action groups.  Manual updating was possible with a context menu button I think.  I imagine a copy and modification of the IR configuration GUI might be useful, but that's a bit beyond me at the moment.  I haven't done anything with Unity menus since that first config menu I made before my long sabbatical.  That thing was clunky as heck.

[Shadowmage]

20 hours ago, Azic Minar said:

Now I'm wondering if its possible to write a mod that auto-applies the breaks once above a certain speed with a toggle on/off on the side of screen with other quick mod access.

Certainly possible, and could be enabled as an auto-safety feature.  Something simple like "if accelerator is not pressed, and above max safe speed, apply brakes momentarily".  Would have to be set on a per-part toggle, through the parts right-click menu.

Will give it some thought, see if there are any as-yet unforeseen issues that pop up.  Likely it could be implemented for the next release.

[Shadowmage]

12 hours ago, Gaalidas said:

If you haven't removed the feature, already we should have a wheel group setting which previously allowed the user to modify a setting on one wheel and have to update to the others in the same group.  However, I never figured out a good way to make those settings visible without looking into the context menu for one of the wheels.  Also, the settings in question only auto updated when changed via action groups.  Manual updating was possible with a context menu button I think.  I imagine a copy and modification of the IR configuration GUI might be useful, but that's a bit beyond me at the moment.  I haven't done anything with Unity menus since that first config menu I made before my long sabbatical.  That thing was clunky as heck.

Its not that I removed anything... its that the current code is entirely new compared to the original KerbalFoundries plugin.  Certain small portions were based on the original functions, but everything was written entirely from scratch for KSPWheel.

I did eventually include a 'wheel group' setting that works as you describe, but what I'm looking for in the potential new UI is a few steps beyond that -- allow each feature on a part to be grouped separately.  So you can have a group that controls max torque for -all- wheels, a separate group for steering limits on the front wheels only, a group for motor inverts for the left wheels, and another group for motor inverts on the right wheels.  I really should try and mock something up, as it would probably make more sense that way...

[Gaalidas]

9 hours ago, Shadowmage said:

I did eventually include a 'wheel group' setting that works as you describe, but what I'm looking for in the potential new UI is a few steps beyond that -- allow each feature on a part to be grouped separately.  So you can have a group that controls max torque for -all- wheels, a separate group for steering limits on the front wheels only, a group for motor inverts for the left wheels, and another group for motor inverts on the right wheels.  I really should try and mock something up, as it would probably make more sense that way...

OH... holy crud... are you mad?  Silly question, of course you are.  Oh god... I my head hurts just thinking about coding something like that in Unity.

Okay... so thinking out loud, so to speak... In order to make all those settings able to be grouped independently... at the moment I would think they would all have to go from being fields, in the current modules they belong to, to being sub-modules of their own that feed their settings into the parent module.  Then, I could imagine, you could set a certain option to be synced between different parts without needing to add a group selector for each individual settings in the context menu.

Then again... you'd still have to have a group selector for each individual setting.  That's where a separate UI would come in handy though.

No... my head is hurting again.  This could be a challenge.  I still think each option being a separate sub-module would be ideal.  Otherwise the code for the parent module is goingt o get very long with a group number for each and every field and a ton of utility methods to keep it all straight.  Might need a new vessel module to make them all talk to each other between the parts...

You are indeed mad aren't you?  Oh god this is bad...

Edited February 24, 2020 by Gaalidas

[Gaalidas]

9 hours ago, Shadowmage said:

Certainly possible, and could be enabled as an auto-safety feature.  Something simple like "if accelerator is not pressed, and above max safe speed, apply brakes momentarily".  Would have to be set on a per-part toggle, through the parts right-click menu.

Will give it some thought, see if there are any as-yet unforeseen issues that pop up.  Likely it could be implemented for the next release.

This is an interesting one.  A while back (like years ago now I think) there was a mod I used that implemented an anti-lock braking system... sorta.  When activated it would pulse the brakes so you could slow down without just slamming down and flipping over.  Very useful in low-gravity environments.  I also remember that the old KF code had curves to control the amount of acceleration/torque/whatever it is that I don't fully understand, the stuff applied to the wheel at certain speeds.

With these two things in mind, I imagine you could implement a feature like what is described pretty easily while limiting the chances of killing your Kerbals via sudden slamming on the brakes.  Whether this is a good or bad thing is up to you.

[vardicd]

47 minutes ago, Gaalidas said:

A while back (like years ago now I think) there was a mod I used that implemented an anti-lock braking system... sorta. 

Maybe you mean this one? 

 

[Shadowmage]

3 hours ago, Gaalidas said:

I still think each option being a separate sub-module would be ideal.  Otherwise the code for the parent module is goingt o get very long with a group number for each and every field and a ton of utility methods to keep it all straight.  Might need a new vessel module to make them all talk to each other between the parts...

Yes, a vessel module would be the root handler for interaction/spawning the UI, and persistent storage of grouping data.  The individual settings would still reside in the existing sub-modules, simply to keep things 'modular'.  Would use a custom attribute system (similar to [KSPField]) or other tagging system to have the vessel module grab references to the fields to be controlled right out of the sub-modules, and then dynamically construct the UI based on the available fields and any persistent data that was available regarding grouping.

The technical aspects of the back-end were never too much of an issue for me, I think I already have a basic controller class in the repository that does most of this; my problem has always been designing a UI that made sense, in KSP.  More so the difficulty of creating GUI's in KSP rather than creating a functional design; I could easily create something usable in WPF, Unity-GUI, or any other number of UI systems, none of which are available to KSP. 

I've never figured out how to import Unity-GUI's through AssetBundles, or if it is even possible, nor had the time to learn how to construct them through code -- but that is what would really need to happen next.  The IMGUI system that I use elsewhere is good for simple debug displays, or a few buttons to click... but if you want tabs, tree-menus, or anything more complicated than a scroll-panel, you need to use the Unity-GUI system (or something entirely custom).

 

3 hours ago, Gaalidas said:

You are indeed mad aren't you?

Possibly, just a bit

Whenever I create systems like this, it usually is on the 'insanely-crazy-configurable' level.  Perhaps a few steps overboard    (Just look at all the features in SSTU's and TU's systems; 50% of which I use rarely, if at all)

 

[Azic Minar]

I think such a UI would be possible. Look at near future electrical. (I think its that one) They have a UI that will automatically read all of the electrical generation and pull live and give you a load of information.

[Gaalidas]

On 2/23/2020 at 9:34 PM, vardicd said:

Maybe you mean this one? 

 

Yup, I'd say that's pretty much spot on.  Those were the old glory days of KSP modding.

23 hours ago, Shadowmage said:

Yes, a vessel module would be the root handler for interaction/spawning the UI, and persistent storage of grouping data.  The individual settings would still reside in the existing sub-modules, simply to keep things 'modular'.  Would use a custom attribute system (similar to [KSPField]) or other tagging system to have the vessel module grab references to the fields to be controlled right out of the sub-modules, and then dynamically construct the UI based on the available fields and any persistent data that was available regarding grouping.

The technical aspects of the back-end were never too much of an issue for me, I think I already have a basic controller class in the repository that does most of this; my problem has always been designing a UI that made sense, in KSP.  More so the difficulty of creating GUI's in KSP rather than creating a functional design; I could easily create something usable in WPF, Unity-GUI, or any other number of UI systems, none of which are available to KSP. 

I've never figured out how to import Unity-GUI's through AssetBundles, or if it is even possible, nor had the time to learn how to construct them through code -- but that is what would really need to happen next.  The IMGUI system that I use elsewhere is good for simple debug displays, or a few buttons to click... but if you want tabs, tree-menus, or anything more complicated than a scroll-panel, you need to use the Unity-GUI system (or something entirely custom).

GUI development, for me, has been a love-hate thing.  I only managed the old settings GUI in KF by a lot of trial and error.  The Unity GUI creator wasn't a thing back then.  I had a look at the IR source today and that mod is a pure mess of chaos and damnation.  It's a wonder it even compiles at all, much less work.  Yet, it does... mostly.  So... I'm afraid I'm a dead end in that area.

On another note, I've been going over a lot of mod related code lately and have found some really odd stuff in the KSP DLLs related, especially, to part resources (as in fuel, EC, etc.).  For instance... apparently the method of requesting a resource using the resource ID (an integer) and a float (for usage I think) in tagged as obsolete.  However, the method which uses the resource ID and a double instead is not obsolete.  To make it stop throwing warnings at me, I've had to do some strange stuff such as changing the variable to a double, casting the usage as a double, and then re-casting the result to a float later down the line.  I don't get at all why they would tag the method as obsolete in the first place though.  Also, apparently the WWW class is obsolete, but there doesn't seem to be any clear way of translating what we would have used for those WWW calls into the new method suggested in the resulting message.

Things made a lot more sense back in v0.23.5.

[Shadowmage]

9 hours ago, Gaalidas said:

I had a look at the IR source today and that mod is a pure mess of chaos and damnation.

   Probably a reason its called Infernal Robotics.

9 hours ago, Gaalidas said:

On another note, I've been going over a lot of mod related code lately and have found some really odd stuff in the KSP DLLs related, especially, to part resources (as in fuel, EC, etc.).  For instance... apparently the method of requesting a resource using the resource ID (an integer) and a float (for usage I think) in tagged as obsolete. 

Indeed.  Unfortunately, the 'replacement' method doesn't work in the same fashion, and there is no documentation stating how the new method works or how to convert between the two.  Last time I tried to fix that, it completely broke... everything

So be aware, just because you made the compiler happy -- doesn't mean it will actually work in KSP.  (Yeah, I tried the same basic 'replace the method with the new one, and cast back and forth from float to double' conversion, that for some reason didn't work)

9 hours ago, Gaalidas said:

Also, apparently the WWW class is obsolete, but there doesn't seem to be any clear way of translating what we would have used for those WWW calls into the new method suggested in the resulting message.

Heh, yep, same as the above.  They implement some new system that is supposed to be an 'upgrade', but don't bother to make it possible to do direct translations to the new system -- you have to restructure your entire program around their new methodology and whatever hoops they want you to jump through.

I'm all for progress, and I fully understand the need to break old functionality in order to make new and better things, but for all that is good -- at least tell someone how to convert from the old system to the new system.

I'm sure both of those points can be addressed.  Just need a good solid couple of days that I can devote to modding time, where I also feel like being frustrated the entire time (dealing with undocumented APIs always gets to me..).  Gotta get into a special headspace for that kind of work and form of punishment.

 

9 hours ago, Gaalidas said:

GUI development, for me, has been a love-hate thing.  I only managed the old settings GUI in KF by a lot of trial and error.  The Unity GUI creator wasn't a thing back then.

Yeah, that's mostly how my GUI's in KSP have gone as well.

The new 'Unity GUI' system is actually very workable.  But only if you can build the game from the editor; it is painful for use by mods.  The issue being that all the GUI elements require scripts to function, you can't pack scripts into AssetBundles, and AssetBundles are the only way to get the GUI's out of the UnityEditor and into KSP.  So, you pack up all your carefully laid out GUI into an asset-bundle, and then in KSP you need to extract them, and spend a few thousand lines of code to hook up all the scripts and fix all the binding info that was lost during the AssetBundle export/import process.

[Gaalidas]

3 hours ago, Shadowmage said:

Yeah, that's mostly how my GUI's in KSP have gone as well.

The new 'Unity GUI' system is actually very workable.  But only if you can build the game from the editor; it is painful for use by mods.  The issue being that all the GUI elements require scripts to function, you can't pack scripts into AssetBundles, and AssetBundles are the only way to get the GUI's out of the UnityEditor and into KSP.  So, you pack up all your carefully laid out GUI into an asset-bundle, and then in KSP you need to extract them, and spend a few thousand lines of code to hook up all the scripts and fix all the binding info that was lost during the AssetBundle export/import process.

I wonder if, within Unity, you can get access to the source of the created GUI and, at the very least, be able to copy the script code for the positioning of the elements and such into VS after using the Unity tools to do it.  I haven't done anything in Unity itself in years, so I'm unsure what I'm talking about really.  Just a thought.  I'd bet someone out there has built a good library for translating what you see in a GUI designer into what KSP would understand.  You might try asking around on other major GUI-using mod topics for information on how they did it.

In the meantime, I've had some people contacting me (as if I know anything at all... shh! don't tell them the truth)... about various ways around the stock code oddities.  So I'm gonna try my hand at redirecting some things around with them.  I'll get back to looking at our little problems here later.

By the way, I did some sifting through old posts here and I am absolutely loving what you've done with the models and textures of the mod.  Beautiful stuff.  The code, for the most part, ain't too bad either.  Looks like lo-fi agrees too, and he's a rare visitor indeed.

[George411]

Got it and so many thanks.

[Catto]

This doesn't work for ksp 1.8 or 1.9! It freezes at the end and says "Verifying expansion/ Breaking ground/Serenity