View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0002186 | FSSCP | user interface | public | 2010-04-20 16:36 | 2016-12-29 20:40 |
Reporter | The_E | Assigned To | The_E | ||
Priority | low | Severity | feature | Reproducibility | N/A |
Status | resolved | Resolution | fixed | ||
Product Version | 3.6.12 RC2 | ||||
Summary | 0002186: Dump the event log to file? | ||||
Description | Simple feature, for debug and/or regular builds to dump the mission event log to a file, as this may make mission debugging and event tracing easier. | ||||
Tags | No tags attached. | ||||
|
I've requested this one a few times as well. Very useful for Squadwar if that ever gets going again. One thing I've never figured out is that back in the retail days people would post text output of the log. No idea how they got it. |
|
Not sure I follow.. but is this solved with Karajorma's recent Event Log feature? |
|
I'm pretty sure it is, yes. Assigning to karajorma for credit & confirmation. |
|
Unfortunately not. What this refers to is outputting the contents of the mission log (i.e the one you can see by pressing F4) into a file. The feature I added doesn't do this, but the generic log functions I added make this ridiculously easy to add. All you'd need would be to add a call to the generic log functions to output to a new mission.log file. It is a new feature though. So I'll add it once 3.7 is out unless we need it now. |
|
Nothing that is needed anytime soon. |
|
I took a look at this, although the add function would be pretty easy to patch, the function that adds the actual text is elsewhere in the log, isn't modular and may be called multiple times or not at all during the mission. So it wouldn't be as easy as I thought it would be at all. |
|
In that case, I think this can be closed. First of all, the SEXP event log is more comprehensive making this partially redundant; and second of all, the mission log is pruned from time to time anyway. And based on karajorma's comments, this would be a lot of work for that small amount of benefit. |
|
I don't particularly want it closed. I can see a lot of value in having it. It actually compliments event.log very nicely and would make that log a lot more useful. The fact that the log gets pruned is actually a very good argument for outputting it to a file as events are added to it. When I said it wasn't as easy as I thought, I meant this wasn't something I could add in 20 minutes. The generic log code is pretty easy to use but you'd need to reorganise the way the mission event log generates text so that it was a function that could be called in-game at whatever time the player happens to look or by the file logging function as soon as the event is added. I actually left it as unassigned in case a newbie coder wants it before I get a chance. It's a mildly time consuming task but a fairly easy one. |
|
Also the goal of this is for it to work in retail not just debug. This logging info is the only fallback for squadwar if automated match resolution fails. These logs would need to be sent so an admin could manually resolve the match. Screenshots work but the problem is on the client side if the host jumps before you have time to hit F4 the log is gone at debrief and debrief is where you find out the save fails. |
|
Logs written to by the generic log system are written in release and debug builds, just like multi.log (which now uses that system). I might want to make it so that the logs can be written optionally at some point but I think we can make sure this log is always written to in any multi game. |
|
This has been resolved via the FRED eventlog |
Date Modified | Username | Field | Change |
---|---|---|---|
2010-04-20 16:36 | The_E | New Issue | |
2010-04-20 19:01 | FUBAR-BDHR | Note Added: 0011898 | |
2012-11-19 21:37 | MjnMixael | Note Added: 0014086 | |
2012-11-19 22:22 | Goober5000 | Note Added: 0014090 | |
2012-11-19 22:22 | Goober5000 | Assigned To | => karajorma |
2012-11-19 22:22 | Goober5000 | Status | new => assigned |
2012-11-20 11:26 | karajorma | Note Added: 0014123 | |
2012-11-20 16:01 | FUBAR-BDHR | Note Added: 0014125 | |
2012-11-22 12:07 | karajorma | Note Added: 0014148 | |
2012-12-30 07:11 | karajorma | Assigned To | karajorma => |
2012-12-30 07:11 | karajorma | Status | assigned => new |
2012-12-30 17:50 | Goober5000 | Note Added: 0014595 | |
2012-12-30 17:50 | Goober5000 | Status | new => closed |
2012-12-30 17:50 | Goober5000 | Resolution | open => won't fix |
2012-12-31 02:27 | karajorma | Note Added: 0014597 | |
2012-12-31 02:27 | karajorma | Assigned To | => karajorma |
2012-12-31 02:27 | karajorma | Status | closed => confirmed |
2012-12-31 02:27 | karajorma | Assigned To | karajorma => The_E |
2012-12-31 02:27 | karajorma | Status | confirmed => assigned |
2012-12-31 02:27 | karajorma | Assigned To | The_E => |
2012-12-31 02:28 | karajorma | Assigned To | => karajorma |
2012-12-31 02:28 | karajorma | Status | assigned => new |
2012-12-31 02:28 | karajorma | Status | new => confirmed |
2012-12-31 03:37 | FUBAR-BDHR | Note Added: 0014600 | |
2012-12-31 05:55 | karajorma | Note Added: 0014601 | |
2013-04-28 07:19 | niffiwan | Resolution | won't fix => open |
2013-05-31 08:42 | karajorma | Assigned To | karajorma => |
2016-12-29 20:40 | The_E | Assigned To | => The_E |
2016-12-29 20:40 | The_E | Status | confirmed => resolved |
2016-12-29 20:40 | The_E | Resolution | open => fixed |
2016-12-29 20:40 | The_E | Note Added: 0016839 |