Journal Entry "MV_DeadTaxman" can have one of it's topics retrieved using GetJournalIndex.
I need to be able to figure out which indexes have been obtained for a given topic. So there are about 6-7 different results
under that one journal entry..how can I check if they currently have a specific sub-journal entry?

In general I want to do different things depending on journal entries. So depending on the status of the dead taxman (what choices the player made) I want to do different things..how can I look and see which individual journal entries that the player has for the
taxman quest for example?

Edit, I could get the most recent entry but I am worried that I won't get the correct one. Some people make different choices during a quest and may not have done part of it, I want to take that into account.

I don't believe it's possible to test for whether a specific journal index has been given in a journal topic.

You could go around it by setting a variable along with the wanted journal index. The hindrance of this (when used in a vanilla quest) is that you still cannot check whether the player had gained that journal index before having the mod loaded.

I think I am just going to make more general news item in this situation. I might do the variable thing if it's something I really need it for but not on these smaller quests. Thanks for the feedback.
Also I want it to be retroactive, so that might also pose me an issue. I will find some way around it. Thanks again for the feedback.

No problem.

I think the cause why you can't check for specific indices is that Morrowind stores the player's journal as a text document rather than an array of entries and dates. This shows when you remove a previously loaded mod from your game and yet the journal entries that were added by that mod remain in your journal.

if ( GetJournalIndex "journal_id" == < > >= <= "index #" ).

Yes but that only gets the last one. Sometimes the player might have missed a journal entry and/or gotten a different one. I want to know whether they completed a specific step in a quest so I can do certain things based off of that. For example, Processus quest in Seyda Neen. You find the body. One step in the quest is to visit his girlfriend and give her back the ring, among other optional options. If you just do the entire quest you acn't use that function to find out if there was a specific journal entry. Giving you less power when creating conditionals for quests.
I am digging around for Alternatives however.

GetJournalIndex looks for a specific journal index, not just the last one. What it does is it tests the current journal index against the one you're testing for. It's true that it won't test to see if the player missed a journal index, for that you'll need to use variables to set whenever a player completes a part of the quest.

After a bit of testing, this is what I've found:

GetJournalIndex, "A1_Dreams" returns the current journal index for that topic. This is 0 by default.
SetJournalIndex, "A1_Dreams", 5 sets the journal index to 5, regardless of its current value.
Journal, "A1_Dreams", 5 sets the journal index to 5 only if its current value is below 5.


So in a test scenario, after starting a new game:

GetJournalIndex, "A1_Dreams";Returns 0Journal, "A1_Dreams", 10GetJournalIndex, "A1_Dreams";Returns 10Journal, "A1_Dreams", 5GetJournalIndex, "A1_Dreams";Returns 10SetJournalIndex, "A1_Dreams", 3GetJournalIndex, "A1_Dreams";Returns 3;Even though there is no entry at index 3 

Saving, loading, or restarting the game doesn't seem to affect the results for me at all, contrary to the behavior descriped in the Morrowind Scripting for Dummies.


So GetJournalIndex either returns the highest index in the topic, or the last one it was set to. In neither case can it be used for checking for specific journal entries. :wacko:

Very odd results. So the main question comes down to whether this function can in reality test for a specific journal entry. I am going to run a few test cases in a few days. I am going to try using the tax collector quest and do a variety of tests. I need to see
what situations of this function return what. It seems kind of add behaviour, but in reality if it's able to do that reliably then it would be immensely helpful. Once I play around wiht it some more here I will post the results here.

SetJournalIndex does just that: it sets a journal's index to whatever number you tell it to. There doesn't have to be a journal entry there for it to work. Journal, on the other hands, needs a valid journal entry for it to work. GetJournalIndex is great for testing: it can tell if a journal index is a specific number, if it's less than or equal to that number, if it's less than but not equal, if it's greater than or equal to, if it's greater than, or if it's not equal to. I'm starting to think that you guys are over complicating this.

Either way, I believe in the first post businessman332211 asked about a way to check for specific journal info (not only the highest index). GetJournalIndex won't do that, as it only returns the highest index in a journal topic. It's great for its own purposes, but it still cannot do that.

Sorry if I'm splitting hairs here, but I think there is a significant difference between those two behaviors and I wanted to make that clear.

GetJournalIndex will return the current journal index, not necessarily the highest because SetJournalIndex can be used to set a journal index to any number, regardless of whether or not it's an actual journal index. Journal, on the other hand, needs an index that has already been added for it to be used. So, GetJournalIndex will not always return the highest index number.

That's true, but unfortunately that doesn't help with the current situation if the quest needs to remain retroactive. If the developers used SetJournalIndex, or better yet, a local variable to update with the different quest stages as they happened then it would be fine, but no such in-game records exist in the vanilla game that would indicate what choices the player made while doing this particular quest.

So I think it comes down to either sacrificing functionality or retroactivity, in a manner of speaking. :rolleyes: