Will be restoring the Griffins and Ravens with corrected loadouts. The COR-7A in this mod will be hidden and removed from spawning as it's now in YAML. The mech itself will still be in the game, so you will not lose any COR-7A you have from YAMM.
Currently in open testing on the YAML discord, so hopefully won't be far from going live with it. All things going according to plan, it will be the final update.
i have had no issues using the original after YAML, cause that should be where it goes based on requirements, other than the 400+ engines being here or there about providing speed and heatsinks...... what is the reason to have YAML override this or the original?
YAML, in recent updates, has fixed some errors that were present in vanilla mechs. this also required changing some of the hardpoint data
the original YAMM, with its default LO having it load after YAML, overrides some changes and re-breaks things
this maintenance fork does not re-break things, and also since it now loads before YAML it should be permanently compliant with any future YAML changes
Good stuff on the update and a very sincere thank you for putting in the efforts to update the mod. As a note, the second E hardpoint on the LT and RT of both the Griffin 1RG and 3RG are now missing on both variants, so no small lasers are present. The mechs show 6/5 (there's extra empty hardpoints on the 1RG's RA) and 6/4 hardpoints but count the tonnage, and you cannot see or remove the offending weapons in the lab without stripping the mech. Changing load order does not alleviate the problem (obviously just relying on YAML hardpoint files, now). Is a YAML update coming soon that adds those hardpoints?
Pity there won't be future development on the concept, as the mod is awesome and the DLC6 "refit" feature took it to the next level. Regardless, I hope Chozo is okay, they just kind of dropped off the face of the earth.
Anyway, the efforts from both of you are sincerely appreciated, as well as the rest of the YAML team. Thank you, again.
If they're existing mechs you have in career/campaign - yep, that will happen, the hardpoints had to be redone on those two energy hardpoints. The "Remove Invalid" button in the mechlab should de-equip those slots though. Had to do it, unfortunately.
It's not in an existing campaign/career. The problem is present in instant action with a "fresh" mech that's just selected. Also, when you select the mech no "remove invalid" button appears. It's counting the weight and saying there are weapons there that aren't present in the loadout or mech details.
Hope that helps clarify the issue. In the mean time I'll try a clean reinstall and see if something is fluttering around that shouldn't be there.
EDIT: Nope. Did a clean reinstall of the mod, disabled everything but YAML and YAMM, GRF 1RG and 3RG are missing the second E hardpoint in each ST.
I've just downloaded a fresh copy of the bare minimum myself - YAML v0.93.1, YAMM-Maintenance Fork v1.0.0, Yet Another Weapon v2.2 All fine.
In fact, the only way I can generate the issue is by using the the previous version of YAML (v0.93), since it's missing the new hardpoints. Theoretically another way it can happen (though my game is refreshing IA back to an AS7-BH) is if you have the mech already in the Instant Action mechbay before updating - if this is the case, select any other mech, then reselect the Griffins so it refreshes the loadout to current mod loadout, not what it remembers for IA.
That said, my YAML says it's 93.1 -HOWEVER- it's been a while since I did a clean reinstall of that. There could -in theory- have been a bad copy there. I'll investigate further. If I try a clean install there, and I STILL have the problem, then clearly I need to do a file verification and/or a full reinstall of MW5.
EDIT/UPDATE: Okay, we've got a double-whammy here. Yes, my YAML was 93.1, but a bad copy on a pak file somewhere. So that part worked. Re-enabled all mods, mech broken again. Big question mark. Turns out there's a conflict with "Yet Another IS Mech" that I had to read through every file conflict to notice. That mod adds/unlocks a bunch of skins on vanilla mechs. However, they apparently also copied the HPS files over for those affected mechs, breaking a handful of hardpoints.
Their default load order and given instructions are also to install after YAML for proper functionality. That obviously becomes an issue of "choose the load order to decide which functionality one wants". I want the working hardpoints. Load order adjusted and everything's working as well as I can get it.
Thanks for the assistance, and thank you for the efforts you've put into updating the mod. It is very sincerely appreciated.
Sure, but I'm also running YAISM, and I've tested it with such. In fact, most of the YAML mods. It's all working fine - those 'conflicts' are quite literally intentional. If you're tinkering with load orders, I can only assume you've moved stuff you shouldn't have, or are running something else you should.
Post your modlist, there's something more to the story, and I'd like to know what's breaking things from working properly.
Here you go, raw load order dump (cleaned up so it's not raw json code). Also worth noting that some of the mods are still pushed higher from conflict testing, so things like exotic IS mechs and special variants need to be pushed back down. Anyway, the list:
Spoiler:
Show
"gameVersion": "1.1.361",
"Revenant"
"T6Ms_MAD_III"
"WyvernYAML"
"WaspYAML"
"TedwinsCustomMechFoundry"
"BC_YAML"
"MW5Compatibility"
"AddedNews_Post3049"
"YetAnotherMechlabMechs"
"Exotic IS Mechs"
"YetAnotherISMech"
"SpecialVariants"
"YetAnotherMechlab"
"YetAnotherWeapon"
"YetAnotherWeaponClan"
"harjel"
"AdjustedPPCX"
"AdjustedPPCX_YAWAddon"
"Sereglach_Tweaks"
"SereglachFlamerVisual"
"QuickArmorRepair"
"RestoreTraits"
"YetAnotherLegendaryMech"
"YetAnotherCampaignHeroMech"
"Lore-based Mech Variants - YAML Edition"
"YetAnotherClanMech"
"EL_Menu"
"LeopardColors"
"MechDelivery"
"PGI_Infantry"
"PGI_Infantry"
"Infantry Tweaks"
"RookReward"
"ECMTowers"
"AdjustableCockpitCamera"
"CockpitGlass"
"ScaryTanks"
"ObjectiveJump"
"Coyotesmission"
"ArenaControl"
"TTRulez_AIMod2"
"TTRulez_LanceMateOrderz"
"RepairBays"
"FasterTravel"
"TheKnownUniverse"
"BetterMissionChoices"
"IncreasedTreefallAnimRate"
"MW2Betty_Ultimate"
"vonHUD"
"Lance_UI"
"BattleGridOrders"
"BetterEnemyWeapons"
"ExpLogos_Mercs"
"StackedCrates"
"ArmorGreen"
"MechShaderV2"
"PurchaseSalvage"
"FactionStandingTweaks"
"Pilot_Potential1"
"Pilot_Potential"
"CommanderQuirk"
"SpawnControl"
"ModOptions"
"AdvancedCareerStart"
"PilotOverhaul"
EDIT: Just got done telling DeadRaiser, already committing to a full clean mod reinstall. I'm guessing the build just got corrupted or whatever over time with many updates, etc. I'll update over on his page with the results tomorrow. I mod the hell out of Bethesda games all the time, so this is absolutely nothing new to me. Regardless, I appreciate the help with the troubleshooting from both of you.
Nothing too dicky in there. The Revenant is ancient and a half, might be broken in itself, but shouldnt be breaking other mods though. But yeah, if in doubt, nuke it and start again. That is something I had to do a while back to fix everything
Got everything rebuilt and it's working just fine. Glad you understand the situation and have been cordial about it. Deadraiser, however, needs to take a chill pill and realize that mod makers are not the kings of load orders, but the users themselves. It's the user responsibility to manage their load order and it's their responsibility to make sure everything is working. If users only listened to mod makers you'd only ever be able to use one mod -or one series of mods- because everyone says their stuff takes priority and their stuff doesn't play nice with others.
Anyway, that aside, came thinking I had a bug, but with your help was able to realize it was just a busted build. I kind of figured that was the case after the YAML corruption, which is why I committed to the rebuild. I do greatly appreciate your help and for you not being a jerk. Thank you for the efforts you put into modding and improving MW5.
Firstly, I apologize for being blunt, rude, and curt in our discussion on the YAISM page. I've gone through so many troubleshoots of user mod lists that I might be a bit tired of seeing the same problems over and over again. While I absolutely understand that it is the user's responsibility to manage their LOs, the problem is that MW5 mods do not interact like mods in Skyrim, Fallout, Cyberpunk, or really any other game. The way we have to create mods in the Unreal editor is very restrictive and doesn't allow for easy things that allow for load order shifting that you would normally do in those other games. Moving 1 mod to new spot in Skyrim might not change much, but doing that same thing in MW5 can break your whole list. Mod authors such as phfor and myself set predetermined load order positions in our mods because not only PGI gave us the option to do so, but also because it allows us to place them where they need to go in relation to other mods they might be or should be used with. The reason why YAISM, for example, has a default load order position of 19 is because it needs to load the other mechs within the YAML mod space to change their mech MDLs to YAISM's updated ones to create a cohesive single list bracket in the mech list for each chassis rather than having 6 just for the Catapult.
The YAML-based mods are especially made with this in mind. We all talk to each other and figure out how to set our mods to load in the best position where compatibility is maintained. It's not perfect and we still run into issues, but when user manipulation runs rampant in lists, then it destroys the whole modding experience for the players. UE modding is an all or nothing affair since we don't edit loose assets or have the option to combine changes from multiple mods into the same asset like with the Bashed Patch or WolvenKit's patcher. So if one mod makes a change to an asset in vanilla, but then another mod edits that same asset, it becomes a battle of who's last in the stack applies the changes and the rest is ignored unless the mod loading last contains all previous changes to the rest. For some changes, it's meaningless while others it breaks an entire mod.
Of course, users have the power to ignore modder recommendations or disclaimers (many have ignored the big bold letters on YAISM about requiring mech rescale after all lol) and that is their discretion, but this isn't a matter of modder control. phfor and I have been through troubleshooting hundreds of lists on the YAML discord to help people get their games in the best working condition and the exact steps I mentioned in the YAISM bug reports (heavy-handedly and unnecessarily harsh though) is the general gist we do recommend people. We're not here to tell people how to play their game, but we do want them to have the best experience while playing and we genuinely try to help every person who asks for guidance, checking, and correcting their lists.
I understand your frustrations, and apology accepted, DeadRaiser. No worries. That's why I didn't retort and I didn't push a fight, all I said is to take a chill pill and cool off; and I didn't do it directly, because I didn't want you to think I was trying to goad you into anything.
One thing to remember, though: these mod load orders ALWAYS function the same, regardless of game. As long as they support a load order, from the Torchlight series to KCD to Bethesda games to MW5, the load order affects 1 thing and 1 thing only, priority. As long as the mods that *need* to load after a given mod load in that order, they work fine; and sometimes the user must decide what takes priority due to conflicting functionality. Yes, YAISM needs to load after YAML, but if YAML is 3 and YAISM is 53 . . . it doesn't matter . . . it still works properly for *their* compatibility.
That's why I have a bunch of crap at the beginning of my load order that needs to be overridden by anything else (like that funky Revenant mod . . . still works, but NEEDS to be first so all the wonky crap is overridden by MW5CP and YAML) and a bunch of stuff shunted toward the end of the load order that's finnicky if overridden or needs specific catering (like the PO affiliated mods). Then there's the YAML clump in the middle; and while y'all can cater your default load order as well as possible (which I'm sure is appreciated by many a user), it isn't going to be the end-all-be-all.
In the end, it's user responsibility; and if something is clearly a load order issue, by all means say "we've got a default load order for our mod series, and it'll work best that way, this shouldn't be loading before that" . . . but it's still user responsibility. If someone destroys their load order, doesn't listen to input, and gets nasty, then by all means that's when you tell them to screw off.
Regardless, I appreciate the help in realizing my build was just borked somehow. Glad to have everything up and running well. Also, as always, a very sincere thank you to both for your efforts in modding and improving MW5, and to the rest of the YAML team.
If you want the revenant - have you looked into Yet Another Gah Dang Mech. While it's got a lot more than just that mech (it's got a LOT of mechs), it's at least updated?
I looked at it; and while I do appreciate their efforts, I just couldn't get myself to make the jump for it. Most of their kit bashes are . . . jarring (particularly in the hardpoint renderings in the screenshots). Certainly not the way I'd do most of those mechs, if I had the talent. However, to each their own. They've put in a lot of effort to make that mod and I'm sure there are many people who enjoy it the way it is.
I'm having an issue with one specific mech and it appears to be a YAMM mech (a variant of UM-R60), that when I put a 175 engine in it, the speed still remains 32km/h max rather than the 97km/h it should be. Do you think it could be something in this mod, or possibly an interaction between it and another mod?
Huh. Looks like commando 1C is bork'd. I sooped up one to be a stealthy lil intel boi with null sig, chameleon lps and a pirate H-RR for a tiny ac5... the gun doesn't exist and i can't turn on the stealth systems. enforcer 4R with a heavy rifle and similar null/chameleon combo appears to function fine. my pair of UM-P67 urban mechs I happen to have dont seem to have any noted issues in mission. Do we have an ETA for the next fork/official YAMM update?
edit: huh i stripped it and the model turns properly. might have been the pirate gun. I'll get back to this post and see whats up. edit2: bearhunter AC from YAGDM has a proper model. huh it... its gone. mod change up must have nuked it. I need to revert my save to ID the mod the pirate gear came from. might have broken mechs in my list ;_; disregard, appears to be user error. edit3: ok its from "yet another weapon"... excuse me while i scream into the night. edit again: yup, turned off YAWR and it broke the (p) tiny gun into generic lb parts. ok so before, it broke the starmap when i turned off YAW/C [dont ask me how, it just stopped showing permission levels and other info], but now its working. at least the cannon is working and the mech appears to function again. ok how do i delete this mess of a post >_>
Questions, please: How is the 3RG not working properly? The 1RG has all hardpoints working just fine, but the 3RG's 2nd energy hardpoints in each ST aren't visible. It's very confusing.
How easy is the fix? It seems like it -in theory- should be pretty simple, since all the hardpoints are properly rendered via YAML. I'd think it should just be fixing what visuals a given hardpoint references.
Thank you for your time and consideration, and thank you for the efforts to update and keep this mod alive.
I get that premise, but here's the catch: The 1RG has almost the exact same hardpoints and functions just fine as-is; and all while loading before YAML.
The only differences are that the 1RG has 3E in the RA (available in vanilla), and the 3RG has 1AMS in each ST (available via YAML). The torso weapon mounts are the same . . . 1B and 2E in each ST (added via YAML/YAMM). The hardpoints function just fine and display just fine on the 1RG, but don't on the 3RG (the second energy mounts are missing). It seems like the 3RG just needs to be told to reference the correct hardpoint displays, seeing as it has AMS along with the other ST weapon mounts.
Mech status update - outlook promising. Hoping to be able to reenable the mechs in the near future. Griffin fix unfortunately will need a new hardpoint setup, so things will re-break there, but I should at least be able to get everything available in the public source functional again!
Sounds good. As long as the Griffin has appropriately sighted hardpoints it should still work, fine. It just might look a little different if the way the hardpoints have been placed is changed. What variants are potentially going to have problems?
A very sincere thank you for putting this together to ensure greater compatibility. It is greatly appreciated. Hopefully Chozo is alright, whether they're able to get back into the mod or not.
If they don't come back, and you ever feel like picking up where they left off, I had given her about 250ish builds, with a few apocryphal variants that fill in some holes in certain chassis' thematic hardpoint variations, that they had been planning to implement. I can readily pass those messages/builds along if you want them. Just let me know.
Regardless, thank you for your time and efforts to ensure greater compatibility and a few bug fixes.
Honestly, I am unlikely to actually develop this mod much beyond where it is currently. I've already got a number of projects that I need to finish, so this fork is probably best considered "life support". Plans only go as far as modifying mechs to being correct (hopefully reenable those Ravens into spawning, for example), and working with base YAML.
That said, there's always the odd new person that gets into making mech mods within YAML, so if they start looking for apocryphal build ideas, I'll keep your repository in mind.
No worries. That is entirely fair. Best of luck with the projects you're working on.
Sadly, I've got lots of ideas and lack the skills to implement them . . . refit builds, apocryphal variants, kitbash/homebrew mechs, etc. But hey, if you do find people wanting to work on projects like that and are looking for ideas, feel free to send them my way.
35 comments
Will be restoring the Griffins and Ravens with corrected loadouts. The COR-7A in this mod will be hidden and removed from spawning as it's now in YAML. The mech itself will still be in the game, so you will not lose any COR-7A you have from YAMM.
Currently in open testing on the YAML discord, so hopefully won't be far from going live with it. All things going according to plan, it will be the final update.
any way a fan tnx o7
the original YAMM, with its default LO having it load after YAML, overrides some changes and re-breaks things
this maintenance fork does not re-break things, and also since it now loads before YAML it should be permanently compliant with any future YAML changes
Pity there won't be future development on the concept, as the mod is awesome and the DLC6 "refit" feature took it to the next level. Regardless, I hope Chozo is okay, they just kind of dropped off the face of the earth.
Anyway, the efforts from both of you are sincerely appreciated, as well as the rest of the YAML team. Thank you, again.
Hope that helps clarify the issue. In the mean time I'll try a clean reinstall and see if something is fluttering around that shouldn't be there.
EDIT: Nope. Did a clean reinstall of the mod, disabled everything but YAML and YAMM, GRF 1RG and 3RG are missing the second E hardpoint in each ST.
In fact, the only way I can generate the issue is by using the the previous version of YAML (v0.93), since it's missing the new hardpoints. Theoretically another way it can happen (though my game is refreshing IA back to an AS7-BH) is if you have the mech already in the Instant Action mechbay before updating - if this is the case, select any other mech, then reselect the Griffins so it refreshes the loadout to current mod loadout, not what it remembers for IA.
That said, my YAML says it's 93.1 -HOWEVER- it's been a while since I did a clean reinstall of that. There could -in theory- have been a bad copy there. I'll investigate further. If I try a clean install there, and I STILL have the problem, then clearly I need to do a file verification and/or a full reinstall of MW5.
EDIT/UPDATE:
Okay, we've got a double-whammy here. Yes, my YAML was 93.1, but a bad copy on a pak file somewhere. So that part worked. Re-enabled all mods, mech broken again. Big question mark. Turns out there's a conflict with "Yet Another IS Mech" that I had to read through every file conflict to notice. That mod adds/unlocks a bunch of skins on vanilla mechs. However, they apparently also copied the HPS files over for those affected mechs, breaking a handful of hardpoints.
Their default load order and given instructions are also to install after YAML for proper functionality. That obviously becomes an issue of "choose the load order to decide which functionality one wants". I want the working hardpoints. Load order adjusted and everything's working as well as I can get it.
Thanks for the assistance, and thank you for the efforts you've put into updating the mod. It is very sincerely appreciated.
Post your modlist, there's something more to the story, and I'd like to know what's breaking things from working properly.
"gameVersion": "1.1.361",
"Revenant"
"T6Ms_MAD_III"
"WyvernYAML"
"WaspYAML"
"TedwinsCustomMechFoundry"
"BC_YAML"
"MW5Compatibility"
"AddedNews_Post3049"
"YetAnotherMechlabMechs"
"Exotic IS Mechs"
"YetAnotherISMech"
"SpecialVariants"
"YetAnotherMechlab"
"YetAnotherWeapon"
"YetAnotherWeaponClan"
"harjel"
"AdjustedPPCX"
"AdjustedPPCX_YAWAddon"
"Sereglach_Tweaks"
"SereglachFlamerVisual"
"QuickArmorRepair"
"RestoreTraits"
"YetAnotherLegendaryMech"
"YetAnotherCampaignHeroMech"
"Lore-based Mech Variants - YAML Edition"
"YetAnotherClanMech"
"EL_Menu"
"LeopardColors"
"MechDelivery"
"PGI_Infantry"
"PGI_Infantry"
"Infantry Tweaks"
"RookReward"
"ECMTowers"
"AdjustableCockpitCamera"
"CockpitGlass"
"ScaryTanks"
"ObjectiveJump"
"Coyotesmission"
"ArenaControl"
"TTRulez_AIMod2"
"TTRulez_LanceMateOrderz"
"RepairBays"
"FasterTravel"
"TheKnownUniverse"
"BetterMissionChoices"
"IncreasedTreefallAnimRate"
"MW2Betty_Ultimate"
"vonHUD"
"Lance_UI"
"BattleGridOrders"
"BetterEnemyWeapons"
"ExpLogos_Mercs"
"StackedCrates"
"ArmorGreen"
"MechShaderV2"
"PurchaseSalvage"
"FactionStandingTweaks"
"Pilot_Potential1"
"Pilot_Potential"
"CommanderQuirk"
"SpawnControl"
"ModOptions"
"AdvancedCareerStart"
"PilotOverhaul"
EDIT: Just got done telling DeadRaiser, already committing to a full clean mod reinstall. I'm guessing the build just got corrupted or whatever over time with many updates, etc. I'll update over on his page with the results tomorrow. I mod the hell out of Bethesda games all the time, so this is absolutely nothing new to me. Regardless, I appreciate the help with the troubleshooting from both of you.
Anyway, that aside, came thinking I had a bug, but with your help was able to realize it was just a busted build. I kind of figured that was the case after the YAML corruption, which is why I committed to the rebuild. I do greatly appreciate your help and for you not being a jerk. Thank you for the efforts you put into modding and improving MW5.
The YAML-based mods are especially made with this in mind. We all talk to each other and figure out how to set our mods to load in the best position where compatibility is maintained. It's not perfect and we still run into issues, but when user manipulation runs rampant in lists, then it destroys the whole modding experience for the players. UE modding is an all or nothing affair since we don't edit loose assets or have the option to combine changes from multiple mods into the same asset like with the Bashed Patch or WolvenKit's patcher. So if one mod makes a change to an asset in vanilla, but then another mod edits that same asset, it becomes a battle of who's last in the stack applies the changes and the rest is ignored unless the mod loading last contains all previous changes to the rest. For some changes, it's meaningless while others it breaks an entire mod.
Of course, users have the power to ignore modder recommendations or disclaimers (many have ignored the big bold letters on YAISM about requiring mech rescale after all lol) and that is their discretion, but this isn't a matter of modder control. phfor and I have been through troubleshooting hundreds of lists on the YAML discord to help people get their games in the best working condition and the exact steps I mentioned in the YAISM bug reports (heavy-handedly and unnecessarily harsh though) is the general gist we do recommend people. We're not here to tell people how to play their game, but we do want them to have the best experience while playing and we genuinely try to help every person who asks for guidance, checking, and correcting their lists.
One thing to remember, though: these mod load orders ALWAYS function the same, regardless of game. As long as they support a load order, from the Torchlight series to KCD to Bethesda games to MW5, the load order affects 1 thing and 1 thing only, priority. As long as the mods that *need* to load after a given mod load in that order, they work fine; and sometimes the user must decide what takes priority due to conflicting functionality. Yes, YAISM needs to load after YAML, but if YAML is 3 and YAISM is 53 . . . it doesn't matter . . . it still works properly for *their* compatibility.
That's why I have a bunch of crap at the beginning of my load order that needs to be overridden by anything else (like that funky Revenant mod . . . still works, but NEEDS to be first so all the wonky crap is overridden by MW5CP and YAML) and a bunch of stuff shunted toward the end of the load order that's finnicky if overridden or needs specific catering (like the PO affiliated mods). Then there's the YAML clump in the middle; and while y'all can cater your default load order as well as possible (which I'm sure is appreciated by many a user), it isn't going to be the end-all-be-all.
In the end, it's user responsibility; and if something is clearly a load order issue, by all means say "we've got a default load order for our mod series, and it'll work best that way, this shouldn't be loading before that" . . . but it's still user responsibility. If someone destroys their load order, doesn't listen to input, and gets nasty, then by all means that's when you tell them to screw off.
Regardless, I appreciate the help in realizing my build was just borked somehow. Glad to have everything up and running well. Also, as always, a very sincere thank you to both for your efforts in modding and improving MW5, and to the rest of the YAML team.
BR
IG
Huh. Looks like commando 1C is bork'd. I sooped up one to be a stealthy lil intel boi with null sig, chameleon lps and a pirate H-RR for a tiny ac5... the gun doesn't exist and i can't turn on the stealth systems. enforcer 4R with a heavy rifle and similar null/chameleon combo appears to function fine. my pair of UM-P67 urban mechs I happen to have dont seem to have any noted issues in mission. Do we have an ETA for the next fork/official YAMM update?edit: huh i stripped it and the model turns properly. might have been the pirate gun. I'll get back to this post and see whats up.
edit2: bearhunter AC from YAGDM has a proper model. huh it... its gone. mod change up must have nuked it. I need to revert my save to ID the mod the pirate gear came from. might have broken mechs in my list ;_; disregard, appears to be user error.
edit3: ok its from "yet another weapon"... excuse me while i scream into the night.
edit again: yup, turned off YAWR and it broke the (p) tiny gun into generic lb parts. ok so before, it broke the starmap when i turned off YAW/C [dont ask me how, it just stopped showing permission levels and other info], but now its working. at least the cannon is working and the mech appears to function again. ok how do i delete this mess of a post >_>
Incorrect salvage tags, certain mechs aren't being turned into the correct parts.
How is the 3RG not working properly? The 1RG has all hardpoints working just fine, but the 3RG's 2nd energy hardpoints in each ST aren't visible. It's very confusing.
How easy is the fix? It seems like it -in theory- should be pretty simple, since all the hardpoints are properly rendered via YAML. I'd think it should just be fixing what visuals a given hardpoint references.
Thank you for your time and consideration, and thank you for the efforts to update and keep this mod alive.
Once that is remedied, it'll just start working fine again. Until that point, it'll be showing 2/0 etc on the hardpoints on the default loadout.
The only differences are that the 1RG has 3E in the RA (available in vanilla), and the 3RG has 1AMS in each ST (available via YAML). The torso weapon mounts are the same . . . 1B and 2E in each ST (added via YAML/YAMM). The hardpoints function just fine and display just fine on the 1RG, but don't on the 3RG (the second energy mounts are missing). It seems like the 3RG just needs to be told to reference the correct hardpoint displays, seeing as it has AMS along with the other ST weapon mounts.
If they don't come back, and you ever feel like picking up where they left off, I had given her about 250ish builds, with a few apocryphal variants that fill in some holes in certain chassis' thematic hardpoint variations, that they had been planning to implement. I can readily pass those messages/builds along if you want them. Just let me know.
Regardless, thank you for your time and efforts to ensure greater compatibility and a few bug fixes.
That said, there's always the odd new person that gets into making mech mods within YAML, so if they start looking for apocryphal build ideas, I'll keep your repository in mind.
Sadly, I've got lots of ideas and lack the skills to implement them . . . refit builds, apocryphal variants, kitbash/homebrew mechs, etc. But hey, if you do find people wanting to work on projects like that and are looking for ideas, feel free to send them my way.