ZDoom

[quote="Graf Zahl"]I find it astounding how many people made this mistake with the random() function[/quote]
I can easily understand how that happened though. I think that the reason is that, to a layman/non-programmer, "random" sounds exactly like what they want. Many of the people dabbling in DECORATE or ACS have minimal or no programming background and rely on looking at examples or figuring stuff out as they go - so when something seems to work, that's good enough.

So they type in something like random(1.0, 3.0) [perhaps having copied/pasted the code from another mod or example] to try to get any fractional value between 1.0 and 3.0 or maybe just think that writing it like that is correct to get either 1, 2 or 3 generated. The layman may not ever really appreciate that 1 and 1.0 carry a different data-type meaning.

With the incorrect format, earlier versions of (G)ZDoom would not spit out an error and the modder may simply have been unaware that "random" was not doing what they thought; perhaps because it was probably doing something close enough to what they wanted (and possibly did for a very long time). Our layman had also probably never heard of frandom [because, unlike random, it's not a real word, and even looks like a typo] and never seen it in an example - because so many examples and other sources of code were also wrong.

I'm not saying that the warning should not exist; it most certainly should. I'm saying that I completely understand how the "random()" mistake became so common. Even taking all that into account, I do still agree that just how ubiquitous it became is quite amazing.

No, we couldn't. It'd throw off any mod expecting an integer return, even if some fractional number gets passed in by accident.
Note that the warning only appears outside developer mode if a floating point constant gets passed, because that can be assumed to be an error in the vast majority of cases. Here it certainly is.

What they really want is something I don't think we could do, even if we wanted to: They want you to just change random() to be floating point.

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.

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.

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.

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?

[quote="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.[/quote]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.

I agree with Gez's post on all accounts.

[quote="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.[/quote]
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.

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.

Can't you just comment them out?

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.

[quote="wildweasel"]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 ;)[/quote]
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.

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.