# The Gables Reverse-Engineering

## Non-Skotos Users

Getting things working for a user outside of Skotos has a number of interesting points.

For instance: the current Skotos codebase runs using a significantly modified older DGD. I can see significant signs of Raymond trying to apply the diffs to more recent DGD, but that's necessarily a big job. DGD has some APIs that have changed a lot, and it's especially hard to be sure that various functionality isn't breaking and being 'left behind'.

While I don't see any *capabilities* of this patched DGD that couldn't be replicated with current DGD, actually making the move is going to be annoying and some work.

I can get the GitHub SkotOS code to cold-boot with current DGD, but it won't bring a statedump with it, so there is basically guaranteed to be loss of data.

## Non-Gables Port Numbers

In addition to port 6000, which is The Gables, I find instances for ports 3000, 4000 and 9000 on the same host. They have noticeable differences and are older game code and game databases.

Only the instance for 6000 shows database backups. Chris confirms it's the real instance, with others being instances that are not currently in use on the Gables VM.

There is significantly different SkotOS code, game databases, instance.data files and so on.

Diffing the "skoot" directory in multiple of them, there are wide-ranging and subtle differences, but it's not immediately clear to me *what* those differences are supposed to accomplish. For instance, source files have been slightly edited in some cases... E.g. skoot/base/lib/act/consent.c has gained a newline in the port 9000 instance versus the port 3000 instance. In general, there are minor source edits between basically each pair of instances.

## SkotOS Repo

The SkotOS repo is a "sanitised base" (personal information, etc removed) by Shentino, and many other cleanup commits of various sorts on top of it.

A quick line-count (find . -name "\*.c" | xargs wc -l) suggests there are about 110,000 lines of DGD. That's sizeable, but not intractable.

## kernellib

A quick diff between latest Kernellib and SkotOS kernellib looks like there is substantial drift over time, but not significant new functionality in the SkotOS kernellib. It should be possible to upgrade the kernellib, with some updates to the places that call it directly. Networking has also changed over that time, and is probably the largest difference in the API that will need fixing.

There's little or no old SkotOS functionality that *should* be moved forward here. It's just a matter of using the new APIs.

That's good. The kernellib is the most problematic place to add new functionality. It looks like old Skotos was pretty clean about adding new code *outside* the highly-privileged core.

## Cold Boot

One difficulty with converting an old, statedumped system to be able to cold boot is that often the necessary dependencies don't exist anywhere in the codebase. Compiling a particular object might have been done manually, and it certainly might not be listed in ~System, since it will have never gone through a cold boot.

Part of Shentino's solution was to go through and compile approximately all objects. That's not a bad first step, but it's necessarily limited - objects with errors, for instance, or that interfere in ways we don't want, shouldn't necessarily be compiled.

Now that I have cold boot working, another big problem is vault objects: they have dependencies, but don't seem to load in dependency-aware order currently.

In the medium- to long-term, the right answer is probably to explicitly add dependencies but also run a CI server (Travis, CircleCI or similar) that does a cold boot. Then errors will surface when we use objects that don't have a declared dependency.

## Testing

Right now there's very little provision for testing. I'm not sure what this should look like, but it should exist and it doesn't.

A certain amount of integration testing (e.g. bring up a web server and hit it with scripted HTTP requests) is important, but it's a high-overhead testing method. Unit tests are important, and by far the easiest to keep up to date.

And right now they don't exist.

## Moving Toward eOS

eOS is a very simple repo. It uses DGD and Kernellib to cold boot. But it currently has no real Skotos content.

One possible intention is that we could "build up" eOS until it worked as a cold-bootable SkotOS game. This might be the easiest way to get a clean version of The Gables, though likely with less functionality than Skotos games at their height.

One difficulty here is that we would like to be able to depend on DGD, Kernellib and Skotos game-independent content while providing additional game-specific content. The current Skotos directory layout above isn't easy to fit as a dependency, and DGD doesn't have an existing library/dependency system.

Note: Chris says that building up eOS is simply more work than we want to bite off any time soon. That's fair.

## Cycle 2020-E Milestone

### 1st week **Sept 7th - Sept 11th**:

- Investigate the current SkotOS implementation of SkotOS as represented by the live warm-booted The Gables on ChatTheatre.com, vs the semi-functional SkotOS repository above.
- Secondary priority if time available, puzzle ideal layout for eOS to work with better with git to seperate dgd, kernel, gamelib, user-generated content.

### 2nd week **Sept 14th - Sept 18th**:

- Report on feasibility of making the SkotOS repository cold bootable such that we can either sync contents of The Gables to it, or be able to cold boot The Gable.
- Secondary priority is if we can move The Gables to the current DGD.
- Third priority is to deploy / document any initial eOS layout suggestions.

### 3rd week **Sept 21st - Sept 25th**:

- Investigate the Orchil Client architecture, with particular goals of being able to support it long-term to fix bugs and add features.
- If possible, do. a few of these:
- BUG: Local Echo problem
- BUG: Ability to use on iPhone Safari without zoom and other obstacles.
- BUG: allow client configure commands to conform with different local commands in different games, in particular the @commandname is the standard for SkotOS OOC commands, but orchil's config command is `clientpref`.
- FEATURE: Marrach's problems with theme setting and default light scheme (Kargh on Marrach has proposal)
- FEATURE: Ability to add additional interface elements / controls in side bars (Allegory of Empires has some), in particular with an eye to future Jitsi UX (should we use Jitsi in a window or tase elsewhere, or try to have Jitsi be a frame inside of Orchil).

### 4th week **Sept 28th - Oct 2nd**:

- Given understanding of ChatTheatre, SkotOS, Orchil, and eOS, investigate feasilibilty and approach to potential integrate with a Jistsi server for audio, with game objects and commands being able to set various Jitsi settings such as voice channel, mute, force mute, etc. Or an alternative MVP where Orchil client does this instead (which means admins can't force mute people in the text enviroment, they must go to Jitsi interface to do so )

### 5th week **Oct 5th - Oct 9th**:

- Continue Jitsi investigation and make some MVP proposals of implementation via SkotOS/ChatTheatre or whether we have to do this integration with eOS.

### 6th week **Oct 12th - Oct 16th**:

- Focus on small wins — given prior 5 weeks, what will have biggest impact with the smallest amount of effort.

### 7th week **Oct 19th - Oct 23rd**:

- Deal with any loose ends, button down the hood. Finalize documentation of results Cycle 2020-E. Make a proposal for milestones for Cycle 2020-F.

### Extra Time (order does not indicate priority):

* How can we backup all woe objects in the The Gables to git? (`/var/skotos/6000/skoot/usr/SID/data/vault` os currently backed up to a private vault-gables but it only seems to be of some objects, plus any recently modified objects. Could be a cache of some kind.)
* Can wiztool login for both SkotOS and eOS be SSH and turn off telnet.
* MVP login to eOS using thin-auth & Orchil.
* Propose how we might be able to move best of SkotOS into eOS, in particular Merry and property based system (I may be able to track down fragments of Zell's SkotOS 2.0)
* Alternatively, propose how we clean out cruft and legacy from current SkotOS ChatTheatres to a more minimal but powerful "base" for people to build on.

#