Weirdest Issue I Have Ever Had! (RESOLVED!)

Lance_Botelle · July 22, 2023, 3:36pm

This is now the second time it has raised its ugly head, and I have no idea what causes it, but now simply ask if anyone else has experienced anything similar …

I have a journal entry update to a state 2 when a player enters an area and it is currently on state 5. In this example, that journal update happens, and my wife saved the game. HOWEVER, on a reload of that same saved game that should have been state 2, the journal state had reset to 5!

Checking the files, this state is only ever updated to 5 from a conversation with a NPC in another area, which, in itself can only happen the once!

Has anyone else ever experienced a journal entry change on a reloaded saved game, where it is supposedly in a state different to what its reload point should say?

Shallina · July 22, 2023, 4:19pm

In BGR i had a lot troubles with “state” in the game journal for various reasons. Can’ t remember them all.

In SOAR I have only one STATE for one CATEGORIE.

Lance_Botelle · July 22, 2023, 4:22pm

@Shallina

Thanks for reporting …

It is the strangest thing though, especially as it is the only journal state I have that has repeatedly had this issue. I am now considering having this particular journal state save as a backup global variable as well, which can then be compared and “fixed” if found its gone awry.

Shallina · July 22, 2023, 4:23pm

It may be tied to the character.

Try with a new one.

Lance_Botelle · July 22, 2023, 4:33pm

@Shallina

As I have it written, the variable is tied to (held) the module, and is set 3 seconds after the PCs enter the area. This is confirmed by the usual journal update and my wife reading the updated entry in the journal. My wife then saved the game and, just to test, reloaded the game, only to discover that latest journal entry was no longer in place, but had reverted to its previous state (prior entering the area where it had been updated).

The biggest problem is that this is inconsistent. So later tests did not have a problem with the missing change. I am trying now to do a deep dive into the code to try to find anything else - For example, it may also be a case that the engine does not handle going to a lower journal state very well, even though that parameter is set within the function that sets it. Or, as another example, there is a state 3 which sits between these two states, which is a “finished” state. In theory, none of these should be (and are not always) an issue, but maybe…?

If it’s a simple enough task to reassign the finished 3 state to fall later in the state numbers and up with the other finished states, then maybe, perhaps, that will help, somehow? although, honestly, I am clutching at straws here at the moment to fathom out what is actually going on.

Shallina · July 22, 2023, 4:36pm

Many things are held inside the character, that’s how they make it able to cross “modules”.

If it’s a “campaign journal”, the state may be saved in the characters.

I am making a patch for BGR to bring in some of the “bell and whistle” from SOAR, and sometime I import a character which have finished the campaign to test it. Everything is supposed to be 100% in the module and rebooted since it’s a “restart”, but the game act as if I have already played it on that character.

Lance_Botelle · July 22, 2023, 4:44pm

@Shallina

Oh yes, I hear what you are saying, and I have a tool that helps me to check that state on the Main PC too … Here, this section shows some of the current journal states held on the Main PC.

Later in this report, it confirms that the state in question is at the correct state, and has (when failed) shown it to be in the incorrect state. I am trying to work out what can possibly have changed that state between the saves, especially without any obvious feedback - as if the state never truly existed/updated on the Main PC.

Here is the data at save time and reload time … Note the difference in the journal state 2 v 5 - It was saved at the 2 state! The only thing done between these two events was a little crafting.

Lance_Botelle · July 22, 2023, 5:59pm

UPDATE: I believe I have found a possible consistency in the failing … It appears that the issue may well be related to the current PC possessed at the time of transitioning, and thereafter receiving the journal update. A timing issue with a possessed PC and moment of journal acquisition, which is somehow failing to update all PCs, especially the Main PC.

I.e. It can “update” for the player, but fail to store the variable if the PC is in the process of shifting player possession.

Looking closer …

Shallina · July 22, 2023, 6:17pm

update the journal for all PC faction member, or only Faction leader. Not possessed PC

Lance_Botelle · July 22, 2023, 6:29pm

@Shallina

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.