 |
As the fix for issue 3139, I added this line in idGameLocal::RunFrame() ret.sessionCommand[0] = 0; // grayman 0003139 - must be cleared here, to handle the "player waiting" time The condump sessionCommand is processed and set up to run in the background, which uses "ret" to hold the request. While the change above is needed to fix 3139, it's possible that the background request is being cleared out before it has a chance to run. But ... commenting out the 'clear' line does NOT cause the background request to be processed. The request just disappears at some point that I was unable to track down. Perhaps a different solution that doesn't clear the request is needed to fix 3139. Something to look at. |
 |
Starting from 2017, MSVC has "break when value changes" in context menu in watch. You can set breakpoint at when the command is put into the variable (where it is lost later), then expand the watch entry to show individual characters, add such a memory breakpoint on the first character, and continue. It should break when the string is changed. Alternative approach is to do "break when value changes" on string length. |
|
|
Do you have anything like a test map? |
|
|
No. I'll create one, but it will take a while. |
|
|
Test map attached. The guards are friendly. If you look at the script file, you can see the categories statistics keeps track of. You can perform actions in the map to raise the counts of many of those categories. When you're done performing actions, press the button on the wall. The stats will be dumped to the console, and an attempt is made by the script to create a file listing the stats. The file isn't created. Let me know if you need more. Thanks for looking at this. |
|
|
The reason it does not work is that sessionCommand is not an arbitrary console command. sessionCommand only allows commands: map, devmap, died, disconnect. Basically, this are the commands for switching map or ending game --- something you cannot do from withing game code. |
|
|
I think there is no way to execute arbitrary console commands from game script, and I bet there is a reason behind it. The only option is to add some event like saveConDump(filename, unwrap), which would save into fms/{currentfm}/condump_{filename}.txt. |
|
|
Thanks for looking into this. Is it a lot of work to provide "saveConDump(filename, unwrap)"? Worst case is there's no support for what I'd like to do. I can point the player at this solution (which I have not yet tried): https://forums.thedarkmod.com/index.php?/topic/20596-beta-testing-ws6-baleford-museum/page/3/#elControls_453529_menu |
|
|
"The reason it does not work is that sessionCommand is not an arbitrary console command. sessionCommand only allows commands: map, devmap, died, disconnect. Basically, this are the commands for switching map or ending game --- something you cannot do from withing game code." Is this note: https://wiki.thedarkmod.com/index.php?title=Calling_Console_Commands_From_SDK an appropriate place to comment about these limitations, so that someone in the future doesn't fall into the same hole I did? I incorrectly inferred that all console commands were supported. Thanks. |
|
|
Yes, the wiki article says any console command should work. But it is definitely not so. Better fix it. I think it wouldn't be hard to implement the new script event. Although I'd probably add some some basic limitations on filename string and number of times executed during single TDM run. |
|
|
Why a limitation? Performance impact when run? The script would take a single snapshot automatically at mission end, and the player can then read the results at his convenience. There's no requirement or interest in multiple invocations. Unless you're imagining a broader scope for what your changes would provide. |
|
|
Done svn rev 8991. The new event is called "saveConDump", called like this: sys.saveConDump("missionstats"); Unlike the normal condump, it saves the dump file into the current FM directory. Dump is always in "unwrap" mode, since I don't see why the other mode could be better. The filename is truncated to 20 characters. Allowed characters are Latin letters, digits, and underscore (all the others are replaced with underscores). If filename is empty, it is replaced with "default". The file is saved at path: fms/{currentfm}/condump_{filename}.txt The condump_ is force-prepended, because otherwise script could potentially overwrite e.g. darkmod.txt, which is too bad. Only 100 condumps are allowed while TDM executable is running. 101-th and later calls will issue warning and do nothing. |
|
|
Works beautifully! One request, though. There's a "clear" console command that clears out everything currently dumped to the console. It would be nice if all the (meaningless) lines prior to the stats dump could be erased before dumping stats to the file. Note my use of this line just prior to dumping, in stats.script: sys.sessionCommand("clear"); // clear the console to make way for the stat report That was when I thought sessionCommand() was a general feature. Thanks! |
|
|
Does the 20-char limit apply to this string: "filename" or this string: "condump_{filename}" |
|
|
The 20-char limit is for the argument you pass, condump_ is prepended later. Won't clearing the game console at arbitrary moments lose potentially helpful debug information? Everything starting from the version and machine characteristics and ending with all the warnings/errors gets lost just because mapper decided to call clear at wrong moment?... |
|
|
On the other hand, there is qconsole.log, which includes warnings/errors but does not include version/hardware info. And players rarely enable it. |
|
|
"Won't clearing the game console at arbitrary moments lose potentially helpful debug information? Everything starting from the version and machine characteristics and ending with all the warnings/errors gets lost just because mapper decided to call clear at wrong moment?..." This happens once, at the end of the mission. The only danger is that something bad is happening at the end of the mission, and the log gets wiped out, taking with it important information. I'm not so worried about this. Players like to know their stats, and this is the only way I can provide that information. I was just trying to provide it in a neat and succinct way, w/o the clutter of X minutes of logging prior to the mission end. When we get to 2.09 beta testing, and WS{6/7/8} beta testing restarts, we can start with the version w/o clearing, and see if people are fine with the extra verbage. If so, we skip the clear request. |
|
|
Rather than building the "clear" request into the sys.saveConDump() function, can it be created as a separate request? That way we give the player the ability to comment out a separate "clear" request line in the script, in case we need to get from him a dump of lines prior to the sys.saveConDump() line. |
|
|
Maybe I should add one more logfile specifically for script? And some function like xprintln? |
|
|
I added second argument in svn rev 9007. If it is not empty, then it is the "marker line", before which everything is removed. Here is the sample usage: sys.println("(WS6 Mission Stats)"); ... sys.saveConDump("missionstats", "(WS6 Mission Stats)"); P.S. I'm sorry for delay. But I really don't like this "feature". To me it looks like a hack which better be avoided =( |
|
|
What do you object to? 1. The creation of the file that the player can read afterward? 2. The overloading of the console mechanism to provide the file? 3. The "break" line prior to which console information is flushed from the file? |
|
|
I think to p.1. The rest are just the issues following from it. Also it is clear that this particular case surfaced because you do NOT want to display statistics but DO want to display them at the same time. |
|
|
Well, I see no difference between TDM dumping info useful to devs and TDM dumping info useful to players. Of course, I'd prefer a more elegant solution along the lines of what greebo did for campaigns, where the author can create a readable document in the following mission that gives stats produced during the previous mission. But that option doesn't present itself here. So let's leave your work in place and see how the beta testers react to what we're offering. Stat-readers seem to be adamant that they want their stats. Perhaps they'll be placated with even a "hacky" offering. If I can talk them out of requiring the stats in any form, then I'd be glad to dump the option. (I didn't plan to give them _anything_ until one of my current testers mentioned that some players would be pissed.) And the presentation of the story--in my mind--overrides the need to present fancy screens of info and sounds, etc. . |
- Anonymous
