Disable console log when starting gzDoom?

[PixelWAD]

Is it possible to disable all that text scrolling when starting gzDoom? My mod has some errors (mostly sprites that are not used yet), and everytime I test it takes a few seconds to scroll through all these errors, then the game starts. I'm pretty sure if we could disable the log, it would help with faster loading.

At least that's how GTK Radiant used to work. If you chose not to output log, the app was working much faster.

It's nothing game breaking, but when making a mod I test it several times every quarter.

[Caligari87]

Well... you should fix those errors that's why they're shown.

More to your actual question though, I do not believe the console log itself takes any actual time. Disabling would just leave you looking at a black screen for the same amount of time while the engine loads.

[wildweasel]

Well... you should fix those errors that's why they're shown.

More to your actual question though, I do not believe the console log itself takes any actual time. Disabling would just leave you looking at a black screen for the same amount of time while the engine loads.

There have been a few situations in which startup has a noticeable delay due to the overhead from printing all the errors, though. I can't find the thread in question, but this was even acknowledged by devs...but yeah, problem goes away if you fix the errors

[Graf Zahl]

Of course printing errors takes time. And of course this will not be disabled. We already got too many mods that have problems their makers just ignored. We don't need more of them.

[Rachael]

There have been a few situations in which startup has a noticeable delay due to the overhead from printing all the errors, though. I can't find the thread in question, but this was even acknowledged by devs...but yeah, problem goes away if you fix the errors

I'm going to thirdly acknowledge this. If your mod has 10,000 errors, expect a start-up time of 10 seconds or more, at least.

Fix your errors.

[PixelWAD]

To be honest I do not have a true error that I'm not aware - followed by one of the advices here I created a custom textures file with custom sprites, and there are like 50-100 that are not in use, yet. I just keep it there as it's easier to work with it, instead of reworking all the files simultaneously.

I do not have the newest rig, everything works really good here, we all work with shortcuts of all kind to speed up progress a little and then playing F9 in Doom Builder and waiting for it to go through all the missing sprites is well.. a bottleneck I guess experimental -nolog command line or something could do no harm, but I do understand the 'nagging' on the screen.

[Matt]

Can't you just comment them out?

[PixelWAD]

Of course that is possible, but this isn't a true solution. I would have to keep editing them back and forth as my mod is expanding.

[Gez]

Is it possible to disable all that text scrolling when starting gzDoom? My mod has some errors (mostly sprites that are not used yet), and everytime I test it takes a few seconds to scroll through all these errors, then the game starts. I'm pretty sure if we could disable the log, it would help with faster loading.

This, along with any other "let modders ignore problems in their projects and then release buggy crap" suggestion, is going to be rejected so very hard.

Fix your stuff. Perhaps remove or comment out unfinished stuff until you want to finish them, but don't try to ignore error reports. If they annoy you, then they're working and you should take it as an incentive to make them disappear by fixing your stuff.

[Graf Zahl]

I agree with Gez's post on all accounts.

[Matt]

Of course that is possible, but this isn't a true solution. I would have to keep editing them back and forth as my mod is expanding.

The "true solution" here is, practically by definition, when you've finished adding all those resources and they all point correctly to things.

Either commenting out the offending lines or just putting up with the proeidoporrhea would be a reasonable compromise while the mod is under development and not yet ready for full release.

[_bc]

Fully agreeing with the logic of "if it's broken, you shall see!", but I understand why this would be practical in a testing scenario. Maybe something like a command line option, e.g. "--testing-disable-warnings", which only the user (or modder while testing) can trigger, but the mod itself can't, so it wouldn't mask coding errors to the end user?

[Graf Zahl]

The main problem with that is that it also hides real errors and not just transient ones. And if you want to see a mod where the developer persistently ignored all warnings up until the release, look up the "Temple of the Lizardmen" series. The quality of the mods themselves nonwithstanding they all spam the console with error messages - the final releases, not development betas! Allowing developers to silence the messages will only make things worse. When programming GZDoom I make sure that I *FIX* all warnings when I see them, not silence them to not get annoyed.

[Blue Shadow]

With the Temple of the Lizardmen series, I think the blame is partially on developing the projects on old versions of the engine and not testing with newer versions. The fourth installment can be played with GZDoom 1.8.2, apparently, and the floating-point truncation warnings, for example, aren't logged like they are in newer versions of GZDoom. It's the same deal with actor classes name conflicts.

Of course, this doesn't excuse the map-related errors and warnings.

[Graf Zahl]

Even the first one spammed the console with the proper version it was made for.

And regarding the truncation warnings, I find it astounding how many people made this mistake with the random() function - and that they rather want to see the warning gone than fixing their mod.