on exit scripts and PC location

[Korennya]

So. A PC leaves an area and the on exit script is triggered. The exit scripts wants to see what area that PC is in. Where is the PC? IS the PC considered in the first area until the exit script completes? or is the PC in the next area already? IE. script calls GetArea(oPC). What is returned? area 1 or area 2?

[tizmo]

I haven't tried to know for certain, but you could make a tiny test by linking 2 areas and adding debug output to your code. Use SendMessageToPC() to print the area name to the server log.

[Gorgon]

Be aware that OnExit doesn't fire when PCs log out, and you need to use it in conjunction with OnClientLeave to get the desired effect sometimes (The link to OnClientLeave describes it pretty well ). The cleartrash script has this problem, but was never updated to deal with it, so PCs who run through an area and log out end up leaving their crap on the ground until someone else triggers it.

I'd assume the PC would still be in the original area as far as the OnExit script is concerned, unless you have some sort of delay that is checking it after the script executes, but that simple test of tizmo's should confirm it.

[Korennya]

Have you two been able to get the script debugger to pop up running win10? I'm in windowed mode, the debug server is running, but the window that shows the code line by line and the variables isn't coming up. I get a flash or something. Some sort of error message but it goes by sooo fast that I can't see what it is

[Gorgon]

I don't use it on Win 10, and avoid it if at all possible. It is great for finding issues when all else fails, but a pain in the ass to set up the debug symbols and slow.

Usually you can do the job with your own debugging code, using things like SendMessageToPC() or WriteTimestampedLogEntry(), and even keep that code in the scripts for later use with a debug variable or constant (Boolean or debug level settings).

If you do need it, I'd assume the same "Run as Admin" and XP-SP3 compatibility mode settings would be needed to use it properly, as with the game itself. Even more-so actually. Not sure what else I can suggest, but others have more experience with Win 10 and game issues than I do.

[Gorgon]

You probably already checked this, but did you compile the script with debug information on? Not only do you need the SpawnScriptDebugger() function in it, but you also need to enable it in the toolset options (and a few others standard quirks with window mode), all before recompiling. Also run the server itself. All of that is covered in the function link there.

*I'm assuming the integrated new script compiler with nwntx handles the "Generate Debug Information When Compiling Scripts" option the same as the standard toolset does, but if you are using an external compiler, you'd need to enable things through it as well (however it does it).

Like I said, I find it to be a PITA, unless I really have no other choice, and also you have to remember to turn off all that again before it can be used live (I know everything gets recompiled after submission at least).

Good luck.

[Korennya]

Yeah, I have all that setup as you mentioned. When the first area loads it pops a little window saying that the debugger is running and to switch windows to monitor. But there's nothing actually there. Triggering the offending script flashes a super fast box in the game that I cant read. Game pauses for a split second and resumes. No idea. I ended up debugging it manually with a shit ton of PC messaging to find out where the problem was. A { was one line to low. Got it all sorted and hasn't popped a single TMI. Just need to go back and remove (or comment out) all the debug junk I had to put into it. So.. should be fixed, and I made some minor improvements to it at the same time.

Thanks for the help.