Problem: When trying to access this.Server.AllPlayers or any other property or function in OnModulesLoaded, it will throw an exception because the Server has not been initialised at this point because of the new way of server object instantiation.

Instead, OnModulesLoaded must not be called during OnCreatingGameServerInstance but rather before calling modules OnConnected when the instance has not already been loaded.

bool hasInitialized = false;

override OnConnected() {
if (!hasInitialized) {
hasInitialized = true;
OnModulesLoaded();
}
existing call forwarding
}

System.Text.Json is too strict again and does not allow for trailing commas

This is a discussion. Add arguments, ideas and examples to this discussion so that together we can make an informed and sound decision on whether or not, and how to implement such a concept.

Currently module dependencies only target a module by their name. This may cause compatibility issues in cases where a dependent module changes its method signatures and becomes incompatible with modules that have a dependency to it.

Instead it was suggested that module dependencies should be version-dependent "just like npm".

Conceptionally a sound solution has to be created that covers all cases.

Requirements

Unique instancing

A module instance must only exist once per server.

Non-breaking updates

A non-breaking update to a module should allow all modules, that depend on it, to continue functioning.

This error message should contain less clutter.

Also in general, error messages should probably stop at the inner exception stack trace.

Some modules may become quite large and it can be a chore to have all code in a single .cs file.

Instead modules should be loadable from dlls too so larger projects can be compiled.

There are safety concerns in this suggestion.

Allow for modules to have nuget dependencies that automatically get downloaded by the runner

This is a discussion. Add arguments, ideas and examples to this discussion so that together we can make an informed and sound decision on whether or not, and how to implement such a concept.

Currently module configuration scopes (global, local) are defined by the module author because they know best what values can and can not be local or global.

Blu thinks this is not good and should be controlled by the user. I doubt this is a good idea.

Conceptionally a sound alternative to the current configuration handling has to be created that covers all existing cases and also allows for the additional case of letting users choose. It also can't be more complicated to use than the current system because some people already struggle finding the config files - making this more complex will only worsen this.

Requirements

Definite global variables

Variables that are declared global by the author and can not be made local by a user.

Cases for this include:

• Global timestamps for limiting
• Global caches

Definite local variables

Variables that are declared locally (per server) by the author and can not be made global by a user.

Cases for this include:

• Local timestamps for limiting
• Local caches

Dynamically scoped variables

Variables that do not have an explicitly defined scope by the author and can be made local or global.
Such variables should also be able to be declared globally and overwritten locally for specific servers.

Cases for this include:

• General settings that allow for local overwriting

Give modules an ILogger so they can be forced to log in a specific format and allow for logging to files.

I'm getting the following error with the latest release when running on Linux:

log4net:ERROR Could not create Appender [ColoredConsoleAppender] of type [log4net.Appender.ColoredConsoleAppender]. Reported error follows.
System.DllNotFoundException: Unable to load shared library 'Kernel32.dll' or one of its dependencies. In order to help diagnose loading problems, consider setting the LD_DEBUG environment variable: libKernel32.dll: cannot open shared object file: No such file or directory
   at log4net.Appender.ColoredConsoleAppender.GetConsoleOutputCP()
   at log4net.Appender.ColoredConsoleAppender.ActivateOptions()
   at log4net.Repository.Hierarchy.XmlHierarchyConfigurator.ParseAppender(XmlElement appenderElement)
log4net:ERROR Appender named [ColoredConsoleAppender] not found.

Would using ManagedColoredConsoleAppender be better to use as per the last comment here? https://stackoverflow.com/questions/64109799/log4neterror-could-not-create-appender-console-of-type-log4net-appender-colo

The GH download only supplies an appsettings.json with the IP and port settings included. Can't it please provide a complete file with defaults for the optional settings for ease of subsequent configuration (ie settings keys don't need to be manually added)?

Also, what are the allowed values for LogLevel other than "None"?

the ability to drop in files and for them to compile