7 réponses à ce sujet

[Lance Botelle]

Hi All,

As some of you will know, I am alpha testing my module at the moment, and so I am doing some "frequent" script updates between saved games to resolve some issues.

Now, rather than use the priority hak system I intend to use to fix potential issues after release, I have simply been updating campaign files as normal, but adding altered module files to the override, playing the mod past the problem point, saving the game, and then removing the (now no longer required) module files, before reloading to continue the testing.

This appears to work reasonably well .... apart from I have started to experience some unusual area transition problems when clicking on a door ... they simply no longer work.

If I restart the module from afresh, all works as it should.

My question is, does anybody have any ideas why the module saved game may be acting this way? Are we talking some sort of weird corruption perhaps? Or, has anybody else experienced this problem and ever discovered what caused it?

At the moment, my guess is that it is something to do with the testing process I am running (as described above), but I am trying to understand what about I am doing is potentially causing this.

Cheers,
Lance.

[rjshae]

Does your transition door have a script in the On Used slot? Perhaps something is awry there?

 

Possibly you could verify that the area transition still functions by using the RunScript debugger command to execute ga_jump_party( "dest_tag", 1, 1 ).

[Lance Botelle]

Does your transition door have a script in the On Used slot? Perhaps something is awry there?
 
Possibly you could verify that the area transition still functions by using the RunScript debugger command to execute ga_jump_party( "dest_tag", 1, 1 ).

Hi rjshae,

That's the weird part .... debug feedback still detects the PC clicking in the door from the script to fire! It really looks like the game simply no longer knows how to do the transition.

And here is one other thing that is strange: One time I was able to swap PCs by clicking between the portraits and then the first PC *would* transition OK.

I have seen nothing like this before.

Cheers,
Lance.

[kevL]

Does it glitch-out only for "not truePC" clicks? ie, companions.

if so,
consider using SetOwnersControlledCompanion() before door-clicks, and other things that may *require* the truePC as actor.

now, I don't like it and ideally it should never be "required" -- because it can switch, and is usually used *to* switch, the Player's controlled character to his/her main character (if not already controlled). Think of it as a failsafe; it's used before area transitions in the OC, eg.


i don't like it, Lance, but setting it up on the door-click might help figure out what's going on,

--
a second thing to try is a Delay.

That is, have the onClick script call a subfunction that does the actual transitioning on a DelayCommand(). That effectively moves the transition-code-execution outside the onClick event itself, and so it runs *after* the engine gets a return from the onClick event.

- am thinking the actor-object might have itself sorted out a bit better then

[kevL]

oh, if you added a file to \Override, the game needs to be reloaded from desktop. ( not always true when merely altering an existing file )

[Lance Botelle]

Hi KevL,

Okay, I had a large response here, which I have now scrapped for clarity ...

The bottom line is, I had this in my script (notice the error), which I have now replaced with the code further below.
 

// FOR CONVERSATION SUPPORT (MUST TAKE PRIORITY)
	
        object oPC = GetPCSpeaker();} 
	if(oPC == OBJECT_INVALID){GetClickingObject();}     /// MISTAKE HERE MISSING "oPC ="
	if(oPC == OBJECT_INVALID){oPC = GetLastUsedBy();}  		
	if(oPC == OBJECT_INVALID){oPC = GetLastOpenedBy();} // CAVE DOORWAY HANDLING 	

NEW CODE (Greater checks for a valid PC.)
 

	
	// FOR CONVERSATION SUPPORT (MUST TAKE PRIORITY)
	
        object oPC = GetPCSpeaker(); 
	if(oPC == OBJECT_INVALID){oPC = GetClickingObject();}
	if(oPC == OBJECT_INVALID){oPC = GetLastUsedBy();}  		
	if(oPC == OBJECT_INVALID){oPC = GetLastOpenedBy();} // CAVE DOORWAY HANDLING 	

Unfortunately, even after making these cde changes, which *does* appear to fix the major issues, I am still left with an occasional spurious weird event when transitioning, which may be due to earlier transitions being stored somewhere in the save game code, which my "fixed" code is somehow missing?

I don't know. The bottom line, I am going with the restart to play it safe anyway. Oh well.

KevL: Thanks for helping me pursue this to get to the bottom of it.

Cheers,
Lance.

[kevL]

2dy. later : yeh idk, go with the restart

( but my attitude is still that solid scripts are solid scripts, even in NwN2 )


oh, one thing to remind you of, is that some of those getters work in more than one event-type, maybe the same or slightly differently. Like, GetClickingObject() & GetLastUsedBy() are similiar and there's another pair that escapes me atm; GetEnteringObject() & ....

but I don't think that's the issue here since it looks like they're all pointing to oPC anyway.

[Lance Botelle]

2dy. later : yeh idk, go with the restart

( but my attitude is still that solid scripts are solid scripts, even in NwN2 )


oh, one thing to remind you of, is that some of those getters work in more than one event-type, maybe the same or slightly differently. Like, GetClickingObject() & GetLastUsedBy() are similiar and there's another pair that escapes me atm; GetEnteringObject() & ....

but I don't think that's the issue here since it looks like they're all pointing to oPC anyway.

Hi KevL,

Yes, those "Get" commands can be similar, but apart from that glaringly obvious typo, I am still uncertain what was causing the "slow decay" of the saved game.

GOOD NEWS: The latest run through is going well, and I intend to do another update soon. (I have posted a couple of screenshots in the module post in the last post - edited in: http://forum.bioware...ing-23b/page-15 )

Cheers,
Lance.