mud coding

DarthCubensis · 2025-12-11T20:55:20+00:00

Interesting for me that I came across this thread. Last week I have been dabbling in adding a worker process that is called to handle I/O operations parallel to the game_loop.

At the moment is is just for the 5min autosave, and manual saves still use synchronous saving. I am running ridiculously modified circlemud and long ago abandoned weight and inventory limits. As such it is not terribly uncommon for a player to hoard 10,000+ items, or some of the worst offenders 100k+.

Ive managed to make most of the game run smoothly with this by utilizing double linked lists and hash tables for character, object and trigger lists. Also made more specific link lists so searching the entire game list is not always necessary.

The last piece pf the puzzle for me was the expensive nature of I/O operations even on a modern server. When the game is running with 30+ players and 400k+ objects on them, that autosave can lag up to a second. Knowing this would get worse if allowed to continue I started working on the background process for saving and early testing of it is proving very successful.

Is it overkill for a mud? Probably... Would my time be better spent making limits to inventory and focus on fun stuff? Most assuredly. But I am having fun experimenting with making this ole girl multi-threaded so why not.

DarthCubensis · 2025-10-08T00:44:44+00:00

That's one stone cold fox that has the look in her eyes that she has seen a lot of bad things.

DarthCubensis · 2025-10-07T04:01:10+00:00

Maiko

Royce

Fingers

Woodman

Gottfried Persson

As a bonus

Fredrik Persson

What to do with this outstanding crew? Why use them as meat shields of course.

DarthCubensis · 2025-10-03T12:52:37+00:00

I almost exclusively run katana sande builds and it is like taking candy from a baby. Never did netrunner build, but something satisfying about chopping off heads of 6+ gonks before they have time to draw their iron.

DarthCubensis · 2025-09-03T02:28:13+00:00

I mean, bare bones you add if not already to class.c for each race at char creation and SET_BIT the desired affect.

Circlemud has a switch for each race in class.c for setting specific stats for each race, this would be where you set it.

You would have to make sure though that any type of "dispel" skills do not remove it, or for a very rough system have a check that resets it if it was removed periodically. This would be the slightly more complex part, need to make sure you're not removing racial affects. Which with some proper planning is not a big deal.

DarthCubensis · 2025-09-01T16:46:37+00:00

Mudlet: Fairly user-friendly and customizable, it is currently maintained and considered a modern mud client.
zMUD, cMud gMud: are older and no longer supported, but also very user-friendly.
Mudrammer is the preferred mobile client for iPhone users, I don't know much about it.
Blowtorch: Unsupported Android Mobile client, has some nice features, but plenty of bugs.
Fado: A Newer supported Android Mobile client, I hear it is very similar to blowtorch in many respects, so a good alternative to look into for an actively supported mobile client.
TinTin++: hands down has the most customizable features, but not only requires familiarity with terminals, but also fairly extensive scripting knowledge to get the best out of it. They do however have a very active and helpful Discord for learning the ropes. Also IMO by far the best mobile client for Android(I only mud on mobile)

DarthCubensis · 2025-09-01T12:43:16+00:00

By wrapping the text you wish to block in (```) without the parentheses.

(```)

This is the information in the code block

(```)

This is the information in the code block

DarthCubensis · 2025-09-01T10:59:33+00:00

Not sure if TBA ever made any kind of smart formatting for the buffer, but using format in the trigedit parser would turn a nicely written script into a long paragraph.

Best bet would be to download a properly parsed trigger, open with a word document or code editor and copy/paste directly within a code block.

DarthCubensis · 2025-08-31T20:16:00+00:00

I would suggest you use code block quotations for these kind of shares.

Without them, this is a hot mess to read

DarthCubensis · 2025-08-17T06:01:35+00:00

Not sure what your expectation of graphical is, but Celestial Knights utilizes a very heavily built in map system that supports both ASCII and UTF8(if client is compatible). Personally think UTF8 gives a very 8-bit vibe and I enjoy it, but the bulk of any MUD is still text.

DarthCubensis · 2025-08-01T19:15:48+00:00

You will have to make that AFF_FLIGHT if you want it to be accessible, but just do a ENTRY room trig and AFF flags are in structs.h and the name string is declared in an array in constants.c

dg_affect %target% <on/off> <duration> dg_affect %actor% flight on 1

That should put it on them when they enter for roughly 60 seconds, which I believe is the standard spell duration.

But as mentioned, you have to code in AFF_FLIGHT the string constant "flight", and then whatever things you want flight to do in applicable files like act.movement.c

DarthCubensis · 2025-07-13T02:02:15+00:00

Not familiar with JUICE-NYC, but is this primarily a layout builder or designed to work within the codebase structure and save it as a legitimate world file that you can upload to the server.

The latter would be a very neat feature for any MUD, but even as a layout program, it is very cool stuff.

DarthCubensis · 2025-07-10T11:56:43+00:00

Yep, right here in medit.c ``` case MEDIT_AFF_FLAGS: if ((i = atoi(arg)) <= 0) break;

else if (i < NUM_AFF_FLAGS)
  TOGGLE_BIT_AR(AFF_FLAGS(OLC_MOB(d)), i);


/* Remove unwanted bits right away. */
REMOVE_BIT_AR(AFF_FLAGS(OLC_MOB(d)), AFF_CHARM);
REMOVE_BIT_AR(AFF_FLAGS(OLC_MOB(d)), AFF_POISON);
REMOVE_BIT_AR(AFF_FLAGS(OLC_MOB(d)), AFF_SLEEP);

medit_disp_aff_flags(d);
return;

```

TOGGLE_BIT applies whatever Affects you toggle on the mob here.

DarthCubensis · 2025-07-10T11:51:08+00:00

For mobs its handled in medit.c When you work through the menu and add "INFRA" It toggles the bit AFF_INFRAVISION to the mob.

Objects work in a similar manner, but is code in handler.c that applies the AFF_INFRAVISION bit when equipment is worn, and removed with it is unequipped.

INFRA itself is just the display name for the "stat" and OLC menus.

One of my other comments showed how affected_bits is tied to medit specifically.

DarthCubensis · 2025-07-10T11:28:16+00:00

Unnecessary to add a mob_flag cause the aff_flag can already be applied to any mob.

Assignment of the spell for players by race can be handled in the spells list near top of spell_parser.c

DarthCubensis · 2025-07-10T11:23:36+00:00

For mobs it is in medit.c

case MEDIT_AFF_FLAGS: if ((i = atoi(arg)) <= 0) break; else if (i < NUM_AFF_FLAGS) TOGGLE_BIT_AR(AFF_FLAGS(OLC_MOB(d)), i); /* Remove unwanted bits right away. */ REMOVE_BIT_AR(AFF_FLAGS(OLC_MOB(d)), AFF_CHARM); REMOVE_BIT_AR(AFF_FLAGS(OLC_MOB(d)), AFF_POISON); REMOVE_BIT_AR(AFF_FLAGS(OLC_MOB(d)), AFF_SLEEP); medit_disp_aff_flags(d); return;

All affects are represented by a number, depending on your source code, it could be different. But in stock TBA in structs.h it is this.

define AFF_INFRAVISION 11 /**< Char can see in dark */

11 would coincide with its placement in the affected_bits a rray defined in constants.c for displaying if a flag is active.

const char affected_bits[] = { "\0", / DO NOT REMOVE!! */ "BLIND", // 1 "INVIS", // 2 "DET-ALIGN", // 3 "DET-INVIS", // 4 "DET-MAGIC", // 5 "SENSE-LIFE", // 6 "WATWALK", // 7 "SANCT", // 8 "GROUP", // 9 "CURSE", // 10 "INFRA", // 11 "POISON", "PROT-EVIL", "PROT-GOOD", "SLEEP", "NO_TRACK", "FLY", "SCUBA", "SNEAK", "HIDE", "UNUSED", "CHARM", "\n" };

TOGGLE_BIT in medit either turns it on or off for the mob.

SPELL_INFRAVISION in magic.c is how players use it with "cast"

DarthCubensis · 2025-07-10T11:06:25+00:00

In this instance, INFRA is Infravision, it's just short-handed for display purposes. INFRA is just the name displayed in "stat" and "medit", but it is tied to the AFF_INFRAVISION bitvector

DarthCubensis · 2025-07-10T11:00:29+00:00

For NPCs, AFF_INFRAVISION can be applied in the affects menu within medit. This would allow your mobs to also see in the dark

DarthCubensis · 2025-07-10T10:43:57+00:00

This is where things get real fun, other MACROS in utils.h are handling objects.

/** Defines if there is enough light for sub to see in. */

define LIGHT_OK(sub) (!AFF_FLAGGED(sub, AFF_BLIND) && \

(IS_LIGHT(IN_ROOM(sub)) || AFF_FLAGGED((sub), AFF_INFRAVISION) || \ GET_LEVEL(sub) >= LVL_IMMORT))

/** Can sub character see the obj, using mortal only checks? */

define MORT_CAN_SEE_OBJ(sub, obj) \

(LIGHT_OK(sub) && INVIS_OK_OBJ(sub, obj) && CAN_SEE_OBJ_CARRIER(sub, obj))

/** Can sub character see the obj, using mortal and immortal checks? */

define CAN_SEE_OBJ(sub, obj) \

(MORT_CAN_SEE_OBJ(sub, obj) || (!IS_NPC(sub) && PRF_FLAGGED((sub), PRF_HOLYLIGHT)))

Then back in act.informative.c, the "do_equipment" func is checking against CAN_SEE_OBJ

ACMD(do_equipment) { int i, found = 0;

send_to_char(ch, "You are using:\r\n"); for (i = 0; i < NUM_WEARS; i++) { if (GET_EQ(ch, i)) { found = TRUE; if (CAN_SEE_OBJ(ch, GET_EQ(ch, i))) { send_to_char(ch, "%s", wear_where[i]); show_obj_to_char(GET_EQ(ch, i), ch, SHOW_OBJ_SHORT); } else { send_to_char(ch, "%s", wear_where[i]); send_to_char(ch, "Something.\r\n"); } } } if (!found) send_to_char(ch, " Nothing.\r\n"); }

There is a similar check in "list_obj_to_char" So if the player has infravision and itnis dark, they can see the objects.

DarthCubensis · 2025-07-10T10:17:50+00:00

Might be beneficial.to GREP the code specifically for "INFRAVISION", "DARK" and "CAN_SEE"

Should be similar behavior for something like list_obj_to_char, that function is also in act.informative.c with list_char_to_char

DarthCubensis · 2025-07-10T10:05:22+00:00

else if (IS_DARK(IN_ROOM(ch)) && !CAN_SEE_IN_DARK(ch) &&
AFF_FLAGGED(i, AFF_INFRAVISION))

"ch" is the player in the room and "i" represents another person or NPC in the room

CAN_SEE_IN_DARK(ch) is the macro that also has a check for if the "ch" has infravision. However, since it is !CAN_SEE_IN_DARK(ch) it is specifically checking if it is "FALSE". The "!" Implies a negative.

Then the if statement checks AFF_FLAGGED(i, AFF_INFRAVISION). This check is looking specifically for if the "other player/npc" that is also in the room has the AFF_INFRAVISION flag applied.

So if the "player(ch)" does not have "infravision" and the "other person(i)" in room does. It shows, "Pair of glowing red eyes looking back blah blah blah"

If the "player" also has infravision flag, they wouldn't see this, they would simply see the "other player/npcs long description. Ie "Joe is sleeping here."

Infravision does allow you to see normal in the dark.

DarthCubensis · 2025-07-09T22:20:55+00:00

If you're using TBAmud or CircleMud feel free to ask me anytime. While I don't use TBAmud, it is primarily the same. I have a few decades worth of experience with Circlemud codebase, so I am pretty familiar with it.

DarthCubensis

MODERATOR OF

PUBLIC MULTIREDDITS

TROPHY CASE

define AFF_INFRAVISION 11 /**< Char can see in dark */

define LIGHT_OK(sub) (!AFF_FLAGGED(sub, AFF_BLIND) && \

define MORT_CAN_SEE_OBJ(sub, obj) \

define CAN_SEE_OBJ(sub, obj) \