2020-06-05 12:24 EDT

View Issue Details Jump to Notes ]
IDProjectCategoryView StatusLast Update
0002186FSSCPuser interfacepublic2016-12-29 15:40
Assigned ToThe_E 
Product Version3.6.12 RC2 
Target VersionFixed in Version 
Summary0002186: Dump the event log to file?
DescriptionSimple 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.
TagsNo tags attached.
Attached Files




FUBAR-BDHR (developer)

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.


MjnMixael (manager)

Not sure I follow.. but is this solved with Karajorma's recent Event Log feature?


Goober5000 (administrator)

I'm pretty sure it is, yes. Assigning to karajorma for credit & confirmation.


karajorma (administrator)

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.


FUBAR-BDHR (developer)

Nothing that is needed anytime soon.


karajorma (administrator)

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.


Goober5000 (administrator)

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.


karajorma (administrator)

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.


FUBAR-BDHR (developer)

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.


karajorma (administrator)

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.


The_E (administrator)

This has been resolved via the FRED eventlog

-Issue History
Date Modified Username Field Change
2010-04-20 12:36 The_E New Issue
2010-04-20 15:01 FUBAR-BDHR Note Added: 0011898
2012-11-19 16:37 MjnMixael Note Added: 0014086
2012-11-19 17:22 Goober5000 Note Added: 0014090
2012-11-19 17:22 Goober5000 Assigned To => karajorma
2012-11-19 17:22 Goober5000 Status new => assigned
2012-11-20 06:26 karajorma Note Added: 0014123
2012-11-20 11:01 FUBAR-BDHR Note Added: 0014125
2012-11-22 07:07 karajorma Note Added: 0014148
2012-12-30 02:11 karajorma Assigned To karajorma =>
2012-12-30 02:11 karajorma Status assigned => new
2012-12-30 12:50 Goober5000 Note Added: 0014595
2012-12-30 12:50 Goober5000 Status new => closed
2012-12-30 12:50 Goober5000 Resolution open => won't fix
2012-12-30 21:27 karajorma Note Added: 0014597
2012-12-30 21:27 karajorma Assigned To => karajorma
2012-12-30 21:27 karajorma Status closed => confirmed
2012-12-30 21:27 karajorma Assigned To karajorma => The_E
2012-12-30 21:27 karajorma Status confirmed => assigned
2012-12-30 21:27 karajorma Assigned To The_E =>
2012-12-30 21:28 karajorma Assigned To => karajorma
2012-12-30 21:28 karajorma Status assigned => new
2012-12-30 21:28 karajorma Status new => confirmed
2012-12-30 22:37 FUBAR-BDHR Note Added: 0014600
2012-12-31 00:55 karajorma Note Added: 0014601
2013-04-28 03:19 niffiwan Resolution won't fix => open
2013-05-31 04:42 karajorma Assigned To karajorma =>
2016-12-29 15:40 The_E Assigned To => The_E
2016-12-29 15:40 The_E Status confirmed => resolved
2016-12-29 15:40 The_E Resolution open => fixed
2016-12-29 15:40 The_E Note Added: 0016839
+Issue History