chattheatre / skotos Goto Github PK

This should nip a large part of the "case insensitive name collision" issue that showed up on the mac.

Stopping those names from being created in the first place will nip the situation in the bud.

Caveats:

Patching idd.c should NOT cause errors with any noncompliant data already loaded, only prevent new folders or object names from being created that would clash with ones that already exist.

There are probably some other caveats that I haven't thought of yet.

Rather than seeing a page with an error log, I get a "Page not found" message when Merry code fails to compile. It makes it difficult to track down where in the Merry script I messed up.

I have also noticed I no longer get an error output when Merry code crashes. It still gets logged in the +kpe tracker but it when code fails to work, it isn't immediately apparent why.

Prior to cold-boot SkotOS, the game's DGD server was nearly always fully booted. It just wasn't much of an issue. In this new world, we cold-boot much more often and so we care more often. That's why deploy_scripts/shared/wait_for_full_boot.sh exists - so we can wait for SkotOS to finish loading all that MERRY code, open its ports, etc.

It would be really useful if wafer and thin-auth could indicate whether SkotOS appears to have booted fully. Because if you click through before that, errors are expected. When spinning up a new local install, we just don't boot wafer until DGD has finished booting -- but a bookmark will still get you to the not-yet-ready server. Some kind of visual indicator (warning text?) would be nice, and possibly a "reload" button to check right now instead of waiting for the next 30 second timer.

There's a URL for that, the same one used by wait_for_full_boot.sh. On the SkotOS raw HTTP port (localhost:10080 or the client URL's port 10080), the url "/FullyBooted" will only return 200 if it's fully booted. A 404 normally means "still booting" and a 5XX (error) response normally means "something went wrong and it's not going to boot up." It's possible to get an error where it will just 404 forever, but that's not normally what happens.

For wafer, the right answer is probably to colour or disable the "Play" and "Tree of WOE" buttons and add a setInterval to keep pinging the server (maybe every 30 seconds or so?) and enable them when the server is fully booted. After the server is up we can get rid of the setInterval and not keep doing it.

It would also be possible to check every you hit "Play" and give you a dialogue if it's not fully booted - not sure if that's a good idea. The up-side is that if you keep a stale Wafer browser tab open it will still tell you if your current boot isn't finished. The down-side is that sometimes you get a browser alert when you may not want one.

Turns out an ancient tape-drive archiving program (called AMANDA) uses port 10080, so Chrome thinks connecting to it as a websocket is dodgy. D'oh! We'll need to change our local config on SkotOS, but also Wafer (and maybe gables_game/vRWOT?) to not expect Chrome to connect to port 10080.

As we move toward support for a broader range of gender identities, we need a more generalized Chatter Ur.

• Remove UrMale and UrFemale bodies
• Put gender-specific body parts in UrMainbody and make them visible when gender is selected
• Make facialhair visible when the facialhair property is set either through @traits/+traits/or some other system that alters appearance (merry:setprop function in UrMainbody)
• Update mainbody description to remove base:gender reference ("Sarah is a person" rather than "Sarah is a female").
• Figure out a solution for start clothing. Up to this point, it has been gender based. Add clothing options to start story?

Right now, it's hard to combine Jitsi (video/audio chat) with a local server. It should be pretty straightforward for the SkotOS server to send the Jitsi URL in a message... but for a fully-local setup, you still need a Jitsi server of some description, and they're painful to set up locally.

Anyway, should be possible to work this out. We need a slightly unusual setup (JWT, token_moderation plugin) so the public meet.jit.si server won't work. But it should be possible to change a config file (or something) to set the Jitsi URL, and right now it's not.

When taking an item, it returns a blank line rather than outputting the action. This has been tested locally and in vRWOT.

Some filenames are indistinguishable without distinguishing between uppercase and lowercase (e.g. s7 vs S7 in the vault data.) Git does a weird mapping here, and I think there may have been problems before that too. Basically, some of the filename case seems borked.

This is causing problems with WOE objects in some cases because WOE tracks WOEnames directly from filenames. So Data/DB/Spawn.xml became Data/DB/spawn.xml and couldn't be found. I suspect the hunting birds (e.g. the saker-terciel) problem came from the same thing with the S7 WOE subtree in the vault.

At some point I need to clone the repo on Linux, get the list of files that Mac Git complains about, and sort out all the case in the filenames.

One difficult workflow for Jitsi: what if we have an expired JWT token on the browser side, and we wind up needing to reconnect? We need to test the "JWT token expires, browser needs to request a new one, then we successfully reconnect" workflow.

Attempting to run this script from the command line gives me an error:

You must set a GAME_ROOT to run this setup script.

This script gets called from the start_server.sh script but would be nice to have the option to call it manually if needed.

When there's any evokes in a language other than common, they trigger an action of language/encounter with some special parameters that get garbled later by merry.

I don't remember whree it is, but I found the reference in an odd place.

When doing a local cold boot of SkotOS, Tool:Lib:Popup is missing which causes other issues in Tree of Woe. Trying to load any file results in:

cannot resolve ${Tool:Lib:Popup}

Tool:Lib:Popup does appear in /skoot/data/vault. I have also tried cold booting my Lovecraft Country vault dump and Tool:Lib:Popup is still missing. The dgd log shows this error during the boot process:

May 1 19:22:30 ** Could not load Tool:Lib:Popup, not found

Right now, to keep the web config simple, I have DGD serving its own HTML web client, its own JS and CSS files, etc. This isn't particularly efficient -- especially because DGD will contact AuthD for every file. It could be fixed with a better NGinX configuration that checked (on a port other than 10080) for static files, served them if present, and fell back to DGD on port 10080 as a back end.

This would also solve the logout problem we currently have with cookies -- by keeping everything on a single port handled by NGinX for static files and DGD for dynamic files, we can keep the cookies unified. Right now that's not happening.

Christopher Allen said:

Eventually you should format any non-internal DGD docs as .md

Some state was missing in the old SID that didn't get dumped, which would make it harder to both preserve enough information for a cold boot as well as hampering runtime manipulation through the WOE interface.

Example: Whether doors are closed in addition to being locked.

When executing the command, everything works fine but I get this message:

• open -a Apple_Terminal -n deploy_scripts/mac_setup/show_dgd_logs.sh
• dgd/bin/dgd ./skotos.dgd skotos.database
  Unable to find application named 'Apple_Terminal'

I assume this is just because I don't have an application named "Apple_terminal" and may not be an issue but I thought it worth mentioning.

When using Gables, RWOT, etc., it's nice to be able to specify an alternate SkotOS branch from the StackScript. It allows reasonable debugging of patches to core SkotOS by running them with a game.

However, right now that branch in the StackScript is not reflected in the final manifest file. So debugging of StackScript variations works from the StackScript, but it's not clear how to debug actual core SkotOS changes from the game.

One possibility: have the StackScript patch the manifest in the cloned game to point at the alternative SkotOS branch.

I'm looking through a dump from the prod Gables server and the WOE directory from ChatTheatre/SkotOS and bringing the latter up-to-date where appropriate. Some notes, some of which are future work:

• The prod Gables server actually has some very old objects in it for no obvious reason - it's missing some surprisingly old changes. Based on revisions it doesn't seem to be that changes happened and were reverted. CTSkotOS just has newer/better versions of a lot of fundamental objects like UrHuman.
• The NIP systems are different. I think prod Gables has the better/newer NIP system, but that's going to be involved to update it properly. The NIP WOE namespace has some updates, but I don't think that's a big part of the update.
• Prod Gables uses S7-Generic versions of all the clothing while CTSkotOS uses the Shared versions. I think that's fine. I'm not going to update all the clothing because I think clothing and UrBodies are both places where these will be split out into various libraries sooner rather than later.
• Prod Gables has some oddities where there's a DevilsCay directory, and objects there are used by Staff objects, which in turn are inherited by other objects in the world... While, for whatever reason, CTSkotOS doesn't seem to have that setup, or anything under a DevilsCay namespace. Not sure if that's the different source WOE dumps that they started from... I don't think Shentino just untangled it all.
• There's also a Regent directory in Prod Gables that looks like a partial dump from another game.
• While CTSkotOS has no DevilsCay directory, it has a Mortalis directory with no equivalent in prod Gables. So: looks like they're of different heritage, not just different age.
• Prod Gables has an HQ directory with directories named SyncApproved and SyncDeclined. I can't tell if those are automated (sync failed) or, more likely, they're full of objects that were approved or declined to be moved over to the Gables. Both subdirectories are further subdivided by source SkotOS game (lcabn, marrach, mortalis, ironclaw, etc.)
• There's also a PROPOSAL directory in prod Gables with some socials (verbs, adverbs) and accessories.
• It turns out that the various MOVED directories is done by some kind of automatic SID archiving. See parse_archives in skoot/usr/SID/lib/vaultnode.c for details. There's only been one moved item since 2011, though (a simple belt,) so it could be worse. I can't tell what calls parse_archives, thus generating MOVED items. A lot of prod-Gables items have MOVED parents, though, when equivalent CTSkotOS items do not.
• The TextIF WOE directories have different colour themes between the two. I don't feel like that particularly needs to be moved over, though it wouldn't be hard to do.
• Prod gables has basically a copy of a lot of Mansion rooms and things under the name LinkZone. I assume somebody was copying it to make changes and just kinda left it to sit around? I don't see anything else using it. I'm not merging it.

I'll keep editing this as I go along.

Running the Gables mac setup seems to happen successfully. However, manually running the show_dgd_logs.sh script shows an error and it's hard to know if dgd actually booted successfully.

$ ./show_dgd_logs.sh
tail: /log/dgd_server.out: No such file or directory
tail: /log/wafer_log.txt: No such file or directory

Wafer does not load and cannot be loaded manually.

$ wafer
Got exception in thread! Dying! Connection refused - connect(2) for "127.0.0.1" port 10070

When attempting to load dgd manually, the output reveals that several ports failed to open. Rebooting my computer does not help.

May 3 22:00:44 ** info:DEV_USERD: accepting connections on telnet devport 10098
May 3 22:00:44 ** critical:Panic: failed to open binary devport 10099
May 3 22:00:44 ** critical:Panic: failed to open Broadcast TCP port 10017
May 3 22:00:44 ** critical:Panic: failed to open AUTHD TCP port 10070
May 3 22:00:44 ** critical:Panic: failed to open CTLD TCP port 10071
May 3 22:00:44 ** critical:Panic: failed to open HTTP port: 10080
May 3 22:00:44 ** critical:Panic: failed to open HTTP port: 10089
May 3 22:00:44 ** critical:Panic: failed to open Woe port 10090
May 3 22:00:44 ** info:WOED: opened port 10090 successfully.
May 3 22:00:44 ** info:TextIF: accepting connections on game port 10443

Not sure if this is an issue on my end but I did not have the same port trouble when loading dgd from the SkotOS repo.

In the rush to get to cold boot, some useful but non essential code was culled.

This includes but is not limited to the CSD module

We should consider how to handle pages and whatnot that are sent/received with bodies involved in a possess chain.

This caused some...difficulties in ironclaw

Something possibly on port X090..the ability to upload and download files with the server as a developer?

I found a java class file to handle this as an applet but no java source was found.

There is a new version of the Orchil client which has fixes to one important bug, and some minor features.

@shentino can you talk with the leads about scheduling this update?

Hello all!

Hoping to get some assistance with an issue I'm running into trying to use the +emitter command. From everything that I can see, it's written exactly the same way in two other games where it functions correctly. Although, that may be part of the issue. Below is the full error string I'm getting upon use:

+emitter
Value is not a string
     /kernel/obj/binary#7064        'ondite'
  90     /kernel/obj/binary             receive_message
 203     /kernel/lib/connection         receive_message
     /usr/TextIF/obj/user#7063      'ondite'
 443     /usr/TextIF/obj/user           receive_message
 825     -                              receive_line
 762     /kernel/lib/auto               call_limited
 920     /usr/TextIF/obj/user           parse_command
     /usr/TextIF/main
 355     -                              command
     /usr/TextIF/cmd/social
 810     -                              cmd_DEV_raw_social
 100     /usr/SkotOS/lib/merryapi       run_merry
     /usr/SkotOS/data/merry#-1
 319     /usr/SkotOS/data/merry         evaluate
     /usr/SkotOS/merry/03f75e0ad4c5edf1a518772c412b2e43 M<Neoct:Staff:Tools:+emitter/global:command>
  69     /usr/SkotOS/lib/merrynode      evaluate
  18     /usr/SkotOS/merry/03f75e0ad4c5edf1a518772c412b2e43 merry
 489     /usr/SkotOS/lib/merrynode      LabelCall
 475     -                              Call
 100     /usr/SkotOS/lib/merryapi       run_merry
     /usr/SkotOS/data/merry#-1
 319     /usr/SkotOS/data/merry         evaluate
     /usr/SkotOS/merry/f7cb14cb8860ad86ca4bfe85867c12a9 M<Lib:chatlib/lib:log>
  69     /usr/SkotOS/lib/merrynode      evaluate
   9     /usr/SkotOS/merry/f7cb14cb8860ad86ca4bfe85867c12a9 merry
 475     /usr/SkotOS/lib/merrynode      Call
 100     /usr/SkotOS/lib/merryapi       run_merry
     /usr/SkotOS/data/merry#-1
 319     /usr/SkotOS/data/merry         evaluate
     /usr/SkotOS/merry/4ea5e5a07a4a245439229467b2822b1f M<Lib:chatlib/lib:chat>
  69     /usr/SkotOS/lib/merrynode      evaluate
 206     /usr/SkotOS/merry/4ea5e5a07a4a245439229467b2822b1f merry
 475     /usr/SkotOS/lib/merrynode      Call
 100     /usr/SkotOS/lib/merryapi       run_merry
     /usr/SkotOS/data/merry#-1
 319     /usr/SkotOS/data/merry         evaluate
     /usr/SkotOS/merry/04f2f91c47f68e997bee66cae1eba7e4 M<Lib:filter:lfc/lib:input>
  69     /usr/SkotOS/lib/merrynode      evaluate
 171     /usr/SkotOS/merry/04f2f91c47f68e997bee66cae1eba7e4 merry
> 

Any help would be greatly appreciated!

self explanatory but I noticed that they were left out of the document.

May 4 17:15:55 ** error:String too long [caught]
error: /usr/System/sys/tool/vault
error: 732 - work
error: 202 - spawn_object_from_state
error:1115 /kernel/lib/auto read_file
May 4 17:15:55 ** Error spawning Bodies:UrMainbody
May 4 17:15:56 ** error:String too long [caught]
error: /usr/System/sys/tool/vault
error: 732 - work
error: 202 - spawn_object_from_state
error:1115 /kernel/lib/auto read_file
May 4 17:15:56 ** Error spawning Data:DB:mhelp
May 4 17:15:56 ** error:String too long [caught]
error: /usr/System/sys/tool/vault
error: 732 - work
error: 202 - spawn_object_from_state
error:1115 /kernel/lib/auto read_file

I'm almost certain this is due to failure to use a sufficiently large maximum string size in the DGD binary.

Suggested solution is a subroutine invoked by INITD->create() that will abort the startup process if certain configuration or status() values fail a sanity check.

I suggest checking max array size and max string size for starters.

I can come up with a patch for this myself if needed but atm the priority is to report the issue. I have higher priorities to deal with irl atm so for now a report will have to suffice until I can get more free time unless someone else wants to take care of this first.

Hey noah I noticed you're gutting a lot of things.

Could you please preserve the ability for multiple instances of skotoslib to communicate on a shared backbone? For things like cross-game chatlines, centralized user accounts, and cross game assists?

I rather liked how Skotos was able to host multiple games with a shared backend and I'd like to preserve the ability to duplicate this functionality going forward.

Fresh clone 1391657 of SkotOS in my local ChatTheatre dev directory, based on today's #22.

Did a cd SkotOS then ./dev_scripts/mac_setup.sh

Got this error:

./dev_scripts/mac_setup.sh: line 115: /usr/local/etc/nginx/servers/skotos_dev_nginx.conf: No such file or directory

I would like to lobby for the preservation of storynuggets as a character generation interface, I think it was used on marrach if I'm not mistaken unless I misread something, and if they still work I don't think they should be removed.

Though by contrast I agree bilbo needs to go.

Tree of Woe fails to load when objects are saved to the root directory. Special characters can also be a problem. We should figure out some solution to either disallow special characters/saves to root or update Tree of Woe to handle it better.

When cloning SkotOS_vault on a Mac, I get path collisions, mostly due to case-insensitive file system on the Mac.

We want everything to work on a Mac for root SkotoOS and SkotOS-Vault.

This might be a good project for @saraht45 — start with SkotOS on a linux install, fix the easiest (which is to just move all of Regents including these collisions to it own repo for a future plugin), and delete them from root SkotOS and submit PR with deletions. Then look at SkotOS Vault and other vaults (gables, etc.) for similar easy to export to a plugin sets. Test by cloning to Mac.

Then work on the remainder of the collisions by group. For instance, why are there verbs in Neoct & neoct, etc.

A side project for @noahgibbs is to make a deeper level fix so that it isn't possible to name objects that might collide.

warning: the following paths have collided (e.g. case-sensitive paths
on a case-insensitive filesystem) and only one from the same
colliding group is in the working tree:

  'Data/DB/Spawn.xml'
  'Data/DB/spawn.xml'
  'Data/Initial/DB/Spawn.xml'
  'Data/Initial/DB/spawn.xml'
  'Data/Misc/Shared/DB.xml'
  'Data/misc/Shared/DB.xml'
  'Jonkichi/Data/aliases.xml'
  'Jonkichi/data/aliases.xml'
  'Jonkichi/Neoct/ic/verb/%40alias.xml'
  'Jonkichi/neoct/ic/verb/%40alias.xml'
  'Jonkichi/Neoct/ooc/verb/%40chargen.xml'
  'Jonkichi/neoct/ooc/verb/%40chargen.xml'
  'Jonkichi/Neoct/ooc/verb/%40finger.xml'
  'Jonkichi/neoct/ooc/verb/%40finger.xml'
  'Jonkichi/Neoct/ooc/verb/%40goto.xml'
  'Jonkichi/neoct/ooc/verb/%40goto.xml'
  'Jonkichi/Neoct/ooc/verb/%40status.xml'
  'Jonkichi/neoct/ooc/verb/%40status.xml'
  'Jonkichi/Neoct/staff/verb/%2Baccadm.xml'
  'Jonkichi/neoct/staff/verb/%2Baccadm.xml'
  'Jonkichi/Neoct/staff/verb/%2Baccfinger.xml'
  'Jonkichi/neoct/staff/verb/%2Baccfinger.xml'
  'Jonkichi/Neoct/staff/verb/%2Bfinger.xml'
  'Jonkichi/neoct/staff/verb/%2Bfinger.xml'
  'Jonkichi/Neoct/verb/%2Brename.xml'
  'Jonkichi/neoct/verb/%2Brename.xml'
  'Shared/Unsorted/S7/HN/bandana.xml'
  'Shared/Unsorted/s7/HN/bandana.xml'
  'Shared/Unsorted/S7/HN/belt.xml'
  'Shared/Unsorted/s7/HN/belt.xml'
  'Shared/Unsorted/S7/HN/boot-cowboy.xml'
  'Shared/Unsorted/s7/HN/boot-cowboy.xml'
  'Shared/Unsorted/S7/HN/chemise.xml'
  'Shared/Unsorted/s7/HN/chemise.xml'
  'Shared/Unsorted/S7/HN/corset.xml'
  'Shared/Unsorted/s7/HN/corset.xml'
  'Shared/Unsorted/S7/HN/drawers-gents.xml'
  'Shared/Unsorted/s7/HN/drawers-gents.xml'
  'Shared/Unsorted/S7/HN/drawers-ladies.xml'
  'Shared/Unsorted/s7/HN/drawers-ladies.xml'
  'Shared/Unsorted/S7/HN/duster.xml'
  'Shared/Unsorted/s7/HN/duster.xml'
  'Shared/Unsorted/S7/HN/garter.xml'
  'Shared/Unsorted/s7/HN/garter.xml'
  'Shared/Unsorted/S7/HN/hat-stetson.xml'
  'Shared/Unsorted/s7/HN/hat-stetson.xml'
  'Shared/Unsorted/S7/HN/petticoat-ruffled.xml'
  'Shared/Unsorted/s7/HN/petticoat-ruffled.xml'
  'Shared/Unsorted/S7/HN/petticoat.xml'
  'Shared/Unsorted/s7/HN/petticoat.xml'
  'Shared/Unsorted/S7/HN/shirt-mens-longsleeved.xml'
  'Shared/Unsorted/s7/HN/shirt-mens-longsleeved.xml'
  'Shared/Unsorted/S7/HN/stockings.xml'
  'Shared/Unsorted/s7/HN/stockings.xml'
  'Shared/Unsorted/S7/HN/suspenders.xml'
  'Shared/Unsorted/s7/HN/suspenders.xml'
  'Shared/Unsorted/S7/HN/trousers-denim.xml'
  'Shared/Unsorted/s7/HN/trousers-denim.xml'
  'Shared/Unsorted/S7/HN/trousers-woolen.xml'
  'Shared/Unsorted/s7/HN/trousers-woolen.xml'
  'Shared/Unsorted/S7/HN/vest.xml'
  'Shared/Unsorted/s7/HN/vest.xml'
  'Shared/Unsorted/S7/Regents/apron-long.xml'
  'Shared/Unsorted/s7/Regents/apron-long.xml'
  'Shared/Unsorted/S7/Regents/apron-short.xml'
  'Shared/Unsorted/s7/Regents/apron-short.xml'
  'Shared/Unsorted/S7/Regents/bandana.xml'
  'Shared/Unsorted/s7/Regents/bandana.xml'
  'Shared/Unsorted/S7/Regents/belt.xml'
  'Shared/Unsorted/s7/Regents/belt.xml'
  'Shared/Unsorted/S7/Regents/blouse-longsleeved.xml'
  'Shared/Unsorted/s7/Regents/blouse-longsleeved.xml'
  'Shared/Unsorted/S7/Regents/blouse-shortsleeved.xml'
  'Shared/Unsorted/s7/Regents/blouse-shortsleeved.xml'
  'Shared/Unsorted/S7/Regents/blouse-sleeveless.xml'
  'Shared/Unsorted/s7/Regents/blouse-sleeveless.xml'
  'Shared/Unsorted/S7/Regents/boot-cowboy.xml'
  'Shared/Unsorted/s7/Regents/boot-cowboy.xml'
  'Shared/Unsorted/S7/Regents/boots-ankle.xml'
  'Shared/Unsorted/s7/Regents/boots-ankle.xml'
  'Shared/Unsorted/S7/Regents/boots-knee.xml'
  'Shared/Unsorted/s7/Regents/boots-knee.xml'
  'Shared/Unsorted/S7/Regents/boots-riding.xml'
  'Shared/Unsorted/s7/Regents/boots-riding.xml'
  'Shared/Unsorted/S7/Regents/breeches.xml'
  'Shared/Unsorted/s7/Regents/breeches.xml'
  'Shared/Unsorted/S7/Regents/busk.xml'
  'Shared/Unsorted/s7/Regents/busk.xml'
  'Shared/Unsorted/S7/Regents/cape.xml'
  'Shared/Unsorted/s7/Regents/cape.xml'
  'Shared/Unsorted/S7/Regents/chemise.xml'
  'Shared/Unsorted/s7/Regents/chemise.xml'
  'Shared/Unsorted/S7/Regents/chemisette.xml'
  'Shared/Unsorted/s7/Regents/chemisette.xml'
  'Shared/Unsorted/S7/Regents/coat-double-breasted.xml'
  'Shared/Unsorted/s7/Regents/coat-double-breasted.xml'
  'Shared/Unsorted/S7/Regents/corset.xml'
  'Shared/Unsorted/s7/Regents/corset.xml'
  'Shared/Unsorted/S7/Regents/cravat.xml'
  'Shared/Unsorted/s7/Regents/cravat.xml'
  'Shared/Unsorted/S7/Regents/day-dress-shortsleeved.xml'
  'Shared/Unsorted/s7/Regents/day-dress-shortsleeved.xml'
  'Shared/Unsorted/S7/Regents/day-dress-sleeveless.xml'
  'Shared/Unsorted/s7/Regents/day-dress-sleeveless.xml'
  'Shared/Unsorted/S7/Regents/day-gown-shortsleeved.xml'
  'Shared/Unsorted/s7/Regents/day-gown-shortsleeved.xml'
  'Shared/Unsorted/S7/Regents/day-gown-sleeveless.xml'
  'Shared/Unsorted/s7/Regents/day-gown-sleeveless.xml'
  'Shared/Unsorted/S7/Regents/drawers-long.xml'
  'Shared/Unsorted/s7/Regents/drawers-long.xml'
  'Shared/Unsorted/S7/Regents/dress-mourning.xml'
  'Shared/Unsorted/s7/Regents/dress-mourning.xml'
  'Shared/Unsorted/S7/Regents/evening-dress-shortsleeved.xml'
  'Shared/Unsorted/s7/Regents/evening-dress-shortsleeved.xml'
  'Shared/Unsorted/S7/Regents/evening-dress-sleeveless.xml'
  'Shared/Unsorted/s7/Regents/evening-dress-sleeveless.xml'
  'Shared/Unsorted/S7/Regents/evening-gown-shortsleeved.xml'
  'Shared/Unsorted/s7/Regents/evening-gown-shortsleeved.xml'
  'Shared/Unsorted/S7/Regents/evening-gown-sleeveless.xml'
  'Shared/Unsorted/s7/Regents/evening-gown-sleeveless.xml'
  'Shared/Unsorted/S7/Regents/garter-pair.xml'
  'Shared/Unsorted/s7/Regents/garter-pair.xml'
  'Shared/Unsorted/S7/Regents/gloves-long.xml'
  'Shared/Unsorted/s7/Regents/gloves-long.xml'
  'Shared/Unsorted/S7/Regents/gloves.xml'
  'Shared/Unsorted/s7/Regents/gloves.xml'
  'Shared/Unsorted/S7/Regents/gown-night.xml'
  'Shared/Unsorted/s7/Regents/gown-night.xml'
  'Shared/Unsorted/S7/Regents/hat-bonnet.xml'
  'Shared/Unsorted/s7/Regents/hat-bonnet.xml'
  'Shared/Unsorted/S7/Regents/hat-top.xml'
  'Shared/Unsorted/s7/Regents/hat-top.xml'
  'Shared/Unsorted/S7/Regents/jacket-spencer.xml'
  'Shared/Unsorted/s7/Regents/jacket-spencer.xml'
  'Shared/Unsorted/S7/Regents/jodhpurs.xml'
  'Shared/Unsorted/s7/Regents/jodhpurs.xml'
  'Shared/Unsorted/S7/Regents/muff.xml'
  'Shared/Unsorted/s7/Regents/muff.xml'
  'Shared/Unsorted/S7/Regents/nightshirt.xml'
  'Shared/Unsorted/s7/Regents/nightshirt.xml'
  'Shared/Unsorted/S7/Regents/pantaloons.xml'
  'Shared/Unsorted/s7/Regents/pantaloons.xml'
  'Shared/Unsorted/S7/Regents/pelisse.xml'
  'Shared/Unsorted/s7/Regents/pelisse.xml'
  'Shared/Unsorted/S7/Regents/petticoat.xml'
  'Shared/Unsorted/s7/Regents/petticoat.xml'
  'Shared/Unsorted/S7/Regents/purse.xml'
  'Shared/Unsorted/s7/Regents/purse.xml'
  'Shared/Unsorted/S7/Regents/robe-dressing.xml'
  'Shared/Unsorted/s7/Regents/robe-dressing.xml'
  'Shared/Unsorted/S7/Regents/robe.xml'
  'Shared/Unsorted/s7/Regents/robe.xml'
  'Shared/Unsorted/S7/Regents/sash-waist.xml'
  'Shared/Unsorted/s7/Regents/sash-waist.xml'
  'Shared/Unsorted/S7/Regents/shawl.xml'
  'Shared/Unsorted/s7/Regents/shawl.xml'
  'Shared/Unsorted/S7/Regents/shirt-dress.xml'
  'Shared/Unsorted/s7/Regents/shirt-dress.xml'
  'Shared/Unsorted/S7/Regents/shirt-longsleeved.xml'
  'Shared/Unsorted/s7/Regents/shirt-longsleeved.xml'
  'Shared/Unsorted/S7/Regents/shoes-buckled.xml'
  'Shared/Unsorted/s7/Regents/shoes-buckled.xml'
  'Shared/Unsorted/S7/Regents/shoes.xml'
  'Shared/Unsorted/s7/Regents/shoes.xml'
  'Shared/Unsorted/S7/Regents/slippers-carpet.xml'
  'Shared/Unsorted/s7/Regents/slippers-carpet.xml'
  'Shared/Unsorted/S7/Regents/stockings-men.xml'
  'Shared/Unsorted/s7/Regents/stockings-men.xml'
  'Shared/Unsorted/S7/Regents/stockings-women.xml'
  'Shared/Unsorted/s7/Regents/stockings-women.xml'
  'Shared/Unsorted/S7/Regents/trousers.xml'
  'Shared/Unsorted/s7/Regents/trousers.xml'
  'Shared/Unsorted/S7/Regents/waistcoat.xml'
  'Shared/Unsorted/s7/Regents/waistcoat.xml'

The latest commit to Maintenance.md specifies 8000 in some places, I suspect this might need to be converted to X000

If you edit out all the old users in WOE:System:Developers using the XML edit mode, none of the changes get committed. You have to delete them by hand from the [V] interface.

Right now, a bunch of folders are still marked as slaved to Castle Marrach. However, they can't see that server and they shouldn't ever be allowed to. So that warning is pretty silly for our end-users.

We should remove sync from all folders so that people don't see the warning that their local changes will go away.

CC: @saraht45