The Scroll - MP SAVE GAME FIXED! (*** SEE REGULAR POST ***)

[Lance_Botelle]

Hi All,

In the last week or so, you may have seen that I have been having problem with SAVED GAMES failing to reload - refusing to offer the SAVED GAME version of the PC to load into the MP game. At least, I am being offered as the HOST, but both a LAN and WAN player are simply loading afresh as if NO SAVED GAME FILE for their PC within the saved game exists! i.e.

1. Start a MP game.

2. Players join the MP game.

3. We save the MP game.

4. I exit game and reload the MP saved game.

5. I use my DM to enter game, and get offered to choose either the SAVE GAME or LOCAL VAULT. (Normal)

6. My friends (LAN and WAN) go to join and enter the game WITHOUT being asked where the PC is being loaded from (like I did).

This only started happening in the last two weeks. We even restarted the game to test afresh and it still fails for them. I even went back to an earlier build (where we were OK) and the players still no longer get offered the choice of PC to use within the game.

Any help appreciated as this is a real MP game stopper. I will let you know if I discover anything.

Thanks in advance, Lance.

[kevL_s]

check the NwN2 .Ini files, especially on the host …

the engine could have rewritten them (?)

[Lance_Botelle]

Hi Kev_L,

Thanks for the response. I checked these (in the game directory as opposed to my files) and they are OK.

UPDATE: I have gone back ten builds and the game appears to reload OK there, so I may just have to do some painstaking backtracking. Although, how MY files have managed to bypass the NWN engine saved game option is anybody’s guess. In fact, if you know how and where this is possible, that may be a place for me to start looking. My guess at this stage may be an XML perhaps.

If you have the time and felt it worth investigating, the problem is relatively simple to reproduce:-

Download, install and start a DM hosted MP game. Have a player join (can be LAN), save the game, then exit to desktop. Reload the game. The option to choose the saved game position is no longer an option for the joining player.

v2.07 appears to work - I now have to see which of my versions between then and now (2.17) appears to break this engine option.

I will keep you posted. And thanks again for chipping in - any and all help is very much appreciated, as this is a real downer.

Lance.

[kevL_s]

unfortunately i know very little about MP – perhaps somebody else could give it a shot

 
things I’d look for

• a flag that references something that’s hardcoded (ie, that references something engine-side)
• a directory mixup of some sort (eg. missing directory, pointer to a directory [localvault/servervault] is funky)

And, y, have a close look at that XML file and its predecessor(s)

[Lance_Botelle]

Hi KevL,

Yes, I agree with you on that. Although, I have just tried “loading” a 2.07 module save into a v2.17 campaign (using all latest XML files both sides) and that loads OK. So, I guess I am stuck with the slow reverse checks. I am about to test v2.12 as that was prior to new Area Clean Up code.

Will keep you updated.

Cheers, Lance.

[Lance_Botelle]

Hi KevL,

I believe I found it: alb_comp_heartscript (line 57): The bold part was not in place …

if(GetName(oMainPC) == “” && oPCORCOMP != oMainPC){TEMPRemoveCompanionFromParty(oPCORCOMP); return;}

This function called a routine that removed companions with “Roster” functions, such as RemoveRosterMemberFromParty and RemoveRosterMember. I believe it was one of these that caused the problem. However, I also have these calls from another script that may have caused the same sort of issue, and so I will check that too. (RemovePCFromWorld called from an OnEntry check.)

So basically, the player’s Main PC, which shares the same heartbeat as the companions, was being removed from the roster and saved game reservation on a heartbeat upon entering the saved game! (I was not checking to make sure the MainPC did not remove themselves.) This code was added with version 2.14, so any reloads after that would version was installed would fail.

Hence all sorts of problems as the game thought the returning player was “NEW” and so my own checks kicked them back out believing the PC was already in the game. At last!

Thanks for sticking with me. Lance.

[kevL_s]

if (GetName(oMainPC) == "" && oPCORCOMP != oMainPC)
{
    TEMPRemoveCompanionFromParty(oPCORCOMP);
    return;
}

(I was not checking to make sure the MainPC did not remove themselves.)

 
makes sense. I’d keep an eye on that condition-check though… it just feels fishy although ofc I can’t say for sure,

I mean, blank for the name of oMainPC (i guess it’s possible).

and i thought player-characters never go on the Roster, technically – that it’s for Companions only.

Why does the condition use GetName(). Would it be better to use (!)GetIsObjectValid(oMainPC)

I mean, from a superficial point of view (i’m not reading the script) here’s an alternate perspective –

if (GetIsObjectValid(oPCORCOMP)
    && (!GetIsObjectValid(oMainPC) || oMainPC != oPCORCOMP))
{
    TEMPRemoveCompanionFromParty(oPCORCOMP);
    return;
}

 
 
/ just ideas – you know what’s going to work so dont feel bound to answer this stuff indepth

[Lance_Botelle]

Hi KevL,

The oMainPC object is a result of my homebrew custom function GetMainPC(), which gets the (main player master) object stored on the companion themselves. It was a very early function from the first days when I was struggling to get the main player object with the OC functions available when trying to consider SP and MP gaming and knowing the players could be controlling any number of companions, even each others (which they can do in this campaign). There may be OC ways of doing it, but with all the different variations of “Get” functions for PCs and FactionMembers, with respect to the TRUE or FALSE parameter, I was always finding myself falling into trouble. Hence, my homebrew function that always returned a valid object : effectively, the main pc of the player controlling that companion at any given time.

The reason I even have this check is somewhat minor, and was simply added to stop players having to “quit companions” and “re-invite them” upon reloads. Again, somewhere between reloads, the companions “lost” their associated player when playing in a MP game … and the check I could do to see this “in action” as it were, was by noticing that the returned object (although WAS STILL VALID) if I recall correctly, did not, however, know what the actual object was. The easiest “test” for this (as I saw it at the time) was that the “valid” object (which obviously was not), did not return a valid name - hence the == “” check.

I think there is something that happens to these variables between reloads in a MP game that does not occur in a SP game. This seemed to be verified by the fact that I could NOT duplicate the error in a SP game, even without the extra fix I mention above. i.e. Like you say, the main PC does not appear to play any part (or have any issue) as this check being absent in the SP test appears to demonstrate.

It may be possible that GetIsObjectValid would work where my own earlier test only had oPCORCOMP != OBJECT_INVALID. I still do not understand how GetIsObjectValid compares to the test against an INVALID_OBJECT, except that for this very reason perhaps?

Anyway, this does appear to fix the issue, but I cannot test it in our current session until my WAN player is available. It does fix it in all my LAN testing.

Please continue to offer feedback, especially if it helps me to learn more.

Thanks again, Lance.

[kevL_s]

Hence, my homebrew function that always returned a valid object : effectively, the main pc of the player controlling that companion at any given time.

ah  :)

 
I don’t know what’s going on there w/ GetIsObjectValid vs. GetName() == “”

 
on a side note, though related, don’t trust GetIsRosterMember() out-of-the-box as it were. I’ve found that a character that was on the Roster but has been removed still returns TRUE. (ie, best cycle through the roster-names to determine if a character actually is currently on the Roster)

 
anyway / sounds like you got tread on the road again

[Lance_Botelle]

GetIsRosterMember()

Hi KevL,

Yes, that’s the sort of thing that can catch one out. Thankfully, I have only left that particular function in place in my scripts where they are extensions of the OC code anyway.

Yes, hopefully, we will actually get a session of gaming done in the next one rather than just beta testing!

Cheers, Lance.

[Lance_Botelle]

Sadly, even after restarting the game with the latest v2.18, the save game issue still remains. In testing, the stable version was v2.12. I am going to rebuild from this version and release v2.20 when available.

Please see The Scroll - v2.18 MP RELOAD QUESTIONS - (Can A Game Reload Twice - playerlist.ifo Info Required)

Sorry about the problems.
Lance.

[Lance_Botelle]

The Scroll - v2.18 MP RELOAD QUESTIONS - (Can A Game Reload Twice - playerlist.ifo Info Required)

Hi All, Well, after some more quick testing, I have been unable to see exactly if there is any specific error in my code. The only thing I have been able to find is that the playerlist.ifo (which appears to carry the list of players and their saved PC) shows a double entry for my player on WAN. One entry for one named PC and another with a PC with only the first name and not any second. This would imply (or looks like) that during testing the player either reloaded with a PC of a different name…