It will be great fun to see how it operates in practice!

Thanks all, again.


What you are doing is pretty much what I was thinking when I wrote the comment: somehow the game reacting differently to each player style, which, in turn, encourages the player to be more flexible in order to get better results.


Pretty much as you say.
There are arrays representing the actors, containing their specs, attributes and states
There are arrays representing the activities, containing their stages, durations, functions, etc
An actor array points to the activity arrays the actor is supposed to perform. (along with min & max counts)
(Although I did no do it, all these arrays could be initialized from .ini files)

With this data structure, the core of the engine is composed of just four functions:
ActorEval - handles and distributes events and processes return codes
ActorPickNextActivity - the aforementioned activity selection algorithm
ActorGotoNextStage - determines the next stage and calls the stage function (Start event)
ActorSetNextActivity - forces a new activity on the actor

Plus one function per stage (about 30) and, of course, a number of utility and 'subroutine' functions.



Right. And thinking about it, maybe there would be no need to remove their original packages.
Provided the engine makes sure there is always an added package, the actor would never process his original list. Subject to a lot of tests, thou, as the game engine is full of surprises.



Yes. The way it is now, the ACE engine is highly dependent on the events generated by OnPackageDone blocks.

But only for GoTo kind of packages, as all (?) other types of action end by other events (timeout mostly)

To get rid of the actor script, an alternative approach would be a token that keeps checking the actor<>destination distance and raises the proper event when the actor reaches destination.
This kind of goes against the no-gamemode goal, but, again, this is just an academic goal I set just for fun.

At first glance, it seems possible, but I wonder . . .

Just a very quick reply: how exactly would that be possible? Array(function)s cannot be used from the console, right? So that includes RunBatchScript too. Or did you mean it in a way like using dummy quest variables and an activator script to read and write those values in a single frame (so it can be used multiple times from the same ini)? :unsure:

so is the "The SimBlivions 4"?

seriously, this sounds awesome! i dont fully understand all of it, but from what i DO understand, its cool!

Oh! . . . I was thinking Pluggy ini files (or, hopefully, a future OBSE ini text file)
I've never looked much into RunBatchScript and I don't really know what can/cannot be done with it.


SimBlivions?!!!! Lol

Wow, great work you are doing QQuix! It sounds fantastic, and very, very complicated! XD

Ah, well as said I was just thinking aloud - not really commenting on anything particular.



I have intentionally never touched the default combat style engine, so that DR stays compatible with mods that edit the combat styles defined in CS.


Now that DragoonWraith has made it possible to read and adjust the combat styles dynamically via scripts, I have still resisted the temptation to touch them at any point, so that if anyone takes on mission to, say, alter the NPC block chances via combat style changing scripts, or lower attack intensity when they are damaged, set temporarily attack chance to 0 when player already blocks, etc....

...there would be no compatibility problems with DR. I really hope someone else would start such a mod, a mod controlling purely the combat style parameters dynamically. It?s a very interesting opportunity, it would work with anything and I would personally use such a mod for sure.

Only for 1 special NPC "boss" to prove it could be done and that it is a much better way to make challenging combat than the usual jacking up of the hit points.

The mod is Hammer-Blade on TessNexus.

I am, like some other earlier posters inclined toward, wondering about the difference in processing drain between this and the normal radiantAI packages? The drain the AI system puts on the CPU seems excessive; one of the main concerns for me is how many NPC are getting processed, as too many makes gameplay a slideshow.

EDIT - Eh, well the real question was if there would be a gain to replace as much of the original packages as possible with this instead. END EDIT

Very interesting mod.

Cheers!

I too would really really like to see dynamically set combat styles (to include magic and stealth as well).

I've been a devoted user of Duke Patrick's SCA mods and so really love them. But it would be neat to meet an NPC who after initiating combat would sneak off and try to snipe me, or actually mix magic and melee - like my character would. Instead of an archer pulling out a dagger or whort sword when you get close but actually using a touch based offensive spell.

Different fighting styles for different races, factions, guilds. NPCs that could change AI even after combat started. Throw some curve balls - random behavior.

.... but not as cumbersomely loaded down as UV can be.

man that would be something.

Ahh yes ofcourse. That would make alot more sense. :facepalm: In theory it could work with RunBatchScript but each and every parameter would need (atleast) one (quest)variable. And with such a complex structure the practicle use is very low for this mod.

Anyways, a couple of questions:
#1. You mentioned the OnPackageDone blocks are required but it could also work with tokens (apart from the, awesome, no gamemode approach) and distance checks. Well I'd like to ask for such an option/alternative for scripts on NPCs.

#2. Forgetting the above, are the scripts that are added to the NPCs generic ones? With a couple of blocks for a couple of standard AI packages (for the various stages of each activity)? Or are the AI packages very specific to an NPCs? I'm guessing it's the former and that you are changing the destination of an AI package through script just before it's added to the NPC. I recall reading something about NPCs using/sticking with whatever the destination or target was when they were assigned the AI package, instead of switching/updating to the new target when you change it by script again.

#3. About the Voters, will it be possible to create new/extra voters put them on the list (I assume there is a list somewhere) of Voters the mod will use?

#4. From what I've read it will be relatively simple to create new types of activities? As each activity might be stored/defined as various stages?

#5. Something else which I seem to have forgotten....

-kyoma

I won't comment on the Combat discussion because, as I said earlier, I have no Combat experience, not even as a player.


What I am doing is superseding the vanilla mechanism of selecting AI packages with an external (scripted), more flexible one. My implementation is very light on CPU and I would bet that I could handle a couple of hundred NPCs without any performance effect. (not all in the same cell, of course)

On the other hand, I would guess that the original package selection algorithm is also very light on CPU, as it only runs when the NPC reevaluates his packages (not that often).
So, it should not be any difference in performance, either way.

I suppose that what really drains performance are the things mentioned by the http://cs.elderscrolls.com/constwiki/index.php/SetSceneIsComplex and its three companion functions.



I suppose one could create one BatchScript file per NPC and run one to populate the quest variables, run a script to move the values to the NPC array, run the next BatchScript, and so forth. Not sure it is worth the trouble.



I've been thinking about it and I think it will work. I will do some tests when I am done with this mod.
But, distance alone is not enough. E.g., when an NPC is following another (which is his 'destination') they may be within distance, but it needs some additional checks to see if the leader has reached his destination.



Yes, all actors share the same script. As it is now, it has 100+ onpackageend blocks.

While experimenting with ways of making the NPCs go here and there, I settled for two alternatives:
1) One Travel package per destination - many NPCs sharing the same package
2) One Travel package per actor - Destination being a reference that is moved to the desired spot

One factor for choosing one or the other is whether you have more destinations than actors or vice-versa.

I am using the second option. I have about 30 travel packages whose destinations are 30 different references (barrels scaled to .01 - I like barrels). When I want the actor to go to the Bar, I move the barrel to the bar and add the package to the actor. I have found that the game engine handles very well these 'moving targets'. Never had any problems.

Note that OBSE's SetPackageTarget function changes the package Target, not the Location. Travel packages use Location, not Targets, so this is not an option.

I also have 30 Find packages to the same 30 little barrels and 40+ Travel-to-NPC packages (used to make one NPC follow another)



Very easily. The Activity Selection script has a number of Call lines calling each voter's function.
It is just a matter of writing a new voter function and adding a Call to the Activity Selection script.



Yes. Here is a sample from the Activities initialization script:

;==============================let sName :=	zAcquirePartnerBar;==============================let arrActivities [sName] := ar_construct stringmaplet arrActivities [sName] [zStages] := arr := ar_construct arraylet arrActivities [sName] [zsLocation] := zBarlet arr [ar_size arr] := call zvBuildStage zGotoBar	 	20 	0 	0	zzActionGotoBar let arr [ar_size arr] := call zvBuildStage zAcquirePartner 	5	0 	0	zzActionAcquirePartnerlet arr [ar_size arr] := call zvBuildStage zProposeDrink 	5	0 	0 	zzActionProposeDrink

zvBuildStage is just a function to format, populate (with the arguments provided) and return the Stage array .
The arguments are: Stage name + Duration + Duration variation + Flag + Function that handles the stage.
Words prefixed with a single 'z' are strings (zBar = "zBar")
Stage functions may be used by more than one activity.

The hardest part is writing the Stage function, as some may require new AI packages, new NPC attributes, etc.

Checking for AI procedure '17' should do. From my testing, getCurrentAIProcedure returns 17, for a few frames, after the calling actor has completed his current procedure. Using that with getCurrentAIPackage will yield a fairly reliable method to check for completion.

Good to know it is reliable.

I am using this test in one particular case: at some point during the tests, sometimes one of the AI packages did not run its OnPackageEnd block. So I added this test. It seemed to solve it, but I was not sure it was reliable.

nice work, im still trying to wrap my brain around it

anyways i think it would be a great idea to add 'civil disputes' as in calling a breton something would call it to start a fight with that ai if the tensions are high enough
to add to these factors maybe 1-Drinking 2-Late Worknights 3- lack of social interaction

once you have this amazing thing sorted out, get a team created to implement this to vanilla npcs

oh yea, and keep it clean with the couples


:cookie: :thumbsup: :woot:

Am I correct to assume that this is the successor of http://www.gamesas.com/bgsforums/index.php?showtopic=1005791 previously developed by Syclonix?

Reading from the description, it looks like a great leap forward on the AI.

I am afraid not.
When I finish this mod I am using for development, I will resume my work on The Evolving Society, which will take, most likely, about six months until a Beta release. Then bug fixes, a stable version 1 release and an eventual version 2 will take the remaining of 2010.

I am willing to do the experimenting and developing necessary to make it work with vanilla NPCs (as a side project), but either somebody else takes the initiative to put a team together or we wait until 2011.



I am afraid I did not understand what you mean.




From Syclonix' description, I don't think so.
He focuses on combat scenarios, while I am focusing on daily routine activities over time.

Many behaviors may be implemented, like the ones Spiderpig just suggested. Or neighbors quarrels, or cheating spouses. Or elections. Or anything else based on an improved NPC decision process.

My The Evolving Society project deals with a growing community, so most things I will do with this NPC engine will, directly or indirectly, affect production.

For example: NPC satisfaction with some aspects of the community, like Security, Health Care, Education, working hours and such will affect productivity. NPCs will have different preferences on these matters and each will react differently to the player's actions. Like, if the player builds, say, a Church, the farmer gets happier and produces more food.

Wondering about implications for the future I note you have touched on ongoing behaviours and their processing take up outside the 'current' cell - are you aiming to create visible changes in 'landscape' and it's furniture to reflect the results of actions of groups of NPCs? Or is that going into 'The Evolving Society Territory?

Nooo ! :shakehead:

The present mod does not require it, as NPCs don't happen to change anything around them.

But the script engine supports this feature. Every single activity has a script controlling it, so it is just a matter of how much effort you want to invest on that script and how complex it becomes.

In T.E.S., my focus is macroeconomic, so I am not planning on investing too much on extreme micro realism, as NWJ or CraftyBits do. Not even if the cell is loaded.

The pirate raid example is one of the few that I plan on implementing as an after-the-fact visual indication, if technically possible. A few other situations may also be implemented, for one reason or another, but this is not the focus.

But, with this engine, I could, for example, do in such a way that if the player goes to the Sawmill in the morning, he sees, say, 4 logs at a corner. Returning at noon, he would see 2 logs and some planks. At the end of the day he would see just planks. (But T.E.S. probably won't even have a realistic sawmill interior, let alone the materials)

I mean, things WILL happen on unloaded cells, like materials will be removed from the warehouse inventory in the morning and products will be added at the end of the day. You just won't see them going back and forth around town.

Heh - so it a matter of choice Seems what you need now is for some bright 'packaging' spark to assemble it into something that modders can use without too much fuss.

Must say I like the idea that there would be visible scars from a pirate attack - vikings and pirates both tended to arson. I would also like to see damaged buildings being repaired. After all, experientially, what is the difference between NPCs wandering around aimlessly making fatuous and irrelevant comments and other NPCs busy with purposeful activity? So I want to see both nitwits and Mrs mop washing the family clothing in the stream then hanging them out to dry etc - that's what gives real atmosphere. Diversity of activity = Immersion.

So long as th eframerate is happy with it

Which also makes me wonder, does "script" related activity really take that much resources? Not as much as graphic improvements stuff, I suppose.

I any modder gets interested in using these scripts, I will be willing to work together to create any new 'packages' that may be required.



I've been thinking about this scenario a little and it may not be that simple.
In T.E.S, the player will choose the building architecture (and position). So there is no way to anticipate which buildings will be in town when the pirates attack, so, unless someone is willing to create a destroyed version of every single vanilla architecture mesh, I won't be able to do much to the buildings visuals.
Anyway . . . lots of time to think about until a solution is needed.



Scripts are not significant on CPU load, compared to all the heavy stuff the game engine has to do every frame (graphics, collision, path decisions, line of sight, and such)
(within reaso, of course)

I have finished the mod used to develop this concept: Anvil Red Light District.
It is in Beta test and I will upload it to TES Nexus soon.

As a teaser, I created an http://www.youtube.com/watch?v=vROUU6I5XEE.

Everybody off stage is controlled by the main ACE engine.

The jugglers are controlled by what I described under "Alternative Event Control Sub-Engine" in the first post (the one I did not like).

That's pretty awesome. Now what we need are some new animations.