Question patches and the "vines" or "weeds effect"

Though effective, some patches cause what I call the "vines" or "weeds" effect, for example by wrapping something like this around the moment of damage in fight.c:
Because the feature is a perk, it's probably not worth updating every mobile's health message every moment or so, so maybe modding like this is good enough. However for it to be at the release standard, it's hard for beginners to know how much deeper it needs to be implemented. I'm still at the skill level where my goal is to minimize the CPU and memory impact of a patch. There's satisfaction in making patches that are a kind of shell game that always work, yet I'd rather have written an entire text MUD and will probably soon step away from mods. My next mod in mind is "sleep goto" without telling characters about it, or, when your character sleeps, your dreaming character wakes up where he/she/it left off dreaming. Slapping all these mods into a MUD sounds like what a custom MUD is for. I'm more interested in coding for releases. Glad to be an active member and I hate to admit it: sometimes others take an idea further. I'll continue learning and anticipate someday no longer feeling like I'm playing a lottery instead of knowing I'm mastering an idea in a programming language.

Which patch is this?

www.tbamud.com/forum/4-development/947-melee-health-messages

It works really well. There are probably a few tighter ways to code it. My thought is generally about how to fully implement an idea beyond simply adding it, in order to avoid a MUD that is so patched up that it lessens as a choice for a codebase.

Generally there are a couple of ways for avoiding code bloat (which I think is what you call the weeds effect).

The first way is modulizing the code. The code is split into modules which each has a relatively limited interface. Each module is testable and is independant from other code. Common datatructures are passed as parameters. This is commonly done to make sure changes in one part of the code doesn't influence the rest too much.

The second way is installing hooks and a plugin engine. This is commonly done to make code easily expandable, and when done right makes the core code extremely lightweight.

We have examples of both approaches in the code today; the event system is a module with a limited interface. And the command structure, spell system, spec_procs and dg_scripts are obvious examples of the plugin engine system - all you need is two integration lines and an ACMD() to make a new command.

However, the system isn't fully modular, and it's not all built with easy pluginability in mind. Especially "internal" functions, like the fight.c or handler.c functions are not built to be expanded upon easily. And the notorious global datastructures in db.c are an eternal source of problems.

I'm afraid you can't really avoid some changes to the core functions that wil lseem like bloat. You might want to refactor them out to a single functioncall, like "send_fight_messages(ch, vict, dam)" or similar. But since this is changing a core aspect, you'll be hard pressed to avoid adding code to the actual function.

What is the event system? Also please comment on the use of macro's.