Do some work on the docs.

Docs/OLD/Attention Lock.md

@@ -1,34 +0,0 @@
-### Attention Lock
-
-Note: at this time, none of the following is implemented.
-
-Attention lock is a new mechanism that is used when you want to force the player to give his *undivided* attention to a single activity. Attention lock is particularly relevant for turn-based combat. Let’s say you have a turn-based combat in progress. You don’t want the player to wander away and grow flax when it’s his turn to attack.
-
-The attention lock mechanism can affect the following aspects of the game:
-
-- Stops the player from walking around (or walking away).
-- Stops the player from clicking on unrelated sprites.
-- Hides the gui interfaces of unrelated sprites.
-- Forces the gui of a sprite to appear even if the user didn’t click on that sprite.
-- Directs the camera to point at a specific place, or a specific object.
-
-## Enabling Attention Lock
-
-The mechanism is as follows: the player sprite has a single field, *actor.attention*, which is a pointer to a sprite that is trying to hold the player’s attention. There is a second field, *actor.attentionID*, which must be equal to *place.attentionID* of the attention-holding sprite. If *attentionID* doesn’t match, then *actor.attention* field is considered no longer valid, and the attention is considered to be not held. With that protocol, it is easy to implement these functions:
-
-- function attentionClear(place)
-
-  - Release the attention of all sprites paying attention to place.
-  - Implementation: set attentionID to a new unique ID.
-
-- function attentionHolder(actor)
-
-  - Return the ID of the sprite holding actor’s attention.
-  - Implementation: returns actor.attention after verifying attentionID match.
-
-- function attentionGrab(place, actor):
-
-  - Cause place to grab the attention of actor.
-  - Implementation: sets actor.attention to place, copies attentionID to actor.
-
-This is designed to be resilient to bugs: let’s say a battleground is holding the attention of some actor. If the battleground gets bulldozed, attention is implicitly released. Or if the battleground starts a new battle, attention of previous combatants would be implicitly released. In short, it should be pretty easy to clean up messes caused by buggy sprites grabbing attention.

Docs/OLD/Combat Systems_ JRPG co-op.md

@@ -1,34 +0,0 @@
-## Mechanisms Discussed:
-
-- Battlegrounds - using a sprite to implement combat.
-- Battle friends - how the friend system (separate) might designate “battle friends.”
-- Camera lock - a means where a sprite can force the camera to look in a specific place.
-- Attention lock - a means where a sprite can prevent a player from doing anything else.
-
-Battlegrounds:
-
-The JRPG combat system expects the god-mode player to build “battleground” in various places throughout the world. A “battleground” marks a physical place where combat can take place, and it defines the parameters of that combat. The battleground sprite contains all the combat-related scripts.
-
-Every NPC that can fight names a single combat arena. If a player picks a fight with that NPC, then the battle takes place in the specified arena. The players automatically run (or get teleported) to the left side of the arena, and the NPC runs to the right side of the arena, and the battle takes place.
-
-Combatant Selection:
-
-The initial step of the combat is that a *single* player picks a fight with a *single* NPC. But the battleground object then drags additional NPCs and players into the fight.
-
-NPCs: the battleground scans the vicinity for other NPCs that are linked to the battleground. It brings in any other NPC linked to that battleground. There may be additional rules that govern this.
-
-Players: the battleground scans the area for other players that are “battle friends” with the player. It picks the closest ones, and brings them into combat. If that isn’t enough people on the player side, the battleground scans for non-friend players and brings them in instead.
-
-Sometimes, the battleground might want to draw another player into the combat, but it might not be able to, because that other player is “too busy.” For example, the other player might already be involved in a different combat.
-
-The friend system is also a plugin. The friend system plugin should be required to export a function “is_battle_friend” to make it possible for the combat plugin to interface with the friend system plugin.
-
-Attention Lock:
-
-When the player enters a combat, the battleground puts the player into “attention lock.” Attention lock is intended for activities where the player is supposed to give his full attention to the activity, and not do other things at the same time. There is a separate document that describes attention lock in greater detail. The attention lock mechanism is used to prevent the player from walking away from the combat, and prevents him from growing flax or doing other irrelevant activities while combat is in progress.
-
-Turn-Based Combat:
-
-In this combat system, all players move at the same time, then, all NPCs go at the same time. The players have 10 seconds to specify which attack they want to use. If a player fails to specify an attack in 10 seconds, then a simple combat AI takes over and makes a choice for them. The goal of the combat AI is to give players whose connection is lagging a fair chance.
-
-When the 10 seconds are up, the battleground animates the combat round: it shows the players attacking one by one, then it shows the monsters attacking. The battleground sprite controls all the animation during this period.

Docs/OLD/Recursion-Free Difference Transmission.md

@@ -1,34 +0,0 @@
-## Definitions
-
-- Synchronous Models and Connections have a one-to-one mapping. The terms are used interchangeably.
-- Sprites are objects in the 3D world. Each has a primary table associated with it.
-- Tables are Lua Tables. The runtime assigns each a two-part ID consisting of a Sprite ID and a Table Index that starts at 1 for a Sprite’s Primary Table.
-
-**Synchronous Models** - Each has a few values within it, which are not directly accessible from Lua:
-
-- Position (Plane, X, Y, Z)
-- SpriteID - If present, the connection’s Position gets updated periodically based on the Position of the Sprite
-
-**Sprites** - These also have a few values which are not directly accessible from Lua:
-
-- Position (Plane, X, Y, Z)
-- Sprite ID
-- NextTableID
-
-**Tables** - Each table has a mode with hints to the difference transmitter when it’s OK to suppress it from a synchronous model. Each Table contains a two part ID consisting of a Sprite ID and a Table Index. A Table has an inferred position based on it’s Sprite ID. Some modes are:
-
-- A: Never Suppress (A Global Table)
-- B: Always Suppress (A Secret Table)
-- C: Suppress from SM’s that are far away (A Sprite’s Primary Table, a Player’s publicly viewable data)
-- D: Suppress when a connection’s SpriteID differs from the Table’s Sprite ID (A player’s sensitive data)
-- E: Call the Table.Transmit(OtherSpriteID) to determine whether to transmit. (Does Lua have a way to make a const call that prohibits storing data in any table fields?)
-
-**Table Creation** - I am assuming that whichever version of GUI->MethodCall we use there will be the notion of “Actor” and “Place” as in our old engine. The default mode of a table is:
-
-- When Place is the same as Actor: D
-- When Place is different from Actor: C
-
-**Difference Transmitter Manipulation** - Designers can explicitly override the default mode of a Table with an intrinsic function:
-
-- SetDiffMode(Table,Mode)
-- SetOwner(Table,Sprite)

Docs/OLD/Skills and Skill Trees.md

@@ -1,15 +0,0 @@
-Every game has a database of possible skills. The database can be edited on the fly.
-
-Skills have:
-
-- Name: eg, “handgun accuracy”
-- Point cost: how many skill points do you need to increment this skill. Note that the game can bypass the point system by procedurally incrementing the player’s skill.
-- Maximum skill level: how high can this skill be incremented. Again, the game can bypass this by procedurally incrementing the player’s skill.
-- A graphical icon representing the skill.
-- Prerequisites list: other skills you have to have before incrementing this skill.
-
-The skill tree isn’t hardwired into code. Instead, there’s an in-game skill tree editor which you can use when you’re in god mode. We should also provide facilities so that two different games can easily share a skill tree.
-
-The engine should provide a built-in character progression screen, so that the player can spend skill points to advance along the skill tree.
-
-When a player comes into a game, he brings his skills with him. There are two preliminary checks: first, that he hasn’t spent too many skill points. Second, every skill he has is checked against the skill tree. If he has acquired a skill in violation of the prerequisites, then that skill is “greyed out” until he buys the prerequisites.

Docs/TODO-List.md

@@ -1,25 +1,33 @@
-In no particular order:
+* Keyboard Event Handling
+
+* Menus
+
+* Skeletal Mesh Tangible
+
+* Implement Interactive Temporary Variables
+
+* A better text console
+
+* Get rid of 3x3 Gridpanel stuff
+
+* Object-Oriented Lua Support
+
+
 
 Secret / semi-secret variables
 
 Secret functions
 
-Global variables
-
 Unicode support for the console
 
 Blockchain integration
 
-Closures instead of a quoted string in menus
-
 GUI that looks for verbs
 
 More sophisticated passage of time
 
 GUI that runs in realtime
 
-The Graphics Engine
-
 Little game demos:
 
 The monopoly game (Errands where you pass thru land owned by others with voronoi diagram)
@@ -30,15 +38,14 @@ Heroes of Rock,Paper,Scissors
 
 Come up with a plan for 'redirect'.
 
-Modify World::scan_near to not allocate any memory, so it can be accessed as a 'getter' in the DrivenEngine.
 
 probes should never modify the state of the world. Currently, there is no protection to guarantee this, except for something in lpxclient where it does a snapshot and rollback before and after the probe. We should come up with a more comprehensive mechanism.
 
-### []()Questionable Design Choices
+### Questionable Design Choices
 
 When we delete a tangible, we currently leave the LUA_TT_TANGIBLE flag on the table, and we leave the metatable in place with the tangible ID in it. Is this the right thing to do? Should we turn it into a truly blank normal table?
 
-### []()Hard Problems without Solutions
+### Hard Problems without Solutions
 
 **Using Multi-Core CPUs**: We want to do difference transmission in parallel (one thread per connected client). This may be possible because each synchronous model is a separate lua interpreter. However, the master world model is shared. It may be possible to access it in a read-only manner in multiple threads.