Manual:Best Practices - Revision history

Sanaki: /* Package and Module best practices */ Added link to gmod functions

2025-08-08T02:15:44Z

Package and Module best practices: Added link to gmod functions

Atari2600tim: /* Package and Module best practices */ stray closing parentheses

2025-08-02T14:50:31Z

Package and Module best practices: stray closing parentheses

Zooka: /* Package and Module best practices */

2024-09-25T13:48:20Z

Package and Module best practices

Zooka: /* Package and Module best practices */

2024-09-25T13:42:00Z

Package and Module best practices

Jmckisson: Add initialization guard variable section

2024-08-27T18:41:02Z

Add initialization guard variable section

Vadi: /* Conversely, avoid _G when possible */

2022-08-07T17:27:20Z

Conversely, avoid _G when possible

Demonnic: /* Use local variables */

2022-08-07T17:16:53Z

Use local variables

Demonnic: /* Capture the IDs returned by your temp items and anonymous event handlers */

2022-08-01T20:44:22Z

Capture the IDs returned by your temp items and anonymous event handlers

Demonnic: /* Mudlet */

2021-09-29T14:28:22Z

Mudlet

Demonnic: /* Avoid expandAlias() where possible */

2021-09-20T14:10:12Z

Avoid expandAlias() where possible

@@ Line 214: / Line 214: @@
 * if you're specifying any fonts, package them
 ** while it might be available on your computer, not guaranteed to be available on every computer
 * if you're a game admin, install it automatically via GMCP or via the Mudlet Package Repository
 ** less overhead for players to get a good experience

@@ Line 199: / Line 199: @@
 * utilize the Mudlet Package Repository for updates
-** so players stay up to date, which will not be the case with manual updates)
+** so players stay up to date, which will not be the case with manual updates
 * modular and extendable - use Mudlet modules for this
-** so people can disable ones not needed)
+** so people can disable ones not needed
 * hook into the sysInstallPackage event to give some introductory text about the package they just installed
 * event based - raise events of your own for others to hook into
@@ Line 208: / Line 208: @@
 ** so people can make their own aliases or keybindings to customize as needed without using expandAlias
 * don't pollute the global namespace, keep everything in a table
-** so you don't get bugs from people overwriting it or vice versa)
+** so you don't get bugs from people overwriting it or vice versa
 ** touched on above but bears repeating
 * undo any UI changes on uninstall: set borders back, hide the UI, etc

@@ Line 202: / Line 202: @@
 * modular and extendable - use Mudlet modules for this
 ** so people can disable ones not needed)
+* hook into the sysInstallPackage event to give some introductory text about the package they just installed
 * event based - raise events of your own for others to hook into
 ** so the order of scripts installed in the players profile doesn't matter

@@ Line 198: / Line 198: @@
 : This is a list of things we have discovered over the years leads to the best user experience with Mudlet packages. They aren't all necessary, but you will find that the more of them you do, the easier the lives of your users and ultimately yourself.
-* built-in auto-updates
+* utilize the Mudlet Package Repository for updates
 ** so players stay up to date, which will not be the case with manual updates)
 * modular and extendable - use Mudlet modules for this
@@ Line 208: / Line 208: @@
 ** so people can make their own aliases or keybindings to customize as needed without using expandAlias
 * don't pollute the global namespace, keep everything in a table
-** so you don't bugs from people overwriting it or vice versa)
+** so you don't get bugs from people overwriting it or vice versa)
 ** touched on above but bears repeating
 * undo any UI changes on uninstall: set borders back, hide the UI, etc
 ** so people have a good experience even if they didn't like the package
 * if you're specifying any fonts, package them
 ** while it might be available on your computer, not guaranteed to be available on every computer
-* if you're a game admin, install it automatically via GMCP
+* if you're a game admin, install it automatically via GMCP or via the Mudlet Package Repository
 ** less overhead for players to get a good experience
 * if you're a game admin, provide GMCP data for your game

@@ Line 67: / Line 67: @@
 -- if the variable has already been defined, it is just set back to itself. If it has not, then it's set to a new table
 demonnic = demonnic or {}
 </syntaxhighlight>

@@ Line 51: / Line 51: @@
 === Conversely, avoid _G when possible ===
 It's not only good practice to use local variables where possible, but you should avoid referencing the global table, _G. The very thing which makes _G useful (being able to reference elements if you don't know their name before hand) is what makes it dangerous, as it can be easy to overwrite things you shouldn't and leave yourself in a broken state. For instance, all it takes is accidentally writing to _G["send"] and suddenly all of your scripts which send commands to the game are broken.
 === Avoid overwriting your variables accidentally ===

@@ Line 48: / Line 48: @@
 *** this means you can increase the speed of intensive processes just by making functions and variables local before using them.
 *** For instance, if you are going to cycle through a large table and cecho items from within it, adding <code>local cecho = cecho</code> above the loop can improve performance.
 === Avoid overwriting your variables accidentally ===

← Older revision		Revision as of 20:44, 1 August 2022
Line 144:		Line 144:
	=== Capture the IDs returned by your temp items and anonymous event handlers ===		=== Capture the IDs returned by your temp items and anonymous event handlers ===

		+	: You can now skip the following by using [[Manual:Lua_Functions#registerNamedEventHandler\|registerNamedEventHandler]] or [[Manual:Lua_Functions#registerNamedTimer\|registerNamedTimer]] instead. The below still holds true if you want to use the anonymous functions directly and is left for that reason.
	: One of the more common issues people come into the help channel with is stacking tempTimers and old anonymous event handlers which have been edited not being cleared out and still firing. The solution for these issues is the same. The functions which create temporary or anonymous items in Mudlet return an ID. You need to save this ID to a variable and use it to remove the existing item before reregistering it. So for examples		: One of the more common issues people come into the help channel with is stacking tempTimers and old anonymous event handlers which have been edited not being cleared out and still firing. The solution for these issues is the same. The functions which create temporary or anonymous items in Mudlet return an ID. You need to save this ID to a variable and use it to remove the existing item before reregistering it. So for examples

← Older revision		Revision as of 14:28, 29 September 2021
Line 141:		Line 141:

	: the c/d/h/feedTriggers functions are great for testing your triggers without having to make something actually happen in your game. But you should not be using it as a functional part of your system. Much like with expandAlias, you should be calling a function from the trigger and the place you are calling feedTriggers to do the same thing, rather than getting the trigger engine itself involved.		: the c/d/h/feedTriggers functions are great for testing your triggers without having to make something actually happen in your game. But you should not be using it as a functional part of your system. Much like with expandAlias, you should be calling a function from the trigger and the place you are calling feedTriggers to do the same thing, rather than getting the trigger engine itself involved.
		+
		+	=== Capture the IDs returned by your temp items and anonymous event handlers ===
		+
		+	: One of the more common issues people come into the help channel with is stacking tempTimers and old anonymous event handlers which have been edited not being cleared out and still firing. The solution for these issues is the same. The functions which create temporary or anonymous items in Mudlet return an ID. You need to save this ID to a variable and use it to remove the existing item before reregistering it. So for examples
		+
		+	<syntaxhighlight lang="lua">
		+	-- incorrect, can stack timers
		+	tempTimer(0.5, function()
		+	send("And another one")
		+	end)
		+
		+	-- Ensures the timer only fires once, .5 seconds after the first time it is called
		+	if not myTempTimerID then -- only do something if we haven't already
		+	myTempTimerID = tempTimer(0.5, function()
		+	send("Only one")
		+	myTempTimerID = nil -- unset it so it can fire again
		+	end)
		+	end
		+
		+	-- Resets the tempTimer each time it is run, so it runs
		+	if myTempTimerID then
		+	killTimer(myTempTimerID) -- can run killTimer on an already fired timer without causing an issue.
		+	end
		+	myTempTimerID = tempTimer(0.5, function()
		+	send("Only one")
		+	end)
		+	</syntaxhighlight>

	=== Package and Module best practices ===		=== Package and Module best practices ===

← Older revision		Revision as of 14:10, 20 September 2021
Line 137:		Line 137:

	: There's a whole wiki page on this at [[Manual:Functions_vs_expandAlias\|Functions_vs_expandAlias]]		: There's a whole wiki page on this at [[Manual:Functions_vs_expandAlias\|Functions_vs_expandAlias]]
		+
		+	=== feedTriggers is for testing, not production ===
		+
		+	: the c/d/h/feedTriggers functions are great for testing your triggers without having to make something actually happen in your game. But you should not be using it as a functional part of your system. Much like with expandAlias, you should be calling a function from the trigger and the place you are calling feedTriggers to do the same thing, rather than getting the trigger engine itself involved.

	=== Package and Module best practices ===		=== Package and Module best practices ===