FO3, NV & TTW Companion Resources Ref & Races List

[nyaalich]

Lol.  Did you even play FO3, Hal?  ; )

 

Don't have time to open the GECK atm, but yes, there are other companions.

 

Cross is a woman.

 

List is missing

• Fawkes (super mutant)
• Charon (ghoul)
• Jericho (human male)

If you need their base ID, you can probably get it from the wiki(a).

[Halstrom]

Lol.  Did you even play FO3, Hal?  ; )

 

Don't have time to open the GECK atm, but yes, there are other companions.

 

Cross is a woman.

 

List is missing

• Fawkes (super mutant)
• Charon (ghoul)
• Jericho (human male)

If you need their base ID, you can probably get it from the wiki(a).

Yeah, thanks for the info, I last played FO3 probably around 5 years ago  

[A.J.]

Once I've built the ref of the optional companion, should I use Compiler Override if I want to play with its variables ?

 

i.e.

Begin Gamemode
if (IsModLoaded "NVWillow.esp")
    Let iHasWillow := GetModIndex"NVWillow.esp"
    Let rZWillow := BuildRef iHasWillow 32353
endif
.
.
.
Begin _Gamemode
   if rZWillow
     if (rZWillow.GetType == 42)
        Set rZWillow.IsHired := 1         ; just to make an example
     endif
   endif
end

[Halstrom]

 

Once I've built the ref of the optional companion, should I use Compiler Override if I want to play with its variables ?

 

i.e.

Begin Gamemode
if (IsModLoaded "NVWillow.esp")
    Let iHasWillow := GetModIndex"NVWillow.esp"
    Let rZWillow := BuildRef iHasWillow 32353
endif
.
.
.
Begin _Gamemode
   if rZWillow
     if (rZWillow.GetType == 42)
        Set rZWillow.IsHired := 1         ; just to make an example
     endif
   endif
end

 

Hmm I would assume if you want to muck around with Willows variables you'd have to make Willow a master of your mod. I have no idea what Compiler Override is

 

[nyaalich]

@Hal:  The More You Know!  (last section in the OP)

[A.J.]

I THINK there's two ways to mock with them without making willow master, which is my goal. One is CO and one is a function in a plugin, but I still never used both and I'm trying to figure what's the best approach

[prideslayer]

The override doesn't (I think) help you with that. It's there so that you can use evals as the RHS (right hand side) of an assignment in places where the vanilla compiler doesn't allow it.

 

As Doc put in his example, if you have an array with a float in it, without CO you can't do "let foo := call getFooValue". It doesn't matter where getFooValue (a UDF) is, in your mod or another one -- the vanilla compiler won't compile the script because 'call' can return anything, but the 'let' in that case requires a float (or int, or whatever type 'foo' is).

 

What you can do, I think, is use GetRefVariable if you have the willow (or whatever ref) and know the variable name. I haven't actually tried it, but it's there in NVSE. Looking at the source (I don't have the latest), it might only work on quests, not on any old reference.

[A.J.]

If CO doesn't work in that case, I assume the only way is SetVariableFloat from Lutana plugin then. So if someone's interested in that and you missed that function you can give a look. He speaks about scripts on REF or quests, so maybe it could be used to set a Willow.IsHired var. Need to try one of these days.

[prideslayer]

If he's doing it in an NVSE plugin, then that means it's possible for NVSE to do it itself -- maybe it already can. If not, you can:

 

- Just use it, make it a requirement for your mod. Ask him to add other var types as well (ref, int).

- Give me some time and I can put all that in NX so everyone doesn't need another plugin.

- Ask jaam to put it and the other functions in NVSE.

[DoctaSax]

The override doesn't (I think) help you with that. It's there so that you can use evals as the RHS (right hand side) of an assignment in places where the vanilla compiler doesn't allow it.

 

As Doc put in his example, if you have an array with a float in it, without CO you can't do "let foo := call getFooValue". It doesn't matter where getFooValue (a UDF) is, in your mod or another one -- the vanilla compiler won't compile the script because 'call' can return anything, but the 'let' in that case requires a float (or int, or whatever type 'foo' is).

Yeah, the CO is mostly there to override the compiler crapping out on you because vanilla & old nvse functions are expected to be used with a specific type of parameter, eg math functions are expected to work with numbers, not "some array element" or "some UDF return".

"Let", "if eval" and "while" themselves though are usually hip to the new nvse stuff and wouldn't need the CO. Eg let fSomeFloat := somearray[somekey] or let rSomeRef := call someUDF are perfectly fine without.

 

Edit:

What you can do, I think, is use GetRefVariable if you have the willow (or whatever ref) and know the variable name. I haven't actually tried it, but it's there in NVSE. Looking at the source (I don't have the latest), it might only work on quests, not on any old reference.

 

I think the function to use there is GetVariable. GetRefVariable is similar but for ref vars. Haven't tried any of those either - I'm guessing that the difference with GetScriptVariable is that GetVariable can also be used on a quest.

[A.J.]

well my concern is Set more than Get. Well, I surely Get before I Set, but yes let's take for example forcing custom npcs do wait for you or fire them, I guess that's the most interesting thing. Think to a mod where you suddenly are enslaved and stripped of all your weapons just to find Willow, Niner or whoever jailed with you with the backpack full of useful things.

 

I don't really know how a NVSE plugin works, if it's like another esm or it's a file to drop in a folder, if I can redistribute etc... but I know I really would like to have less dependencies possible. Because I already created a new ESM which will be necessary to run my future works, if I even put another requirement the installation will be quite a pain...

 

if I remember well, you gave the possibility to put NX inside a mod, is it right Prideslayer? if it's so, it would be sweet if you could put Set inside. Of course I never forget to credit, if it's the only necessary thing to include a NVSE plugin. But yes I personally see the possibility to set values very useful, it would avoid to make thousand patches

[prideslayer]

NX is an NVSE plugin, so is that thing you linked to. There's one that comes with MCM and one with PN as well. You can't redistribute them unless the author says so. Just plopping them in a directory works, but your users need them too for your scripts to work.

 

You can do whatever you want with NX, but that doesn't help you. Everyone already has NX, it's required for sexout -- however, NX itself doesn't have that get/set functionality. Not yet anyway.

 

I understand slightly what you're trying to do, like check and see if willow is hired, but beyond simple things like that it's really a bad idea to try peeking in other mods private vars and an even worse idea to set them yourself.

 

What exactly are you trying to do that makes you think you need to do that?

[Halstrom]

Yeah, got to be careful pulling stuff from other plugins, I just noticed that the latest release of WIllow had changed JT's REF which I have SCR adding to the dog lists, I am working on a separate plugin now called SexoutCommonExtras to move 3rd party stuff into so if this happens again SCR is still stable and SCE can be deactivated.

[A.J.]

naaa don't worry, it's not that big damage. Of course first I'll study the scripts to see what it could happen, but... if I must be true, custom companions usually follow the same ol' vanilla-copy-paste-script rules, so I really feel I won't find big issues in that

[prideslayer]

The bigger issue comes up if there are other scripts doing 'stuff' depending on those vars, and expecting them not to change out from under them. Or, if the author inserts a new var into the script before the one you're using, you'll end up accessing a different one than you mean to unless you recompile your script.

 

I blew up everyone when I did this once in an early sexoutNG release because I didn't know better.

 

If there are vars like

int varA

int varB

int varC

 

and you're going after VarB.. if the author changes the list in their script to

int somethingNew

int varA

int varB

int varC

 

You're going to end up getting B and not C. They're indexed by number at runtime, not actually by name, so your script that says "someref.varC" is actually saying "someref.<third var>".

[A.J.]

that's the kind of things I'll check on their mod, like if there's a gamemode external script influencing the current values you usually set by wheel / dialogue under certain conditions, but yes generally these things are not done on a custom follower companion, they're not that different from vanilla basic functions.

 

But I didn't get the last part, that last sentence really sounded strange for me. I can't think to a practical example to reproduce a issue like that. My script runs under a certain event, and often in a custom cell. I really can't see how introducing new variables on willow.esm could affect how my script handles them, or at least I think a clean save (without my mod) after updating willow should solve that, shouldn't it?

[Halstrom]

The good news is I just checked the FO3 FormID numbers with Tale Of Two Wastelands and they haven't changed REFs, I had considered that was a possibility that they were different, not knowing how it worked but it's all good

 

I added Fawkes, Charon & Jericho to the OP and fixed Star Paladin Cross's REF, I screwed the decimal conversion by one

 

If anyone wants any FO3 DLC companions added, list them here with their REF ID's from in worldspace not their base REFs, I don't remember which NPC's in the DLC's are companions.

[Nessa]

Alright, if I'm understanding this correctly, we need the Reference ID of the companion wherever they are placed in the world. Meaning in a cell or in a worldspace. We then ignore the first two hex numbers. Then we convert to decimal, yes?

 

In that case:

• Brisa Almodavar: RefID: 0D005297 --> 5297--> 21143
  "RHKBrisaAlmodovar.esm"
• Delilah: RefID: 01000AE1 --> AE1 --> 2785
  "delilah.esp"

In the case of existing NPCs like Bittercup (or at least in my version of the companion) I haven't been using BuildRef. I've just been using her Refrence Editor ID (BittercupREF) and it works fine so far. Are there some pitfalls I'm unaware of?

[Guest tomm434]

 

In the case of existing NPCs like Bittercup (or at least in my version of the companion) I haven't been using BuildRef. I've just been using her Refrence Editor ID (BittercupREF) and it works fine so far. Are there some pitfalls I'm unaware of?

 

BIttercup is a simple reference so it will work.

Your mod is dependant on TTW ----> TTW has Bittercup -----> You use Bittercup --------> ???? --------> Profit!

[Halstrom]

Yeah you need to use the inworldspace ID from Render window not the base ID.

[DoctaSax]

In the case of existing NPCs like Bittercup (or at least in my version of the companion) I haven't been using BuildRef. I've just been using her Refrence Editor ID (BittercupREF) and it works fine so far. Are there some pitfalls I'm unaware of?

 

Mostly buildref is used to be able to refer to forms (in this case NPCs) that may or may not be in the game, depending on LO. In your case Bittercup is, so no need to use it. Mods like mine or Halstrom's can't make themselves dependent on too many other mods, so we do use it.

[Nessa]

Oh right, the esp's would help just a TAD! I updated my initial post to include those too!

[Halstrom]

Alright, if I'm understanding this correctly, we need the Reference ID of the companion wherever they are placed in the world. Meaning in a cell or in a worldspace. We then ignore the first two hex numbers. Then we convert to decimal, yes?

 

In that case:

• Brisa Almodavar: RefID: 0D005297 --> 5297--> 21143

  "RHKBrisaAlmodovar.esm"

• Delilah: RefID: 01000AE1 --> AE1 --> 2785

  "delilah.esp"

In the case of existing NPCs like Bittercup (or at least in my version of the companion) I haven't been using BuildRef. I've just been using her Refrence Editor ID (BittercupREF) and it works fine so far. Are there some pitfalls I'm unaware of?

 

There's no custom races for these I assume and if so what vanilla race should they be treated as?

[Loogie]

Both Brisa and Delihla are both custom races.  Brisa should be considered hispanic and Delihla is white.

[Halstrom]

Both Brisa and Delihla are both custom races.  Brisa should be considered hispanic and Delihla is white.

Ah well I also need the BuildREF ID of those races so they can be added to the relevant race formlists for Pregnancy to be treated correctly assuming there's only one race for each not like Wendy Gilbert which had a dozen NPC/Race variations.