ZDoom

While we're on the topic, can we also add a simplified version of the console.printf function to just print or trace? And maybe even support for multiple arguments, IE print(a, b, c)? Just sort of annoying having to type so much for a basic debug feature.

This can be closed now, we have [c]PrintfEx[/c].

Console.PrintString(PRINT_HIGH, PRINTF_NOLOG, "Printing to screen and console without adding to log file");

I submitted a pull request along the lines of Marrub's original suggestion for this [url=https://github.com/coelckers/gzdoom/pull/1408]here[/url].

Summary:
- Split print flags into separate enumerator from print levels
- Added Console.PrintString ZScript function that takes print level and flags as the first two parameters, then standard printf-style input after that

Use:
[code]Console.PrintString(PRINT_HIGH, PRINTF_NOLOG, "Printing to screen and console without adding to log file");[/code]

[url=https://forum.zdoom.org/viewtopic.php?f=15&t=66946]Duplicate[/url], but tbh I prefer your way of talking about it.

	native static vararg void Printf(string fmt, ...);

Currently the only API for printing is Console.Printf:

[code]
native static vararg void Printf(string fmt, ...);
[/code]
But, there are some features of the console that aren't accessible yet. Things like:

[list]
[*]Print levels (PRINT_LOW to PRINT_BOLD)
[*]No-notify mode (PRINT_NONOTIFY)
[*]No-log mode (PRINT_NOLOG)[/list]
Print levels are very useful since mods often need to print out errors or warnings about their inputs. For instance if "Some Mod" had a CVar format that was parsed into several variables, and the user gave garbage input, it would be useful to print the warning as an actual warning.

No-notify mode is particularly useful because currently the only way to use it is by using HudMessage. Yes, really. It IS exposed, but only through HUDMSG_LOG, and nowhere else in the entire engine. (Save for some very particular edge cases that wouldn't be useful in the same situations.)

No-log mode is not particularly useful for mods so it could be omitted, however an example case against omission might be that you have some debugging data that only makes sense to be given at runtime.

It's probably not a good idea to expose these as-is to ZScript since they have the same flags-inside-description issue that A_PlaySound had. However, they are very useful features. My proposal is, then:

[list]
[*]Move PrintLevel's flags into a separate parameter internally. This could for instance be done by adding another function like "PrintfFlags".
[*]Expose Printf's level and flag parameters, probably through a new function in Console, like Console.PrintLn or whatever sounds nicest.[/list]