[Resolved] Softlock in FO3 Start Chargen (modifying CG00 Quest/script for NV race mod compatability)

[iSharingan]

I'm trying to make a small patch/tweak for a FONV player and follower race mod to prevent (or even reverse) MatchRace execution in stage 65 of the CG00 Quest.

I'm having no problems getting my changes to work (in 4 different successes the race was properly set back to/left as default) - but a side effect is a softlock every time the next part of the chargen should appear (specifically the menu to select traits like "Wild Wasteland"). Background sounds still play, but characters stop their animation and everything hangs waiting on the trait menu to appear (the program is still responding - its just the trait selection menu that doesn't appear).

I've tried adding a condition to prevent stage 65 from executing (this I know breaks bc there's a script that checks if the stage is done), reversing the changes as soon as stage 65 completes (I two separate attempts, I used MatchRace again back to CG00DadREF both by various scripts and by adding a new quest stage 66 - both which properly saved [it would fail if there were syntax errors] and were verified successful via console [which means no typos and the code is executing]) but the softlock occurs regardless of my previous methods.

The need for me to make the patch is that the custom player (and follower) races are set up only work for Female gender characters (Male gender settings have no model/texture data, so male characters are bald and pink under the custom races) and was made for New Vegas - otherwise it works flawlessly in TTW.

Does anyone have insight into what might be breaking, specifically (or rather what TTW script/patch/whatever I'm undermining to make the Traits menu fail to display - as it's definitely related to the changes I'm making)? I have GECK already patched/etc. for working on TTW mods, so I mainly need to figure out which additional Master files I need for additional changes.

Edit: looking at other posts, I might run into similar issues to another recent problem (no linked child race) later on, but those solutions are known. As a last resort, I'll just modify the custom races to mirror Caucasian on the male settings while fixing the other issues - but its a lot more work than a working patch to prevent MatchRace on non-vanilla player races should be.

Edit 2: It was indeed a conflict with TaleOfTwoWaselands.esm - specifically my mod was reverting the changes to the GC01 script. Accounting for the TTW changes in the master files before making the changes would indeed be the solution if I had kept this approach (and still is the solution with my less-intrusive approach)

[iSharingan]

So I actually found a workaround that makes the lack of child race irrelevant and properly prevents issuing Matchrace on the MGDad and vault 106 Dad references (the CG0XDad actors are made irrelevant). Basically, I use the JIP LN function "SetIsPlayable" to disable the 'unsafe' playable races until either the GOAT is finished (CG03 is complete - the standard 'Chargen Complete' check in official FO3 content) or the New Vegas intro cutscene (VCG00 - the cutscene where Benny robs the Courier) is complete (the New Vegas chargen doesn't issue a MatchRace even with TTW). By doing it this way, I only needed to edit the Vault101ExitScript script (to prevent the final Matchrace if a global variable is True) and the TTW-specific patch script "TTWVault106DadRaceFixScript" (a sanity check in case the player started in New Vegas instead of FO3).

This means the races I marked as problematic will be disabled for the initial FO3 chargen, but can be selected at the prompt to leave Vault 101 or in the FONV chargen and there will be no need to add a child race for NV race mod compatibility in TTW

This means with some light tweaking, I can most likely convert this workaround into a core mod to check if the player is an 'unsafe race' found in a form list (empty in the core mod) and prevent the Matchrace execution if a match is found (using a form list as a conditional will check against every entry in the list) - and anyone with a problematic custom race they want to use can simply make a compatibility mod merely that adds the race(s) in question to the form list via a separate quest/script and the 'AddFormToFormList' command (mod dependency would be my core mod and the custom race you intend to patch - effectively making 'compatibility plugins' for use with the core mod and that will won't conflict with each other). I'll edit in the Nexus Link when I post it.

[IAreBob]

In regards to the 'no need for child race', it looks like you're forgetting about the Tranquility Lane sequence. You're reverted to a child in the simulation.

-IAreBob

[RoyBatty]

Yeah, this isn't a good idea.

You do what you like in your own game, and maybe make a post for people who just HAVE to have some different race. But I'll put any such mod on the incompatible list regardless, we have enough headaches.

[iSharingan]

it looks like you're forgetting about the Tranquility Lane sequence

Indeed I was (I had ruled it out up until now as there were no MatchRace calls). I'll look into how the game handles that segment again and see what I can work out. Off the top of my head, I remember later games like Skyrim being able to spawn duplicate instances of Player as NPCs and you could reference the spawned instance to revert changes to the 00000014 instance - albeit with very limited utility. A proper solution will definitely take time - as this is barely in a practical stage and heavy on theory. I wasn't going to release the mod structure until I had play-tested the quests that mess with the player's age/appearance.

I understand the concern, but I have no intention of giving you all headaches. I never even considered outsourcing support for anything I write. My problems are mine alone - but outside perspectives do help avert some of them. At the end of the day, if it won't work it won't work. I'm not going to try to bend the elements to my will.

All that said, I do appreciate all the work that's gone into TTW. If I do end up perfecting and releasing this, it would only be to make the experience more enjoyable.

[RoyBatty]

You don't have to worry about the End Sequence anymore either, in 3.3 I've fixed it so it won't lock up anymore ever. It was also breaking in vanilla under certain circumstances so I rewrote the whole the script.

[iSharingan]

You don't have to worry about the End Sequence anymore either, in 3.3 I've fixed it so it won't lock up anymore ever. It was also breaking in vanilla under certain circumstances so I rewrote the whole the script.

I think I actually encountered that vanilla freeze few times back in the day. If I did release anything, it'd be after 3.3 is out - especially so I can properly apply my changes to the few scripts I'm editing after they're updated.

In any case, I've been manually tracking the few edits I've needed to make. Minus the 'fix' for Tranquility Lane that hasn't materialized, so far its actually quite unintrusive. Very little code insertion is needed on existing resources (literally 3 conditionals added to 2 different scripts - and can be swapped to 1 quest and 1 script - and those are already modified by TaleOfTwoWastelands.esm) and only a few newly added resources are needed to manage it. If my latest theoretical approach ends up holding water, (and a suggested solution on the bethsoft listing for AgeRace says indicates it should) it should be possible to entirely write out AgeRace calls that restore the player to adulthood (and thus remove the command's biggest side effects from the game entirely) by using an extra NPC.

All that said, I do understand the skepticism voiced here. A new user pops up and immediately starts talking like someone who has been active here for years. 99% of the time such users turn out to be complete novices when it comes to the subject at hand.

[RoyBatty]

It's not that, it's just everyone's tried and failed many times.

You can remove the agerace, but you'll be an adult in TQL which upsets how the game works. But if you are fine with that, it's up to you.

F3/NV is neither Oblivion nor Skyrim, so nothing there applies except very basic things. I've seen mods which use a proxy NPC but only in 3rd person.

[iSharingan]

Yes, I was a bit hasty in my wording (and the way I worded it would indeed be very awkward). The failsafe concept is 99% the same, but combines the concepts I've seen in follower mods with FO3's own Matchrace scripting for making the Dad actors resemble the player.

Ideally, a mere [quest] script variable will suffice to track the player's adult race (making the below completely irrelevant) through "let rRace := player.GetRace" and issuing "SetRace player rRace" after Agerace [incorrectly] reverts them to adulthood - or to replace the AgeRace call entirely in cases where the player returns to adulthood. Updating the variable (GetRace) under "begin menumode 1036" should keep the variable up-to-date even if the player calls "srm" via console at some other time in gameplay. If this doesnt work in practice, I have a more complicated 'failsafe" I have successfully applied when helping a user resolve a bug in a New Vegas mod. The specific mod both added several followers with custom races and allowed the player to play as some of those custom races (excluding the corresponding follower as an option if you picked one of their races to play as). Different assumptions are necessary to apply the same concept here (as the followers aren't going to exist to double as a control entity), but my "failsafe" method's logic is thus:

1: There are already objects handled as control objects (like the radio controllers that are enabled/disabled as you exit/enter DLC or other special quest areas)
2a: The player is used as a source of information to set info on the Dad actors, so (2b)
2b: this process (2a) should be reverse-applicable to the player from another NPC reference
3: I've seen issues in some cases with applying changes to references that are deactivated or are activated but are in unloaded cells - though that may be only by referencing ref id and not base id. Usually such issues were in regards to accessing a reference's inventory, but there may be other calls that are affected.
4: If 3 is a concern, the space used to keep entities control entities (1) should be an acceptable location for a control NPC's reference (2b) - though if 3 is irrelevant, 1 can also be disregarded.
5: the specific process would be Matchracing and matching face date to the control NPC from the player (2b) in menumode 1036 (racesex/the full character editor) just like in CG00 stage 65 (2a)
6: when AgeRace is called to revert the player to adulthood, insert a second call to matchrace/copy face data back from the control NPC (prepared under 5) to correctly revert the player. In cases where the player is already a vanilla cace, this would do absolutely nothing, but if a custom race is involved it gets properly re-applied to the player

To restate: a more accurate description of the concept is making AgeRace irrelevant when returning the player to adulthood, as the original adult race would be restored from a separate 'storage' variable/NPC. If a "Proxy NPC" is required - its only as data storage and changes to the player are only called at the same moment AgeRace would have updated how the character looks, anyway.

EDIT: So it appears my source about AgeRace was incorrect. Player.AgeRace -1 does nothing if there is no younger race configured (likewise with AgeRace 1 and no older race). This makes things so much simpler - though the method doesn't change. Only the sanity checks do (I'll even go the extra step and simulate being a child if there is none).