Reset Password
Existing players used to logging in with their character name and moo password must signup for a website account.
- BigLammo 7m
- Mobius42 30s
a Kard 14m
- Knyghtskye 7s
- Komira 7s
- JMo 28m Sheriff's posse's on my tail 'cause I'm in demand
- spungkbubble 37s
- Sivartas 1m
w Macabre 1s 60% GM, 40% Baby Builder!
- Napoleon 2m
- QueenZombean 52s
- Rillem 1m
a Mench 2m Doing a bit of everything.
- Baphomei 41m
- adrognik 33s
- Meat 13s
- Hivemind 10s
- zxq 45m
- Enven 13m
And 23 more hiding and/or disguised

[Nov '22] Improvements & Bug Fixes
Change log for November 2022


The 'burn' command on this one use item was broken. Not sure how many people have attempted this, had only one bug report. However, this code never worked, as it was calling an internal verb on an variable that was not defined (a typo most likely). Not sure how this made it IC without testing. I've resolved the issue and it should work now.


This was not working because while the code was attempting to support the operation, it was checking file extensions on a directory, which obviously, does not have a file extension. I've fixed the issue and this has been tested and works.


Salads now have more than the default taste thanks to Boots.


Someone crafted something and got more than one item. This is not a bug, it's a critical success. I've added a help file that is pretty basic right now but it does outline this so that others don't think it is a bug if they encounter it.


50 bugs have been submitted since 10/07/22

39 of those bugs have been resolved.

200 bugs have been submitted since 06/23/22

148 of those bugs have been resolved (fixed, unable to replicate, working as intended).


This had an incorrectly set hardpoint, it has been fixed.


I've updated the guidance in @bug to include more information on what makes a good bug report, and added some color.


Some tires improve your traction to the point you won't see 3-point turn messages. This isn't a bug. It's how these tires work I guess. I'm only assuming because there isn't any documentation on how it is supposed to work.


In the current process as we rework it, there is no automatic order delivery. The dates you get from the NPC are when the order 'arrives in the city' essentially. You still need to schedule a time with the NPC via puppet request to do the handoff. I've updated the messages the NPC responds with when you ask the status of your delivery to include these hints to put in a puppet request.


When the fixer term was created it was done with different discount %'s than the Job object specified. This was leading to confusion as the employment term would say something like 5% discount and the fixer terminal / NPC was using 10%.

I've brought these in line so that there is no longer confusion and rewritten how the job object presents the information so it is more clear as you rise through the ranks.


I added a recurring GM notification when then are undelivered fixer crates that need to be delivered. This should make it easier for GMs to stay on top of this without too much additional effort of having to track when they are available.


There was a bug where slotting an e-memory module with a broken filesystem into your chip reader and then checking the filesystem with /fs and then unslotting it would cause the module to disappear because the cache was caching an error instead of a filesystem. I have resolved this, though the issue with e-mems having broken filesystems still exists. Looking into that next.


If you have an ememory module with no file system detected, I have a fix for this but I want to run it manually for each broken module so I can gather more information on how this happened. Please put in an @bug if you have one of these (and have not already @bugged it) and include the location and name of the e-memory module in question. I'll look into it and reach out about reinitiatlizing the file system.

Please also include if this e-memory module was blank, had data, if you had used it previously, if it had randomly stopped working, and what commands you may have run on the e-note or chip reader prior to it breaking. Also please let me know if you've been using an e-note or chip reader or both.


If you try to slot an e-memory module into a chip reader or e-note that is full or if the chip is missing a file system, it was giving an error message:

You try in vain to slot your PRI e-note 7 into your PRI e-note 7, but you can't seem to make it fit or it's rejected.

Now it will be the correct: You try in vain to slot your e-memory module [25000u] into your PrimeSoft ChipReader Slot, but you can't seem to make it fit or it's rejected.

These messages are obviously dependent on if you are using an e-note or a chip reader.


I had to make this and other e-note bugs fixes in two places, because while the e-note and the chip reader do literally the same thing, the code was just copy and pasted to both objects, instead of having some kind of abstraction that both object types call. This means that every bug that exists for e-notes/chip readers, exists in two places and has to be fixed twice.

Rationalizing these two systems that do literally the same thing with the same code that exists in two places is now something we have to do, to avoid future issues.

(Edited by Slither at 6:02 pm on 12/1/2022)


After further testing I've updated the gunner hardpoint to the rear hardpoint.


This weapon was apparently never tested. It had no chance of working because it was trying to use an integer where the code expected a float. I've fixed the error and this now 'works' but it has several other issues such as the messaging being broken, the person shooting the weapon being attributed, the ammo type not being parsed correctly resulting in an anomalous ammo message. I've got players submitting bugs for these issues and I'll start looking into them at some point soon.

There are probably a ton of vehicle combat bugs, especially with vehicles that have multiple weapons. So please @bug them as you see them and as I learn this system I'll start fixing the issues.


There was a recent thread on this, but I had actually planned to implement this change a few weeks ago and then it fell off my plate and I forgot.

If you are employed at a Mega Corp (PRI, VS, NLM, WJF) and you are CORPORATE (non service) worker, and have moved beyond Junior (or whatever the first tier of employment is), you will no longer be able to run errands for NPCs topside.

By errands I mean you can't walk up to the NPC and ask them if they need something, they are going to say no, very politely, because you are too high status to run bullshit errands.

Nothing is stopping you from using Juniors at your corp, or service workers, or whoever, to hand items over on your behalf for a cut, if that's a hustle you want to go after though.


There was a bug in the cargo delivery code where if you had recently requested a new license (any kind) and it hadn't been reviewed as of yet, it would cause the cargo delivery code to traceback as it was looking for an entry in the license that didn't yet exist.

I've fixed this and the code will work as intended now.


There was a bug in the parry code due to a fork() where if two attackers attacked in the same phase, against a person who was guarded and using a weapon that can parry, and successfully executed a parry on both attacks, they would potentially get two counter attacks where they should only have gotten one (since we rate limit counter attacks).

I've found the source of this bug and fixed it. This further balances weapons that can parry, especially when someone goes guarded against multiple attackers.

This means in big fights where there are a lot of attackers, you are still going to parry the same amount, but you will not get more than one counter attack.


A big fight happens. NPCs are involved that jump in automatically. All the sudden a few people are attacking like six times in a row. Sound familiar?

I created a new logging framework for the MOO specifically to track down this issue with combat. I'm pleased to say that I've identified the issue, which was that several assumptions were being made about how forked tasks work in the MOO that were incorrect, which resulted in combat phases being executed more than once. This issue has been around a while, ever since the major combat overhaul that happened last year.

I've resolved the issues around forked tasks. I've tested with a massive ganger battle and the results are now inline with what you would expect.


In general, it IS possible for someone to get two attacks in a row. That's as intended and based on initiative. Just flagging this as not everyone is aware. Obviously if it's 3-4-5 in a row that's a bug. But didn't want people seeing two in a row happening sometimes and thinking it was a bug.


PLEASE! Continue to @bug any wonkiness you see with combat. My changes are probably not going to fix every issue, though I hope I've addressed the biggest one. Please flag issues you have.

(Edited by Slither at 7:07 pm on 11/6/2022)


If you try to shower while in a cube and you are sitting or doing something else, it will stop you before taking your money now, instead of after taking your money.


For those with the skill, when looking at someone you can see the quality / state of the armor being worn. There was a bug where if armor quality fell below zero there could be a TB due to the code not expecting a negative number. I've fixed this issue.

EAC Ten25-SK Sabre Pistol ATTACKS

These attacks no longer reference 'glock 20' and reference 'pistol' instead. If you come across other guns that are showing the 'old' names for their attacks during combat, please @bug the name of the weapon and an example of the message.


This entrance got messed up and stuck in a security scan state. I manually fixed it.


Some deck of cards were broken when adding to the community pot of cards that appears in the room. I've resolved this issue and they should be working as expected now.


22 bugs remain from those submitted since July 23rd, 2022.

442 overall (though some of these date back to a year ago and are probably already fixed or obsolete by now).


Photos of art were very broken in some cases, with colors not showing up, artist name not showing up, etc. I've implemented a new photo capture verb for art that will capture them properly, such that they will present the same in a photo as if you looked at the art itself. This is a FORWARD FACING fix and will NOT fix old photos of art. Those were captured badly and we can't fix them now.


There were some configuration issues in how the following sets of armored clothing were calculating their 'current damage':

Generic neXus Mesh Jacket

Generic neXus Synth-hide Trenchcoat

Generic neXus Synth-hide Codpiece

Generic neXus Mirrorshades

Generic neXus Synth-hide Boots

Generic ProTek Proline flak jacket

Generic Ballistech ToughShades

Generic WJF Combat Medic helmet

These items had 0.0 in slots that they didn't have coverage for (like left ear) when they should have been 100.0. This didn't impact how well they protected the wearer, but they did impact the score the clothing got when examined by someone with the skill to see the condition of the armor. It was showing as 'catastrophically damaged' because of the 0's even if the armor was mint.

I've resolved these issues. As a result of the complexities involved in resolving it, anyone with these items has had the item quality set back to 100.0 for all slots (including ones where it might actually have had legit damage). It may still show as having been repaired previously which is normal.


You can't typically put a disassembled gun into your inventory, but there are ways for this to happen (like getting your gear back from a landlord). When in your inventory you can't drop the item and you can't assemble it. I've made it so you can now assemble it from your inventory -- for situations where it ends up there.


I've updated the messaging on toggle to correctly state the 'toggle' command and not 'turn'.


Previously, if you were scanned to and controlling a robot and then you unscanned the robot from the controller, the internal shutdown command would still work even though you weren't still controlling that robot as you had unscanned it. I have fixed this, and the controlled robot must still be scanned to the controller for commands like that to work.


There was a fun bug that made it so if you were authorized for a vehicle, someone could see your current disguise name if they looked at the security system. I've fixed this and the persons name will now just show as 'disguised person'. If there are multiple disguised people it will show multiple 'disguised person' entries.


It was impossible to unauth a disguised person even if they were in the vehicle. This was annoying for obvious reasons. I've added the ability to unauthorize based on a list. If you enter:



unauthorize from permission group here

It will provide a list of authorized people that you can unauth based on. The names of disguised people will be obfuscated. This does mean that if you have two disguised people on the list you won't know which one is which, but it's better to be able to unauth both of them to be safe than none of them!


If you fail to unauth someone because they aren't present it will now show and additional message pointing you to the unauthorize command without a subject:

[Display] Try unauthorize without providing a subject name to pick from a list: 'unauthorize' or 'unauthorize for '

(Edited by Slither at 1:06 pm on 11/9/2022)


This shirt was named things like 'midnight black honey badger baby doll tee' but certain versions of the shirt didn't have a proper color so when you looked at it, it said it was white. I've fixed these. They may now be named slightly differently but they are the same shirt.


Previously the telepresence avatar that spawned when you called someone with your telepresence unit was locked to the description you had when the call started. I've fixed this so it now proxies the description of the avatar any time it is looked at, meaning if you wear/remove something or update your @describe, it will be reflected in the avatar right away.

Holo strippers now have a job!


Depending on the skill roll, while using the /proj verb your audience would either see something like:

Joe projects a hologram of (insert your projection here)

Or simply

(your projection here)

Based on your skill roll. Due to the two different options it was unclear if you should capitalize or not. IE: /proj a pretty scene or /proj A pretty scene.

I've resolved this issue, it will now auto capitalize for you, so you should always use /proj .


There were some objects that didn't define the :tell_speech verb that were causing the /proj verb to TB. I've resolved this issue.

(Edited by Slither at 1:05 pm on 11/9/2022)


There was a bug when trying to stock this type of room with the stuff that knocks people out. Some of these were manually fixed but the root cause was not addressed. The property that held the stock was misconfigured and that resulted in the TB. I've fixed it for all of these mobile medical rooms and that specific stock command should work again.


I've regenerated the filesystems on all the e-mem modules that had completely invalid filesystems (never assigned one, basically). This means they will work but be empty, most likely they never had anything on them.

This fixes some of the modules, but not ones who have a file system pointer, but that pointer is pointing to files that don't exist in the database. I still need to manually fix those when they appear, as I want to dig into what is causing them further.


This command has been broken for about a year. I've resolved the issue with the code and it should function again.


The command previously functioned like 'go' where you could string together a a go string style movement queue. This no longer works due to the changes made to how movement is processed for vehicles. The result was that the player was left behind in the original room and didn't attempt to move until the wheelchair reached its ultimate destination. There is no easy way to carry this functionality forward with the movement code that is in place now, so I have disabled this feature.


Mech's use a different look_self command than other vehicles, and it was old and hadn't been updated, this meant that it didn't show graffiti that had been painted on it. I have corrected this. That means any graffiti spraypainted on mechs in the past (and I've confirmed there are some lovely bits that were sprayed previously) will now be showing.


I've fixed @bug so that when you submit a multi-line bug report it doesn't put it all onto the same line when it comes into Jira.


A previous coder made it possible to throw things out windows in cars but never checked what would happen if you threw something out of a window while flying in an aero, or from a non aero but into a dynamic space room (like exists in some aero landing pads in game). Thus, the code never initiated a 'fall' and the items would just hangout in the the room they were thrown into even if that was mid air. I've resolved the issue by checking if the room is a free fall room and initiated the fall for things thrown out the window.

If you see anything floating around please xhelp with the location so we can clean it up. No more floating severed hands.


I've finished my review of all bugs submitted last year around this time (see above) and have resolved all but 6 of the 42 submitted during that time. The 6 remaining require me to test with a player and I'm waiting to see the right folx online.


I've finished a cursory glance at all the bugs in gojira, and have closed out more duplicates, things already fixed, or things so specific to a situation that they are not replicateable now that so much time has passed.


After resetting the quality scores on the items below:

Generic neXus Mesh Jacket

Generic neXus Synth-hide Trenchcoat

Generic neXus Synth-hide Codpiece

Generic neXus Mirrorshades

Generic neXus Synth-hide Boots

Generic ProTek Proline flak jacket

Generic Ballistech ToughShades

Generic WJF Combat Medic helmet

It became apparent that we also needed to remove damage stickers for these items as well, essentially resetting them to perfect working order. I have done this -- which meant removing the damage stickers. I took care to only remove damage stickers and not other stickers that may have been intentionally applied to the clothing.


I've updated the taste message to NOT mention smoke, because these messages can show up in drinks that are drugged with things like th-2c.


This now has a coverage of abdomen, so it can be worn. There was one in game working right, but the rest were missing this prop setting.


I've added a few more rooms to the 'ignore list' for ambient reports of crime (like assault) topside. These are rooms where corps typically have some amount of combat that the WJF doesn't need to be aware of.


If you are attractive and have chic / dashing as part of your automatically calculated short description, you will now also get your attractiveness added to your shortdesc, instead of it being over-ruled.


It came to my attention that there were times people were using the CHIC/DASHING shortdesc to hide their appearance in an IC-ish manner. Since I've removed that, I wanted to add a way to appear uglier than you are, for disguise / misdirection purposes.

Using APPEAR requires disguise skill, and more options become available the higher your skill goes. This new option is gated behind a skill check AND an appearance check. If you don't have a high enough charisma you can't appear uglier. Cause you already ain't attractive.


Any vehicle with all off road tires has been able to drive into any room (including indoor rooms, up stairs, etc) for a while now apparently.

I've resolved the issue. Off Road tires will let you drive on dunes in the badlands. They will no longer let you drive in the ocean, through a mountain or forest, into a shop, into an elevator, up stairs, down a sewer hatch, etc.


Fixed a bug where the fixer NPC was failing to return a result on exact name matches in some situations in the fixer product matching code. Clever fixers had already found a work around, but this should make their lives easier.


Fixed a dune dragon attack miss message that had 'n' instead of '%vn' for the victim's name.


A few times now, we've created persistent TERRA and Judge NPCs. You probably know the ones. And a few times they have inexplicably gone missing. Retired or recycled and we didn't know why.

This was because PCs put in charge of NPCs can tell them to 'go home' or 'back to base' or 'dismissed' expecting those NPCs would return to their homebase.

What was actually happening was that these NPCs would 'retire'. AKA be recycled. This was fine for the memento NPCs that were not persistent, and that was the intended use of the command in some cases. However, persistent NPCs were created with the same parentage and thus, were subject to the same rules.

I've removed this. Which defaults it to the default behavior which up until now was for the NPC to say they didn't support that command on local OOC. Bringing me to...


If an NPC has a valid home that isn't a coffin or OOC area, and you can boss them around, they will attempt to 'go home' to that area, if they are able. If they don't know how to get there, they will tell you so ICly. If they are already home, they will tell you they are where they need to be. This should make it easier to send NPCs back to base when you need to. They will also refuse if they are busy doing other stuff like being puppeted, or doing a dispatched task.


I found some badly spawned mementos hanging around, taking up space, still digging into how they got spawned wrong but it was primarily a hidden factions NPCs and memento VS guards. I've manually retired all 25+ of them.


These had a thickness of 1, which is the lowest thickness, or so I thought, but apparently there are some player made clothing items with a thickness of 0. So in those cases, you couldn't wear contact lenses and then wear those clothing items (like sunglasses).

The thickness issue is something I will look at in general as no clothing should really have a thickness of 0, but you should be able to wear anything you want over your contact lens now.


See above update, same change made for wigs. I've added the thickness issue to the staff meeting and will discuss there if we need to make an update to player material to hava a thickness of 1 to avoid issues like this in the future.


It's working now, as far as I can tell, though if anyone see's issues with it under varying circumstances please @bug.


There was a TB in crowded rooms due to a task running out of ticks, I've switched to a suspended version of that task which hopefully fixes the issue.


Looking through a window with thermos will now show you a wash of color, with you unable to make anything out clearly. This is as opposed to showing the view as if you didn't have thermos on. Get closer or don't use a window if you want your thermo-vision to work.

This applies to all the different kinds of windows including cube windows.


I've fixed the broken color for this location when shown at a distance. It just doesn't have colors now.


Another 50 of the oldest bugs reviewed, 41 of them resolved. I'm working from both sides, clearing out any new bugs that are submitted and working from oldest to newest on the other side. Up to January 11th 2022 in terms of the date of the oldest bug I haven't fully reviewed.

268 bugs remaining.

(Edited by Slither at 1:04 pm on 11/11/2022)


TopMudSites has gone into read only mode. I've removed the xtms social and updated the voting reminder for those that have it turned on. I've added xmv for mud verse since they allow voting and we already have votes over there.


You can no longer run jewelry through the nanopress meant to let you recolor clothing.


Ganger HQs are now considered 'secure areas'. If you're going to go merc someone in the middle of one, best be xhelping so we can have a response prepared. Thanks!


I've updated the code that manages memento NPC retirement. Instead of making 6 attempts to get to their 'home' they will make 3. I've also updated certain NPCs to spawn with a home they can actually get to, and made the code check that NPCs homes are not OOC holding pen areas, and if they are, they will just retire since they can't get there from an IC area.

This should mean fewer NPCs hanging around that should have retired, and fewer forked/scheduled tasks, thus reducing lag.


I've hardened the inventory command against those trace backs that would cause your entire inventory to be unlistable. Now you'll either get a little red status under the item informing you the item is bugged or traceback immediately below the problematic item. In either case, your inventory will still work.


There was a bug in the code for keying a radio. It was attempting to call a verb 'keyed_players' which didn't exist. The verb is actually 'keyed_player'. I've resolved the issue.


There was a bug that cropped up sometimes where when handing an npc an item they wanted the task would run out of ticks. I've added a suspend if needed to prevent this. Hopefully fixes the issue. If you continue to see it, @bug it please.


There was code in dress score calculations which was not taking into account 'face' being exposed as part of showing attractiveness and other things. I've added it and that should resolve any issues around this. If you continue to see wonkiness around it, @bug it so I can track down any other issues.


I've fixed a TB where if you typed /listen here in a vehicle you'd get wonky responses.


The feed verb was tbing because critters don't have faces, as when we updated all the nakeds for people, we didn't update the nakeds for critters, and we were checking if their face was exposed to feed them. I've fixed this, by allowing the code to continue if the face isn't present in the nakeds of the critter.


If you did key on radio and something was less than 3 characters long it would break things. I've resolved this.

There was code on the radio utils package they didn't update the messaging so it was not using the proper objects to substitute for %t and %n. I've resolved that as well.


The shortdesc of the spaceport apron at Neo was showing as a rooftop instead of an apron. I fixed this for the one room I saw. If there are more, @bug them.


There was another bug where the code was calling a verb to check if the person who had keyed the freq was still in the same room as the radio, this is useful for if the player keyed a freq and then left, and we need to do messaging.

However... that verb simply did not exist. Fixed.


I updated the help file to mention how keying works and the fact that it puts your radio on cooldown.


I left a debugging statement in /listen that was causing TBs. It's fixed now.


The color on the flarelighter tease message has been fixed.


Drug taste messages are not written in such a way as to be displayed when they are spiked into food/drink. I've made it so if a drug is being taken via food or drink the drug taste message doesn't get shown any longer.

You will still potentially get a message about 'something doesn't taste right' though, which is the intended way for the system to work.


This shop was not hooked up to the crate delivery service, so it was never going to get any new stock. I've resolved this.


TMC's SSL cert is broken/old or something. I'm considering removing TMC entirely but I've been holding out hope they will come back. It's not an issue we can fix at this point as it's on their end. Use MudVerse instead.


There are currently 272 bugs in the backlog. 13 from November that have yet to be resolved. Most of the November ones are either vehicle combat bugs or I need to talk to specific players to help reproduce / get more information, and I'm just waiting to see them online.


I've made a simple edit that (per player request) just displays the macro you want to edit, then confirms you want to edit it, deletes the macro, and runs the macro adder with the current macro name, thus allowing you to edit a macro without having to manually delete it.

This brings to a close a feature that has had a verb for 26 years, that just said 'you can't edit yet'. Gosh, this code is super old.


I've made it so you can now view a macro, which is useful.


Small update to cover an edge case. When you hide something it is moved out of the room and to a secure storage room, and a record of its location is generated in a registry, then when you search a room it searches the registry. But the issue is if some how an item gets moved out of the storage room by accident or by an admin moving it not realizing it was a hidden item (there is a warning about this but it can still happen), it can't be returned when it is found because it is somewhere else IC.

Basically the registry says the item should be hidden in X room, but the item is actually in some player or NPC inventory or in the market or something. This doesn't come up a huge amount, but when it does there is a GM message about it happening. However, there was no output to the player that it happened. It would just say you found the item and you would check your inventory and it wouldn't be there.

I've added a new OOC message when this situation occurs which explains, provides the object # for GMs to investigate and tells the player to xhelp.


If your hands are full and you get a gift wrap you were not getting the gift handed back to you. I've added a final check that waits two seconds, checks if the gift is still on the NPC and drops it on the ground instead of just keeping it on the NPC.


Not a fix, just an update. Skateboards are currently broken. Just like wheelchairs were broken. I had thought that they used the same code as wheelchairs, but nope, they are just copy pastes of the same code, so my fixes for wheelchairs didn't apply to them.

I need to speak with Johnny about how they are supposed to work. I'll do that soon and then fix them once I understand how they are intended to operate (it is slightly different than wheelchairs).


There was a bug where if you listened in on an elevator from outside, you'd hear the stuff inside regardless of floor. The opposite was also true, you could listen to the 'out' and hear that destination even if you changed floors. This wasn't being abused, but I noticed it while fixing another issue, and have made it so attenuated hearing does not work from within elevators or when listening in to elevators due to their constant floor changing.


If an NPC wants a drink and you deliver it to them, they will now drink that drink instead of putting it away and potentially spilling it all over themselves.

This also opens the possibility of NPCs that want drinks getting spiked drinks. Though the NPC will only consume 1 use of a drink and then the drink will be recycled (to prevent people causing NPCs to OD without GM intervention). So you could technically drug an NPC this way.


You can pry some things, like robots, open with a wrecking bar. If the robot is active it moves away and you get a message about this. The message has the iobj and dobj swapped, so the wrecking bar would move away instead of the robot. I've fixed the issue.


We've upgraded our Postgres DB to a newer version. This shouldn't have any impact on the game or the grid, but if anyone see's anything wonky please let me know. I tested the upgrade on our dev server with a dev instance of the db first, to confirm things worked but I could have missed stuff.


I've set the proper timezone in postgres, this means anything coming from or to the MOO will have the proper timestamp. Your @notes are a good example of this. You'll now see the correct time in DST for when you left a note. This applies on the admin side as well. It is NOT retroactive. It also means a few things, for today may appear out of order, if you left a note before this change and then after, your note from after will probably show up before and such. Don't sweat it.


Rejoice! The grid is now working in the proper timezone. On top of setting the database timezone there was some weird quirk with our date formatting library that was defaulting it to UTC. I've fixed that, by hacking in a change that just sets UTC to false so it defaults to local time on the server.

THIS IS A RETROACTIVE CHANGE. Because of the way we were storing dates previously, this change should be retroactive. All posts/gridmails/etc should be showing up with the date in DST that they were actually posted. Not like 8 hours in the future.


There was a bit of a race condition in the cook verb when cooking meat from a carcass. On the last usage, it would try to silently sheath the item and recycle it, but it's possible the item could have already been recycled (if the player trashed it?) or if some other weird stuff happened.

I've added additional checks to make sure it's still the 'same' object and that it is still on the player.


Apparently, cameras in the same room with a monitor no longer show you things that happen in the room. I've updated the tutorial to not have the camera/monitor and updated the tutorial script to not reference it. Since emotes are in the third person anyway it was somewhat redundant.


There was an issue with the supermarket where its exits property was set to non readable. I don't know why this was the case, or if it was intentional, I'm guessing it was not, but who knows. As a result NPCs trying to path through the area were generating tracebacks because the recursive pathing code couldn't access the exits prop, which we expect to be readable, and thus tracebacked. I've resolved this by setting the prop to readable. If other shit breaks as a result, @bug it.


There is a type of exit in game that is one directional. If you're on the non usable side, looking at it would show you literally nothing.

I've made it so you see a message about it being a one way exit, and not being on the usable side.


I've fixed the worn_msg on all existing wigs of this type and fixed the code that spawns them. The message read very weird, because of the pattern matching that was being used. Should be better now.


So there was a weird bug that happened because of a refactor Johnny did to stores in 2021. When you stock an item at a store, it moves that item to a store room, where it stays until it is purchased. It then adds the item to the stores registry of on sale items.

This was working 99% of the time, but sometimes the store room was not able to accept the item. I don't know why that was happening but I have added additional debugging to help track it down when it happens.

The bug was that there was no check if the store room accepted the item, so in cases where it did not, the item ended up on the floor of the shop. There was some weirdness with picking it up resulting in trying to buy it, but if you tried to purchase it from the shelves the purchase would go through but the item wouldn't be moved to you and you had no idea that one of the items on the floor could now be picked up and taken.

I've made it so when stocking items if it fails to move it to the store room, you'll get a message about it failing to stock, a GM message goes out, logging is saved, and the item will not be stocked / added to the on sale list.

This would only be affecting player run shops to my knowledge. The Dark Shop has been manually fixed. I think there is one thing. SSC has one item on the ground in a bad state. The owner of that shop needs to unstock and restock that item. If you encounter other shops with this issue of items on the floor please shoot us an xhelp so we are aware.


The taxi destinations were set up in a weird way that was not interfacing with the $destinations matrix in a sane way. I'm sure it was setup the way it was for future improvements, but given how the system organically developed, it didn't make sense to have to manually add destinations in two different places. I've made it interface directly so taxis and limos will have direct access to more places with fewer changes. This means taxis should know more destinations off the bat.

If there are places that are not included that you think should be, please put in a service request for CODER with the name of the place that you think should be included.


Some vehicles have a navigational system to help plot a course to a location. These have been updated to use $destinations directly instead of a prop that was never getting updated. This means if we add a destination, it'll be available to taxis/limos/nav systems right away instead of when someone remembers they need to update multiple places.


Taxis and limos were broken at various times.

One of the changes made was to make it so that you had to have hands free to drive. An understandable change but one that none the less broke the hell out of taxis because in checking if hands are free, it has to try to lock the action for a moment before releasing. This, coupled with the fact that taxi drivers try to 'lock back' was running into a situation where the action for hands free was locked as part of the driving check at the same time they tried to lock the back, meaning the doors were never locked and you could just exit the taxi without paying.

I've removed the hands free check on driving altogether as there was no easy fix for this issue and it was probably breaking other shit as well. I think this is fine. Drive with your knees like everyone else.

In another situation, if the destination was not 'reachable' because it was set as say, The Drome (and not the street outside the Drome) the taxi would drive there, and fail to drive INTO the drome, thus never completing the fare cycle because the :do_stop verb was not being called for unpassable terrain. I've resolved this by calling :do_stop properly when this arises.

So, in these cases, Taxi's will actually charge you for using them. This was broken for a year, and we only had a few reports of it, people probably not realizing there was a bug, or enjoying a free taxi fare. This fix should push people more towards PC taxi drivers at any rate.


When we display 'sitters' in a car's seats, we show people sleeping if they aren't connected. We didn't check if the person sitting was an NPC, thus all NPCs were shown as sleeping in vehicles. I've fixed this.


The code that was showing if people were sleeping handled the driver sleeping, but never removed the driver from the list of sleepers after showing them sleeping in the drivers seat. As a result a sleeping driver was shown twice. I've resolved the issue.


I had to make a few fixes to SQL Notes after updating to the most recent postgres because of the way timestamps without timezones were handled in the newer versions.


When the new e-note file system was first rolled out you could create files without file extensions. This was later corrected. However, these files that are created without a file extension cannot be read by the existing code. I've gone through all the files created and manually added extensions to ones missing them. This is something that should have been done when the issue was fixed, but it was not.


This should hopefully now not attach the @voice message to any explosions.


Plants were blooming with blossoms that were BlackFlat or YellowCanary, because those are the names of the colors. This was builders bolting 256 colors onto the plant system which was designed before we had 256 colors.

I've redesigned the system to support setting props on the flowers like this: {"BlackFlat", "black"} or {"YellowCanary", "sunshine yellow"} where the second item in the list is what is displayed to the player who looks at the plant.

This means builders can use all types of purdy colors with minimal difficulty.

I've reviewed the bloom messages on all 173 plants in game, to confirm they all appear as intended. If anyone notices any issues, please submit an @bug.


There are some types of clothing that if worn, will show a name or special emblem if the person is employed at the place they are wearing the clothing/armor for. There was a bug in this code that was making it so if the person had no employment info, it would traceback, because the result wasn't a list like it was expecting. I've fixed this, so it won't traceback in those situations.



The verb logging incoming calls was calling 'do_incoming' but the verb was actually named 'do_incomming' because I can't spell for shit. This has been renamed and will get called properly. Meaning incoming calls will be logged.


These will now use the IC name of the character no matter if the character is OOC or IC. Previously, it used :name which was returning the OOC name of the player if they were OOC.

This applies to:

- @add-guest

- @show-guests

- @remove-guest


These did not have an integration message previously, which meant that if you installed them unhidden, they would not show up in the room desc and not be found when searching. I've added one that reads:

A surveillance microphone shaped like a palm-sized small mesh dome hangs from the wall.

They will now function visually the same way that unhidden cameras do.


If two people are charging a barrier at the same time and the first person removes it, the second person will no longer get a traceback due to the barrier already being removed.


This room was freezing, but not preserving cyberware left in it. I've changed it to a proper parent so it will preserve stuff like corpses and cyber.


If you inspect a part, it caches the result so you can't spam it and get different results. But now, if you repair a part, you'll be able to inspect it fresh again and possibly get a different result since the value would have changed after the repair.


There is now a rate limit on how fast you can chute items to prevent someone chuting something multiple times super fast and getting multiple credits for the same item.


When looking at a TV, the list of broadcast TV channels will now appear ordered from lowest to highest.


I've done another full pass on all the @bugs we have. I've marked a number of them for review by Johnny (mostly aero / dynamic space stuff). I've flagged a bunch of others for investigation by staff to confirm they are still issues and get me more information on how to reproduce.

I've also started the process of scheduling a bug bash day for sometime in December. Waiting on responses from Staff for when they will be around.

I cleared out a bunch of bugs today, and resolved a bunch more that were duplicates of ones I've already fixed, or that were already submitted.

Currently, there are about 100 bugs that I've only glanced over a few times and that still need me to heavily review them.

Current Bugs in Backlog: 205


Cheese is good, but not if you don't put cheese in your sandwich recipe. Especially your ice cream sandwich. Anyone who used the grilled cheese sandwich recipe to make a sandwich from their kitchenette had sandwiches that tasted cheesy. This will be fixed for anyone buying grilled cheese for their kitchenettes in the future. However, I can't update every kitchenette that already has it, so if you are still having this problem put in a service request for me to fix your kitchenette.

For the future, there will be sandwich, and grilled cheese sandwich as an option to make on your kitchenettes to control the cheese. :P


These were displaying only certain vehicles (on purpose) but the 'touch name on billboard' was pulling from a list of all vehicles. I've modified this to only pull from the list of vehicles the billboard is configured for.

This resolves an issue where you could view details on vehicles not for sale at that location.


So, the way installing addons works is that you install a part, and it recycles the part and adds the generict to the vehicles addon_matrix. Mods, like 3d navigators and rigging hubs work the same way.

That's a problem when you have set a system up based on objects and then restricted the number of connections an object can have.

Let me give an example:

I install a single port rigging hub in my vehicle. That hub is recycled and the 'generic' (parent of the actual item) is stored in my vehicle mod matrix.

Then, someone connects to that hub using their rigging cyberware.

Great! It works.

Now someone else, in a different vehicle, connects to their hub.

It doesn't work. Because the object (the generic) already has a connection. Thus only one person in the entire game could be using a rigging interface to control a vehicle at the same time. Unless they had a double port hub, at which point, two people in the game could be doing it.

I've had to spend the afternoon bolting an entirely new mod installation system on top of the existing one. The new system should be basically the same from a player perspective. However, instead of recycling certain items when they are installed into vehicles, it will no longer do this, and instead keep them in the vehicle, integrated with the contents. All the commands work the same way, but behind the scenes a lot is different.

I had to modify 15+ verbs, and add a bunch of new ones to make the system work. I've tested in across multiple vehicles and NPCs (which was obviously not done the first time this system was rolled out) and it appears to be working.

This should resolve a number of bugs that were reported about not being able to connect to your rigging interface (because little did you know, someone else was rigging in a vehicle somewhere else in the game at the same time).

While going through this code I noticed a lack of error state handling, which is causing tracebacks and bugs for people who can't disconnect or get into a bad state somehow and have no resolution to it, and was the original thing I was looking into. I haven't resolved all those issues yet, as this took precedence.

Edit: Also, I have updated all vehicles that had a rigging hub to have an actual hub. This means you have an actual item in your vehicle. It's still installed/uninstalled the same way.
I'll keep looking into it as I have time.

(Edited by Slither at 2:45 pm on 11/28/2022)


These can now be closed after they are opened.


The messaging on the feed command has been updated to no longer capitalize things it should not.


There was an authorize verb on the generic vehicle that was being overwritten IN SOME CASES on motorcycles. To understand this you need to understand how the MOO parses verbs.

A verb that is set to 'any any any' will match anything passes to it.

A verb that is set to 'any on this' will match: authorize me on cricket

So, in some cases, the code for authorization was working but using the wrong verb, like if say you did... 'authorize me for cricket' it would actually call the generic vehicle's authorization.

This was actually a good thing, in that the motorcycle authorize verb was not as updated as the vehicle one. There wasn't actually a need to have a specific motorcycle auth verb at all. So I've removed it and update the generic vehicle one to send messages either into the vehicle (if you are using it inside) or outside the vehicle if you are using it outside.

This does NOT correct the issue of not being able to see who is authorized on a bike -- that system was designed such that you have to be inside the vehicle to 'look' at the security system and didn't consider the outside use case. I'll look into that next.

(Edited by Slither at 9:13 am on 11/29/2022)


You can no longer authorize a vehicle from outside it. This was working, but not giving any input because the messages were showing inside the vehicle. I've added an OOC response saying you need to do it inside the vehicle.


You now need to be wearing your mechanics toolbelt in order to use it to repair vehicle parts. This should prevent a situation where you consume scraps, but then get told later in the process that you aren't wearing the belt and thus the repair fails.


Stages set up in bars and such didn't have a default description, thus showing up as a tangible RPG thing. I've set a default description, which resolves any that didn't have a description, and future stages will also have the basics.


We are down to 187 reported bugs. I've resolved some additional duplicates (for unfixed issues as well as fixed issues).

We're getting close!


This command will now work when there are N vehicles with the same name in the room. So you can do things like 'estimate 4th honda'.


This was tbing on inspect because it was calling its parents :custom_inspection verb but that verb didn't exist. :custom_inspection is only defined on specific objects taht need to do custom inspections. I've removed the call to the parent and it won't TB now.


Unlike Jacuzzi's, which defined a special integration verb to show you people that were in them, you couldn't tell if a pool was occupied without going into it. I've moved the integration verb to the Generic Pool, and tested shallow and deep pools. They now function just like jacuzzi's and will show you who is in them integrated with the room description.


These were displaying really weird when you looked at available for purchase items. I've updated the max line length and the # of characters of the name that can be displayed so that the entire name is visible.


In general, I upped the line length on these too. It was pretty low at 50 characters. It's now 100 characters per line max.


These were spawning with 15 rounds but had a max rounds of 10. I've reduced it so they spawn with 10 rounds. I also checked all other ammo clips in the game to confirm no other generic ammo had this issue.


There is an edge case somewhere that makes it so you might stay connected to a vehicle even if you leave that vehicle. Could be related to unconventional ways of being removed from a vehicle, IE: crash, eject. I'm not sure.

If you run /system and you aren't in a vehicle, instead of showing you the system information for the vehicle, it will disconnect you from the vehicle.

I haven't fixed the edge case, as I haven't found it yet, but I'm looking into some additional cleanup/checks for if the people connected to a hub are actually in the room. That way, you won't get stuck unable to use a hub that someone eles is still hooked up to even if they aren't around.

(Edited by Slither at 3:03 pm on 11/29/2022)


Deleting a directory previously required confirmation, I've extended this to deleting files as well.


When you called 411, you'd see a hangup message that used %t without substituting it for the name of the phone. This is fixed.


Pets and such will no longer say actual words in response to some commands (like if you told them to stop following someone and they weren't following someone). This will make it harder to know why they aren't doing what you are told... but ya know, animals be tough to understand sometimes.


Previously we were not saving the SIC id of the character that posted a SIC ad. Moving forward the SIC id will be stored. That means if someone requests information ICly on who submitted a SIC ad (like a Judge) they will get the SIC ID back instead of the name of the character. This prevents situations where a SIC ad from a previous character is attributed to a new character, and situations where ICly people were getting the 'display name' of a character back.

This is a change that will take a few weeks to fully populate, it doesn't fix existing saved sic ads just new ones.

(Edited by Slither at 8:02 pm on 11/30/2022)


I fixed an issue with memento spawning where there could be a TB if the memento recycled/retired before the spawn code finished. I dunno why NPCs would retire so quickly, but it's technically possible, and it happened at least once.


This verb is admin only. Instead of telling you 'I don't understand that.' it will now tell you to put a service request in if you want to give someone access to work in a garage.


Cubes now have a 'rentcheck' verb which calls the same code that you get when you log in within a cube, telling you how long the cube is rented for.


Rooms can be full. Different rooms have different capacities. This has always been the case though it doesn't come up much There was no indication that this was the case. You would just try and fail to walk in with a generic you can't go that way. I've added a gm alert for when this happens and updated the message you see so that it says You can't go that way, the room may be full.

This should make it easier on players and staff when this comes up randomly in the future.

Whoops, it's december now. Moving this.

(Edited by Slither at 4:41 pm on 12/1/2022)