Skip to content
Brett Smith edited this page Jul 27, 2013 · 4 revisions

Config generator like this or a web interface hooked up to the server directly (but then again… guess this would be very mod-specific)

Logging

I don’t think ULX had nearly enough emphasis on keeping a good log system. This should be at the core otlib level, with general knowledge of how files work but not having to write out to one (IE, write to SQL instead or both).

otlib.Log( tag, message )
otlib.Debug( message ) → alias for otlib.Log( “debug”, message )
alias for Trace, Warning, Error?

When doing files, should these be written to the same file or separate files (or both?). Maybe the best option is to only write to SQL and provide someway to dump to a file as needed? (IE, dumplog debug somedate to somedate) Would be confusing to casual users though… maybe we should expect to write to both SQL and files? Whatever the case, files should be separated by date.

Modules

A simple module system for otlib.

module = RegisterModule( module_name (string), version (string), author (string), load after (string) )

This function returns a table with which to build the module around. Specify a name of a module to load after to ensure this module loads after that. (IE, ULX.grabby loads after ULX)

Module:Init() – Called when you should init the module.
Module:Pause() – Called when the module has been paused. (Don’t worry about hooks, they’re already taken care of)
Module:Resume() – Called when the module should be resumed.
Module:Destroy() – Called when the module needs to be destroyed.
Module:AddHook() – Mod-specific hook adding.
Module:RemoveHook()

Other

Allow for direct command calling and directly returning errors in case we want to wrap the commands in something (like XGUI). This is opposed to ULX, where you can throw the command into console but don’t hear anything back.

Clone this wiki locally