Hello. This is an idea I've been kickin' around, but not really qualified or motivated to implement. Regardless, perhaps the Tarrant's or the TalkieTheToaster's of the world will find it interesting. Also, it may be more appropriate to develop it for FO:NV at this stage.

Basically, I've been really frustrated by the entire way that companions work from a modding perspective. There are tons of mods that change the way the vanilla followers work. There are others that alter vanilla companions and add other companions (i.e. Phalanx). There's the mods that add totally new followers, often with lots of fancy new features. There are others that allow you to recruit/hire random existing NPC's (i.e. companion share + recruit, sharing and caring companions, etc...).

What there isn't is a centralized mod standard/resrouce (ala CRAFT) that contains a consistent set of improved companion behaviors, balancing, and commands (and a way to communicate) that other mods could develop content for.

To illustrate:
Right now, with FWE's followers enhanced I have essential companions that I talk to with my "command headset" and require stimpaks and so on to heal. I can also only have X number of them at a time based on my charisma. But i can also have a bunch of robot followrers via Robco certified that I use a different tool to communicate with, have a totally different set of command/order options. Lastly, I have some other companions that don't work at all in same way. Agggh!!!

So, if this 'companion standard' could do the following, it would be sweet:

• Have a unified for system for controlling how many companions you can have, based on karma or other parameters, that apply to everyone, whether they be a full fledged companion, some random NPC you press-ganged into your service, or your latest baby deathclaw animal friend.
  
• Have a common/unified set of combat related commands (hold position, combat ranges, wait orders, etc...) with a centralized method for communication.
  
• Have a common/shared set of upkeep requirements. For example, can be they essential, do they need reviving? Do they need stimpaks/medical equipment to heal? Do they heal instantly on rest or based on time spent sleeping? Having this be standardized would be awesome.
  
• Common/shared framework for companions to perform special tasks based on their skills (i.e. pick locks for you, hack terminals, etc...)
  
• Consistent system for companions to gain experience and/or level up.
  
• Other ideas?

I'm not suggesting that 3rd party companions can't ALSO have unique extra skills (i.e. companion "X" likes to also give haircuts) . . . but at a minimum standardizing the above would be sweet.

EDIT: From an implementation standpoint, using FormLists is an effective method in conjunction with merged patches for extending features onto other subjects. I.E, a formlist for all companions that can repair is setup, and those dialogue choices show up if the companion you're talking to is in the formlist., etcc....

Any takers? Any other ideas? Let's kick the can around a little.

Well, NV has a standard command wheel thing which I'm assuming will be accessible to custom companions...

One thing I thought of though, as I played Dragon Age...



It'd be awesome for a HUD with companion health bars.

---|--- Dogmeat
-----|- Jericho

Etc...


As for the above... I don't see why Charisma should count for a Robco Certified bot, for example. Some companions would lend themselves to a different parameter..

I believe the next version of Darn's UI was supposed to allow for follower health displays, but I have no idea about his progress. He even showed some screenshots of those.

As for a standardised follower setup, I've also been thinking of how to implement such a thing. I've attempted to create a personal mod that partially integrates the Sydney Follower mod into FWE Followers Enhanced, but all I did was alter the AI script; I quickly realised that the command headset script was too long and complex to touch. I ended up just pasting the script, and altering the 'Sydney Radio' item to add commands. The commands themselves are simple, but the length comes from the numerous individual checks for every vanilla follower, so there is a ton of duplication.

The optimum way to do the headset, I think, would be to draw from the player's Hired list, if such a thing can be accessed. Perhaps splitting the command headset and scripts for each individual follower could work, with checks for custom followers. I believe you did something like that for the integrated MMM and follower's enhanced menus in your FWE menu, Mez. That would best solve the command headset part of a companion standard. There'd still be a ton of duplication, though. I hope that NV's command wheel would render that all moot.

This was something I'd kind of planned to attempt in NV. We've seen before that attempts to organise large community projects often just go too slowly, so I was planning to sneak Companion Core into everyone's load orders by releasing a non-FOSE version as soon as NV came out with companion kills rewarding full XP functionality in, something everybody seems to want. Then when it's everywhere by default, when FOSE:NV comes out expand it to include the "Lists of followers" stuff. Core's set up in a very cross-compatible way; each mod using it can set up its own follow criteria, own combat start/end behaviour and so on.

Having standardised recruitment caps for everyone, standardising essential-ness and so on isn't really a good idea as some companions will want to be nonessential even if all the others are (e.g. robco robots), some won't want to contribute to the cap or will want their own alternate cap system. The way Core is set up, though, it's quite easy to make a standard but flexible system.
Basically there's a registry of factions linked to a list of 'function collections'. You put someone in a certain faction, then when they're ordered to follow/wait/combat starts/they die/whatever the mod looks in the linked 'function collection' for the appropriate function (e.g. "Wait") and uses it (in this case "Wait" might alter mod-specific things like the mod's own companion counter). That lets you have a bunch of standardised functions (and dialogue) in Core, which people can use if they want by putting their companion in the "Default Faction", or lets them assemble their own set of restrictions and behaviours whilst still sharing the rest of the mods features (like group healing, orders etc.).

The problems are you pay for that flexibility in the amount of understanding needed to use the system- it uses lots of flag items to denote who can do what and other attributes (e.g. lockpick, heal, this follower has no ranged attacks, this follower is healed by repairmen) and the functions list runs off of activator functions, which aren't very well known or used. So... it's not difficult to use if you've got a tutorial, but it's perhaps difficult to understand what you're doing. Which might prove problematic for new modders.

E: Oh the other problem is I come across as a dike for essentially attempting to hijack companion mods, which is a bit unfortunate.

Thanks for the reply.

I totally agree that different 'sets' of companions would likely be required, having for example different parameters controlling how they are hired, how many you have, etc... (i.e. human followers might be based on Charisma, robots on something else, etc...). All I'm advocating for is that the system is centralized and standardized in a way that people can understand it and add onto it easily.
A lot of FWE's newer features like stealth fields reworked, curtsey of schlangster, are setup using a formlist method. Granted, this relies on FOSE, but it allows you to have a core feature/mechanic that other modules can plug into simply by adding the relevant records to an override of the formlist, and then updating your merged patch.

For example, the “command” script could reference a formlist of all potential followers and check whether they were hired or not. This list would initially include all the vanilla companions, but it would also include all your 3rd party companions (harkness, bittercup, syndey, etc. etc…).

Likewise, a series of top-level dialogue choices + attached functionality could be developed, which modders could quickly attach to custom companions to replicate a feature or option (i.e. hack a terminal, repair my stuff, etc…).

The last piece would be to have a generic companion script that’s attached to companions (or even just a global script that again uses a formlist to search for valid companions) that controls their healing an so on.

Anyway, I think CSR does a lot of what I’m trying to get at. The piece that seems to be missing from it is changes to vanilla followers for consistency and adding a little more depth to generic companion behavior (i.e., I’d love it if CSR hired NPC’s used the same healing and drug use mechanics as FWE). I need to play around with it a little more.

EDIT: Any chance of doing another optional file that alters the vanilla followers to use the CSR system in place of all their usual commands? Obviously the hiring part should still remain unique, but the other options could probably be switched to use CSR?

Formlists are more friendly to compatibility.. just add to a formlist, but FOSE may end up being required depending which formlist functions you need, and I can see where Toaster is coming from... it takes a big push for a library mod to get a big install base, and part of that is not needing FOSE, at least at first (not everyone will use it, but also it won't probably be available for a ltitle bit, I would guess). The other thing needed is for highly desirable mods to depend on it. Here though, Toaster already has that covered... Robco/whisperer/CSR will use it.

I think it can get a good adoption rate if you can get it out ASAP.

But you you have a point... it needs to be easy enough for modders to hook into. Maybe have some documentation ready to roll


On a sort of selfish side note, Dogmeat Leather Armor would be easier to hook into stuff if mods used a ref variable for him so that when DLA switches him out, the variable can point to the right dog

I don't want to de-rail this into into an FOSE debate . . . but something to consider is this: who is your audience when it comes to FOSE?

If you really want a given mod to be used by anyone and everyone, avoiding FOSE makes some sense. But at the same time, if your compromising the implementation of a feature, and/or crippling cross-compatiblity potential by not using FOSE, that's going to cut into "attractiveness" the mod as well. Certainly if there is a way to implement a given feature without FOSE, that's cool, but it seems like most of the time it can compromise implementation for no real gain.

I don't know, they should just bundle FOSE with FOMM and be done with it. But then again, I never understood the obsession with achievements, particularly in a single player game.

If you want all the achivements for the PC Fallout 3, incert a console command to give them all, there you go, you win, now you can start playing with FOSE without worrying about achivements!!

Too lazy for the console command, I'm sure I've seen a couple give all achivement mods on Nexus!

I really don't know the first thing about companions, neither did I ever recruit one nor have I ever looked at a mod that does improve them.

That being said, here's how I image a flexible companion framework could look like:

https://docs.google.com/drawings/edit?id=1FEUIVWK7G5Bw6OKxwcH-SGdo0qIlyCn19T1SHM8GbhA&hl=en&authkey=CNP7h74K

Edit:
Ok, heres a better explanation then...

The main challenge this framework addresses is that, other mods shall be able to extend it, without causing conflicts between each other and with as little limitations as possible.
It's event-based, and an event can be something like "Received Follow Command", "Received Stay Command", "Received Heal Self Command" etc. Every event has its own event queue (a formlist), which contains all companions who have received it.

Companions are added to an event queue in two ways:
1. Explicitly with a "companion remote control" or sth alike, where the player selects "Companion X, hold position", so the remote control script adds X to the HoldPositionEventQueue.
2. By a monitor token, which is attached to a companion and monitors its state. For example a monitor token could watch the companions health, and if its below 10%, add its parent to the HealSelfQueue.

The question now: Why not just initiate the actions directly instead of using these queues?
Answer: Because actions may cancel each other out, or generally be in conflict. Also, some command may result in different actions for different types of companions, and other mods should be able to plug their own behaviour to these generic events.

So we have queues which contain all companions who received a respective event. What happens next, is that every queue has its event dispatcher. These dispatchers are registered by adding themselves to a formlist. So to add a new event, a mod would have to have its own queue formlist, and a dispatcher which added itself to the dispatcher formlist. Every dispatcher has to implement a stage function at index 1, which processes elements in the queue (this includes removing them). Every t seconds, a global scheduler walks through the dispatcher formlist and calls stage function 1 for each of them. Whether a dispatcher will process the complete queue at once, or only one element at a time doesnt really matter.

An event dispatcher processes a companion that was added to its queue in the follow way: It has a list of event handlers (again, same principle as the dispatcher formlist) for this specific type of event, all of them implement a stage function at a common index. The dispatcher has a reference of the current companion, so the event handlers can access it and run checks on it. Also, the dispatcher contains shared state so the event handlers can synchronize.

Why multiple event handlers? Because an event handler will not necessary process every companion. There might be one for robots, which will initiate self-repair if they are low on health, and one for humans to make them use a stimpak. Once a handler accepted the current companion, it could set a flag in the dispatcher, to signal that further processing is not necessary, because the next action has already been decided.

The event handlers themselves then will do whatever is appropriate.

So... its possible to add new types of events without having to change anything, while still being able to reuse existing event handlers, and its possible to add new event handlers which provide behaviour for specific companions. Whats left open yet is how to prioritize handlers, if thats even necessary.

One problem with this model is that its not possible to pass additional parameters to a dispatcher for a specific companion added to the queue. One might consider using async. notification for the dispatchers, so once something was added to their queue, and any input variables have been set, their stage function is called directly instead of by the scheduler. This would require enqueueing and calling setStage to be atomic.

That would get a bit unwieldy and wouldn't allow for mods that add new companions on the fly (e.g. RobCo, CSR, WW). The way Core handles things is to have a bunch of different lists for each 'status' (following, waiting, deployed) and add/remove NPCs from the lists as required. Then you can easily issue a group follow order by just going through the wait list and applying packages then moving the NPCs to the follow list. Then the follow list is relatively short and tidy, so you can scroll through it every second or so to check health, make sure they're folllowing right and the like without needing to put scripts on the individual companions- CSR only uses a script per companion to track ammo use, and RobCo's scripts on robots are mostly there to handle levelling up- if I added a Level Up trigger (like the Start Combat, Follow etc. triggers already in) to Core, then it'd more or less totally remove the need for scripts on the individual NPCs.
I don't really want to step on Tarrant's toes, so I've decided not to make the regular companions depend on Companion Core as it'd conflict with Phalanx something awful.
It'd be more than possible to switch CSR-recruited NPCs to heal in the FWE-style, currently healing for them is handled by their "Combat End" function, so it'd be easy to change. I tend to prefer low-micro companions so it's currently just 'stimpak to heal crippled limbs'.
Basically the flow goes

[1]Companion Core detects combat ends
[2]Core looks up the Combat End function for the CSR NPCs
[3]CSR Combat End runs, heals/handles cripple chance
[4]CSR now handles healing crippled limbs etc.

So the actual healing bit doesn't need to be part of Core; individual mods can use Core to manage their own systems. A few 'default' setups in Core wouldn't hurt, though.


I'll try and get an 'example doc' written up and see how comprehensible you think it is.

Very cool thanks for your reply. I've been using Robco + Wasteland whisperer forever (including the newer version) and really like it. I grabbed CSR last night and played with that for a while, and also really like it. The system overall pretty much does what I'm advocating for, with two exceptions (which have already been discussed).

First: changing the healing/chem use system for CSR companions to work like FWE. I haven't looked at the CSR scripting, but your comments above point me in the right direction to look at it. Basically, FWE modifies the scripts on the vanilla companions so that they heal similarly to the player under the integrated triage mechanics. It works like so:
- When the follower's health drops below a certain threshhold (in combat below 25% I think), the script will have the NPC consume a stimpak to heal, this initiates a second check
- The stimpak check also checks body part condition. If they have broken limbs, the the NPC will also consume a medical brace to heal the limb, and/or surgical supplies (renamed surgical tubing) for broken head/torso. A single medical brace, if present, will heal all limbs, with a chance to "recover" the brace after a few minutes based on their medicine skill. Same with surgicial supplies.
- Follower's also use psycho, buffout, rad-x/radaway, and morphine, with similar checks setup for that.

How difficult would it be to inject this system into CSR as an optional file? I can look into doing a sort of CSR-FWE patch perhaps with a little guidance.

Second: retrofitting the existing companions to use the CSR mechanics in place of the vanilla dialogue and control choices (and FWE's command system for that matter as well). I appreciate not wanting to step on Tarrant's toes, he's done a lot of wonderful stuf. At the same time, Phalanx includes a lot of extras that for me kinda break the immersion of the experience. But his altered combat AI and behavior is really excellent. You guys need to join forces somehow

Regardless, how difficult would it be to create an override to change the dialogues and control options for the vanilla followers?

Cheers!

I was wondering if/when you'd pole your head in here

You're falling in love with the google drawning tools aren't you? Anyway, good idea, I look forward to further explanations.

We're already way beyond that

(And I've edited my previous post)

In the words of my avatar: "It . . . Could . . . Work ! ! !"

Although I have to admit I only followed about 50% of that. It's like reading a biology textbook explaining the http://en.wikipedia.org/wiki/Citric_acid_cycle. I'll give it another read

EDIT: I'm going to attempt to follow this by using an example. In this case, Compaion Self Healing and we have Nurse Grims and a Robo-Brain as followers.

Step 1
So, there is a Monitor Manager for "Companion Self Healing" which looks at Nurse Grimes + Robo-Brain and says, you should be allowed to self heal. They are in a FormList of allowed to self-heal followers that's part of the heal self monitor manager (i.e. HealSelfAllowedFormList), so the monitor manager gives them a "Self Healing Monitor Token."

Step 2
We fight some baby deathclaws and nurse Grimes and Robo-Brain are injured as the fighting continues. The self healing monitor says, 'oh my, you only have 25% life left' and adds Nurse Grimes and Robo-Brain to HealSelfQueue.

Step 3
Now, the HealSelfDispatcher is running/being processed (as a quest/script?) in the background as it is in the ActiveDispatcherFormList. The GlobalScheduler (another quest/script?) ticks over says, "HealSelfDispatcher, run your check through the HealSelfQueue and see who needs healing up".

Step 4
The HealSelfDispatcher sees both Nurse Grimes and Robo-Brain in the cue to self heal. It decides that Nurse Grimes needs to use the HealSelfFleshNBloodEventHandler (for living things of course) and that Robo-Brain needs to use the HealSelfGearsNGreaseEventHandler. These are each called/activated on their respective actors.

Step 5
The HealSelfFleshNBloodEventHandler goes off, and Nurse Grimes uses a stimpak to heal herself. The HealSelfGearsNGreaseEventHandler runs and Robo-Brain unplugs his old runny brain and installs a fresh one, healing him up. These event handlers remove Nurse Gimes and Robo-Brain from the HealSelfQueue.

Step 6
Now were back the default state. Nurse Grimes + Robo-Brain are healed. The scheduler keeps initiating the Dispatchers at period intervals, which see that it's que is empty, and resets (until such time that the followers get injured again).

Is that basically how it all works?

If so, it's pretty slick, because you can easily add new followers (i.e. custom followers) into the relevant FormLists depending on what features they should have/use, requiring very little effort. Basically, anyone with a basic knowledge of FO3Edit could expand the formlists to plug in custom followers.

Likewise, it's also easy to plug entirely new features into the system. You'd need to have the following:
1) FeautureXMonitorManager quest/script to add monitor tokens to followers.
2) FeatureXMonitorToken object/script to monitor conditions for processing
3) FeatureXDispatcher quest/script to be inialized by the global scheduler. In fact, you could merge the functionality of the dispatcher with the monitor manager right?
4) FeatureXEventHandler quest/script to execute the desired action. The scripting for the event handlers could be integrated right into the monitor token too right?

Heh, I also had to keep my mind primed to follow that. Thanks for the example.


I think the point is to atomize as much of the functionality as possible. If the MonitorManager, Dispatcher and EventHandler are merged, updates to either would need to edit the full script, which could yield trouble when making updates or customizations. Also, I seem to remember Tarrent being pretty cross with 1000 lines being the max script length. The MoniterManager could be a single quest script running in each frame. The dispatchers and eventhandlers could be a Function Activators called by the MonitorManager, so they would only consume resources when needed. Usage of Function Activators could also make it possible to send arguments to the EventHandler.

(Phalanx here)

* reads *

* cringes *

The more powerful commands and behaviors I made (for one) are highly scripted. And the .exe has problems dealing with what I'm doing, so I'm constantly watching for and correcting gamebreaking buglike-things as they occur. I can't think of a way to let a third party .esp which does not take my mod as a master work with with it in a powerful way.

The commands and behaviors I do generally need to be able to explicitly script for the REF names, which they cannot do if the NPC is in a different, unmastered .esp or .esm. TalkieToaster had done some work with this but, I know that its not possible to do it all, because some of the behaviors have the followers explicitly aware of one another's behaviors (aware in a virtual sense).

Maybe for simple functions you could pull it off, specifically and only, those which contain variables within the follower's REF object script. On Phalanx followers I've maintained the 'waiting' variable intact, as Bethesda did it. If all makers of followers used that structure for that 'waiting' variable within their REF scripts, it should technically be possible for a 3ed party mod to access the REF name via variable and manipulate that variable.

so for example if someone loads a 3rd party mod, and is able to detect that Phalanx' Malcolm is standing there (it identifies his REF using an area effect of some sort or maybe through a perk's entry point), it can then test his REF and see that he is a follower using getplayerteammate. It should then be possible for that .esp to store his REF ID as a variable somewhere, and, attempt to manipulate his waiting variable now and then.

but to manipulate complex behaviors, I don't wanna think about the nightmare sorta.

Right


The dispatcher is a quest with a stage function at index 1. Thats where everything it does is implemented, it doesnt have a normal questscript running in the backgorund (other than maybe to declare some variables used for state). The GlobalScheduler is a quest with a script that gets executed every t seconds in gameMode, and it iterates through all dispatchers in ActiveDispatcherFormList (= a form list containing the dispatcher quests) and calls setStage quest 1 on each of them.


The HealSelfDispatcher doesnt contain any decision logic since that would mean whenever you wanna add some new handler you'd also have to change the dispatcher. Instead, the dispatcher simply iterates through all handlers for this event.
The dispatcher somehow has to pass the currently referenced companion to the handler, preferable with a helper variable in some global quest (no concurrency issues since everything is executed sequentially). The handler itself will then decide, whether to accept the reference and do something with it, or leave it for another handler and just return (so HealSelfGearsNGreaseEventHandler will check for robots, and HealSelfFleshNBloodEventHandler for humans). Once a handler accepted a reference, it can tell the dispatcher (again, via helper variable), so it wont pass it on to more any other handlers.


Right, except that the dispatcher is in charge of removing the elements, since the handler itself probably doesnt even have to know from which dispatcher it was called, though im not sure if thats really necessary, i tried to think of a scenario where it would make sense for one handler to be called by different events, and i couldnt come up with any, mainly because the examples i picked for events are already pretty specific. For example, the HealthMonitor says "low on health -> heal yourself". "Low on health" could also be an event itself, so the monitor just adds a companion to the LowHealthQueue, and in the handler list for the LowHealthDispatcher are HealSelfGearsNGreaseEventHandler and HealSelfFleshNBloodEventHandler, which would be the same handlers that are also in the handler list of HealSelfDispatcher for the normal "heal yourself" dispatcher. The LowHealthDispatcher then could also contain an additional handler, which causes the companion to flee instead if you treated him badly before


Yes, overall thats how i imagined it.


The Dispatcher is more like a "function object", while the monitor manager has a different task. It would not be a good idea to merge them together, especially since theres not necessarily a 1:1 relation. Not all events require monitors (direct commands issued by the player for example).

Same issues as before. If you mean adding the action thats taken to the monitor, thus making all the dispatcher and stuff unnecessary, you COULD do that to create a much simpler system, yes. The problem, besides that this wouldn't be as easy to extend, is that each monitor acts more or less in isolation. It will notice a condition and execute the necessary steps itself, not knowing if there's any other monitor token active which tries to do the same.

You dont necessary have to create all of the mentioned entities if you wanna add something new.
For example:
You can create a new MonitorManager + a set of MonitorTokens to implement some new intelligence, but reuse existing events and handlers (= just use existing queues, no changes required)
You can create a new Event (=Dispatcher, EventQueue, HandlerList for the dispatcher) and a monitor that makes use of it. This event uses some existing handlers, but also defines some of its one which are exclusive to this event.
You can create your own handler and add it to an existing event dispatcher.

Edit:
Aaand.. since i mentioned this earlier with the flee on low health example, it would probably be a good idea if calling the event handlers by the dispatcher would happen in two phases to establish a priority:

So phase 1:

short priorityshort winnerFor every handler i=0...nset Helper.currentRef to queuedRef ; (companion reference for helper)setStage handler 0 ; (handler sets priority var, depending on priority or 0 if he rejects the ref)if Helper.priority > priority set priority to Helper.priority set winner to iendif

The handler with the highest priority value is selected, and in phase 2 gets executed with

set hand to listElementAtIndexBlah HandlerList winnersetStage hand 1

The handler and dispatcher stuff looks interesting and definitely powerful, although I think it might be a tad overengineered. For the most part, mods aren't going to want to add new handler-requiring events that need to be spread over all other companion mods. Things like the FWE drugs/healing are likely to be just wanted by the FWE-companion mod, so don't really need a way to integrate into the overall system.

Yeah, I've gotten around a lot of the "You need to add a package with a variable reference" things by sort-of-trickery and intermediaries- issuing packages using references defined in the esm which are then moved to the variable reference. It's a bit cludgy, but you can get around it.

I think that could be handled by just adding a scripted item to their inventory with that code on it when they're recruited and removing it when they're dismissed. Just adding AddItem/RemoveItem lines to the scripts for CompanionActivatorFollow and CompanionActivatorFriend would work.

The easiest way would just be to remove their scripts, and alter their dialogue so that when you would recruit them rather than setting whatever variables changed their packages, it just added the "Recruited" token to them. Ironically I wrote a tutorial for how to make mods dependent on CSR back in the Oblivion version, but didn't bother for Fallout as no-one used the Oblivion guide (they just emailed me to ask if they could include edited copies of CSR with their mod, ignoring the volume of script duplication you'd get). It'd probably be easier to make a "FWE Followers for Core" mod based off CSR though- CSR is pretty light as a mod, it mostly provides hooks to features from Core. I can build a basic frame and send it to you no problem, I've just got to finish bugtesting the new RobCo.

I tried writing up the sort of tutorial I'd package with the NV core... it's aimed a couple of notches below the modders ITT, but shouldn't be too offensively hand-holdy. It's also working on the assumption Core comes with a collection of default functions for you to build your own companion behaviour package out of (e.g. Limited By Charisma, Resets Health After Combat and so on). Google docs mashes the examples up so it's on Mediafire: http://www.mediafire.com/?0tjepaxz5uia9in.
It sort of leaps into describing the components and mechanics of Core, it needs an intro page but I couldn't really think of one and it wasn't hugely important.
The list of triggers is currently pretty short, but would be easy to extend.

I feel like I'm battling with forces beyond my wildest comprehensions




That would be awesome. No pressure or anything, but I'd love to plat around with the framework for this.




I followed most of what you describe in your doc. I'd have to think through it more, but it sounds a fair amount like what schlangster's proposed in a broad sense, but using a slightly different set of mechanics for implementation. Very interesting, glad to see how CSR/Core works under the hood.



I know that phalanx has very sophisticated scripting to govern behaviors. My knoweldge of the inner workings of AI is inadequate for this conversation unfrotunetly, but my question to you is: how much of phalanx's commands/behaviors could be re-packaed as a "Behavior Function" and merged into something like companion core as a base resource function? Or is a lot of the advanced behaviors / AI decision-making etc... scripted into the actual actor scripts and not easily "globalized"?

For example, I imagine a lot of the orders commands in Phalanx (i.e. the strategic attack modes) could more easily be implemented into a globalized framework for compaion behavior. The harder part is maybe porting over the weapon selection decision making to non-vanilla/phalanx followers, but maybe this too can be packaged into a "behavior function?"

This is complicated. But the result could be VERY powerful. Imagine, you get the vanilla/phalanx followers that are in the gameworld 'to be followers' for you, but use a common set of command/control features shared by your robot followers, other NPC's, or animal followers. They are all unique in how you hire/acquire them. Heck, you could even start to merge in aspects of the slavery overhauls, so an option instead of persuading NPC's to follow you (ala CSR) is to mez 'em, throw a slave collar on them, and make them do your bidding (if that's your thing).

Hmmm...

Hm... overengineered... now that you mention it

I minimized it a little since different dispatchers would probably only differ in operating on different queue/eventHandlerList pairs, so this can an well done by a single one. Same link:

https://docs.google.com/drawings/edit?id=1FEUIVWK7G5Bw6OKxwcH-SGdo0qIlyCn19T1SHM8GbhA&hl=en&authkey=CNP7h74K

The script for the generic dispatcher (untested beyond compilation):


So now, to add a new event, one would have to a queue (=empty formlist) to PNXCCEventQueueList, and a list of handlers for this event to PNXCCEventHandlerLList.

A handler has to implement 2 stage functions:
index 0

ref actorset actor to PNXCCDispatcher.actorOut(decide if we want to process actor)set PNXCCDispatcher.priorityIn to X

index 1

(here is where the real work starts)