Yes, I think it may be related to this, but … I believe it is also because of the timing of the campaign setting that forces all other PCs to keep in synch with the leader …
So, the problem is a bit like this, and bear in mind that this only appears to break for this transition, which is odd when you consider this is not the only onenter transition where the journal is updated. So, here is my current thinking …
This particular transition is between two largish areas, probably the biggest two areas in the game, and so therefore, there is the added element that may be making a difference between certain timings of PC possessions that cause this particular transition to “fail” with respect to a journal update because the journal update fires a bit later at a time when the PC being controlled has returned possession (that is how my campaign works). So, at that time, the journal is updated (slightly too late for this particular transition) for that faction member, and even when I switch to the main PC with the journal still open, it appears as if it is good there too. However, closing and reopening the journal at this stage has proven that the stage has indeed NOT changed for the Main PC!
BUT, then the campaign setting kicks in and because the state has NOT updated on the Main PC as I thought it had, then every PC faction member is reverted back to the state held on the Main PC!
I believe that is going to be the issue! I will confirm with a positive result if this is the case.
UPDATE 1: OK, this is not quite as “simple” as it seems, as this piece of code suggests that the Main PC (the leader) is indeed receiving the update for the party …
SendMessageToAllPCs("JOURNAL pc > " + GetName(oPC) + "\nJOURNAL STATE > " + IntToString(nState));
AddJournalQuestEntry(sJournID, nState, oPC, TRUE, FALSE, TRUE);
Furthermore, when we open the journal on the Main PC, it is indeed showing the correct journal update. However, I have a function that I use at around the same time that is somehow interfering with this apparent result, because when you switch to another PC and back, this journal entry has reset!
In testing, if I remove this other function (that does some internal switches required to fix another OC issue), it fixes this point. So, a full workaround where I can keep this function in place is still being investigated …
UPDATE 2: OK, I have managed to move the offending function to a timed execution after the journal requires updating, which stops that function interfering, but fires its own fix just after.
I will be releasing another version of my module to cover this potential quest breaking bug!
UPDATE: I also wanted to add that there appeared to be another potential issue with the AddJournal function, where its parameter to allow lower to overwrite higher entries appeared to fail if (a) The canpaign synch with leader was set TRUE and/or (b) there was a finished quest state between the two. Bottom line, I had to resort to removing an entry prior updating to ensure it worked alongside my own function.