OneLifeDocs OHOL editor guide.txt

From twohoursonelife/OneLifeDocs

ONE HOUR ONE LIFE EDITOR

This is a descriptive guide about EditOneLife.exe, OHOL asset editor. The official documentation is scarce and available only on GitHub repository. The tool was created by Jason Rohrer solely for Jason Rohrer, at the beginning the interface does not look too friendly and the program, while obviously quite sufficient for needs of a single game designer, sometimes shows unstable behavior under various technical circumstances. The purpose of this document is to give a clue to an aspiring modder about how to use it. Some descriptions of parts of the usual workflow of game assets preparation are provided as well.

This document contains assumptions and unfinished sections. Technical remarks, speculations, uncertain information presented in [] square brackets. [description missing] tag indicates an element of user interface whose function is not yet outlined in the text. It is assumed that the reader (as potential modder) has initial familiarity with the overall look of One Hour One Life game "from player's point of view", there are examples and references to facts about things in game world. It is also assumed that the reader has "on fly" access to the editor, as without direct access to particular user interface in question, literary descriptions of such interface tend to be overburdened with details and provide a vague, if not useless impression.

It takes time to process things, newer versions of editor have options currently not just marked with [description missing] tag, but not even mentioned: first published version of the document covers state of things for "OHOL before roads update".

ADDITIONAL INFO

Videos on how the creator uses his tool: https://www.youtube.com/watch?v=27cztry-gJQ - Jason adds sheep to OHOL (short version) https://www.youtube.com/watch?v=WbQsZ5rQ2gg - Jason adds sheep to OHOL (long version)

Documentation available on GitHub repository: https://github.com/jasonrohrer/OneLife/blob/master/documentation/EditorNotes.txt https://github.com/jasonrohrer/OneLife/blob/master/documentation/EditorAndServerBuildNotes.txt (including instructions about compiling editor executable from source code).

STARTING EDITONELIFE.EXE ON WINDOWS

Depending on the software configuration and way of obtaining the executable, the program may refuse to start, telling various obscure messages. If that seem to be the case, adding zlib1.dll file to the game's root directory may solve the problem: If you're working with more fresh, past-2018, version of the editor, or building it from sources yourself, version 2.2.11.0 (76 088 bytes) will suit. EditOneLife.exe from 2HOL-2018 worked with 1.3.0.0 version of the library (73 544 bytes).

There is no editonelife.exe in official user package. In 2HOL package the executive file was located in the root directory of the game.

OVERVIEW

On the first run the editor may seem confusing, looking more similar to the dashboard of some highly specialized vehicle (which, in a sense, it really is) rather than a habitual interface of commercial applications with extensive help available for novices. This program is a "bundle" of interfaces for editing any kind of game asset that One Hour One Life may require: sprites, objects, transitions, categories, animations, and also scene editor. [What about tile textures?]

Buttons in the top part of the graphic interface allow to switch between editing of various kinds of assets. On editor load the tool assortment for SPRITES editing is loaded. From that mode user can switch to OBJECTS editing by pressing "Objects" button.

The overall scheme of modes interconnections looks like this:

SPRITES <-> OBJECTS <-> TRANSITIONS <-> CATEGORIES /
| \ / ANIMATIONS /
| \ / SCENE

Now, what means what? One Hour One Life is a game that happens on a tile grid (width: 128, height: 128) : everything that is in the game, is placed on some tile, with certain (X, Y) coordinates. There are no things that exist in-between tiles, all movement happens instantly after certain delay (with an animation creating an illusion of smooth movement and arbitrary point of stop). Usually only one object per tile is allowed (there are exceptions to this rule, some of them, not numerous in types, are very important to the overall game, like human bodies - objects that are controlled by players; obviously this kind of object is allowed to stay with plenty of different objects simultaneously, as long as tile is declared "passable"; another exception is containers mechanics, but let's not make things overcomplicated right now: generally, one tile can contain one object (or be empty)). - Practically everything in the world is an OBJECT of some kind, object definitions are stored in .\objects folder. - Every object is drawn using multiple parts, usually several of them, rarely only one, and sometimes alot (reaching sixty and more in count), each such part is referred to as a SPRITE, technical information about each sprite, with the picture itself is stored in .\sprites folder. - The game does not just draw static images, but depicts various kinds of their movement. Any real-time change of the object depiction is an ANIMATION, the animation codes are stored in .\animations folder. - The crafting and the world change are among the cornerstone aspects of the game: simply speaking, some objects under various circumstances tend to turn into other objects. Every such transformation is defined as TRANSITION. All code for transitions is stored in .\transitions folder. - For the sake of usability many objects are grouped. The formal, defined by an asset file, group is called CATEGORY. Categories are usually not presented to players in game and serve mainly for easy defining the details of transitions, for example making fire includes "object from "wood source" category": that way all branches from various trees, logs, firewood and kindle are included into the recipe, without need to make a different transition for each branch, and, more importantly, not making another transition for any freshly added object.

All these kinds of assets can be created and edited using the editor.

- In addition to all that, the game uses tile backgrounds, or "BIOMES", also called ground, stored in ./ground, cached to ./groundTileCache. The ground tile cache images are a 4 by 4 represenation of the non cached ground images with a square and non square type. The ground is static, has no meta data associated with it, editor not provides tools for tile editing. Take a note: there is also special kind of objects called "floors", they lay underneath all other objects, are passable, can have various other properties. Generally they look similiar to biomes yet they are OBJECTS. See the details in corresponding section (quick search: [FL]).

Before starting to mod anything it is good idea to make backups of corresponding folders. Modders confident in knowing that they know what they're doing will benefit from reading ["Save" button] and ["Delete" button] paragraphs of ANIM section (quick search: DB_ANIM).

SPRITES SECTION

The game engine obviously can deal with images of any origin, but as the creator draws his images on paper by hand, the editor software is adapted for streamlining "the digitalization of analogous art". The drawn shapes are expected to be scanned in two passes, firstly obtaining the image layer and then adding to it lineart layer. The sheet can contain dozens of shapes, no separating drawings into different files beforehand is required. If not sure what resolution you should initially pick for scanning, you may start with 72 dpi, it's the setting used for images in official version. There are more bits about the art style in "guidelines" section.

Working on sprites starts with preparation of 2 image layers: sprite layer and lineart layer. They should come in separate files, either obtained through scanning of hand-drawn art like Jason does, or by any other mean (like robbing Spanish galleons, for example). Shapes placed into different layers are treated differently: sprite layer contains colors and general look of object, lineart layer contains fine details and also determines the selectable area of the sprite. [What happens if the lineart layer is not provided at all?] Lineart layer can contain only graphics in grayscale palette, anything imported into that layer will be devoid of color. In lineart layer anything that is not a shade of gray/black is counted as transparent space. Each layer should be imported in editor by placing corresonding file in right place and hitting "sprite import" or "lines import" buttons respectively. The "right place" is determined by .\settings\editorImportPath.ini file, by default it contains "/home/jasonrohrer2/default.png". For example, shortening it to "default.png" will lead to editor seeking "default.png" file in the root directory of the game.
- '<' near 'Sprite import' - restores the last image imported as sprite layer.
- '<' near 'Lines import' - restores the last image imported as lineart layer.
For both '<' buttons the editor remembers the last image even if the source was moved, modified or deleted.

- 'Overlay import' - This button is used, in conjunction with an overlayImport folder in the editor's home directory, to import new art for editing as a single image. In this way you can completely skip the above section and import images with lineart prepared prior to importing into the game's engine.

Once both sprite and lineart layers are loaded and synchronized (they should form one complementary picture, after sprite will be cut out from the prepared picture, it is going to be treated as a single inseparable image), next thing to do is to select the sprite on loaded image by dragging a rectangle around it: left click and hold the mouse button, then move the selection until the desired shape will not fill into rectangle; only move from left to right and from top to bottom is accepted. Once mouse button is up, the selected area is copied to buffer, it can be viewed right away as it is constantly redrawn wherever cursor is currently placed. In this guide that area is further referred as "cutout". Before that, after graphics are loaded into the sprite layer, the "sight mark" is revealed, it is glued to the middle of work area and represents sprite rotation center: any cutout will use its relative position to the mark for all tasks related to further sprite modification (such as rotation) or animation, so, before making cutout, it is expected to move the shape in question somewhere close to "the sight mark".

Making any cutout will reveal "Save" button. Clicking on it will save the current cutout as finished sprite, adding it to grand list of sprites, labeling it according to contents of "Tag" field: the field must not be empty, but the given name may be not exclusive - as many sprites as the creator wishes can have identical tag.
    - Seemingly bug: if cutout will be discarded (by left click on any place on loaded image), "Save" button will not disappear. Clicking on it will lead to saving an empty sprite, the corresponding tag will appear in sprites list (the left list), but no image will be attached to it. The "empty sprite" can be deleted just as any regular sprite.

Most of editor sections contain two lists, one on the left and one on the right from the main area. In "Sprites" section
- left list has any sprite that was added to the game, freshly added sprites will appear here.
    - [ASSUMPTION: this point seem to be valid only for sprites that were not used and have no connection to any object in database] Selecting an item in that list will reveal "x" button, meant for the deletion of the sprite. Pressing it will reveal in turn "!" confirmation button. Pressing "!" will delete the active sprite, deselecting sprite will hide "!".
- right list - [it seems that in SPRITES section right list is always empty, not serves any direct purpose]
- as any of these lists could not display every item (the displaying type may contain hundreds if not thousands of items), "prev" and "next" buttons appear for the navigation through the entire item selection.
- the text field above lists provides a query search option through the list; "type . for recent" tooltip suggests the option to see recently accessed elements.

Good amount of hotkey hints is revealed upon loading the sprite layer:
- 'r-mouse = Mv sheet' - Right-click and holding allows to move image.
- 'c = Mv sprite center' - click while holding 'c' key moves "the sight mark", the sprite rotation center described above.
- 'x = Copy pixel color' - [? - elaboration may follow] copies the RGB value of the pixel under the mouse pointer.
- 'w-click = white out' - click while holding 'w' key fills small area around cursor with white color.
- 'W = clear white out' - pressing 'W' removes all alterations made with "w-click".
- 'ijkl = Mv sheet' - again, means for moving a loaded image, this time with keys. The shift is only 1 pixel per key pressed, key holding has no effect.
- 'Ctr/Shft = Bigger jumps' - modifiers for moving image with keyboard, for making bigger jumps. Ctrl-move - 5 pixels per key press, shift-move - 10 pixel per key press.
- 'p-click = internal paper' - [description missing]
- 'P = clear internal paper' - [description missing]

Filling lineart layer reveals additional hint:
- "arrows = Mv lines" - keyboard arrow keys are used for moving content of lineart layer.

- TRIM button - used for trimming sprite sheets. this is very inefficient and creates auto-populated names for sprites.

Sliders:
- 'Shadow' - to each cutout a drop shadow is automatically added, this slider determines how dense the shadow is going to be. Zero means no shadow. In unmodded game this setting is usually left at 50% but can vary depending on specific picture requirements.
    - 'D' button - reset to default value
- 'Black Threshold' - upon selecting a rectangular area, the editor seeks inside for black lines, once it finds one, it cuts out the area surrounded by the line, hoping that is the thing that was expected from it. "Black Threshold" option can be translated as "How black the found line should be to be counted as a sprite border". It also governs the interpretation of opacity of the cutout area: the bigger the value, the less opacity.
    - 'D' button - reset to default value
- 'Saturation' - once sprite candidate is cut out, that slider can be used to adjust (post-process) its colors.
Each of these options adjusts the final cutout look "on the fly", there is no need to figure out the required settings before selecting the shape from the loaded picture, all adjustments will be immediately visible with currently active cutout.

- 'Solid' checkbox - unchecking this box will create a transparent sprite. This is useful when making transparent objects such as glass jars or ice.

OBJECTS SECTION

This is the sub-editor for all kinds of ingame objects: items for use, obstacles and decorations, man-made structures, food, perishable items, tools, creatures, including human characters and possibly other kinds of stuff.

There are still two lists, like in SPRITES section, one on the left and one on the right from the main area:
- right list contains finished OBJECTS, to load them for further editing or making new ones based on old ones;
- left list contains finished SPRITES, each object is assembled from several such pieces.
    - left click on item in that list adds new sprite to the current object.
    - right click on item in the list replaces the currently active sprite of the object with selected one, that's what hint below the list ("R-Click = Replace layer") suggests.
    - right click on RIGHT list does the same, but inserts not just one sprite, but the whole saved object as a sprite subset of currently edited one; hint "R-Click = Insert object" below the right list refers to that.

The main graphic area - here's where the look of the currently loaded object is displayed. Each separate sprite that was used during the creation of the object will be highlighted with a glowing green effect upon hovering a cursor over it. The area is divided by zones by the background of different colors: the middle-bottom, consisting of four gray squares, represents the tile where the object stands, red zones represent neighboring tiles. If object sticks out of gray square zone, it will not fit in one tile in the game as well. It is normal for plenty of objects, like tall trees, but certainly a thing to keep in mind.
- clicking on a sprite will reveal its name, coordinates below the main window in a "ivoryspear ( 60, 62 )" fashion and an assortment of additional controls (see below, "Revealed upon sprite selection"). The sprite which stats being shown is considered "active sprite".
- the sprite can be drag-an-dropped, changing its position, adjusting the overall object look.
- sprites can be grouped in parent-child hierarchy, meaning that any "child" sprite can be readjusted independently, but if "parent" changes location, so do all "children", maintaining their relative location to "parent"; feature is used for making stable sprite groups, like wall with several moss sprites, or head with separate sprites for eyes, hair and so on, so it is possible to quickly move the whole group without painful readjustment of every separate bit.
    - Right-click on inactive sprite makes the currently active sprite the child of clicked sprite.
    - Right-click on free space breaks relation for the currently active sprite and its parent sprite.
        - If the currently active sprite at the same time is parent of other sprite, that link will remain.
        - Attempt to swap parent and child by selecting the parent sprite and right-clicking on child sprite will do nothing: the link first must be broken and then reestablished with reverse order.
        
- "Blank" button: this is "clear all" button, it simply reverts the main area to the initial blank state, a simple way to scratch the previous attempt and start over. It is revealed upon loading of any previously created object, sprite, just making the main area contain anything but emptiness.
- "Save new" button is revealed once object editor stops being empty, it adds the current work to the grand object list as separate entity, labeled according to contents of "Description" field (in the bottom part of the GUI set), not overwriting possibly existing previous work.
- "Replace" is revealed in addition when previously saved object is loaded, it updates the already existing objects with freshly made changes.    

It seems that editor places each new sprite in separate layer, which is referred to by hints described below, despite the object editor generally operates with "sprite" entity rather than "layer".
All sprites that make a certain object are drawn in certain order. "Operations with layers" can alter that order.

hotkeys memo:
- R-Click = Layer parent - see paragraph about sprite parent above.
- Bkspce = Remv layer - removes currently selected sprite.
- d = Dupe layer - duplicates currently active sprite. The sprite copy will be placed at slightly different position, making it immediately visible that a copy was successfully created.

- n/m = Switch layers - this is a way to quickly cycle through sprites without need to pinpoint and choose each of them with a mouse click; pressing "n" or "m" will activate previous or next sprite relative to the currently active one.
    - Bug: pressing "m" or "n" with empty scene throws an error and causes application termination.
- arrows = Move layer - moves the currently selected sprite (and, as usual, all its "children") 1 pixel up, down, left or right. [The system is currently viewed in terms of separate sprites and not "layers", so far it remains unclear what exactly is meant by "layer" in this and following hints]
- Pg Up/Down = Layer order - increase or decrease the drawing order of currently active sprite by one. In other words, move it one step up or below in the whole stack of drawn images.
- r = Rotate layer - while holding "r" key, cursor moving will rotate the currently active sprite; the exact degree of rotation is shown with "Rot: NUMBER" hint to the left of main area, with 0 meaning the default sprite orientation, and 1/-1 meaning the sprite made one full circle clockwise/counterclockwise respectively (ending up in the default position). Keep in mind that sprite rotated not exactly by eighth part of the circle (so, by 1/8, 2/8, 3/8 and so on) most probably will end up blurred, will lose part of its initial quality. '<', '>' buttons provide an option of rotation by exact 1/8 per operation, see below, in "Revealed upon sprite selection" paragraph.
- p = Ignore parent links - if a sprite will be moved while "p" key is pressed, only that sprite will be moved, while all its "children" (normally moved with it as well) will be ignored and stay at their old position.
- c/v = Copy/paste color - [? - elaboration may follow] copies or pastes the RGB value of the selected layer.
- C/V = Copy/paste delta from saved - [? - elaboration may follow] copies or pastes the RGB values as an additive or subtractive value to the selected layer.

If one of these controls is checked, that means the object is a piece of clothing:
- Bottom - "something to cover crotch", example: loincloth made from rabbit fur.
- Backpack - "something to wear behind shoulders". Note that this does not necessary mean it is a container, or that a container should go only into that clothing category. See "slots" paragraph.
- Shoe - "something to wear on foot", any such item can be worn in pair, and will be displayed in pair on "Pos" screen (see below).
- Tunic - "something to cover chest".
- Hat - "something to cover head".

The game recognizes three positions where the object may be drawn: when object rests on a tile, when object is held by a person in hand and when object is worn by a person as a piece of clothing.
Object on a tile is determined in "default object" mode.
Location of object when it's held by a person can be tuned after pressing "Held Pos" button.
Location of object when it's worn is possible to adjust after pressing "Pos" button, which is revealad after checking any of radiobuttons of clothing pieces set, described above.
In all 3 cases the position of object can be adjusted with arrow keys, or by drag-and-drop.
Both "Pos" and "Held Pos" buttons reveal identical control sets. Upon hitting, a person (one of objects that represent of playable characters, picked at random) will appear, the main area will show how the current object will be positioned relative to the holding/wearing person.
    - '<', '>' - these buttons allow to cycle through different persons holding an item. There is no way to position object differently for different characters, a change made while character A is displayed will be applied to wearing fashion of everyone else.
    - 'c', 'P' buttons set - [description missing]
    - 'Age' field and tied slider - allows to see a person holding an item at various age, it can matter as character's height changes with age.

    
- "# Use" field - this parameter determines the behavior of object when it participates in transition as handheld reagent, in other words resides in transition in Upper Left slot (see TRANSITION section for transmutation mechanic specifics). Intuitively that is perceived as "how many uses the object has before it is going to break up", "how fast steel hoe is going to break", "how much bites can I take from that pie". Most objects have "1" in that field, the default state, meaning that particular thing has no durability, and in whichever transition it participates, it's either consumed, or left untouched. Otherwise, such object starts with its maximum durability, and each time the object is used as handheld tool in a transition (like axe that cuts the tree), its "# Use" parameter goes down by 1. When it should go from 1 to 0, "last use transition" is invoked instead of regular transition for that object. Such last use transition instructs the game to turn "steel ax" into "broken steel tool", for example. Note that "simulation of tool durability" is merely intended use, obviously the presented object stat can be used in many creative ways.
For object with "# Use" > 1, sprite editing reveals additional options: upon single sprite selection "Vnsh", "Appr" checkboxes appear, as well as "Sim" checkbox and tied slider.
"Vnsh" makes the sprite disappear as "# Use" goes down, "Appr" does the opposite.
"Sim" allows to see how the look of the object changes as it wears down.
[Obviously, a binary instruction of whether sprite should appear or disappear at some point while object wears off, is not enough, so there should be some additional organizational tricks or missed controls; however, so far the exact mechanic of designing multi-stage object remains unclear.]

Object can be either "Handheld" or "Rideable". Or neither, but not both simultaneously:
- Handheld - counterintuitively, this indicator is NOT about whether the object can be picked up by a player. This is merely visual thing, determining if upon picking up the object is going to be show in character's hands, and wobble according to hand animations, or just abstractly be somewhere in front of him. To make object not pickable one should check "permanent" checkbox, see the corresponding paragraph below.
- Rideable - determines if the object can be mounted by a player. While mounted, object counts as "held" by player, so to hold anything player must dismount first, but unlike held object, mounted one overrides player's speed, so horses make people faster. Mounted people still can end their movement on occupied tiles, like players usually able to do, although to dismount they must find a free tile to leave their steed/vehicle. Alternatively, player can dismount by interacting with another object, for which an according transition reserved, like instantly hitching riding horse to fence: for purpose of transitions rideable/mounted object also counts as handheld and can participate in transitions where is presented in UL slot (see TRANS section for details). The notable difference with handheld status is that mounted object can't instantly be swapped with another object, lying on ground.

- Blocking - means the tile that is occupied by an object is impassable by players. The object is a physical obstacle, either permanent, like a wall, or temporary: transforming interactions or movement may still be allowed.
Checking "blocking" reveals "L Radius" and "R Radius" fields - radius of tiles to the right or left that are blocked beyond the visual representation of the object's sprite.

- [FL]Floor - indicates if object is a kind of floor tile: a pavement that can't be picked up, can be walked over, does not count as occupying the tile (so other objects can be here, except other floor tiles, of course) and may alter the insulation properties of the tile. Floor tiles are objects, they can be constructed and (if according transitions are provided) deconstructed and should not be confused with biomes, a "background" of the world.
- Death - [? - elaboration may follow] flags this as a final death condition to simplify transitions later on.

- Containable - this one indicates whether the object can be put into container.
    - "Contain Size" field - how much space object takes when placed in container. 1.0 size means object is small enough for backpack, basket or cart-like container; 2.0 means the object is large, but can fit in a cart. The majority of pickable game objects use one of these two sizes, some are marked as "extra small", like stock letters with 0.5 size. Object can't fit in a slot if the object is larger than the slot. Otherwise, regardless of the size, object occupies one full slot: only one object can fit in one slot.
    - "Vert" button - reveals '<', '>' rotation buttons, to determine whether upon placing into container object should be rotated in an unusual manner. [The default behavior is that anything put into container is rotated by 90 degrees clockwise.]

- Permanent - an object that marked as "permanent" can't be picked up by players: a wall, a tree, a bear and so on. "Permanent" word invokes pictures of "unshakable" things: boulders, solid structures, but all that flag really means is that the object can't be picked up, nothing more. So some objects, intuitively perceived as in fact not very permanent, like starving lamb, have and should have that box checked nevertheless. Note that floor tiles do not have that flag checked. Checking "permanent" box hides controls related to picking up specifics:
    - Hides "Held Pos"/"End Held" and related buttons, hides "Pickup age" field.
    - Reveals "Behind" button - [description missing]
    - Reveals "Hug Floor" - [description missing]
    
- MapP - how high is the chance that the object will appear somewhere in world "naturally". Zero means it never appears, [the exact meaning of non-zero values so far remains unclear, it was referred as "percent" in some sources, but can have values higher than 100.] There is slight further customization of item generation possible, see "Biomes" paragraph.
- Heat - how much heat object produces and disperses around.
- R - [SUPPOSEDLY] the insulation value that item provides to the [GROUND?] [NEIGHBORING SPACE?] [ELSE - NEED TO CHECK THE EXACT TEMPERATURE MECHANICS]
- Food - if not 0, the object is edible and value determines how much nutrition bars it restores. "# Use" determines amount of "bites" that a person can take from the object before it disappears, each bite restores Food amount of nutrition bars. Such food provides Yum bonus only for first bite, resetting it to 0 on second bite. However, "multy-bite food" that provides Yum on each bite can be simulated making a separate item for each consumption stage and tying them all together through appropriate transition chain.
- Speed - how fast object moves. 1 is human movement speed, 2 is wild horse movement speed. Non-moving objects have their animations proportionally affected by this parameter.

- Slots: determines whether the object is a container and can hold items. Number of slots is how many items can hold container, "More" button adds another slot, "Less" removes the last added slot. Added slot will appear as red box with a number in a main area, it is a sprite placeholder which determines where the stored object is going to appear inside container. Selecting the box reveals "Vertical Slot" checkbox, it determines whether the stored object should be rotated by 90 degrees.
    - "Tm Strtch" field - [? - elaboration may be required] time strech indicates whether an object will undergo modified time, i.e. food in a refrigerator.
    - "Locked" checkbox - if checked, objects can't be taken from the container. For example, there are two transitions allowing free transmutation between "open wooden chest" and "closed wooden chest" or vice versa. "Open wooden chest" is not locked container, items can be picked from it, "Closed wooden chest" marked as locked container and not gives away its items.
    - "Slot Size" field - determines the maximum size of item that can occupy container slot. Unmodded game makes a distinction between 1.0 size slots (backpack and apron slots, can hold small items) and 2.0 size slots (cart slots, can carry logs and similar large objects); text signs are actually containers that have generous amount of slots, but restrict their use to objects not large than 0.5 (and each letter stock has 0.5 size). So that means that the system can be expanded or modded with any other sizes. Or anything of size 0.5 or lesser can be squeezed into billboard. Object can't fit in a slot if the object is larger than the slot. Otherwise, regardless of the size, object occupies one full slot: only one object can fit in one slot.
    - "Demo Slots" - a tool to see how actual items are going to look inside that container. After hitting "Demo Slots" button, picking an object from the right list will not load that object, but instead place it into every container slot (if the size allows it). "End Demo" button exits the mode.

- "Biomes" field - if object occurs in wild nature (i. e. has MapP > 0), "Biomes" field determines on which biomes object is allowed to spawn. Several biomes can be listed, separated with comma, in "1,2,3" fashion. Field can't be empty, 0 just means grassland. In unmodded game:
    0 - grassland,
    1 - swamp,
    2 - savannah ("yellow biome"),
    3 - badlands ("gray biome"),
    4 - snow,
    5 - desert,
    6 - jungle.
    
- "Use Dist" field - how many tiles away can handheld object be successfully used on another object to create a successful transition. For example, bow&arrow has "Use Distance" 5, meaning any animal or person can be shot if it is withing 5 tiles and nothing blocks the view. Most objects have "Use Distance" 1.
- "Deadly Distance" field - identical to "Use Dist", but restricted solely for wound inflicting transitions. [How the game determines that it is wound-inflicting transition? Perhaps, from technical point of view, "Deadly Distance" parameter is used for determining the possibility of "Generic on-person Transition", since editor distinguishes that subtype and gives appropriate hint, see transition types for more info.]
- "Pickup Age" field - characters whose age is less than this parameter, can't pick up an object. Note that object still has to be marked as "Handheld" or "Rideable" to allow picking/mounting in general. Objects do not need to be handheld to be interacted with.

- "Description" field - the same thing as "tag" for sprites, it is "the human-recognizable name" of the object; this is the string which will be displayed near the picture of the saved object in each list where that object will appear, and will bring the object for every matching search query.

Revealed upon sprite selection, related to the currently active sprite:

to the left of the main area:
- "H Flip" button - mirrors the active sprite, "F" mark near the button will indicate that the sprite is flipped.
- '<', '>' buttons - rotates the active sprite by 1/8, counterclockwise and clockwise respectively, each subsequent pressing rotates sprite further. More precise rotation is allowed with holding "r" key, see "r = Rotate layer" hint description above.
    - '0 Rot' button is revealed after clicking on '<' or '>' - resets the sprite to its initial position.
- Rot: 0.000000 info - indicates the current orientation of the sprite relative to its default orientation: 0 means default orientation, 0.125 means 1/8 rotation clockwise, -0.125 same but counterclockwise.
    - Possibly bug: once sprite makes a full circle, it's orientation remains 1.000/-1.0000 instead of 0, so the integer part just means "that picture was rotated that many times".

below the main area, three fields and sliders provide means for change of sprite look by applying simple rendering filter, for the detailed information please see https://en.wikipedia.org/wiki/HSL_and_HSV :
- H field and slider - change sprite's hue parameter.
- S field and slider - change saturation.
- V field and slider - change volume (aka lightness).

- "Person" - indicates if the object depicts a "playable character", in other words, in unmodded game - a person, male or female. Checking it reveals the subset of controls for tuning the appearance of a character. One of notable distinctions is that characters have dynamic appearance: they age, starting as babies, maturing and growing old, hiding one features, revealing others and changing third ones. There are also additional kinds of animation reserved for persons (see "ANIM" section).
    - Number of meaningless for a person-type object controls becomes hidden upon checking "person" checkbox as well: "Home" checkbox, "# Use" field, "Handheld"/"Rideable"/"Blocking" set, "Floor"/"Death" set, "Use Dist", "Biomes", "Deadly Distance", "Pickup Age" fields.
    - "Race" field - each person is assigned to some race, [it seems that any female of given race can have only babies of the same race, that's a simplest nod to genetics that game does so far].
    - "NoSpawn" button - [description missing]
    - "Male" button - if checked, the object depicts male person, otherwise female. In unmodded game the only mechanistic difference between males and females is that females can have babies (which appear just as another player joins the server, by an asexual reproduction/parthenogenesis from mom's point of view) at some period of their lives, while males can't.
    - "Age" field - allows to see how person looks at different age, how all revealing-hiding sprite directives (see "Age Layer" below) actually interact during age progression. Merely referential tool, not influences actual properties of object.
Selection of a single sprite while editing "person" object reveals (sprite + person)-specific controls:
    - "Head", "Body", "Back Foot", "Front Foot" - [supposedly, sprite can be marked as representing the according body part for the purpose of proper attaching various articles of clothing, so the game will automatically know, seeing object marked as "hat" that it should go somewhere around "head" sprite of the wearer.]
    
    - "Age Layer" - means the sprite will be shown only while character's age is within certain range, determined by "In" and "Out" fields. "S" button near each field sets its value equal to current value of "Age" field.
    
In lower part of the screen there are 4 buttons with red circles. They meant for attaching sound samples to an object, labels above them indicate events on which the attached sound is going to be played:
- "Creation", "Using", "Eating" and "Decay" - [it seems that object-attached sounds work no differently than animation-attached sounds; the specifics of working with sound remain not entirely clear so far, see known info within ANIM section, "red circle" for quick search].

TRANS [TRANSITION] SECTION

This part of the editor serves the purpose of defining "the transmutation rules": under what circumstances A turns into B. On the right there is a list of available objects, similar to lists in other editor sections. Picking an item from this list will add that item into currently active "slot" on main field. The main field consists of 4 [ ] slots placed in a square pattern:
[ ]  +  [ ]
     =
[ ]  +  [ ]

Upper slots represent "transmutation reagents", while lower mean its "products".
One of these slots is active and marked by yellow frame around it, clicking changes active slot.

Before transition:
- upper left slot - "what's held in hand".
- upper right slot - "what's on the ground".
After transition:
- lower left slot - "what is going to be left in hand".
- lower right slot - "what is going to be left on the ground".

From Jason's "EditorNotes.txt":

ACTOR  +  TARGET
       =

NEW ACTOR + NEW TARGET

Placing an object into any slot reveals upper and lower quick search bars: lower contains reactions where the picked item serves as reagent, upper grants an access to reactions in which that item is a product.
    - Despite its look each of these bars is "a single button", user can't pick between 2 represented pictures, in fact he can click between them: it is a single reaction (transition) that is showed, not a separate object from the transition.

Supplementary parts of user interface:
- [X] button is attached to each slot, 4 buttons overall - clears contents of active slot and hides related parts of interface.
- "Last use" checkbox is attached to each of 2 upper slots - determines whether the current transition is used when "# Use" parameter of the object in corresponding slot is greater than 1 (case if checkbox not checked), or it is reserved for the situation when "# Use" of the object goes from 1 to 0. [Checking it for object that has 1 use maximum (so, most objects in game) seemingly makes no difference.]
- "Min Use Fraction" field is attached to each of 2 upper slots - for variable-use objects that occasionally use more than one "use", this sets a minimum per interaction.
- "Reverse Use" checkbox is attached to each of 2 lower slots - replenishes a "use" of the object. See the vanilla ponds for an example.
- "No Use" checkbox is attached to each of 2 lower slots - does not exhaust a "use" of the object.
- '<- ->' arrows buttons between each pair of adjanced slots - swaps contents of corresponding slots; upon swapping active slot changes as well.

- "Save" button - saves the current transition; it will start to appear in transition list related to participating objects.
- "Delete" button - deletes the current transition; clicking will reveal "Delete?" button, hitting it erases current transition and clears all slots and fields of TRANS editor section.

Usual transition types and their reagent/product configurations:
(the legend: UL = upper left slot, UR = upper right slot, DL = lower (down) left slot, DR = lower right slot)

- "Regular" transition: use one object on another to get third, A + B -> C.
    A)All 4 slots are filled: something was in hand, something was on ground, something left in hands, something left on ground.
        - A tool use transition: saw in hand, butt log on ground -> saw remains in hand, butt log turns into wooden disks.
        - A station use, or "catalyst" transition: tongs with iron ore in hand, firing forge on ground -> iron ore in tongs turns into hot bloom in tongs, firing forge remains a firing forge.
    Example: cooking a rabbit skewer on coals.
    B)LD empty, other slots are filled: something was in hand, it is added to something on the ground.
    Example: held limestone used on clay bowl to get limestone in clay bowl.
    C)RD empty, other slots are filled: something was on ground, it is picked up and added to something in hand.
    Example: picking up an arrow while holding a bow.

- "Use on bare ground" transition, invoked with a right click on empty tile while holding object in hands. Editor provides a hint, displaying "Use on Bare Ground" label when currently loaded transition matches the criteria.
    UL == held object,
    UR empty,
    DL may be empty,
        if yes, nothing will remain in hands,
        if not then == object left in hand.
    DR == object left on the ground,
    Example: holding clay bowl in wooden tongs, place a freshly fired clay bowl on ground.
    
- "Pick part of something" transition, when player is bare-handed and interacts with object on ground, picks something up, but something else is still left on the ground. Like freshly shorn sheep that stays with a fleece near it: a playable character picks up fleece, now fleece is in his hands, the sheep-with-fleece "transmutated" into shorn sheep.
    UL empty,
    UR object on ground,
    DL product that going into character's hand,
    DR what is going to be left on the ground.

- "Passive" transition, when one object turns into another with just passing time, without any input:
    UL, DL empty,
    UR == object before transition,
    DR == object after transition,
    "AutoDecay Seconds" field (revealed upon filling UR, only if UL, DL empty) determines the time required for the transition to occur. Note that time actually goes in game only in the presence of players nearby, so the sapling will never grow into tree without eyes watching it, despite the common saying.
    Examples: milkweed that goes through various stages of growing, compost pile turning into compost, adobe walls turning into cracked walls, baskets turning into floppy baskets, various items turning into their worn and tattered versions.
    Counterintuitively, so-called "decay mechanic" is achieved not only through passive transitions, but also through activity-checking server-side algorithm; to completely turn off decay (for example) there is not enough to remove tattering passive transitions.
    
- "Movement" transition allows animals and alike entities to move across the map: it looks like, strictly speaking, each time when animal "moves", it's perceived intuitively as the same object that "changes position", but actually it's "an object that turns into another, identical object that stands elsewhere".
    UL, DL empty.
    UR == the moving object.
    DR == the same object.
    An assortment of radiobuttons appears on the right to determine the specifics of motion transition:
    "None" - the transition in question is not movement transition;
    "Chase" - the moving object will seek nearest player and will try to move as close as possible to him. If player is within movement reach of the object and there are no other objects on that tile, moving object will occupy the same tile where player stands. If there's no player close enough, object will move to random free tile;
    "Flee" - the moving object will seek nearest player and will try to move away from him;
    "Random" - movement point will be picked at random, but staying within same biome where object was prior to the start of the movement;
    "North", "South", "East", "West" - movement in corresponding direction.
    If any other than "None" is picked, "Dist" field appears - it governs the movement distance, measured in tiles.
    "AutoDecay Seconds" is how often object moves.
    
- "Maturing" transition allows young animals (as well as any other object, as need arises, of course) to spend some time moving around (each move is formally a transition itself, so "passive" transition not suits for autonomously moving object) and then turn into something else: growing into adults, starving or whatever.
    UL, DL empty.
    UR == the moving object.
    DR == the transformed object.
    One of movement radiobuttons is checked, like with a "Movement" subtype.
    "Dist" determines the walking distance.
    "AutoDecay Seconds" determines how often object moves.
    "Last Use" should be checked: the object makes a number of moves equal to "# Use" parameter of the object (see "# Use" paragraph of OBJECTS section), "spending a use" each time movement transition occurs. When no unspent "uses" left, "Maturing" transition plays instead of "Movement" transition.
    
- "Generic Use Transition" (editor will display according label if conditions for the subtype are met) [seems to be an exception from the general transitions working principle: instead of describing an exact, specific recipe, "Generic Use" tells "whatever this thing is used for, upon using it will turn into another thing"]. It is used for turning tools into broken tools and for food that can be eaten in several bites.
    UR, DR empty.
    UL, DL == held object, before and after the use.
    "Last use" flag indicates the transition should occur only when all uses of the object are spent (see "# Use" paragraph of OBJECTS section).
    
- "Generic on-person Transition" (editor will display appropriate label if conditions for the subtype are met) is another special kind of transition: it involves "person" object as its reagent, but "persons" can't be spent as reaction component, so instead it applies the transition result as something attached to the person. This is how wound-inflicting transitions work.
    UL == a wound-inflicting object, a knife, a bow&arrow, a sword, a bear etc.
    UR == person.
    DL == object after use. May be the same bear, instantly ready for more killing, or may be altered object, like bloody knife that slows down its bearer.
    DR == wound that is going to stick to the person and soon kill him/her if left untreated.

CATEGORIES SECTION

Category is a list of items that can play a role of an "item substitute" in a transition, meaning that any item from given list will suit for that transition. "Categories" editor is meant for compiling of such lists. There are no failsafe measures in that section, not even save button: any change is immediately written in a corresponding file in .\categories\ folder. So, trying to add an item for a category as a test and then immediately removing it leads to two subsequent overwrites of corresponding category.

- left list (the same GUI element as in "SPRITES" section) - list of possible items and categories.
- right list (the same GUI element as in "SPRITES" section) - [description missing]

- the list (another one) that appears upon selecting an item from the left list - [description missing]
- the list (another one) that appears upon selecting an item from the right list - [description missing]
- the white space near the right list - [description missing]

hotkeys memo:
"Up/Down = Change selection" - [description missing]
"Pg Up/Down = Change order" - [description missing]
"Ctr/Shft = Bigger jumps" - [description missing]
"Bkspce = Remv item" - [description missing]

ANIM [ANIMATION] SECTION

After the work on the object look is finished, it may require some "final touches" by adding a movement, an animation to it. Not every object really needs that, most of them expected to remain static, but some, like flames or moving animals, would look strange without any animation. And that what ANIM editor section is for.

Each object can have 3 animations of various types. A group of 3 checkboxes, of which only one can be selected, determines what type of animation is currently shown and worked on:    
- "Ground" checkbox - "idle" animation, it is played when object simply rests on its tile, like fire or flowering milkweed. [Will that animation be displayed if object is stored into container, or held by player?]
- "Held" checkbox - that animation is played when object is picked up. Most objects do not require it, simply going in character's hand, but some require special rules, for example, hand cart readjusts its position and must be located behind character instead of simply "go into human hands", bow with arrow reorientates itself upon picking.
- "Moving" checkbox - animation played when object changes its position, moves. Playable character moving, beasts moving, held carts following the characters and so on. [Moving by any mean? What if object is carried by player and have "moving" animation? Will that animation be played?]
All three are separate independent entities, checkboxes only switch what is displayed at the moment. None of these animation types are required, most objects in game do not have any animations.

Other controls available on section load:

- right list (the same GUI element as in "SPRITES" section) - the usual list of objects, the animations of picked object are going to be displayed.

- "+ Scenery" - loads a background object. For "moving" animation makes the main object move past the line of the same scenery object, for all other animations adds scenery object in front of main one. "x Scenery" ends mode and hides secondary object.

- "Test speed" field + bar - how fast the animation plays in editor. Slowing down is useful to determine fine details of complex animation. It has no effect to how fast the animation will be played in game, instead "Speed" parameter of the animated object influences that (see OBJECTS section, "Speed" description).

Controls unlocked after anything is created or any previously finished animation is loaded: 

Hints:
- "R-Click/arrows = Move layer rot anchor" - right clicking or using arrow keys while any sprite is active moves the rotation center ("the sight mark") of that sprite. For more info about rotation center see SPRITES section ([the "sight mark"] for quick search).
- "Ctr/Shft = Bigger jumps" - arrow keys move rotation center 1 pixel per pressing, with "ctrl" holded 5 pixels, with "shift" - 10 pixels.
- "f = Flip horizontally" - flips entire object, allowing to see how animations look when it faces not in the default direction.
- "h = Hide/show UI" - self-explanatory; hides/reveals all editing controls, allowing to watch animation without tools cluttering the view.

Buttons:
- "Copy up" - [description missing]
- "Copy child chain" - [description missing]

As every object consists of sprites, in animation different sprites can have different "tasks": that goes up, that goes down, that oscillates back and forth. An assortment of fields and sliders attached to the fields commands each sprite its task. These sliders show the situation for the currently active sprite. Which one is active is indicated in the bottom part of the screen, below object name, as "Sprite 1", "Sprite 2" and so on, the selection is changed by pressing "Prev Layer" and "Next Layer" buttons. Alternatively, each sprite can be selected with a mouse click.

Fields tied with Sliders:

First two triplets, "X Osc" (oscillation), "X Amp" (amplitude), "X Phase" and "Y Osc", "Y Amp", "Y Phase" determine "oscillating parameters" of the sprite: in utilized animation each sprite can oscillate ("shake", "wiggle", "move around back and forth") around its starting position. How exactly it will do is determined by these triplets.   
- X Osc - "how often sprite wiggle horizontally".
    - Off - linear X offset by which sprite will be shifted (left or right) when animation will start to play. It does not influence the sprite position on static object.
- X Amp - "how far sprite wiggle horizontally".
- X Phase - all moving parts of complex object start moving in synchronous manner, but it is often required to make them move in some kind of more complex coordinated fashion, like pistons of combustion engine, #1, 3 go down while #2, 4 go up and vice versa. "Phase" parameter serves the purpose of adjusting the oscillation animations of various sprites to each other, by adjusting (making it start from the different point of the cycle) the actual start of the particular sprite animation ("by adjusting the phase").
- Y Osc - "how often sprite wiggle vertically".
    - Off - linear Y offset by which sprite will be shifted (up or down) when animation will start to play. It does not influence the sprite position on static object.
- Y Amp - "how far sprite wiggle vertically".
- Y Phase - see "X Phase".

- Rot - controls rotation animation, provides option to make active sprite rotating, the value determines how fast sprite rotates. The rotation center is marked by red cross.
    - CCW checkbox - makes sprite rotate counterclockwise, the default direction is clockwise.
- Rot Phase - analogue to "X Phase" relative to rotation animation, see "X Phase" description.

Next triplet governs "rocking", "swinging" animation, when sprite rotates around its rotation center like it does with rotation animation, but slowing the movement at the end and in the middle of a cycle, then reversing the rotation move, producing "rocking chair", "swinging pendulum" or "pumpjack" impression.
- Rock Osc - how fast sprite swings.
- Rock Amp - how far sprite swings.
- Rock Phase - see "X Phase".

Next five sliders govern the behavior of "fade-in/fade-out animation", making a sprite gradually more transparent, then more dense, then more transparent and so on. For example this effect can be used to represent the changing shadow density.
- Fade Osc - how fast sprite flickers.
- Fade Min - this setting determines how transparent the sprite should become at the middle of the cycle, 0 means absolutely transparent, 1 means absolutely opaque.
- Fade Max - this setting determines how transparent the sprite should become in the start/end of the cycle, 0 means absolutely transparent, 1 means absolutely opaque.
Note that "Fade Min" and "Fade Max", although suggesting "the proper" use with the setting names, do not enforce it on modder, so having "Fade Min" = 0 and "Fade Max" = 1 is a visual equivalent of having "Fade Min" = 1 and "Fade Max" = 0, both determine only the transparency degree at certain points in time.
- Fade Phase - works just like "X Phase", "Y Phase", but relative to the sprite transparency, see "X Phase".
- Fade Hard - this setting determines in how big fraction of the fading cycle the smooth fade-in/out should be replaced with instant transparency change. That does not influence the cycle length, only transparency change smoothness. At 0 the option is ignored, at 1 sprite waits for a full cycle length, then instantly changes its visibility (hides/shows), at intermediate values an according fraction of the smooth transparency change is "cut out" from the beginning and end of the cycle, so low values like 0.2 may be interpreted as "skip 20% of fade out, making sprite instantly slightly more transparent, then carry the rest of the fade out smoothly, then carry 80% of fade in smoothly, then instantly give sprite full opaqueness."

Last three sliders determine "animation suspension", if there is any: for how long during the whole animation cycle the sprite should freeze and stand still.
- Duraction Sec - how many seconds sprite animation played. It has no effect on animation speed, but instead acts as independent timer: "allow other sliders do their job for N seconds, then just freeze it all, at whatever stage it is". It has no effect if "Pause Sec" slider is at 0, since no time for freeze phase is given at all. Note that for unclear reasons "Seconds" here do not strictly mean "real world seconds" and serve as some relative phase length comparison unit, so manual adjustments are always required to get the desired result.
- Pause Sec - how long is freeze phase.
- Start Pause Sec - how long is the delay before the very first animation play. It has no effect on subsequent cycles.

All available animation types can be invoked at the same time, overlapping and producing all kinds of interesting movement patterns.

Below fields and sliders:
- Full sound copy - copy all animation state sounds from selection.
- Button with red circle - record using audio input device.
[How to attach prerecorded sample to object or animation?]
Recorded sound reveals a set of controls for manipulation with sound sample:
upper row
- 'x' button - stop.
- '>' button - play.
- '1' green triangle button - play once.
- 'X' button - [description missing]
- overlapping squares button - places current sound sample into sound buffer, revealing "folder button".
- folder button - places the content of sound buffer into current sound slot, either filling empty slot or replacing whatever sound was previously loaded.
lower row, in addition to button with red circle
- green triangle button - ["play once"?]
- slider - volume meter, how loud the sample is going to be played.
- 'D' button - [description missing]

The rest of the controls is nominally available right after the anim section is loaded, but will lead to application crash upon accessing their functions if no object was loaded:
- "Copy all" button - copies the full set of animations of current object, meant for quick transfer of animation between objects of identical structure, like "domestic sheep" and "shorn sheep" for example.
- "Copy" button - copies into buffer the state of "fields with sliders" for currently active sprite; it is meant for quick transfer of already refined movement from one object to another, similar one.
- "Paste" button - applies the contents of "slider buffer" to the currently active sprite.
- "Clear" button - resets "fields with sliders" of currently active sprite to default "no movement ordered" values.

- "Random start point" checkbox - begins animation at a random keyframe.
- "Force zero start" checkbox - always plays animation in sequence beginning at keyframe 1.

- "Extra" checkbox - [? - elaboration may follow] additional animation state.

- "Delete" button [DB_ANIM] - instantly deletes active animation. NO CONFIRMATION PROMPTS WILL APPEAR, one click or one misclick and animation is instantly erased from asset files. It remains unclear why it is programmed that way in a context of various confirmations presented at other places, but when dealing with animations modder should be careful. ONE CLICK == YOUR WORK/PART OF THE GAME LOOK IS LOST, reinstallation or asset reintegration will be required.
- "Save" button - saves all changes made to animation. Works in the same fashion as "Delete": NO CONFIRMATION WILL APPEAR, ASSET FILES ON HARD DRIVE WILL BE INSTANTLY OVERWRITTEN, OLD VERSION WILL BE LOST.

For "person" type of object there is a number of additional controls.

More animation types:
- "Eating" - how should be displayed the "person"-object during the consumption of edible item; in unmodded game arms moving towards mouth, mouth moves as munching something, etc.
- "Doing" - [supposedly meant to be played during prolonged interactions, but so far the game has only instant interactions]; [? - elaboration may follow] similar to eating, but for extended duration interactions.

- "+ Clothes" button - adds clothes to person's animations depiction.
- "+ Held" button - adds held item to person's animations depiction.
Both controls serve to visualize how some movement will look with additional in-game details around, the actual animations not changed. After corresponding button is pressed, the modder is expected to pick an object from right list. Instead of loading another object and its animations, editor will try to add the picked object to the scene, as an article of clothing to the person currently shown, or as an item in its hand. If another item needs to be added, "+ Clothes"/"+ Held" should be pressed another time: clicking another time on right list skipping this step will lead to immediate load of another object and erasing current progress without any confirmation. So: 1 press - 1 object loaded. "X Clothes" and "X Held" buttons will erase all worn/held items from the scene respectively.

SCENE SECTION

This section serves the purpose of creating and using the test environment where the creator can observe how things that he's working on would look inside the game.

- The white square represents currently active tile, the red cross marks the center of the scene. As the hint "Arrows = Change selected cell" suggests, pressing arrow keys will move the white square and the active cell with it.

                                                                                             

- left list (the same GUI element as in "SPRITES" section) here contains the list of all available biome tiles, to make a background for the test scene. Picking an item will fill the currently active tile of the scene (marked by white square) with that biome, either defining previously empty tile or redefining already filled one. Right click on an item, like the hint below the list suggests, will flood-fill all tiles of the same type with the picked biome, leaving all tiles of different type, as well as tiles that can not be reached from the active point by flood fill tool, without change.
- right list (the same GUI element as in "SPRITES" section) contains game objects: all stuff that can be inserted into test scene. Picking an object from the list will place that object on currently selected tile. If there is already an object on a tile, it will be replaced with a new one. The "MALEXXX" and "FEMALEXXX" objects, representing bodies of playable characters, are exceptions: they will be added to the existing object. There still only one person can be in a cell of a test scene.
    - "R-Click = Add Floor" tip under the list - if the object from right list is "floor" (has corresponding checkbox checked), right click will add it "as a floor", meaning that it will not block anything passing through its tile and there is still possible to place another object in that tile. Unmodded game has "wooden floor", "stone floor", "ancient stone floor" and road tiles eligible for this.
    - If the currently active cell contains an object, a set of controls related to that object is revealed, see below "Object controls" subsection.
    
- "0, 0" field - the non-clickable field that initially shows "0, 0" - this is a coordinate display, it shows the coordinates of currently selected tile relative to the center of the scene.

- "Save New" button - saves the scene in separate file. Writing performed into .\scenes\N.txt file, where N is the number taken .\scenes\next.txt file, increasing that number afterwards, so scenes are saved as 1.txt, 2.txt, 3.txt and so on.
If there is "scenes" folder in the root directory of the game and it's not empty, "Replace" and "Delete" buttons are revealed.
    - "Replace" button - overwrites the scene .txt file from which the current scene was loaded.
    - '<', '>' buttons on sides of "Replace" button - meant for cycling through saved scenes, back and forth.
    - "Delete" button - deletes the corresponding scene file.
    
- "Clear" button erases the whole scene, reverting the section to its initial state.

- "Export Test Map" button - [SUPPOSEDLY] exports the created scene as a playable environment, "a part of the world". [SUPPOSEDLY] the game server should be running on the machine where the editor is loaded, otherwise the command will be ignored; further steps of the process are unknown.

Written hints:
"Arrows = Change selected cell" - moves the cell selection, represented by white square; see above.
    - There may seem to be a difficulty with moving the cell after activation of the quick search field on top of objects list: the program will respond to arrow key pressing as to command to navigate through the list, not to move change selected tile. To deactivate the quick search field pick an item either from left (tiles) or right (objects) list.
"Ctr/Shft = Bigger cell jumps" - ctrl+arrow moves active cell frame by 2 tiles, shift+arrow does it by 4 tiles.
"f/F = Flip obj/person" - if there is an object in currently active cell, it makes that object face in the opposite direction. "f" flips ordinary object, "F" flips person.
"c/C/A = Copy obj/person/area" - puts something in copy buffer. "c" == copy object in cell PLUS the background tile (grassland, swamp, desert etc.), "C" == copy "person"-object, "A" == copy contents of 6x6 area, with currently active tile serving as upper left corner, without "person"-objects.
"x/X = Cut obj/person" - same as "copy" but also removes the contents of a tile. "x" does it with object, "X" with "person"-object.
    "x" : removes object, leaves background tile, puts object AND background tile in buffer;
    "X" : removes "person"-object, leaves background tile, puts ONLY "person"-object in buffer*.
    * - uniformity is for losers.
"v/V = Paste/Fill" - "v" pastes the current content of buffer, "V" flood fills 12x7 (don't ask) area around the active tile, the way the active tile is (6,3) tile of that rectangle, counting from (0,0) (as I said, don't ask, I'm just registering the esoterics of the tool, the emanations of genius of its creator).
"i/I = Insert contained/held" - tries to paste the buffer content, "i" tries to put it in the container which is in the currently active cell (such as place a firewood into wooden box), "I" gives the buffer content to person that stands in currently active cell. So, it is possible to place items in containers or give them to persons in demo scene, but for that the object should be put in buffer first: placed on scene somewhere and then cut from it by pressing "x".
"Bkspc = Clear cell" - erases all objects from active cell, leaving background tile.
"Hold d/D = Set obj/person dest" - [Supposedly sets up a target cell towards which the object/person will start move upon test scene load.] In editor the object will repeatedly move from the tile it occupies toward the destination tile, reaching the destination, then teleporting back to the start.
"o = Set map origin" - Changes center of the scene to currently active tile.
"p = Play time" - [description missing]
"r = Record frames" - [description missing]
"h = Hide/show UI" - self-explanatory; provides an ability to observe the created scene without any technical elements around.

Object controls (revealed only if there is an object in currently active cell):
- "X Offset", "Y Offset" fields with slider - how much the depiction of the object is shifted relatively to the center of the tile it occupies. (0, 0) means it is depicted exactly at the center of the tile. Both fields can have value in range between -256 and 256, with minimum/maximum value meaning 2 tiles offset.
- "Ground"/"Moving" switch - what animation, from animations available for current object, should be displayed.

"Person"-object controls (revealed if there is a person in active cell):
- "Age" field and slider - [description missing]
- "X Offset", "Y Offset" fields with slider - same as with object controls, see corresponding section above.
- "Ground"/"Moving"/"Eating"/"Doing" switch - same as with object controls, with options expanded since "person"-objects has additional animations available for play.
- "Person time" - [description missing]

GUIDELINES

This document section intended for information of what to do to produce the assets more or less in-line with ones that Jason makes for (his, official) OHOL.

- Before starting to mod anything it is a good idea to make backups of corresponding folders. Modders confident in knowing that they know what they're doing will benefit from reading ["Save" button] and ["Delete" button] paragraphs of ANIM section (quick search: DB_ANIM).

- Editor saves the work directly into respecting game client folders: objects go into \objects, transitions into \transitions and so on. Each file is named automatically.
    - Objects receive a number that is stored in \objects\nextObjectNumber.txt file, with the file content being overriden with a next number.
    - Categories are named in the same fashion as objects, their folder contains its own nextObjectNumber.txt. [Index management or interaction between these 2 files remains unclear.]
    - Sprites are named following the same way, sprite folder contains nextSpriteNumber.txt.
    - Animations are named in a style X_N.txt, where X is the index of an object being animated and N is the number of an animation related to that object.
    - [The way of naming transitions remains unclear.]
It is possible to jump to certain namespaces ("numberspaces") by manually editing nextObjectNumber.txt. It can be useful for reserving some distant number interval to be sure the modded objects will not be overridden by future updates of the official OHOL or by other modders, or for a collaborative work as well. Saving in nextObjectNumber.txt the number that is actually in the middle of already used number interval will lead to overriding of already existing assets and all kinds of bugs, weird engine behavior and development confusion. It should be also kept in mind that choosing too distant number intervals will significantly increase the game load time: it seems that the program checks each number and performs a try to load a corresponding asset regardless of the folder contents, so having 1000000.txt in objects folder will lead to 999999 relatively slow attempts to load not existing objects.

- Most, perhaps all game sounds (working stations, interactions, tool use, animal noises and so on, with an obvious exception of music) are made by Jason Rohrer himself, shouting and whispering, mimicking and imitating all kinds of sounds that his vocal cords are capable of. To be in line with that one style bit, consider making sound support of freshly-added, modded objects, by providing "mouth sounds" as well.

- Jason Rohrer draws the prototypes of his own sprites by hand, on paper, using "Uni-ball Vision" ballpen for drawing shapes and then coloring it with "Tombow" brush markers.

- One thing easy to overlook when making custom graphical additions to the game is shadows: plenty of original objects have very subtle shadow sprites attached to them, barely noticeable in most in-game circumstances but still playing their bit in the overall impression of style.

- Keep in mind that the game tends to significantly lag in the areas where plenty of sprites are drawn. It seems that the overall number of sprites, not their size or variety, matters: areas with ancient walls and mossy wells, 2HOL bee farms, mammoth enclosures and similar areas tend to slow game on outdated PCs: each ancient wall has at least 6 sprites of the moss, mammoths were very detailed too. As a result, the significant performance boost may be achieved by conjoining several static sprites into a big one. Making object modifications without minor graphic details like shadows helped too. However, that particular observation was made Summer-Autumn 2018, the game engine was upgraded since then, particularly addressing the graphics storage, handling and displaying, so there is a high probability of the given information being already outdated: further reports and testing are required.