How to disable client-side logging?

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

the way i understood it its because of getting rid of the shader errors on the log which are not caused by modding errors
in every other case I would agree to Bejaymac

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

still good work finding that offset ^^

@FuryFreelancer:

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.

@Bejaymac:

@FuryFreelancer:

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.

Thank you for finding that offset, FuryFreelancer. I’ll give it a look - does logging defined in freelancer.ini still function with this hack in?

In other words - as it is currently in Flak, FLSpew.txt is just over-written with 0x00s, however I can still define logging to a custom file in freelancer.ini for when errors need to be found (this is implemented as a hidden mod option for bug testers) - will the hack still enable this to be done?
(I guess I can just check myself, but that’ll have to wait a while XD)

@Bejaymac:

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.

While part of this statement is indeed true (the client log is great for catching errors related to effects), I would appreciate it if you didn’t make such assumptions in the future; some of us work very hard to keep our projects clean. Thanks. ^_^

Many errors are not reported on the server but are flagged on the client in the flspew. You might run all the error checkers you can and claim your mod is clean because you have fixed the obvious errors, however, you should use the players flspew from time to time to highlight areas that need attention.
A good tactic is to ask for the spew files from your admin or server staff from time to time and look through them, I found this very usefull in narrowing down and finding problems. Before you judge what i say, get your admins active on the server for a good few hours and get their spew files, then when you have gone through them, you will realise that the flspew is sctually as good an error checker as the software most of us use.

Fox, I believe it does still function yes. I’ll test this too, and post up if you haven’t already. And yeah, good idea Strail. Dismissing it altogether is maybe not such a great option…

Agreed, FuryFreelancer - I use client-side spew myself to track down errors, as does any bug-tester.
However, considering the end-user shouldn’t have to deal with errors in the first place, it is nice to be able to disable the log spew to increase framerates. Besides, logging can always be re-implemented as an option incase issues do pop up and people want to help find the solution.

Revisiting the end-user point, look at how many games are released today that have show-stopping bugs or crashes - the number one question asked is “where was the testing team?” It is standard that all major bugs be fixed pre-release, and I accept no less of a standard when packaging Flak up. It’s partly why the 1.27 Betas have been in development for 3 years now.

Just did some testing with it, FuryFreelancer, and it works great. Logging can still be enabled via Freelancer.ini, so I’ve added it to the 1.0-1.1 Offsets - I’ll update the topic shortly

Thats good to know. Thanks for the update. I didn’t get chance to do it myself up to now