How to disable client-side logging?
-
freelancer.ini, play with these or comment them out:
[Error]
;EMAURER these four should remain as set.
log = $Window,65540 ; alert all asserts
log = $Window,-1,1 ; alert all errors (SEV_ERROR=1);EMAURER comment out lines below to vary the amount of output spew.
log = $Text, 65536, 5 ; 65536 means ‘don’t care’ about kind value.
; 5 refers to TRACE_LEVEL_5. means report all messages
; with severity of 5 or less. lower the number, more severe
; the message. WARNINGS are at level 2. reduce for less spew.;log = $Text, ‘I’ ; incoming packet transmission
;log = $Text, ‘O’ ; outgoing packet transmission
;log = $Text, ‘i’ ; instance creation related messages (mass, MOI, equip)
;log = $Text, ‘r’ ; significant attitude/reputation events (show results of AdjustAttitude calls)
;log = $Text, ‘a’ ; detailed info regarding loading/unloading of archetypes.
log = $Text, ‘c’ ; report server-side events sent to contollers
log = $Text, ‘m’ ; mission-generated messages
log = $Text, ‘s’ ; log second thread activity
;log = $Text, ‘f’ ; report file opens/closes
;log = $Text, ‘e’ ; explosion/fuse messages
log = $Text, ‘d’ ; damage messages
log = $Text, ‘A’ ; reload console command messages -
I think Foxunit disabled the logging you’re talking about for the FLAK mod. More details are found in this thread:http://www.memes.no/88flak/forum/viewtopic.php?t=1039 (scroll to the middle of the thread)
I think this is what you’re looking for, FK?
-
why in gods name do you even want to do that?
i cant seem to see a benefit doing thatThat log’s file size could get pretty massive depending on the frequency with which the errors get logged, not to mention the performance hit that Firekiss already mentioned.
-
foxUnit01 did this for Flak due to the way a certain version of the ENB series bloom shader works. I did this for Itano Circus as well.
From what I recall, JONG has it spot on. Open Freelancer.exe in a hex editor, search for FLSpew.txt, and replace it with zeroes. Then, you can use these freelancer.ini lines to debug and create a log for errors and stuff.
log = fl-client-errors.log, -1 ; alert all errors (SEV_ERROR=1) ;log = fl-client-errors.log, 0 ; alert no errors -
Nope. It’s simply not supplying a filename to write to - in doing this, Freelancer has nowhere to send the file output stream. If logging is enabled, regardless of rather you’re using custom shaders or not, you’re wasting a ton of CPU time writing to disk, which is a terrible waste of resources.
I’d highly recommend getting rid of FLSpew logging - client-side logging can still be enabled through freelancer.ini, so if you ever need the client logs to track down a crash you can always turn them on there and then turn 'em back off later.
-
Just seen this topic, and I know it’s a few months out-of-date now. But I am hesistant to believe that simply replacing the filename with zeroes with a simple hex-edit is anywhere close to good enough. The .exe will still run the routine that is supposed to output these errors, although it just won’t output. But the processing time is surely still used regardless of whether anything gets dumped to disk or not. Wouldn’t it be better to trace to the function that deals with this an alter a compare and force a jump? I have a certain amount of experience with navigating assembly code, so perhaps I’ll take a look and find a cleaner solution to this. I will of course post up any finding for use as hex edit offsets
EDIT - Ok, so that didn’t take as long as I was expecting. Here is the offset you need to change and this will prevent the routine from even running that generates that log file and prevents a few other related bits too. This should save on a little processing overhead/lag (however great or small that may be):
Offset: 0x1B2819 Change: "74" to: "EB"Done
-
tbh this is a dumb idea, how the hell does the client find out why he crashed while playing your mod.
Your better cleaning your mod rather than block the log, as every mod has errors in the code, even those that don’t list anything in the logs. Get rid of those and you won’t need to worry about the log taking away precious prossesing power, as without the errors you’ll have more spare prossesing power than you can shake a stick at.
-
I beg to differ. Like some of the guys already said, there are some things that always appear in the log, that can’t be helped. You do know we are talking about the flspew.txt log here, and not flserver’s error log right? Every time you start the game, a ton of notices get dumped in flspew, most of which aren’t even useful in any way whatsoever. Just FYI, so far I have a very clean mod indeed. There are virtually no errors, yet that file caught my attention, for being very lengthy and verbose. And also, like was suggested before, you can turn on error-logging in the freelancer.ini file if you really do need to some serious checking if you suspect a problem with the mod. And, 99% of ‘clients’ will not navigate into local settings\appdata\freelancer to check a hidden-away log. Most will not even attempt to rectify it, choosing to post for help instead. Cheers
-
Fair points guys. I just posted an offset that I think may be useful that’s all. I’ll not post further in this one
-
Just FYI, so far I have a very clean mod indeed. There are virtually no errors
I couldn’t help but laugh at this, yes FlSpew & the server log might be clear, FLEC & FlScan might show nothing, but I can guarantee you that your mod & everybody elses mod for that matter is far from clean.
Syntax errors are small and don’t show in the logs, but they show up in some place far more important, the CPU. They act like boulders in a stream, get enough of them and you severely restrict the flow and slow down your CPU, to many and you’ll dam the flow and crash. Symptoms are client side lag with the odd random ctd, and server load which can result in the odd server crash.A quick example - the HpCockpit, how many custom ships don’t have one, without it you create 1 syntax error on launch, 2 when you “V” to look back, 2 when you enter & exit turret view, and at least another 2 when you enter & exit cockpit view (without a built in camera in the cockpit you create 1 more), so that’s 7 (8 ) possible errors from just one ship, and that’s only using those views once. Now why does this happen, simply because the cameras are designed to attach to the HpCockpit, without it FL is forced to attach them to 0,0,0 or it would crash.
The same goes for every missing hardpoint you designate in the shiparch.Generally speaking most average mods generate tens of thousands of errors, so you can’t call your mod clean until you’ve gotten rid of all of these.
Before I forget, installers are bad, they give the client a large injection of syntax errors long before they see the menu screen.
-
I’m well aware of that. No need to be so critical. I was speaking about actual 'error’s that would cause a problem; those that the game engine won’t just ignore and allow it to continue. Because of the others that come up… a lot of them yes… that’s why I think the disabling of the client log is a good idea. All that garbage getting spat out is just something else that can be prevented. I’m quite happy to do that, which is why I looked for the offset in the first place.
-
eventhough i have put much energy in getting rid of every known error including about 30000 syntax errors of vanilla FL and the mod code (due to copy/paste) and all possible hardpoint errors that i was able to find (including case sensitive stuff) i can clearly say that my mod is still not error free
Im aware of several animation errors which still need to get fixed. Im aware of several sound errors which recently got discovered.
Im aware of serveral errors which i can not fix due to the fact that i dont have the FL source code.
And im absolutly aware that due to the size of my mod there are going to be some other errors which i did not notice yet (eventhough i am very sure that this wont be many and for sure no serious errors)FL will never have a clean code. And FL mods are far away from such an “illusion”.
But in the end this is a fact we should never accept… we keep finding and fixing the errors.
To ignore that fact is the only option we have to improve our mods. -
Just FYI, so far I have a very clean mod indeed. There are virtually no errors
I couldn’t help but laugh at this, yes FlSpew & the server log might be clear, FLEC & FlScan might show nothing, but I can guarantee you that your mod & everybody elses mod for that matter is far from clean.
Syntax errors are small and don’t show in the logs, but they show up in some place far more important, the CPU. They act like boulders in a stream, get enough of them and you severely restrict the flow and slow down your CPU, to many and you’ll dam the flow and crash. Symptoms are client side lag with the odd random ctd, and server load which can result in the odd server crash.A quick example - the HpCockpit, how many custom ships don’t have one, without it you create 1 syntax error on launch, 2 when you “V” to look back, 2 when you enter & exit turret view, and at least another 2 when you enter & exit cockpit view (without a built in camera in the cockpit you create 1 more), so that’s 7 (8 ) possible errors from just one ship, and that’s only using those views once. Now why does this happen, simply because the cameras are designed to attach to the HpCockpit, without it FL is forced to attach them to 0,0,0 or it would crash.
The same goes for every missing hardpoint you designate in the shiparch.Generally speaking most average mods generate tens of thousands of errors, so you can’t call your mod clean until you’ve gotten rid of all of these.
Before I forget, installers are bad, they give the client a large injection of syntax errors long before they see the menu screen.
While that may be true, I think your conclusions regarding performance are not valid at all.
Fall back code, such as the cockpit camera reverting to 0,0,0 is not necessarily taking longer than bugfree code.
In fact, the fallback may be faster in some places than the normal code, parsing an ini or whatever.
