Jump to content

Modular support for companions?


MistahIncognito

Recommended Posts

I was sitting around just being my usual absurd self when I started wondering about G.E.C.K. and Sexout in-general. Which of course led to the issue of how various mods have minor support for companions either inside or out of the base system. And any companions supported have to be explicitly so.

 

Disclaimer: Not asking for this to be implemented by anyone. It is mostly a thought experiment and at best an idea for a future mod or implementation to an existing mod.

 

So, my question is: Would it be possible to dynamically handle non-core (New Vegas native) companions through say... a formlist. I know we hold formIDs of certain creatures and equipment. Since companions are unique, could we have a (common?) formlist for Companions to be added to.

 

As for utilization, it is my understanding that scripts are instanced to their attached objects. So in theory it'd be possible to utilize generic scripts to take advantage of the companions listed in the formlist. Through clever, okay simple, usage of loops the mod would be able to grasp onto their necessary companions and go from there.

 

The idea is so that the numerous legions of companion mods that exist could be supported without the need to hard code them all. Of course I could be entirely off base with my musings. But as said in the start, it's mostly a thought experiment. Which may or may not be code for don't think of me as an idiot for proposing the query.

Link to comment

Not going to happen due to companions being scripted differently. There's no universal way to control non-vanilla companions.

 

The idea isn't so much for a universal way to control in the sense of NCCS framework. The idea was sexout calls in mods in particular. While the beasts of burden are all scripted differently' date=' in the sense they are still the same. Simply actors to have calls applied to them.

 

The idea is instead of "If this companion then do this" and instead move towards a more generic approach that way if you had non-vanilla companions you wouldn't need explicit support for them in various mod's calls. I know SCR added some support of their own for Kirina and Jentai, but that's still not quite exactly what I had in mind.

 

What I'm referring to would be essentially an array of active companions. Or in this case, a formlist populated with active companion references that can be accessed and re-cast on local references for utilization within scripts without having to explicitly say "If you have sunny then have her do act." or "If you have [insert companion here'] then have him/her do that act."

 

And further, I feel I have to clarify. This isn't a request for anyone to do. It's simply a big of banter on the possibility and feasibility of this. I'm still learning the limitations of the engine as far as modding goes so these sort of questions help build that sandbox.

Link to comment

Well it's certainly possible to have a quest running a script on gameload/gamerestart that has a huge chunk of if-endifs containing IsModLoaded checks that then GetModIndex/BuildRef's reference variables to place in an SCR "Companion List" or a list residing in a controller plugin that contains the "scenes" you want those companions to play out. Then you would create some top-level topics that had responses using IsInList conditions for that list ran on Subject.

 

With that said, custom plugins generally can focus more specifically on the quirks and unique aspects of individual companions better than a generic handler... though having a generic handler for common sorts of scenes like "follow me over to the bed" or "come join me in the booth" or even "go seduce that NPC" would likely be useful. this could easily be handled by a collection of scripted AI packages that would run in order based on a state manager quest, each scripted package having as the end result script a call to the next scripted AI package so that you're managing their current AI specifically throughout the entire process overriding their default behavior.

 

But that's just off the top of my head... I'm sure implementation would be a bit less trivial than that hehe ;)

Link to comment
The idea isn't so much for a universal way to control in the sense of NCCS framework. The idea was sexout calls in mods in particular. While the beasts of burden are all scripted differently' date=' in the sense they are still the same. Simply actors to have calls applied to them.

 

The idea is instead of "If this companion then do this" and instead move towards a more generic approach that way if you had non-vanilla companions you wouldn't need explicit support for them in various mod's calls. I know SCR added some support of their own for Kirina and Jentai, but that's still not quite exactly what I had in mind.

 

What I'm referring to would be essentially an array of active companions. Or in this case, a formlist populated with active companion references that can be accessed and re-cast on local references for utilization within scripts without having to explicitly say "If you have sunny then have her do act." or "If you have [insert companion here'] then have him/her do that act."

 

And further, I feel I have to clarify. This isn't a request for anyone to do. It's simply a big of banter on the possibility and feasibility of this. I'm still learning the limitations of the engine as far as modding goes so these sort of questions help build that sandbox.

 

SCR currently has 2 formlists, SexoutSDataPossibleCompanions which has all the vanilla companions, Sunny & Jentai. Some others in it like Willow & Kirina are added if they are loaded.

Also SexoutSDataCurrent companions has any of those added if they pass a PlayerTeammate check :)

Link to comment

Archived

This topic is now archived and is closed to further replies.

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue. For more information, see our Privacy Policy & Terms of Use