ACR debugging
Moderators: ALFA Administrators, Staff - Technical
- AcadiusLost
- Chosen of Forumamus, God of Forums
- Posts: 5061
- Joined: Tue Oct 19, 2004 8:38 am
- Location: Montara, CA [GMT -8]
- Contact:
ACR debugging
Found a few loose ends that have been causing problems, don't have time to test them all tonight though.
It seems that OnClientLeave() we're only saving the rest timestamp, but not actually calling ACR_PCSave(oPC, FALSE) to record the final HP totals, etc- hence the exploit problem with combat and death/bleed logging. Any reason we /shouldn't/ add an ACR_PCSave to the ACR_PCOnClientLeave() function?
Also, discovered a bug in the offline resting / bleeding controls, the update performed on the PC OnLoaded uses a 0.3 second DelayCommand to apply any archived/saved damage, meaning that damage doesn't exist when we're caching the GetCurrentHitPoints() for RestOnClientEnter(), nor when we check the bleeding flag against the number of HP. Any objection to delaycommand-ing RestOnClientEnter, say, 1.5 seconds?
Initial testing looks promising for these two fixes.
It seems that OnClientLeave() we're only saving the rest timestamp, but not actually calling ACR_PCSave(oPC, FALSE) to record the final HP totals, etc- hence the exploit problem with combat and death/bleed logging. Any reason we /shouldn't/ add an ACR_PCSave to the ACR_PCOnClientLeave() function?
Also, discovered a bug in the offline resting / bleeding controls, the update performed on the PC OnLoaded uses a 0.3 second DelayCommand to apply any archived/saved damage, meaning that damage doesn't exist when we're caching the GetCurrentHitPoints() for RestOnClientEnter(), nor when we check the bleeding flag against the number of HP. Any objection to delaycommand-ing RestOnClientEnter, say, 1.5 seconds?
Initial testing looks promising for these two fixes.
- AcadiusLost
- Chosen of Forumamus, God of Forums
- Posts: 5061
- Joined: Tue Oct 19, 2004 8:38 am
- Location: Montara, CA [GMT -8]
- Contact:
Allright, have gotten the resting, death, bleeding, etc systems pretty stable and functional, though I still notice 2 oddities, one of which is potentially disruptive to players.
When entering the module after having been logged off longer than a rest cycle (2.8 RL hours), the PC location is being overrwritten with that of the start location. It would seem a ACR_PCSave() or something similar is updating the characters table and overwriting the properly stored PC logout point with a transient starting location (or at least interrupting the AssignCommand() that should be jumping the PC to their last known location.
Open to any ideas or fixes on this one, it's resisted a few attempts to narrow down and eliminate.
When entering the module after having been logged off longer than a rest cycle (2.8 RL hours), the PC location is being overrwritten with that of the start location. It would seem a ACR_PCSave() or something similar is updating the characters table and overwriting the properly stored PC logout point with a transient starting location (or at least interrupting the AssignCommand() that should be jumping the PC to their last known location.
Open to any ideas or fixes on this one, it's resisted a few attempts to narrow down and eliminate.
- ç i p h é r
- Retired
- Posts: 2904
- Joined: Fri Oct 21, 2005 4:12 pm
- Location: US Central (GMT - 6)
Missed this thread before, but the reason we can't call the global save function OnClientLeave is because the player is already gone. As such, location information cannot be determined, which is probably what's causing the location reset issue you're running into.
It'd be nice if OE fixed this, but it's unlikely they will. One solution might be to pass in a boolean bSaveLocation to the save function to determine whether or not location should be saved as well. Alternatively, just save hitpoints on clientleave if the player is dying. Player stats are saved on death so nothing else should have changed.
It'd be nice if OE fixed this, but it's unlikely they will. One solution might be to pass in a boolean bSaveLocation to the save function to determine whether or not location should be saved as well. Alternatively, just save hitpoints on clientleave if the player is dying. Player stats are saved on death so nothing else should have changed.
- AcadiusLost
- Chosen of Forumamus, God of Forums
- Posts: 5061
- Joined: Tue Oct 19, 2004 8:38 am
- Location: Montara, CA [GMT -8]
- Contact:
I read some detailed analysis of the OnClientLeave() event, and the gist of it was that the Player is already gone by the time this event fires, but the PC persists long enough to record location and other critical statistics. So, attempts to glean GSID, CDkey, etc need to rely on caching local variables, but there is still a window for recovering other data.
I've got my code running on the OAS2 currently if you'd like to try it to confirm- seems pretty reliable for recording damage to PCs even with speedy combat logs or during bleeding/death. As far as I can tell, it works well and is solid.
With regard to the loss of last stored location, may require a bit more hunting. Could be the ForceRest() wiping the action queue and overriding the AssignCommand() to jump to the location, could be a problem with the ACR_PCSave in the area_onenter (oncliententer?) event, or it could be the initialization of the PPS cycles (which may also try to save the PC). I may have some time to poke at this behaviour tonight.
I've got my code running on the OAS2 currently if you'd like to try it to confirm- seems pretty reliable for recording damage to PCs even with speedy combat logs or during bleeding/death. As far as I can tell, it works well and is solid.
With regard to the loss of last stored location, may require a bit more hunting. Could be the ForceRest() wiping the action queue and overriding the AssignCommand() to jump to the location, could be a problem with the ACR_PCSave in the area_onenter (oncliententer?) event, or it could be the initialization of the PPS cycles (which may also try to save the PC). I may have some time to poke at this behaviour tonight.
- ç i p h é r
- Retired
- Posts: 2904
- Joined: Fri Oct 21, 2005 4:12 pm
- Location: US Central (GMT - 6)
If it *is* saving location now, then that's great news! I know that at least a few patches ago (1.04?), I could not obtain a valid location when a player logged off, and I read posts by others confirming the same behavior on the NWN2 boards. It's also a problem that existed in NWN1 and is confirmed by the nwnlexicon (see GetLocation).
If you can confirm that GetLocation does work now on players that log out, then it's a big improvement in the game. Hallelujah!
If you can confirm that GetLocation does work now on players that log out, then it's a big improvement in the game. Hallelujah!
- AcadiusLost
- Chosen of Forumamus, God of Forums
- Posts: 5061
- Joined: Tue Oct 19, 2004 8:38 am
- Location: Montara, CA [GMT -8]
- Contact:
I had this sinking feeling reading Cipher's post... and yes, it turns out the location isn't saving OnClientExit(). I had thought we had a separate bug overwriting the last saved location with 0/null on login, but as it turns out, it's that onclientexit event wiping the last location with an attempt to pull location from the departing PC.
I do believe the all-important "damage" stat is exporting though, so I think I'll just be trying to juggle things to save to DB without location update. May require adding a variant version of the ACR_PCSave() function, though alternatively I could add a third operand (defaulting to TRUE) on whether to export location to the existing function.
Thoughts?
I do believe the all-important "damage" stat is exporting though, so I think I'll just be trying to juggle things to save to DB without location update. May require adding a variant version of the ACR_PCSave() function, though alternatively I could add a third operand (defaulting to TRUE) on whether to export location to the existing function.
Thoughts?
- ç i p h é r
- Retired
- Posts: 2904
- Joined: Fri Oct 21, 2005 4:12 pm
- Location: US Central (GMT - 6)
- AcadiusLost
- Chosen of Forumamus, God of Forums
- Posts: 5061
- Joined: Tue Oct 19, 2004 8:38 am
- Location: Montara, CA [GMT -8]
- Contact:
- ç i p h é r
- Retired
- Posts: 2904
- Joined: Fri Oct 21, 2005 4:12 pm
- Location: US Central (GMT - 6)
- AcadiusLost
- Chosen of Forumamus, God of Forums
- Posts: 5061
- Joined: Tue Oct 19, 2004 8:38 am
- Location: Montara, CA [GMT -8]
- Contact:
Had a productive evening- got the time advancement bug as well, and managed to work in logging and tracking for the classic exploits of combat-logging, bleed-logging, and looting one's own corpse.
Also addressed a minor bug with the offline resting system making a fatigue check with armor when in the 1-day (but less than 2 days) offline case. Just a > where a >= was needed.
I'm pretty pleased with the state of these systems currently- only lingering oddity is PCs being resurrected get logged as if they are looting their own corpse (because, in a way, they are).
Haven't looked at the quest system yet, but as soon as it's workable we should bundle up a new alfa_acr.hak IMHO.
Also addressed a minor bug with the offline resting system making a fatigue check with armor when in the 1-day (but less than 2 days) offline case. Just a > where a >= was needed.
I'm pretty pleased with the state of these systems currently- only lingering oddity is PCs being resurrected get logged as if they are looting their own corpse (because, in a way, they are).
Haven't looked at the quest system yet, but as soon as it's workable we should bundle up a new alfa_acr.hak IMHO.