Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: General Battuta on October 30, 2015, 03:43:49 pm
-
As far as I can tell, events.log will grow bigger every time you run a mission. I ended up with a 2 GB txt file. I think this feature should probably rewrite the log each time it runs the mission.
If I'm mistaken, then I guess what's happening is that logging on a mission where many events are running every frame can create monstrosities if the mission runs for several minutes. Not sure!
-
As far as I can tell, events.log will grow bigger every time you run a mission. I ended up with a 2 GB txt file. I think this feature should probably rewrite the log each time it runs the mission.
If I'm mistaken, then I guess what's happening is that logging on a mission where many events are running every frame can create monstrosities if the mission runs for several minutes. Not sure!
It does, in fact, open the logfile with the "wt" mode, meaning "non-appending write, text mode". So it does, in fact, rewrite the log each time. If you want smaller logs, you'll need to log fewer things (it should be noted that one rarely needs to check every logging option when diagnosing an event).
-
Yeah, I think the dangerous thing here is logging on a complex event that repeats thousands of times in a mission. FRED still has an issue (or had an issue in the past?) where it would apparently mark arbitrary events for logging — so you might through no fault of your own end up eating a couple of gigs with text logs...
-
Marking arbitrary events definitely shouldn't be happening. I've never seen that happen so I'd appreciate it if you can figure out under what conditions it does it.
As for the event log, it does write multiple missions to the same log file but this is by design. The log file is opened on game start, not mission start because the idea was that if someone played a campaign through and got errors in one mission, they wouldn't have to stop playing in order to still have a log. In addition if the problem was with a persistent variable you could have both missions in the log to figure out where the error was.
Event.log is not just meant to be a debugging tool during mission development (although that's its main purpose). The idea was that you could release missions with the event logging still turned on so that if a player later reported a bug you couldn't reproduce you could get useful data without needing them to have any special kind of debugging skills. You could simply say "Stick this in data/missions and next time you play the campaign again send me the event.log" That's the reason I have the game write to event.log even in release builds. Normally you wouldn't have any events tagged for logging in a release, but if several people are reporting a bug you just can track down, you can turn it in in a patch and then get a log which will probably help you find the cause of the problem.
Yes that can result in a very huge log if you've tagged something that repeats every frame but you won't be doing that release versions of the game. And when debugging you don't need the entire log and you can do little tricks to find the relevant entry within the logged data (for instance, have a SEXP in the event that only triggers once, then just search for that). Remember that the mission name is written to the log every time so it's pretty easy to find the last instance and delete all prior ones.
Basically, I think everything is working as intended. If you feel I can do something to improve it though, I'm all ears.
-
Yeah, just got an event start logging itself when 'true' or 'false'. Don't think I fat-fingered it. Seems to happen upon mission save? Not sure.
-
Sounds like something isn't being initialised properly. I'll look into it.
EDIT : Looks like this one is not my fault. Apparently FRED has always had this bug. This will work in retail or FS2_Open. Make an event, give it a repeat count and then immediately press the insert event button. The newly created event ends up with the repeat count and the old event goes back to a repeat count of 1. How on Earth I've failed to pay attention to this bug for over 14 years is a bit of an odd one. I guess I just simply fixed the bad data and barely noticed it.
I don't have time to fix this one today but it looks like both the insert and add event buttons can suffer from this bug at different times. More calls to update_cur_event() might help but that can't be the entire solution cause if you delete all the events in a mission the repeat count, trigger count, chained and event log flags all remain set to whatever they were on the last event you deleted.
-
Wow! That's crazy.