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

[kcs123]

19 hours ago, Shadowmage said:

@0111narwhalz

This might be of interest to you:

https://github.com/shadowmage45/KerbalFoundries2/issues/16

(sorry, no ETA, but at least it is on the official 'todo' list)

Sorry, have to ask, am I understand it properly. Is it just suspension without wheel ?

If it is, than big thanks for making that, I was looking something like this for quite a while.
There is always some workaround possible, but some crafts would be much easier to create if custom suspension is available. For example:

On that Rocker Bogie rover, I have to create "chain" (those smaller IR exendraton parts attached between fromt leg and structural fuselage). (Sorry, don't have better picture.) Those were necessary to prevent over rotation of otherwise free moving parts. With custom suspension strut whole craft would be much more simple to create.

One other thing that have poped up on my mind, while thinking of it. Would be possible to create "dead" zone for suspension, meaning, spring and damper forces from suspension strut would not be applied at all until certain force does not exceed "dead zone force" or length of extended/retracted strut does not exceed length limit.

Don't know would be better to have force or length for "dead zone". Can that help with kraken oscilation due to game engine physics ? Meaning, unless certain force is not exceed, suspension strut would not try to compensate and hopefuly it would not add more to unwanted "phantom" oscilation.

 

[Gaalidas]

On 7/12/2017 at 6:22 PM, FungusForge said:

It wouldn't be too much of a stretch to request it then? There's a lot of ways I could use a wheel like this that I've not done simply because it looks atrocious with the current selection of wheels (and I really don't like the stock wheels, or wheels that work like them)

A really good example is the surface track.  That's basically a track, but with the mount on top.  So, Yes... I think it would be reasonable to request a wheel where the suspension system is packed inside the wheel space.  However, it would probably help any world-be-modeler if they had an example that you could provide for what you're looking for.... something either in another game or the real world that would fit what you're thinking about, before a solid assessment can be made as to what can and cannot be accomplished.  I will say this though: I don't think new parts are really a priority at this time.  I could be wrong, but this is what I've gathered from the activity lately.  lo-fi had a special talent for making wheels, which work well within his original code, at record speeds.  This is not a common trait... and his absence is a blow to this project.  That being said, I've been wrong before so... yeah...

The do-ability of a wheel that has mounting nodes on both sides is something we could actually accomplish now, but it wouldn't have quite the appearance you're aiming for without the source unity projects for lo-fi's models.  The nodes themselves I could accomplish with some config tweaks if appearance wasn't an issue.  The difficulty here is in the modelling of the part itself.  Other problems that could crop up are related to part hierarchy and whether or not attaching more of the ship on the other side of the wheel is going to be stable.  With the mod called "Recoupler" it might be alright, since it can attaching parts that would not normally attach in the editor if they have attachment nodes in the same location upon loading into the flight scene, but without it there might be some unforeseen issues.

Keep in mind, I'm just theorizing and hypothesizing.here from a purely logical standpoint.  I'm really jsut a coder, and not an amazing one at that.  Yes, i did create all the original part's stack nodes back in the day, but I got lucky with those.

 

On the note of suspension-only parts, I've been asking for those since I first started working with lo-fi a really long time ago.  It has it's own set of issues though, since you're not just working with colliders, but rather IR-style movement of everything attached via that suspension node in the hierarchy.  I didn't understand that way back in the day, of course, but I know now why lo-fi shot me down when I would talk about it.  It's more in the realm of an IR plugin than a KF plugin.  I always did think that IR and KF (or KSPWheel nowadays) would be capable of doing great things if coded for interaction between their modules and sharing of data.

 

Finally... I've done some poking around in the current KSPWheel code, the old KF_plugin code, and some of my own code in an attempt to get lo-fi's deceptively simple auto-configuration code to work with it.  I'm really close to a possible way to allow a user to select if they want the steering constraints to be auto-generated, but I've run into the block with how KSPWheel is currently coded.  Specifically, it's not coded to be easily extended by an outside plugin.  I really need some way to hook into it, or I'd need to simply integrate the old code directly into the current project.  I'm cool with that, since it's not really my code anyway, I'm just making it function again... but it's requiring me to make some changes to the steering module in just about every method contained in that class.  I ain't done working on this baby though... so who knows what I'll finally come up with.  I still have a few tricks up my sleeve for overriding values in the main modules without having to alter the original code... long as the information I need to alter are exposed to the configs.

Either way... progress is starting to be made.  The goal is for the end user to be able to click a button on a single wheel's context menu and have it auto-calculate steering limits based on its position on the craft, within the wheel's group number or on all of the wheels on the craft.  I'm also trying to find a way for the original values to be saved and for it to be a toggle where, while on, manual changes will be disabled and, when turned off, the original settings will be restored.  I'll keep y'all posted.

Edited July 14, 2017 by Gaalidas
my typing stinks... badly.... so badly...

[Shadowmage]

Updated release is available:

https://github.com/shadowmage45/KerbalFoundries2/releases/tag/2.0.2.7

Change Log:

• Update KSPWheel to latest, includes a few bug-fixes and feature enhancements.
• Updated included ModuleManager to latest (2.8.1)
• NEW PART - Large Deployable Landing Leg - Has optional angled deployment using stock animation module, with adjustable deploy-angle limit. Model+textures by @TiktaalikDreaming, rigging/configs by @Shadowmage

[Gaalidas]

3 hours ago, Shadowmage said:

Updated release is available:

https://github.com/shadowmage45/KerbalFoundries2/releases/tag/2.0.2.7

@TiktaalikDreaming, rigging/configs by @Shadowmage

I'd like to point out a few things with the current release of this mod.

1. In the KFCommunityTechTree.cfg file:
   - @PART[KF_*]:HAS[@MODULE[KFRepulsor]]:NEEDS[CommunityTechTree]:FOR[KerbalFoundries]
   This will have no effect at all considering the module in question is now called KSPWheelRepulsor
   
   - @PART[KF_*]:HAS[@MODULE[APUController]]:NEEDS[CommunityTechTree]:FOR[KerbalFoundries]
   This will also not have any effect because the module in question is now called KFAPUController
    
2. Is DustColor.cfg even used anymore?  If it is, I really don't see a point, at this time, of keeping it.  At the very least it was never updated to reflect actual biome texture colors so I would either remove it from the process or give it an updated run.  You might be able to update it on the move by detecting the biome a rover is in while rolling, and selecting an average color to attach to the config.  I'd still just take it out though considering how easy it is to sample the terrain using the camera.

[Shadowmage]

14 hours ago, Gaalidas said:

I'd like to point out a few things with the current release of this mod.

1. In the KFCommunityTechTree.cfg file:
   - @PART[KF_*]:HAS[@MODULE[KFRepulsor]]:NEEDS[CommunityTechTree]:FOR[KerbalFoundries]
   This will have no effect at all considering the module in question is now called KSPWheelRepulsor
   
   - @PART[KF_*]:HAS[@MODULE[APUController]]:NEEDS[CommunityTechTree]:FOR[KerbalFoundries]
   This will also not have any effect because the module in question is now called KFAPUController
    
2. Is DustColor.cfg even used anymore?  If it is, I really don't see a point, at this time, of keeping it.  At the very least it was never updated to reflect actual biome texture colors so I would either remove it from the process or give it an updated run.  You might be able to update it on the move by detecting the biome a rover is in while rolling, and selecting an average color to attach to the config.  I'd still just take it out though considering how easy it is to sample the terrain using the camera.

1.) Good catch;  I don't get to play often enough to spot stuff like that   Both are fixed now.

2.) Umm...I don't think so?  I would have to look at the code, but I believe the config is used for a fallback in case someone disables the dust camera.  Otherwise, yeah, it could probably just be removed entirely.  Will see if it is still setup as fallback.

[Gaalidas]

So, i've done a little research on how addons for KSP can hook into the base part module's setup to set their own procedures and whatnot.  It's something that never made a lot of sense in class mainly because it was never really necessary to use them.  Virtual Classes.  So, I'm going to do some fiddling locally and see what can be done here.  The short of it is that I will likely propose that some of the base KSPWheel modules include a method that uses the keyword "virtual" in them.  These methods can be completely blank as far as what's in them but, if called from somewhere in the other classes, it would allow me to inherit the class and then use the "override" keyword to hook into the parent module and modify some things.  Again, I'm not ready to make a recommendation just yet, but I'll be looking into this in the next few days/week if I get the time.  This would allow me to make a real add-on for KSPWheel to re-implement some of lo-fi's old code without having to modify the original modules at such an extensive level that I've been having to do to implement the code.  A cool side note: this is how the "override OnAwake()" method works when inheriting "PartModule" in our own modules.  Again, I'll keep y'all posted on my progress.  I'm gonna get an auto-configure working if it kills me.

 

1 hour ago, Shadowmage said:

1.) Good catch;  I don't get to play often enough to spot stuff like that   Both are fixed now.

2.) Umm...I don't think so?  I would have to look at the code, but I believe the config is used for a fallback in case someone disables the dust camera.  Otherwise, yeah, it could probably just be removed entirely.  Will see if it is still setup as fallback.

Would you believe I don't actually play anymore... at least not right now?  I just checked the configs cause I've been in the source code for a while now and noticed you'd renamed all the modules.  The DustColors.cfg probably isn't slowing anything down, and it would make an alright fallback I suppose if it could be updated.  Current KSP, however, has a bit more ram allowance than the old ones the camera was implemented on originally and I doubt it would cause much extra latency.  You might just merge the camera disabler with a global dust disabler and take DustColors.cfg out of the loop entirely.  It wasn't really meant to be a long term solution anyway, and would have no use outside of the stock planets as they are now.

Edited July 16, 2017 by Gaalidas
I can't stay away... literally...

[Shadowmage]

@Gaalidas

What you are referring to is certainly doable, though with C# there are a few other options available that allow for even cleaner integration of derived code (delegates vs. sublcasses).  Generally I've found type based polymorphism (base classes->subclasses) to be... very limiting.... and have been moving to using C# delegates instead.  Delegates allow for defining of a method at the place where the method is called (or really anywhere), rather than in a concrete class that must be setup before hand.

But anyhow, yes, I am quite familiar with virtual methods (and abstract methods by extension), and they are already in use in KSPWheel to allow for the kind of functionality you are looking for:  https://github.com/shadowmage45/KSPWheel/blob/master/VSProject/KSPWheel/PartModules/KSPWheelSubmodule.cs#L69-L77

^^ Blank / empty base method, that is defined and implemented by whatever the subclass needs.  If you look in the steering/motor/etc 'submodules', they all override these methods to do their lifecycle code.

So I believe I already have the functionality in place that you are looking for with the current multi-module setup.  You could make a KSPWheelAutoConfigure module, extending from the KSPWheelSubmodule class.  From there you would get automatic hooks/callbacks from the base module at specific lifetime events (part initialized, wheel created, physics started, pre- and post- physics and rendering frame updates).  The real trick would be hooking into the existing steering/motor modules (of course, custom steering/motor modules could be created with the built-in auto-configure functionality, possibly even using the existing steering/motor modules as base classes and only overriding the setup functionality).

 

 

[Gaalidas]

I literally noticed you use virtuals and such just after writing the last comment.  Anyway, they're new to me... so still exciting stuff.

 

I will look into that.  I hadn't thought of looking into the submodules considering my only experience is in simply modifying public variables in other stand alone modules.  I'll have to mess around with that.  One thing that may be a bit problematic is that you have a low and high limit setting for steering while, in the old code, we simply had a single variable for max steering angle.  It turns out lo-fi's code is deceptively simply.  It really just counts out all the wheels of a compatible type are on the craft and gives them a position in an array of sorts, then uses a curve to set their optimal angle.  That's simplifying it, but that's it in a nutshell.

So, the current plan is to simply make it a toggle option in the wheel's configuration.  If any single wheel has the option set, it will take the other wheels into consideration when setting up the angles for that one wheel, but will only update and disable the manual configuration for wheels that also have that setting applied.  Thus you could have steering that only uses the front wheels, but they'll take the rear wheel positions into account when setting the angles.  That's the idea anyway.  It would be a lot more efficient, of course, if the detection and settings could be run from a vessel module instead, keeping it form being repeated for every wheel with that setting applied, but I'm unsure as of yet how that might be achieved while still allowing for per-part toggling of the option.  I'm still playing with it though.

As for delegates... I really hate those.  Mostly for the reason that I simply can't seem to wrap my brain around them.

 

Morning-after update:
So, I guess I'm going to have to launch KSP with KF installed and do some fiddling around.  I don't actually know how most of these settings are applied or what they do.  I did take a look at hooking into the submodules class, but I can't just add my module in there and do things, I need to override things that are happening in other modules.  This is all getting really complicated and I wonder if I should just make some modifications to the original steering class in your project and submit them to you directly for integration.

Edited July 17, 2017 by Gaalidas
Just can't stop thinking... over and over and over and ove...

[drtedastro]

Hello all.

First, thanks for this great mod and all of your work.

Next, with the latest KSP_WHEEL and KerbalFoundries some of my craft are breaking on the the runway, where that did not happen on previous version.

I have 'glanced, rapidly' at previous posts and did not find anything about this.

did i miss something in posts, or has there been some major change that is rendering my adjustable wheels more susceptible to damage?

thanks for any info, and if needed i can load up craft file and logs.

Cheers again.

[Shadowmage]

1 hour ago, drtedastro said:

Hello all.

First, thanks for this great mod and all of your work.

Next, with the latest KSP_WHEEL and KerbalFoundries some of my craft are breaking on the the runway, where that did not happen on previous version.

I have 'glanced, rapidly' at previous posts and did not find anything about this.

did i miss something in posts, or has there been some major change that is rendering my adjustable wheels more susceptible to damage?

thanks for any info, and if needed i can load up craft file and logs.

Cheers again.

Going to need at least pics of the craft, possibly .craft files (as long as they are stock+KF only).  Impossible to tell what is going on without a bit more info.  Log files are also good, as that will contain the reason for the breakage (over-loaded, or over-speed).

Nothing should have changed regarding wheel damage / load rating that I'm aware of, but that doesn't mean there isn't a new bug somewhere, or that an old bug that got fixed was allowing the previous usage incorrectly.

Edited July 17, 2017 by Shadowmage

[drtedastro]

I will get those to you later today.  many thanks.

[Shadowmage]

3 hours ago, drtedastro said:

I will get those to you later today.  many thanks.

No problem; even just the log would probably tell me most of what I need.  Specifically I'm looking for if it was a speed or load related breakage.

[drtedastro]

still unable to get on to get the info for you, but it was related to load..

the new version showed the adjustable medium's breaking and for some reason it was unable to apply throttle.

but that is from memory..

cheers.

[Shadowmage]

12 hours ago, drtedastro said:

still unable to get on to get the info for you, but it was related to load..

the new version showed the adjustable medium's breaking and for some reason it was unable to apply throttle.

but that is from memory..

cheers.

Hmm... strange... there were no changes to load handling in the recent release (that I'm aware of).  Would need a bit more info so that I could test / duplicate the problem in order to see if it actually is a problem or not (.craft files, or at least pics of the craft and some stats).

Edit:  Here is a diff of the changes that went into the recent release.  Zero things 'load rating' related.   https://github.com/shadowmage45/KSPWheel/compare/c76d14118b78ad1cda80ff57ec8372074c964601...master

 

 

Re:  ALG-Black textures..... is this 'stealth' enough?  (same texture, with all the white bits replaced with stock-black; will be brighter/more washed out in KSP due to lighting differences)

I'll try and do some comparisons vs. the black on some of the stock parts to see how well it all meshes.  No matter what though, these are going to be sub-par textures as I do not have access to the masters, and about all I can do is simple recolors.

Now, if someone has access to the original texture master files (.psd or .xcf), I might have a chance to do a proper job on them.  Sadly, those were not part of the assets that I had/have access to.

 

Edited July 18, 2017 by Shadowmage

[TiktaalikDreaming]

7 hours ago, Shadowmage said:

Hmm... strange... there were no changes to load handling in the recent release (that I'm aware of).  Would need a bit more info so that I could test / duplicate the problem in order to see if it actually is a problem or not (.craft files, or at least pics of the craft and some stats).

Edit:  Here is a diff of the changes that went into the recent release.  Zero things 'load rating' related.   https://github.com/shadowmage45/KSPWheel/compare/c76d14118b78ad1cda80ff57ec8372074c964601...master

 

 

Re:  ALG-Black textures..... is this 'stealth' enough?  (same texture, with all the white bits replaced with stock-black; will be brighter/more washed out in KSP due to lighting differences)

I'll try and do some comparisons vs. the black on some of the stock parts to see how well it all meshes.  No matter what though, these are going to be sub-par textures as I do not have access to the masters, and about all I can do is simple recolors.

Now, if someone has access to the original texture master files (.psd or .xcf), I might have a chance to do a proper job on them.  Sadly, those were not part of the assets that I had/have access to.

 

My conversion from dss was very washed out. I've got the unwrap as well then got distracted.

[Shadowmage]

49 minutes ago, TiktaalikDreaming said:

My conversion from dss was very washed out. I've got the unwrap as well then got distracted.

Yeah, I had to decompose the image (to remove the alpha), and then recolor and recombine the RGB channels for the base diffuse texture.  Its still a bit of a blocky decompressed .dds mess, but at least something to start with.  Still trying to figure out what to do with it from there to extract the 'detail' layers from the base colors (have something..usable... but could be much better and easier to work with).  I already uploaded the combined UV maps to the shared folder, and will add the texture files that I am working with -- perhaps you'll have better luck/ideas

 

[TiktaalikDreaming]

2 hours ago, Shadowmage said:

Yeah, I had to decompose the image (to remove the alpha), and then recolor and recombine the RGB channels for the base diffuse texture.  Its still a bit of a blocky decompressed .dds mess, but at least something to start with.  Still trying to figure out what to do with it from there to extract the 'detail' layers from the base colors (have something..usable... but could be much better and easier to work with).  I already uploaded the combined UV maps to the shared folder, and will add the texture files that I am working with -- perhaps you'll have better luck/ideas

 

So you did.   So used to ignoring Dropbox's "alerts" I didn't notice.

[Shadowmage]

 

On 7/16/2017 at 10:45 PM, Gaalidas said:

Morning-after update:
So, I guess I'm going to have to launch KSP with KF installed and do some fiddling around.  I don't actually know how most of these settings are applied or what they do.  I did take a look at hooking into the submodules class, but I can't just add my module in there and do things, I need to override things that are happening in other modules.  This is all getting really complicated and I wonder if I should just make some modifications to the original steering class in your project and submit them to you directly for integration.

It really should be doable through a separate submodule (e.g. KSPWheelAutoConfigure), that is added to the parts after the steering module.  It can then run its code either when parts are added/removed from the craft, or once on the first startup of the flight scene;  all it should need to do is hook into the existing steering module and adjust its high/low steering limits and bias setup (which are all public vars).  Should be no need to override existing methods; just hook into the steering module and adjust some of the existing config variables.

Could also be done as edits/adjustments to the current steering module (as long as it is optional, and preferably disabled by default).  Probably just a single method / few lines of code to hook into the auto-configure code (which should be able to be ported from the old KF plugin, with a few adjustments).  Once in the editor the user could hit the 'auto-configure' button, or set the toggle for auto-configure to true (whatever method is used to turn on/off the auto-configure).

One other option would be for me to define a blank/abstract/virtual method in the existing KSPWheelSteering class that is called during part setup.  You could write a new module derived from the KSPWheelSteering module, and override/define that single method to affect your desired auto-configure.  Lastly, you would patch/edit the existing part classes to replace the existing KSPWheelSteering with the new KSPWheelSteeringAutoConfigure module.

If you would like help / more pointers on how to get things working, please let me know.  I could probably put together the majority of the module code for you, where you would only need to fill in the code for the auto-configure method.  Probably easiest that way anyhow, so you don't have to deal with trying to learn the existing codebase/hooks/delegates/etc, and can concentrate just on the auto-configure code.

 

Delegates -- they are a bit different (and the syntax is...very odd... if not familiar with it).  Once you wrap your head around them though, they open up all sorts of new code-design possibilities and 'shortcuts' to getting things done.  I had spent a couple of years working with Java though, where delegates are very similar to Javas anonymous methods.  Also spent some time in the C++ world where function pointers could be passed around as arguments, which is the other side of delegates (a function as a parameter/input for a method).  So once I learned of their existence in C#, it was just a bit of figuring out the syntax for that language.

 

[LordOfMinecraft99]

I only have the adjustable landing gear. I am using ksp 1.3 and the latest kerbal foundries.

[Tivec]

I'm not sure what I am doing wrong, but I have built a small aircraft, roughly 8t, and added the small adjustable landing gears from Kerbal Foundries on it, and it's looking great. However, whenever I land, the aircraft will bounce rapidly up into the air, spin, and come crashing down. Do you have any idea what could be causing something like this? Wheel settings are default, except for tilting and extending the gears out slightly, and aligning the wheels.

[Starwaster]

2 hours ago, Tivec said:

I'm not sure what I am doing wrong, but I have built a small aircraft, roughly 8t, and added the small adjustable landing gears from Kerbal Foundries on it, and it's looking great. However, whenever I land, the aircraft will bounce rapidly up into the air, spin, and come crashing down. Do you have any idea what could be causing something like this? Wheel settings are default, except for tilting and extending the gears out slightly, and aligning the wheels.

Try decreasing springiness and increasing damping. 

[Gaalidas]

19 hours ago, Shadowmage said:

It really should be doable through a separate submodule (e.g. KSPWheelAutoConfigure), that is added to the parts after the steering module.  It can then run its code either when parts are added/removed from the craft, or once on the first startup of the flight scene;  all it should need to do is hook into the existing steering module and adjust its high/low steering limits and bias setup (which are all public vars).  Should be no need to override existing methods; just hook into the steering module and adjust some of the existing config variables.

I would prefer to not make you do any extra work to make this function... and it really would be better to have this as a separate sub-mod for KF/KSPWheel so I can update it at my own pace and/or add other new features to various modules.  Thanks for the tips though... I'm going to continue fiddling around with various ideas and see what I can come up with.  I hit these coding-blocks in my brain from time to time that make it hard to see the right path to take... or even see what it is I'm trying to make happen.  My biggest block right now is in the way the steering limits are implemented (your high and low limit vs. the old steering ratio that lo-fi used) and which of those limits I should be modifying for the desired effect.  I would have thought there would only be one limit, with the other limiting factor being the default position of the wheel when not steering any which way.  I need to dig into the part configs a bit to see what you've set them all to, as well.  Is there are single value that best represents the overall steering ratio in the current steering module?

Another thought that I need to put into action is to disable the auto-calc when the wheel type is a track, since it has really no point (except for with the surface track, which has wheel-style steering I think?) when track steering is in play, unless a part uses both forms of steering together.

I think best case scenario is to not replace the class entirely with a derived class.  That would make more work for me if/when you update the steering module with some new feature or whatnot.  Would cause the end-user to get some strange results.  The best plan would be to alter the way the module is working though another module.

Delegates... oi.  When the class I took covered them, the idea, from what I could figure out, was that it allowed you to input an unknown function as a parameter instead of just a data type.  This differed from providing a data type using a method like we do all the time, but rather providing the method itself for the parent method to use.  I suspect I have it all wrong though and the teacher was just condensing it.

This all being said... in the process of making this I have discovered several ways the existing code could be updated for some efficiency bonuses.  I'll probably have some coding recommendations for you in the future.  I also managed to implement a few features that you had in To-Do comments.  I'll include those when I make any recommendations.  As for now.... there are floors to vacuum and I'm the vacuum technician (glorified carpet janitor really) so... off I go.

Edited July 20, 2017 by Gaalidas

[Shadowmage]

18 hours ago, LordOfMinecraft99 said:

I only have the adjustable landing gear. I am using ksp 1.3 and the latest kerbal foundries.

That would point to an installation problem.  Going to need at least log files and pics of your GameData folder.

 

2 hours ago, Tivec said:

I'm not sure what I am doing wrong, but I have built a small aircraft, roughly 8t, and added the small adjustable landing gears from Kerbal Foundries on it, and it's looking great. However, whenever I land, the aircraft will bounce rapidly up into the air, spin, and come crashing down. Do you have any idea what could be causing something like this? Wheel settings are default, except for tilting and extending the gears out slightly, and aligning the wheels.

Is this on the most recent version?  If so, you could try out the previous release to see if the problem persists.  Have they ever worked properly for you (or is this your first time trying them out)?

If the older version works for you, please let me know so that I can look into whatever code I may have messed up.

[Grease1991]

I've encountered a something weird and i'm not really sure if it's a bug, or not or whether it's the landing gear or the catapult from Carrier Accessories pack. 

The way the catapult works is you run your front wheel up to the starting point and it locks in and then you hit the breaks and get shot off.
However the catapult doesnt not seem to lock in with the AGL gear, it works with the stock landing gear though, 

So my first thought was how the AGL gear might be viewed game wise vs the stock gear, however im not code literate 
I havent tried the legacy B9 gear yet (cause i think they run on KSPWheel as well)but i thought i would bring it to the attention of people more capable of solving and figuring stuff out than i am.

Edit #1: I just tested the B9 Gear and they don't work either with the catapult.
Edit #2: I've also noticed that Engineers Report does not view ALG or B9 Gear as landing gear. maybe something there?
Edit #3: so looking at the source for the Catapult it looks for ModuleWheelBase to activate the catapult, and both the ALG and B9 Gear use KSPwheelBase. 

So my guess is that if KSPwheelBase was added to that then it would most likely work. can that be done Via MM patch?

 

 

Edited July 21, 2017 by Grease1991

[Gaalidas]

4 hours ago, Grease1991 said:

So my guess is that if KSPwheelBase was added to that then it would most likely work. can that be done Via MM patch?

I highly doubt that would fix it really.  It's likely locking into a specific transform on the models that are used for stock landing gear and/or modded landing gear under the stock modules.  I'd need to dig into the source for the catapult to know for sure.