Big 2021 Area/Vehicle Patch


TABLE OF CONTENTS / TL;DR: 0. Big patch next boot! (Mostly backend stuff.)

  1. Movement system rewritten (mostly same behavior though).
  2. Skills rewritten (not much changed behavior, possible changed messages).
  3. Vehicles rewritten (very different behavior!).
  4. Settings system ("toggles") rewritten (changed behavior).
  5. "Crafting" skills rewritten (not much changed behavior).


After the big equipment rebalance in April 2020, we started talking about a skill rework project. This really hasn't gotten off the ground yet, for a variety of internal and external reasons. The external reasons are things like COVID-19 and the associated lockdowns, and other real-life considerations. The internal reasons include (as always) the decades of weird stuff that has accumulated, layer-by-layer, in our code base that make large-scale changes difficult.

So, while we all collectively licked our wounds over the past year, we've been spending time fixing up more and more of our core game code that always annoyed us. And it's almost time for release.

But don't get too excited yet! Except in a couple areas, we generally did *not* change how the game actually behaves. Instead, we tried to rationalize the systems that make up the game, and to make sure these systems interact with each other in consistent ways. This will give us the foundation to do some interesting things with skills in the future, but for right now most things are still the same.

So, here is the list of what's changed. This isn't a changelog for stuff that you, as a player, *should* notice - really, it's a list of place where you *may* find bugs.


OLD AND BUSTED: Movement functions would take a direction string ('north' or whatever), then figure out what to do with that string on their own. Anything that might interrupt movement, or print special messages about that movement, would be custom in that particular movement codepath. This lead to a variety of ways to handle very common tasks like turning a direction into a room, or blocking movement if the player shouldn't be able to bounce, etc.

NEW HOTNESS: All code that may cause a player movement collects relevant information (room to go to, how 'strong' your movement is, strings to print, requirements for the move, bounce restrictions) in a consistent manner, and passes that info to lib functions that process it in a consistent manner.

POSSIBLE BUGS: We didn't go through every place in the game where we have custom movement code! We checked exemplars that we believe cover most or all cases, but there is a chance that some <climb> syntax somewhere is weird in ways we didn't anticipate. Further, weird edge cases related to LR droids and high-level Bimm trees blocking movement may act strangely (though we tested those pretty thoroughly). Also, there may be some issues with bounce code. If you notice any issues around this (even old issues), let us know. This is a part of the game that we really want to get right.

MOVEMENT BLOCKERS: We did change one thing though: movement blockers. Different movement blockers used to use various means to prevent movement, and used different math to decide how long to block for. Now, movement blockers have a block strength, and players' movements have a movement strength, which can be increased by various skills and items. If the player's mobility is less than the block amount, the player must wait 1 second to try moving again (cumulatively increasing their mobility score with each move).

So if a LR droid blocks a player for 20, the player will have to try to move out of the room 20 times (with at least 1 second between each attempt). If the player uses <haste> and increases their mobility to 5, they will have to try to move out of the room 4 times (5 + 5 + 5 + 5 = 20). Those aren't exact numbers... You'll have to figure those out on your own. :)


OLD AND BUSTED: When a skill was invoked, we would call a command function, and from there the skill could do whatever it wanted. If we wanted it to select a target the same way as another skill, we would copy/paste the target selection code. And so on. When we wanted to reference the name of the victim, we had to do something like "You hit "+target->query_cap_name()+" with your fist."

NEW HOTNESS: We wrote a "base skill" object that handles skill requirements and target selection consistently. Actual skills can inherit this object and provide custom failure messages and give it hints at how to resolve the target (e.g. default to attacker? default to me? look in my inventory?). Further, all skill messaging (including all possible failure messaging) is run through a function that allows us to just write "You hit $vic with your fist." This change also allows us systematically display certain features about the skill in the panic file, so the headers of skill panic files usually give a little more info than they used to.

POSSIBLE BUGS: We rewrote over half of the skills in the game to have them use this new system. Generally, when it comes to the "core behavior" of a skill (i.e. what happens when you have a valid target and the skill check succeeded), we just copy/pasted what was already there. And we've gone through and tested each skill for consistency. But there are surely cases we missed. And of course, you may see un-replaced "$vic"-style messages in cases where the string replacement code isn't working as intended. Please <typo> these.

FURTHER NOTE: While we were there, we couldn't help but rewrite some of the messages that we thought needed a little love. If you are doing any pattern matching for timers and so on, you may need fix some things up (sorry).

SLICERTOOL NOTE: In the interest of actually wrapping this up and releasing it, we have NOT changed many slicertool-based skills over to the new system. Untangling that knot is going to happen soon, as a stand-alone project.


OLD AND BUSTED: Vehicles were weird things that didn't really interact with the rest of the game. You could enter them, and leave them, and move them around, and fire at things with a special syntax, and that was about it. You couldn't attack them, so we're not even sure of the last time a vehicle was destroyed in our game (other than scripted destructions as part of a fight). You had to move by typing <zoom east> or whatever.

NEW HOTNESS: An enclosed vehicle with weapons ("combat vehicles," if you will) now has a weapon class, and will auto-swing during normal combat. Certain commands like <kill>, <consider>, etc. will work on vehicles, and will work from vehicles. Vehicles can only be repaired a limited amount (several HP pools' worth) before they are too worn down to repair further. And you can just use the regular room exit dirs to move while in a vehicle.

POSSIBLE BUGS: We had to go through the combat system and make sure vehicles were handled correctly in each possible branch. We believe we've tested each of those branches, but it's possible we missed some things. If you run into issues where only one combatant in a vehicle fight is swinging, please <bug> it.

FURTHER NOTE: This is a functional but bare-bones implementation of this type of vehicle combat. Most skills don't work on vehicles, and don't work from vehicles. If you notice a skill that you think would make sense to be able to use on vehicles, or from a vehicle, please <idea> it!




POSSIBLE BUGS: This is a new system. We've tested it a bunch, but please report anything odd you notice with settings seeming to be "off" even though you have them "on" (or vice-versa).


OLD AND BUSTED: Any time a skill took items from a player's inventory, deleted them, and gave the player a new item (i.e. a "craft" skill or "build" skill), the skill would do all of the item finding and other requirements-gathering completely custom. A lot of the code had been copy/pasted among skills over the years, but there were lots of inconsistencies.

NEW HOTNESS: All build skills now use a common backend, allowing us to make nice improvements across the board, like (a) telling the player ALL of the requirements they are missing if they can't build an item, (b) telling the player all the items they could build with their current inventory if they don't provide an argument, (c) interpreting the player's input generously for all builds (don't need to capitalize, can just give the first few letters).

POSSIBLE BUGS: We *think* this should be good - as some of you may have noticed, we've already implemented some parts of this change on the live mud, and quashed a few minor bugs that cropped up. But there may be other issues we haven't seen yet!

PATCH STATS FROM GIT: 1,610 files changed. 31,506 lines inserted, 46,472 lines deleted.