31 réponses à ce sujet

[Failed.Bard]

  Starting a new topic for it, as Rolo suggested, so that the UoA thread can stay for if anyone gets any more info on it.

Edit: Updated  Erf download link Here: 

This system is set up for using Set/GetPersistentString under the table "pwrumors", which it will create and initialize if hooked into the OnModule load.

  If the persistence isn't needed, or someone wants to use it without NWNX, those calls can be commented out, and the Get/SetLocalString calls can be commented instead.  I use those for quick testing of changes, but they would work for SP module use since the variables on the PC would be saved in that case.

  I'll be expanding the options for what the NPCs will say later, that's the only part that's still quite obviously unfinished.  It works, but there's only three variations at the moment.  I figured out how I want to do it now though, so in a day or two I'll have an easily expandable and customizable framework in for that part of it as well.

  If there are any suggestions for other rumour worthy acts, I'll expand that as well.  I just went with the obvious ones to start.  Here's the ones in now:

const int RUMOR_TYPE_SLAY_ENEMY = 1;
const int RUMOR_TYPE_ROB_ENEMY  = 2;
const int RUMOR_TYPE_BETRAYAL   = 3;
const int RUMOR_TYPE_DEFEAT_BY_ENEMY = 4;
const int RUMOR_TYPE_SAVE_ALLY  = 5;


  There's an option to have it check for only a specific rumor type that I haven't finished writing in.  At the moment it only finds the highest weighted one that the NPC can make the lore check for.  It's just a few if statements to add that I haven't gotten around to yet.

  The biggest drawback of the system, is that creatures named by type are "spoken back" in a very fluid way, since they're missing the "a" or "the" needed.  There's a variable check in to allow for giving them a more fluid name for rumours, but that's only an option for non-default creatures.

  The biggest advantage, is that it can hook into any existing system without affecting others, since it just stores and writes variables, and occasionally makes an NPC speak a string.

Modifié par Failed.Bard, 30 octobre 2011 - 10:01 .

[Rolo Kipp]

<rubs his hands...>

Failed.Bard wrote...
  Starting a new topic for it, as Rolo suggested, so that the UoA thread can stay for if anyone gets any more info on it.

*Or* their tasty AI routines ;-)

Erf download link Here:

Tucked away for later perusal :-)

This system is set up for using Set/GetPersistentString under the table "pwrumors", which it will create and initialize if hooked into the OnModule load.
...
If there are any suggestions for other rumour worthy acts, I'll expand that as well.  I just went with the obvious ones to start.  Here's the ones in now:

const int RUMOR_TYPE_SLAY_ENEMY = 1;
const int RUMOR_TYPE_ROB_ENEMY  = 2;
const int RUMOR_TYPE_BETRAYAL   = 3;
const int RUMOR_TYPE_DEFEAT_BY_ENEMY = 4;
const int RUMOR_TYPE_SAVE_ALLY  = 5;

How about  _QUEST_INFO to be able to dynamically insert rumors about quests...?
and _RUNAWAY_RUNAWAY for when the PC chooses discretion :-)

Thanks a lot FB :-) I can really see a use for this.  I'll also be looking at the stuff Squatting Monk pointed out when I get somewhere that doesn't block the Vault :-/

<...in Glee™>

Modifié par Rolo Kipp, 24 octobre 2011 - 08:38 .

[Squatting Monk]

SQL Tip: In the FB_SetUpRumorDatabase() function, use CREATE TABLE IF NOT EXISTS instead of making an entry in the pwdata table that it exists. This will make it so you don't have to have three separate NWNX calls the first time you set it up, and will allow you to easily DROP the pwrumors table without having to go into pwdata and clear the marker. Cleaner code all around, too.

Suggested rewrite of that function:

void FB_SetupRumorDatabase ()
{
    // Comment out if already initialized elsewhere.
    SQLInit();
 
    SQLExecDirect("CREATE TABLE IF NOT EXISTS pwrumors (" +
        "player varchar(64) NOT NULL default '~'," +
        "tag varchar(64) NOT NULL default '~'," +
        "name varchar(64) NOT NULL default '~'," +
        "val text," +
        "expire int(11) default NULL," +
        "last timestamp NOT NULL default current_timestamp," +
        "PRIMARY KEY (player,tag,name))");
}

Modifié par Squatting Monk, 24 octobre 2011 - 10:48 .

[Failed.Bard]

The check was made in the pwrumors table, not pwdata, though the IF NOT EXISTS suggestion is still a valid one. I'll likely not change it in my own though, since I keep a server log shortcut on my desktop and I can more easily check if it set up properly there as the script is.

[Squatting Monk]

D'oh! I see that now.

[Failed.Bard]

  I updated the erf, at the original download link.  It's got a compartmentalized structure for putting the rumour parts together, to allow for easier adding and customizing of variants.  I also added rumour types based on class and racial groupings, to allow for more specific rumours to be stored by plot events.

Here's the updated rumour type list:

const int RUMOR_TYPE_SLAY_ENEMY = 1;
const int RUMOR_TYPE_ROB_ENEMY  = 2;
const int RUMOR_TYPE_BETRAYAL   = 3;
const int RUMOR_TYPE_DEFEAT_BY_ENEMY = 4;
const int RUMOR_TYPE_SAVE_ALLY  = 5;
const int RUMOR_TYPE_RUNAWAY    = 6;
const int RUMOR_TYPE_ROMANTIC   = 7;
const int RUMOR_TYPE_QUEST_INFO = 9;

Only the first five can be easily hooked to generate them automatically off PC or creature events.

Edit:  I changed it to have class and race of the rumor target stored as subtypes, as well as the inverse of the targets alignment.  I just realized I'll need to add a seperate alignment check for the romantic subtype though, since that's the only one that wouldn't need the inverting.

Modifié par Failed.Bard, 25 octobre 2011 - 03:31 .

[Failed.Bard]

I'm playing around with the idea of an override version of it as well at the moment. It might make for some interesting variance in the OC and expansions if the NPCs were a bit more active in the background.

[Failed.Bard]

  I made a few small changes to the include, added a check to ensure a particular rumour base isn't stored multiple times, and a routine to help hook the OnPLayerDeath event.

  I ended up having to run GetLastDamager() in the OnPLayerDeath hook, since even running it in a script with the PC as the caller I could only ever get GetLastKiller() to return the module.
  It might end up catching the wrong object in some cases due to that, particularly in the case of instant death spells/effects.  I'm not going to try to make a change to correct that though, since I think the occasional false rumour could actually make the system more believable from a purely IC standpoint.

  The next change will have some extra constants and a switch added to allow the messages to be done by stringref.  The main advantage I see in that, is the ease in which it would be to configure "accents" in the NPCs repeating the rumours.  Obviously, servers not using a custon tlk simply won't turn on the option.
  This will likely be at least a week away.  I expect real life will keep me pretty busy through the next while.

 The download link in the original post has been updated.  I'm trying to keep the link just in that post, so anyone wanting to take a look at it won't have to sift through dead links to find the current one.

[Rolo Kipp]

<covering his mouth...>

Failed.Bard wrote...
...
  I ended up having to run GetLastDamager() in the OnPLayerDeath hook, since even running it in a script with the PC as the caller I could only ever get GetLastKiller() to return the module.
  It might end up catching the wrong object in some cases due to that, particularly in the case of instant death spells/effects.  I'm not going to try to make a change to correct that though, since I think the occasional false rumour could actually make the system more believable from a purely IC standpoint.

I was actually going to suggest a mechanism for injecting false leads... =) Works for me! 
"The reports of my death are greatly exaggerated"

  The next change will have some extra constants and a switch added to allow the messages to be done by stringref.  The main advantage I see in that, is the ease in which it would be to configure "accents" in the NPCs repeating the rumours.  Obviously, servers not using a custon tlk simply won't turn on the option.
  This will likely be at least a week away.  I expect real life will keep me pretty busy through the next while.

Thanks FB. You are so much faster than I and I like what you've put together.  Take some time off NwN. Relax. Work <he's snickering. you should know that> Only 'cuz I'm jealous. :-P

The download link in the original post has been updated.  I'm trying to keep the link just in that post, so anyone wanting to take a look at it won't have to sift through dead links to find the current one.

That's the way I like to do it, too (see my CCC posts). Makes things tidier =) <tidier? *snort*> What? I can be tidy. I can!

<...and spreading rumours>

[Failed.Bard]

Rolo Kipp wrote...

<covering his mouth...>

Failed.Bard wrote...
...
  I ended up having to run GetLastDamager() in the OnPLayerDeath hook, since even running it in a script with the PC as the caller I could only ever get GetLastKiller() to return the module.
  It might end up catching the wrong object in some cases due to that, particularly in the case of instant death spells/effects.  I'm not going to try to make a change to correct that though, since I think the occasional false rumour could actually make the system more believable from a purely IC standpoint.

I was actually going to suggest a mechanism for injecting false leads... =) Works for me! 
"The reports of my death are greatly exaggerated"

<...and spreading rumours>

  You can manually inject false rumors through the script as it is now, though the current system requires an object to be entered.  I can add a routine that allows for the relevent details to be added directly as strings for times when an object isn't present to use as the base, or where a group needs to be represented instead of an individual.

[QlippothVI]

You know, for some time I've been thinking I'd like a system for intercreature communications. In a living module there should be method for npcs to cause a flow of information across the module. If a forester is run out of their area by a monster, this is something they should convey to authorities, who in turn can farm out securing that area for the forester again. So this system might be a good start.

[QlippothVI]

I also need a way for PCs to add to the flow, like _runaway_runaway to tell NPC authorities about said monster in some other area, via dialogs

[Lightfoot8]

Failed.Bard wrote...

  I updated the erf, at the original download link.  It's got a compartmentalized structure for putting the rumour parts together, to allow for easier adding and customizing of variants.  I also added rumour types based on class and racial groupings, to allow for more specific rumours to be stored by plot events.

Here's the updated rumour type list:

const int RUMOR_TYPE_SLAY_ENEMY = 1;
const int RUMOR_TYPE_ROB_ENEMY  = 2;
const int RUMOR_TYPE_BETRAYAL   = 3;
const int RUMOR_TYPE_DEFEAT_BY_ENEMY = 4;
const int RUMOR_TYPE_SAVE_ALLY  = 5;
const int RUMOR_TYPE_RUNAWAY    = 6;
const int RUMOR_TYPE_ROMANTIC   = 7;
const int RUMOR_TYPE_QUEST_INFO = 9;

.

hmm, When scaning past this, I can not help but think that you would have more dynamic universal options in the system if you changed your rumor constants to bit flags,  instead of just linear constants.  
i.e.

const int RUMOR_TYPE_SLAY_ENEMY = 1;                //0x01   or %0000_0001
const int RUMOR_TYPE_ROB_ENEMY  = 2;                //0x02    or %0000_0010
const int RUMOR_TYPE_BETRAYAL   = 4;                   //0x04   or %0000_0100
const int RUMOR_TYPE_DEFEAT_BY_ENEMY = 8;  //0x08    or %0000_1000
const int RUMOR_TYPE_SAVE_ALLY  = 16;               //0x10     or %0001_0000
const int RUMOR_TYPE_RUNAWAY    = 32;               // 0x20    or %0010_0000 
const int RUMOR_TYPE_ROMANTIC   = 64;               // 0x40    or %0100_0000  
const int RUMOR_TYPE_QUEST_INFO = 128;          //0x80    or %1000_0000

of cource the benifit here is that you would be able to use the same var to hold more then one rumor type without fear of them overwritting  a differant type that they already have.   

e.g. 

int nRumors  = GetRumorTypesFrom( oTarget);
int nSAVEnSLAY =RUMOR_TYPE_SLAY_ENEMY+RUMOR_TYPE_SAVE_ALLY;
if (nSAVEnSLAY & nRumors == nSAVEnSLAY  )
{
    // I have a rumor about saving and slaying.  Of cource you would want to work out wether it was one event or two.   
}

Just a thought of a different way you might want to do it.

[Failed.Bard]

Lightfoot8 wrote...

Failed.Bard wrote...

 ...

.

hmm, When scaning past this, I can not help but think that you would have more dynamic universal options in the system if you changed your rumor constants to bit flags,  instead of just linear constants.  
i.e.

const int RUMOR_TYPE_SLAY_ENEMY = 1;                //0x01   or %0000_0001
const int RUMOR_TYPE_ROB_ENEMY  = 2;                //0x02    or %0000_0010
const int RUMOR_TYPE_BETRAYAL   = 4;                   //0x04   or %0000_0100
const int RUMOR_TYPE_DEFEAT_BY_ENEMY = 8;  //0x08    or %0000_1000
const int RUMOR_TYPE_SAVE_ALLY  = 16;               //0x10     or %0001_0000
const int RUMOR_TYPE_RUNAWAY    = 32;               // 0x20    or %0010_0000 
const int RUMOR_TYPE_ROMANTIC   = 64;               // 0x40    or %0100_0000  
const int RUMOR_TYPE_QUEST_INFO = 128;          //0x80    or %1000_0000

of cource the benifit here is that you would be able to use the same var to hold more then one rumor type without fear of them overwritting  a differant type that they already have.   

e.g. 

int nRumors  = GetRumorTypesFrom( oTarget);
int nSAVEnSLAY =RUMOR_TYPE_SLAY_ENEMY+RUMOR_TYPE_SAVE_ALLY;
if (nSAVEnSLAY & nRumors == nSAVEnSLAY  )
{
    // I have a rumor about saving and slaying.  Of cource you would want to work out wether it was one event or two.   
}

Just a thought of a different way you might want to do it.

  I think I might include this method for handling rumour specialties stored on NPCs, to allow for the potential a particular NPC might have multiple areas they know more about.

  Trying to include all the verbage combinations needed in order to support dual type rumours wouldn't be feasible with the rumours portion, since the rumours themselves are assembled at the time the NPC speaks them to allow maximum variance and customizing of them off of the stored target name and optional descriptor.

[Failed.Bard]

const int RUMOR_TYPE_SLAY_ENEMY = 1;
const int RUMOR_TYPE_ROB_ENEMY  = 2;
const int RUMOR_TYPE_BETRAYAL   = 3;
const int RUMOR_TYPE_DEFEAT_BY_ENEMY = 4;
const int RUMOR_TYPE_SAVE_ALLY  = 5;
const int RUMOR_TYPE_RUNAWAY    = 6;
const int RUMOR_TYPE_ROMANTIC   = 7;
const int RUMOR_TYPE_QUEST_INFO = 9;

const int RUMOR_SPECIALTY_SLAY_ENEMY = 1;      // 1
const int RUMOR_SPECIALTY_ROB_ENEMY  = 2;      // 2
const int RUMOR_SPECIALTY_BETRAYAL   = 4;      // 3
const int RUMOR_SPECIALTY_DEFEAT_BY_ENEMY = 8; // 4
const int RUMOR_SPECIALTY_SAVE_ALLY  = 16;     // 5
const int RUMOR_SPECIALTY_RUNAWAY    = 32;     // 6
const int RUMOR_SPECIALTY_ROMANTIC   = 64;     // 7
const int RUMOR_SPECIALTY_QUEST_INFO =  256; //9

  I'm starting to incorporate Lightfoot8's suggestion, but I'm not sure I'm doing the conversion from whole number to bitwise digit properly.
  At the moment I'm using this:

nTestType   = 0 << FB_GetRumorType (sTest);

  Will it work properly starting from zero, since there isn't a 1 present yet to shift?  The intention is that it will shift it one for each point in the type to make a bitwise to compare to the one used for the specialty, which I think I can compare just using the &, if I read it right.  I'm still trying to learn how to use these properly.


  I can convert it to something like this if necessary, but it seems a bit of a waste if I can start from zero:
 
  nTestType = FB_GetRumorType (sTest);
  if (nTestType) nTestType = 1 << (FB_GetRumorType (sTest) - 1);

Modifié par Failed.Bard, 08 novembre 2011 - 01:21 .

[Lightfoot8]

Hmm, I dont have a lot of time right now.

Lets see if this helps.

bit positions are 0 based. So
1<<0 = 1 or a test for bit position 0.

if (1<< 0 & nRumor) //would check to see if the 0 bit was set in nRumor.
if (1<< 1 & nRumor) // would check to see if the bit in position 1 was set or not

nRumor= nRumor ^ 1 << 0; //( '^' is an Exclusive or. ) would toggle the state of bit positon 0;
nRumor= nRumor ^ 1 << 1; //would toggle the state of bit positon 1;

nRumor = nRumor | 1<<0; //would set bit posistion 0 to 1; reguardless of wether it was set yet or not.
nRumor = nRumor | 1<<1; //would set bit posistion 1 to 1;

To unset a bit you take the logical bitwize NOT of the number and do a logical AND

nRumor = ~(1<< 1) & nRumor ; // ('~' is a bitwize logical NOT) would unset bit posistion 1;

[Lightfoot8]

I know I posted my flags include on the boards here some where. The heck if I can fing them though.

since I cant find a link I just posted it to pastebin. perhaps I wont lose them again this way.

Ok rant done. See if this library helps you at all. RR_I0_flags

If you are still having problems please post back and let me know.

[Failed.Bard]

  Okay, thanks to Lightfoot8's help the bitwise comparison seems to be working properly now.

  The newest version of it has a constant flag for "misheard" rumours, as well as the chance of a rumour being repeated incorrectly.
  This change affects only how the rumour is said, not the stored rumour itself, at the moment.  I could probably add another flag with a check to see if a sufficient number of NPCs are around to hear a misrepeated rumour to justify the stored one being changed.

  A simple mechanism for deliberately storing false rumours has also been added, that doesn't require a target object to be entered.

  As before, the download link for it is in the first post.

[Rolo Kipp]

<muses...>

A thought on that, if a sufficient number of NPC hear the misspoke rumor, generate a *new*, false rumor, but leave the original in place so there are competing variations...

<...that his muse is prominent in her absence>

[Failed.Bard]

Rolo Kipp wrote...

<muses...>

A thought on that, if a sufficient number of NPC hear the misspoke rumor, generate a *new*, false rumor, but leave the original in place so there are competing variations...

<...that his muse is prominent in her absence>

Done.

  The weight of the new false rumour is the average of a DC 15 persuade roll and the speakers CR, plus the number of NPCs (of 8 and over int) there to hear it above the initial 5 needed before it will store it.

  With an unconvincing speaker the weight will likely be too low to be able to overwrite any existing rumours, but if that reknowned travelling minstrel happened to get it wrong, that might be a rumour that the PC can never shake.


  I also found a bug in the version I'd put up this morning while adding that.  I'd made the false rumour part a void function, when it should have been returning a string.

[Rolo Kipp]

<chattering...>

Failed.Bard wrote...
...
  With an unconvincing speaker the weight will likely be too low to be able to overwrite any existing rumours, but if that reknowned travelling minstrel happened to get it wrong, that might be a rumour that the PC can never shake.

Just the kind of behavior I was thinking of. Thank you, FB. :-)

<...like a schoolboy>

[Failed.Bard]

  I've kept working at this off and on in my little mod, mainly in tailoring it specifically for that, but this week-end I started into an accents add on for it.  Using the FindSubString routine I only found out the varied uses for recently (for the Hex String to Int converter), and a simple letter/letter grouping replacement system.

  So far I've just been playing around with simple accents (replace "simple" with cliched there, really) for it, and accents that I've used for characters I've played/DM'd.


  Here's a few examples of the variety achieved so far, pulled directly from the logs.  NPC name has been replaced with accent name.  I'm not happy with the prevalence of "offed" instead of "killed", it's supposed to be the lowest level of reply, for below average to average (10) intelligence, but is the most common.

  The only thing actually stored here as a string is the name of the creature killed, zombies of various sorts in these cases, since they're the most prevalent enemy in my mod.

// The only thing scarier than a bear in the woods?  A Zombie bear in the woods.
[French/HM] You're Zherese Davis, right? You offed a monstrous zombie grizzly?
[French/HM] Aren't you zhe one zhat offed one of zhose large zombie brown bears?

// The same orc rumour in two different accents.

[French/HM]Is it true you offed one of zhose brutish zombie orcs?
[French/HM] Aren't you zhe one zhat offed zhat brutish zombie orc?
[Simple] Hey, Therese Davis. I heard'ja killed that brutish zombie orc.

// Same dwarven accent, same rumour, different random part components.
[Dwarf] Hey, Derese Davis. I heard you offed dat huge zombie bulette.
[Dwarf] You're de one dat killed dat huge zombie bulette?
[Dwarf] Is it true you offed one of dose huge zombie bulettes?
[Dwarf] I keep hearing how you offed a huge zombie bulette.

[Dwarf] Aren't you de one dat killed dat unholy stone giant?


  Any ideas for accents that could be pulled off under this system?

  To give an idea how it works, here's the "French" accent routine.

//// If bioware can use french accents in the expansions, I don't see why I shouldn't slap in
//// a cheesy french accent.
//// For Ravenloft - High Mordentish
string FB_AccentFrench (string sString)
{
string sFind, sReplace;
int nLength, nReplaceStart, nCaseSensative, nCount;

while (sFind != "DONE")
{
switch (nCount ++)
{
  case 0: sFind = "me"; sReplace = "oi";
        nLength = 2; nReplaceStart = 1; nCaseSensative = FALSE; break;
 case 1: sFind = "Yes"; sReplace = "Oui";
        nLength = 3; nReplaceStart = 0; nCaseSensative = TRUE; break;
 case 2: sFind = "yes"; sReplace = "oui";
        nLength = 3; nReplaceStart = 0; nCaseSensative = TRUE; break;
 case 3: sFind = "No"; sReplace = "on";
        nLength = 2; nReplaceStart = 1; nCaseSensative = FALSE; break;
 case 4: sFind = "Th"; sReplace = "Zh";
        nLength = 2; nReplaceStart = 0; nCaseSensative = TRUE; break;
 case 5: sFind = " th"; sReplace = " zh";
        nLength = 3; nReplaceStart = 0; nCaseSensative = TRUE; break;
 case 6: sFind = "H"; sReplace = "'";
        nLength = 1; nReplaceStart = 0; nCaseSensative = TRUE; break;
 case 7: sFind = " h"; sReplace = "'";
        nLength = 2; nReplaceStart = 1; nCaseSensative = TRUE; break;
 case 8: sFind = "th"; sReplace = "'";
        nLength = 2; nReplaceStart = 1; nCaseSensative = TRUE; break;
 case 9: sFind = "I "; sReplace = "Ah";
        nLength = 1; nReplaceStart = 0; nCaseSensative = TRUE; break;
 default: sFind = "DONE"; break;
 }
 sString = FB_FindAndReplaceSubString (sString, sFind, nLength, sReplace, nReplaceStart, nCaseSensative);
}
return sString;
}

sFind is self explanatory, as is sReplace.

nLength is how many characters to skip when replacing.  This is usually the length of sFind.

nReplaceStart is used if you're keeping certain characters from the original.  Useful here to allow "No" and "no" to become "Non" and "non" off a single check, by leaving the original "n".

 nCaseSensative is used largely when nReplaceStart > 0, for the use mentioned above.


  Since I'm not sure how processor intensive FindSubString is, I'll be keeping all the accents under 20 replacements max, and preferably under 10, but other than that I'll put in any that people can suggest.

  All I would need is an accent "name" to give it, and what to change.  Adding one only takes about five minutes, so it's easy on my end to put more in before I package it up again into an erf.

Modifié par Failed.Bard, 10 juin 2012 - 03:21 .

[Failed.Bard]

Here's  (or here if the project DL isn't working) a very simplified demo module of the current system, set to run off a database item at the moment.  It can use a NWNX database, the vanilla bioware DB, a database item, or local variables on the PC.
 The last is really only good for testing, even the database item is really only useful with server vault characters. 

  There are 4 rats in the area, 1 HP each, with an artificially boosted CR to try and ensure a rumour is stored.  Once those are killed, simply walk in and out of the NPCs field of view to see their responses.

  There are no hooks into the player death event in the demo mod.  There are comments at the end of the rumor include on how to do that, as well as the script snippets needed for the various events.

Modifié par Failed.Bard, 11 juin 2012 - 07:29 .

[QlippothVI]

 "403 Forbidden"... 

[Failed.Bard]

Oops. Should be fixed now, hopefully. I'm still not used to the projects DL set up.