[Possible Bug] Required "optional" entries in Pennmush config file

[mdziczkowski]

There is a possible bug in Pennmush, with treat the optional entries in the Pennmush config file as required ones - not setting it's value or commenting the entry out causes displaying in the console an message that it's not set and that it uses default values.

In my opinion, if they are optional then Pennmush should not throw an message about them not beeing set at all.

[talvo]

It should not; which option(s) are you getting errors for? Which version of PennMUSH are you using?

[HarryCordewener]

Aren't those just 'warnings', instead of 'errors'?

[talvo]

They are, but you still shouldn't get them.

[mdziczkowski]

@talvo Those messages have jumped out after starting up a fresh made pennmush, after commenting out the "optional" entries

[mdziczkowski]

Including exaple output files

Note: I had split the mush.cnf file into several parts (for easier administration) and had put them into separate files in conf sub-dir and then had included
them to mush.cnf

server.log
error.txt

[HarryCordewener]

These are warnings, not errors - in your server.log.
As for your error log, you are going past the limits of the config maximums, and it appears you are putting restricted names into the wrong file?

[mdziczkowski]

ignore the wrong names and passing the limit (I have already corrected them). The case are only the messages like:

CONFIG: directive 'xxxx' missing from cnf file, using default value, where the xxxx is name of it

[mdziczkowski]

@HarryCordewener

These are warnings, not errors - in your server.log.

is there anywhere in my message woten that this are errors ?

[HarryCordewener]

Fair. I guess since it's a Bug Report, I approached it as you reporting they are there in error.
In general, logging happens at multiple levels - INFO, WARNING, ERROR, FATAL.
You are coming at this from the point of view that logs should not contain anything that's not an error.

But the errors in the error log were errors.
And the logs in the general server.log is anything that relates to servers. Which seems flawed. Especially contrasted against you (presumably) being fine with the startup messages.

It is also the only thing that would help a game that's updated and missing options, from knowing those options are missing. Not reporting them seems a bad idea.

[mdziczkowski]

As @talvo has wrotten, they should not be shown into the console if they are optional (and/or commented out) entries.

[ray73864]

Except as @HarryCordewener has rightfully pointed out, if you are bringing your gamedir over from an older version of penn (because sometimes it's easier than going up several patches), your mush.cnf might be missing options that the new mushcnf.dst file has.

If that's the case, and you have forgotten to run 'make update', then you'll have no way of knowing (without doing a 'diff' between the 2 files) what new, or changed entries there might be.

It's all fine for an experienced person, but for a new person or someone who just hobbies, it's much easier to be able to look in the logfile, see all these entries and see the problems.

[mdziczkowski]

If that's the case, and you have forgotten to run 'make update', then you'll have
no way of knowing (without doing a 'diff' between the 2 files) what new, or
changed entries there might be.

It's all fine for an experienced person, but for a new person or someone who just
hobbies, it's much easier to be able to look in the logfile, see all these entries and
see the problems.

That why I'm trying to find a solution for it. I think I had thought out the solution for the log part (and else related to management). See the issue #1363 for more details

[HarryCordewener]

At this point, you are trying to solve a feature and turn it into a bug. I do not believe you are going to get any forward movement on this ticket. However, I am not a maintainer here, so you may get a different result.

[mdziczkowski]

You had pulled out a false results. I'm not trying to turn it into bug, but I'm trying yto find a good workaround for solving the reported case

[HarryCordewener]

Why do you need to work around it though?

1. Why can't you put the missing items back in like it warned you to do? Using a null string as a value is the appropiate way of removing a config option.
2. What is the problem you are running into that requires you to 'work around this'?

[mdziczkowski]

Using a null string as a value is the appropiate way of removing a config option.
it isn't always working (I tryed it already and had left it as it got provided by the archive) and even then it was throwing it out. The strange thing is, that only after modyfing the orginal config file

[talvo]

None of the options which you're getting reports for are ones which are classed as being optional - the "optional" ones have no effect on functionality and are purely display/message settings (like the names of pennies, the dump message, etc). All the options you've listed affect the way the game runs - hence why you're being notified that you're missing them and default values are used. This is intended behaviour.

With regards to your "error.txt" log - you appear to have added an "include" for names.cnf, and this is not how this file is intended to be used, it should only be referenced via the names_file option in mush.cnf to show where to find the list of banned names - it doesn't include actual config options.

[mdziczkowski]

With regards to your "error.txt" log - you appear to have added an "include" for names.cnf, and this is not how this file is intended to be used, it should only be referenced via the names_file option in mush.cnf to show where to find the list of banned names - it doesn't include actual config options.

I had noticed and fixed it (as well as the limit extend for the variable values) short after pasting the "error.txt" file ;-)

Why there is an upper limit for the numeric variables anyway?

None of the options which you're getting reports for are ones which are classed as being optional

Strange, some of them have a "optional" comment before them (like for example: "who_file" and "who_html_file") and despite this, Penn is complaining in the terminal about them beeing missing and using the default value.

Wouldn't it be better to make that such messages would be put into a log file, instead of console ?

[talvo]

Strange, some of them have a "optional" comment before them (like for example: "who_file" and "who_html_file") and despite this, Penn is complaining in the terminal about them beeing missing and using the default value.

Wouldn't it be better to make that such messages would be put into a log file, instead of console ?

They aren't marked as being optional actually in the Penn code - those two probably should be. (Bold for emphasis since there's a lot to read through in this ticket now.)

The logfiles are defined in mush.cnf, so errors that occur in mush.cnf don't necessarily have place to be logged, yet

[mdziczkowski]

How would you explain this then (directly quoted from mush.cnf file):

# OPTIONAL
# who_file

and

# OPTIONAL
# who_html_file

?

[talvo]

The actual code in conf.c, which is where the error message is produced from, does not have them marked as optional.

[mdziczkowski]

What do you think about the idea to split the mush.cnf file into seperate config files grouped by function categories (for example: ssl, chunk, etc.) with would become included into the mush.cnf. In the mush.cnf should be as only the nessecary core to run core setting ?

Bellow, I try to draw a proposed structure for the configuration branch inside the game folder (marked as [Root]).

Note: I will use "[" and "]" for folders

`
[Root]
|
|- mush.cnf

• [conf]
  |-- files.cnf
  |-- category_1.cnf
  |-- category_2.cnf
  |-- ...
  |-- category_X.cnf
  `

The mentioned files.cnf would include the other config files.

Above would give an adventages of:

• easing up the configuration (smaller config files with less lines to edit)
• more clean and orderer config structure

The proposal of spliting of the config files is directed the rule of not making the work more dificult ;-p

I know that more lines to edit, then the work goes slower, it's more tireing and it's easier to make mistakes ;-p

[talvo]

Please open separate tickets for new ideas - otherwise the discussion becomes too long and muddled, and tickets get closed without everything having been properly looked at. The implication of this needs to be properly looked into, in terms of whether make update follows includes or not, but I'm for the idea in general; we have a lot of config options now and mush.cnf has gotten long. I would say probably split along the categories as per @config as the simplest method.

[mdziczkowski]

sorry... It seem I had wrote it in the wrong ticket...

[talvo]

Still needs to be open re: some optional entries not being marked as optional in the hardcode :)

[mdziczkowski]

About that... maybe the most of config should be marked in hardcode as optional, leaving only so called "minimal core" as required. This would increase the server speed and would produce less errors ;-p

[talvo]

It.. would have no effect on server speed whatsoever, but people also wouldn't notice if they were missing options from their config that can have a profound effect on how the MUSH runs. If you don't want the error, don't delete config options from your mush.cnf :)

[mdziczkowski]

how about creating a config template file (next to the minimal config), with would contain all parameters listed and described instead ? this way no config option get missed ;-)

[HarryCordewener]

That's literally mushcnf.dst, the file that sits next to it.