Author Topic: Events.log never cleans itself up?  (Read 1630 times)

0 Members and 1 Guest are viewing this topic.

Offline General Battuta

  • Poe's Law In Action
  • 214
  • i wonder when my postcount will exceed my iq
Events.log never cleans itself up?
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!

 

Offline AdmiralRalwood

  • 211
  • The Cthulhu programmer himself!
    • Skype
    • Steam
    • Twitter
Re: Events.log never cleans itself up?
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).
Ph'nglui mglw'nafh Codethulhu GitHub wgah'nagl fhtagn.

schrödinbug (noun) - a bug that manifests itself in running software after a programmer notices that the code should never have worked in the first place.

When you gaze long into BMPMAN, BMPMAN also gazes into you.

"I am one of the best FREDders on Earth" -General Battuta

<Aesaar> literary criticism is vladimir putin

<MageKing17> "There's probably a reason the code is the way it is" is a very dangerous line of thought. :P
<MageKing17> Because the "reason" often turns out to be "nobody noticed it was wrong".
(the very next day)
<MageKing17> this ****ing code did it to me again
<MageKing17> "That doesn't really make sense to me, but I'll assume it was being done for a reason."
<MageKing17> **** ME
<MageKing17> THE REASON IS PEOPLE ARE STUPID
<MageKing17> ESPECIALLY ME

<MageKing17> God damn, I do not understand how this is breaking.
<MageKing17> Everything points to "this should work fine", and yet it's clearly not working.
<MjnMixael> 2 hours later... "God damn, how did this ever work at all?!"
(...)
<MageKing17> so
<MageKing17> more than two hours
<MageKing17> but once again we have reached the inevitable conclusion
<MageKing17> How did this code ever work in the first place!?

<@The_E> Welcome to OpenGL, where standards compliance is optional, and error reporting inconsistent

<MageKing17> It was all working perfectly until I actually tried it on an actual mission.

<IronWorks> I am useful for FSO stuff again. This is a red-letter day!
* z64555 erases "Thursday" and rewrites it in red ink

<MageKing17> TIL the entire homing code is held up by shoestrings and duct tape, basically.

 

Offline General Battuta

  • Poe's Law In Action
  • 214
  • i wonder when my postcount will exceed my iq
Re: Events.log never cleans itself up?
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...

 

Offline karajorma

  • King Louie - Jungle VIP
  • Administrator
  • 214
    • Karajorma's Freespace FAQ
Re: Events.log never cleans itself up?
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.
Karajorma's Freespace FAQ. It's almost like asking me yourself.

[ Diaspora ] - [ Seeds Of Rebellion ] - [ Mind Games ]

 

Offline General Battuta

  • Poe's Law In Action
  • 214
  • i wonder when my postcount will exceed my iq
Re: Events.log never cleans itself up?
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.

 

Offline karajorma

  • King Louie - Jungle VIP
  • Administrator
  • 214
    • Karajorma's Freespace FAQ
Re: Events.log never cleans itself up?
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.
« Last Edit: November 03, 2015, 05:15:43 am by karajorma »
Karajorma's Freespace FAQ. It's almost like asking me yourself.

[ Diaspora ] - [ Seeds Of Rebellion ] - [ Mind Games ]

 

Offline General Battuta

  • Poe's Law In Action
  • 214
  • i wonder when my postcount will exceed my iq
Re: Events.log never cleans itself up?
Wow! That's crazy.