AGuyNamedJens / FactorioChatBot

Two-Directional chat bot connecting Discord and Factorio chats together, written in nodejs.
MIT License
13 stars 9 forks source link

Added support for debug logging #14

Open Mattie112 opened 2 years ago

Mattie112 commented 2 years ago

Just a suggestion to make it a bit easier to debug stuff (leave messages still don't work all the time for me).

mikhailmikhalchuk commented 2 years ago

Don't necessarily see the point of this - console already provides the info, debug, and error methods, and this pull request dose not implement any of them. Filtering what to log based on a config option is impractical.

Mattie112 commented 2 years ago

Why would that be impractical? That is how a lot of software works. Normal use case is either info or warning and then a debug for well debugging. You don't want to leave debug logging running all the time as (depending on the software ofc) this can cause for a lot of disk usage. The built-in console functions do not have anything to set a log level (as far as I know correct me if I'm wrong).

For example: I have issues with leave messages so I want to know what the bot is doing. Is it reading correctly from factorio (and then not sending?) Or is it not parsing? Or can't it post to Discord. So I want stuff that logs it all but for the normal flow that only wastes disk space.

Me not using console.debug or console.error is from my web dev background, that used to give a lot of problems on IE. I don't really mind using those functions but that is something different from wanting to set the log level.

mikhailmikhalchuk commented 2 years ago

Normal use case is either info or warning and then a debug for well debugging. You don't want to leave debug logging running all the time as (depending on the software ofc) this can cause for a lot of disk usage.

There's a config toggle on whether or not to send debug messages to the console, see config.logLines. You can use this to debug without the need for an enum.

Me not using console.debug or console.error is from my web dev background, that used to give a lot of problems on IE.

In this case, you could use console.debug for debugging and console.error for warnings/errors. Considering the introduction of the enum, this would be the more sensible option.

My concern is that this pull request adds a lot of unneeded bloat for a config feature that exists already or could simply be altered.

AGuyNamedJens commented 2 years ago

It could be an idea to make every log be able to be set, but except for logLines, which logs all incoming lines to the console, there isn't any other "debug" item to log unless you want to disable all connection logs, which in my opinion are quite important

Mattie112 commented 2 years ago

Normal use case is either info or warning and then a debug for well debugging. You don't want to leave debug logging running all the time as (depending on the software ofc) this can cause for a lot of disk usage.

There's a config toggle on whether or not to send debug messages to the console, see config.logLines. You can use this to debug without the need for an enum.

Me not using console.debug or console.error is from my web dev background, that used to give a lot of problems on IE.

In this case, you could use console.debug for debugging and console.error for warnings/errors. Considering the introduction of the enum, this would be the more sensible option.

My concern is that this pull request adds a lot of unneeded bloat for a config feature that exists already or could simply be altered.

But that config item really logs everything, the nice thing about log levels is that the user can decide how much logging he/she wants. But I agree that you want one of them, not both. I don't mind using the other console functions, doesn't change anything in the output for cli afaik.

It could be an idea to make every log be able to be set, but except for logLines, which logs all incoming lines to the console, there isn't any other "debug" item to log unless you want to disable all connection logs, which in my opinion are quite important

Well other stuff could be discord status checks, the parsing of messages for example. The more features you add the more stuff that (might) break.

AGuyNamedJens commented 2 years ago

Hmm, interesting..