Having read the change log for the new Development release ([89.8193.37-11] - 2024-10-01), I have some questions that I hope someone can help answer.
Logging has been redone: All engine logs now go into nwenginelog.txt, with a new and improved format.
NIT reads the log file (nwclientlog1.txt) to determine how long a particular mod has been played. It relies on the format of these log entries…
[Thu Nov 02 18:17:24] Loading Module: ModuleName
[Thu Nov 02 18:34:37] Server Shutting Down
Known date formats are “ddd MMM d HH:mm:ss” and “ddd MMM dd HH:mm:ss”
Does this need to be changed for the Dev version or is this information still written to nwclientlog1.txt?
Crash reports are now written to directory “crashreports” in the user directory in a new unified file format.
NIT checks for files starting with “nwmain-crash-” and offers the user options to send or delete the log files.
Does anyone have any information on what file/s are written to the “crashreports” folder and whether reports are still submitted to (https://beamdog.atlassian.net/servicedesk)?
The game now has a new keytable, nwn_retail.key (+ various bif), with the contents of the ovr/ directory.
Does the ovr directory still operate as before when files are added?
Many thanks for any information or help you can provide.
I [21:12:39] (serverexoappinternal.cpp:2162:LoadModule): [Sun Oct 6 21:12:39] Loading Module: FolderName\ModuleName
...
I [22:07:57] (serverexoappinternal.cpp:3789:StopServices): [Sun Oct 6 22:07:57] Server Shutting Down
Would you be kind enough to confirm that nwenginelog.txt is created in the user files logs folder?
Also, are you able send me a copy of your nwenginelog.txt file after you have finished a session where you have loaded a game save more than once. I want to use the file to perform some tests.
I guess the first question is, why?
What is your scenario?
Pretty sure there is a CashPlease option somewhere, I think it needs to be entered in the console.
Per Clippy:
Typing ##PleaseCrash in chat should do it. Or PleaseCrash in the aurora console. It is an actual command that exists for this exact reason. It should be enabled on public builds too.
Only a few days ago I had an reproducible crash when I tried to do something using nwscript console. Basically it was turning a (broken) json into a template like:
@Qlippoth and @Kamiryn
Many thanks for your help. In the end I went with PleaseCrash, which worked perfectly.
Is it only me, but answering OK to the crash message does not close NWN - it simply displays the message again. I have always had to use the Task Manager to close NWN.
I needed to use the @Kamiryn script to crash the released version so I could submit a bug report about NWN having to be closed with the Task Manager after a crash, because using the @Qlippoth method just closed the Retail version of NWN without displaying the crash message.
I guess the ovr folder still works as it used to, so I will mark this as answered.
Please share the exact log prints your application depends on. I can add them back to nwclientlog.txt, though the timeline for this is short - 37 will be on stable soon.
Send where? Delete why? Please explain what you are doing to these crash reports. We have some vague plans on sample submission for these, so collaborating on this would be good idea.
No. ovr/ is no longer read by the game at all. We do not want users to touch the installation directory, just the user dir. The remaining nwscript.nss file in there is a concession to nwnsc, which needed it to operate. The authoritative source of truth though is in retail.key.
The split between the log files is explained as follows:
nwenginelog.txt is a new file and format. There is no “institutional knowledge” about this, forum or otherwise, as it is new.
This is part of the attempt to address the atrocious logging/introspection situation that’s pervasive throughout the game. For example, the newly-added Tracy functionality opens up a lot of doors for authors without source access to debug performance problems that were previously entirely out of reach.
Analogously, this new log format affords opportunity for authors and players to gain a lot of understanding about issues seen that were previously unclear. This requires a fundamental rearchitect of the log system, as the pre-existing single logfile was just not acceptable to spam with a lot of debug info going forward.
95% of the prints you see in it are entirely new or newly exposed.
It is currently not designed to be parsed by programs. It is not a stable format. It is a purely human-readable file; and I reserve the right to change the format, the prints in it, and the frequency or location/purging behaviour as needed by new discoveries or engineering decisions made. (But once this format stabilises, we can discuss adding e.g. JSON output.)
For example, the logs also go into a internal memory ringbuffer and are emitted to crashlogs. A future change might add opt-in remote instrumentation for ASSERT type events to help developers figure out hard-to-trace issues. Logs print like that might again disappear from enginelog and go into other files. This is NOT intended to be a “stable ABI”; these logs are for humans to read, developer or otherwise, if and when they need to diagnose a live problem.
nwclientlog.txt is the old, “legacy” format. It retained the old format and prints exactly for the reason seen in this thread: some programs parse this; mainly chatlog archivers; and a lot of serverside tooling on PWs uses this log for data exfil into external programs. The format of this file is not going to change going forward.
All the non-sensitive prints have been looked at, cleaned up, reformatted and put into enginelog where appropriate. Concessions have already been made both for script systems we saw in place, and obviously sensitive data, like chatlogs. This file is never included in crash reports or log submissions by users, unless they explicitly choose to include it.
Again, please share the logs you need for NIT, @Surazal, and we can work on re-including them for 37 stable to not break this usecase.
First, I already have a version of NIT that uses the engine log to get the information.
However, here is how NIT parses the log…
Ignore lines that do not begin with “[”.
Extracts the date and time as well as the folder\file name of entries containing “Loading Module:”
Uses the date and time of the “Server Shutting Down” entry to establish how long the Mod was played.
Changes made to support the Dev version were…
Detect which version of NWN is being used to determine which log file to use.
Only process lines that begin with “I [”.
Scan the full line for “Server Shutting Down” and “Loading Module:” rather that rely on the character position that the client log used.
I have already changed NIT to look for the crash information files based on which version of NWN is being used.
When NIT detects that crash files have been created, it displays a list of and provides options to Submit or Delete the crash files. Here is what it looks like (the Submit button Tool Tip is shown to explain what NIT does).
Only one entry is displayed for the dump and log file used in the Retail version.
Edit:
The option to delete is based on the crash information having submitted or when the same problem occurs and there is no need to submit it again.
Let me know if this answers your questions. Also, I am quite happy for you to leave the Log File changes as they are and allow NIT to detect which version is running and respond appropriately.
If I readd these two to nwclient.log, is that enough for NIT so it won’t need to read engine.log? As outlined, the engine log might change again in the future, but the client log is supposed to be stable. So if that supports your usecase, it’d be preferable.
Would it maybe be better if NIT submitted the .dmp files to Pixie and then gave the player a text dump to post? If we’re daydreaming, it might even search existing issues for the same stacktrace and direct the players to that instead of filing a new one.