Skip to content

Persistent Journal Entries

I haven't gotten to this point yet, but I want to address It as soon as possible, as It's one of the more Important things on my list of things that I want to get Implemented Into my current project.

I know Journal Entries have always been an issue with NWN when It comes to PWs, because they're reset whenever the server Is restarted or reloaded and I had a few Ideas to sort of get around this, without needing to resort to NWNX.

1)
The player recieves a token when they accept a quest, which contains a variable that Is changed as the quest advances. Everytime the player enters the server, their journal updates based on the tokens they have and the variables contained In them.

2)
Instead of relying on variables, go with tag based. As the quest advances, the player recieves a token based on what stage of the quest they are In with a different tag and when the player enters the server, they recieve the journal entries based on the tag of the tokens In their possession.

Could either of these two Idea work? potential pros/cons?

Thanks!

Comments

  • FinalStandFinalStand Member Posts: 87
    I just stored it in bioware database, but can be done on tokens or NWNX.

    Each quest has quest name (variable name) and state (int)

    So you have "FETCHQUEST_1" with 4 states (given quest, found item, returned item, end state).

    On join, it just checks those quests and adds journal entry for appropriate state.



  • PhantomizerPhantomizer Member Posts: 76

    I just stored it in bioware database, but can be done on tokens or NWNX.

    Each quest has quest name (variable name) and state (int)

    So you have "FETCHQUEST_1" with 4 states (given quest, found item, returned item, end state).

    On join, it just checks those quests and adds journal entry for appropriate state.



    Is there any place or article that explains In more detail? I've never really done anything with the Bioware Database, so I'm going In blind here, lol
  • NeverwinterWightsNeverwinterWights Member Posts: 339
    Just my 2 cents. This is one of those things that would, imo, work better if you used a token, or rulebook, or some other item that is specific to that player character as apposed to the database. This way if you ever want to delete the player character for whatever reason or the player makes a lot of characters and does the quests several times it wont inflate or interfere with the database.
  • MermutMermut Member Posts: 44

    Just my 2 cents. This is one of those things that would, imo, work better if you used a token, or rulebook, or some other item that is specific to that player character as apposed to the database. This way if you ever want to delete the player character for whatever reason or the player makes a lot of characters and does the quests several times it wont inflate or interfere with the database.

    Database entries should always be unique to player/character combo....
  • PhantomizerPhantomizer Member Posts: 76

    Just my 2 cents. This is one of those things that would, imo, work better if you used a token, or rulebook, or some other item that is specific to that player character as apposed to the database. This way if you ever want to delete the player character for whatever reason or the player makes a lot of characters and does the quests several times it wont inflate or interfere with the database.

    Already ran Into this issue In the PW I host, deleted my character off the server vault, made a new one with the same name....bam, he still had all the quests the old character had finished checked off :tongue:
  • NeverwinterWightsNeverwinterWights Member Posts: 339
    Mermut said:



    Database entries should always be unique to player/character combo....

    Well I wouldn't say always. There may be specific instances where one might want to do something where they are not linked.
    The point being it can be easier to manage when character specific variables are stored on an item specific to that character. If you ever find yourself cleaning out old characters from old players or what not, you won't need to go rummaging around the database for folders or files to clean up. It will already have been deleted when the character was. Or a DM might want to remove a character's database item to give the player a fresh start on quests, kill counts, etc while the game is running. Basically when it comes to character specific variables I usually keep them with that character. That's not to say the database can't or shouldn't be used. Personally it just makes more sense for me an it's just easier for me to manage.
  • FinalStandFinalStand Member Posts: 87
    I use database, it's keyed by cdkey and character name. We have NPC you can talk to to delete character which will clean up both character files and databases. But the character name is also in database file name, so manually deleting is easy too.

    Technically I use this, which is object in chest that gets saved to database: https://neverwintervault.org/project/nwn1/script/nbde-natural-bioware-database-extension-v10

    In hindsight, I think having item on player to store variables might be better way to go. Does that also work in local vault for testing?

    We do have a tool on backend to modify database directly. But unfortunately doesn't work with NBDE. The database is just a "Fox Pro" database and lots of libraries to read/write them.



    Either way, quests are the same. Just have one var per quests that tracks state and redo journal on login.
  • antirelicantirelic Member Posts: 20
    I've started a crude port of the PQJ script set for NWNX:EE. So far so good.
  • dTddTd Member Posts: 182
    Cool, waiting on it actually :)
  • antirelicantirelic Member Posts: 20
    Sorry for the delay. I'm having problems with the database connection at the moment. Not sure if it's nwnx problem or the Amazon rdbs. Moving the DB to the local server to see if that fixes it.
  • DorrianDorrian Member Posts: 15



    In hindsight, I think having item on player to store variables might be better way to go. Does that also work in local vault for testing?

    Either way, quests are the same. Just have one var per quests that tracks state and redo journal on login.

    We do a few things as vars on an undroppable object that the player has. It seems to work quite well. If we need to allow the character to reinc or anything we just grab the vars in a conversation and save them to a database and then purge those database entries after they are reclaimed by the new character.
  • antirelicantirelic Member Posts: 20
    Hello,

    Before you begin, these scripts and module will only function properly on a server that has been built using NWNX:EE.

    Here is a link to a module that is configured to allow you to create tables, and create and test basic persistent journal entries.

    https://nwn-stuff.nyc3.digitaloceanspaces.com/nwnx_mysql.mod

    Here is a script set to load into your module (please backup your module before you import any scripts). Configuration of these scripts should be fairly straightforward.

    https://nwn-stuff.nyc3.digitaloceanspaces.com/nwnxsql_pqj0502.erf

    Happy persistent journal writing.
  • AtrophiedericAtrophiederic Member, Mobile Tester Posts: 147
    Hey, friend @antirelic - did you release this work to the Neverwinter Vault? If not, do you have any plans to? Inquiring minds, and all that ...
  • antirelicantirelic Member Posts: 20
    No. If you want to, feel free. I don't really care about credit, but knat might (though, most of the PQJ was wholy ripped out... I just used the function names really).
  • dTddTd Member Posts: 182
    Perfect.
  • MermutMermut Member Posts: 44
    The biggest advantage to using NWNx rather then variables stored on an item in the character's inventory is debugging and versitilty.
    With NWNx, you can check (and adjust if the character is offline) quest states without any special in game tools.
    You can still check the variables in game with tools, but the DM doesn't have to find the character and the special item in the character's inventory.
    From a builder/admin point of view, that makes the database far superior.
Sign In or Register to comment.