opened
CosmoMyzrailGorynych
username_0
In GitLab by @CoMiGo on Aug 26, 2017, 01:18

null
Решить, в виде чего будут поставляться модули. В идеале это должны быть npm- или схожие модули, но вот как их прикручивать к проекту?
issue
created
CosmoMyzrailGorynych
username_0
In GitLab by @CoMiGo on Mar 24, 2018, 14:47

NPM — слишком жирно. Особенно жирны его 109 зависимостей.

Проще всего сделать в виде стягиваемых гит-репозиториев. Собирать модули от пользователей можно, опять же, с помощью гита и пулриквестов, собирая JSON-реестр модулей. Дёшево и сердито.

Тогда, для лучшего сжатия и редактирования:

* один модуль === одна папка;
* создаётся один JSON с метаинформацией и полями для настройки внутри редактора (последнее — потому что самый логичный формат и самое логичное место, имхо);
* ридми, инъекции, доки — всё это представляется в виде отдельных доков в папке модуля.
comment
created
CosmoMyzrailGorynych
username_0
In GitLab by @CoMiGo on Mar 24, 2018, 14:51

Так можно вообще делать npm-пакеты, по сути, с возможностью автосборки для крупных проектов; главное, чтобы автоматизаторы создавали нужные конечные файлы
comment
created
CosmoMyzrailGorynych
username_0
In GitLab by @CoMiGo on Mar 24, 2018, 15:29

Пишу по-английски, чтобы потом не заниматься переводов для документации.

# Making your own modules

Any module is a directory with a following structure:

* `includes`
  * (files to be copied to a resulting game)
* `injects`
  * (injects go here)
* `CHANGELOG.md`
* `DOCS.md`
* `index.js`
* `LICENSE` (plain text, strongly recommended)
* `module.json` (required)
* `README.md` (strongly recommended to include)

`index.js` usually represents the main code of your module, and is bundled with all the remaining code of compiled game. A rule of thumb is to pack all your dependencies in one file or, if your dependency is an another ct module, to explicitly state it in README.md.

`module.json` allows your module to be discoverable by ct.IDE, and contains basic info, list of authors and description of module settings.

`README.md` is a markdown file with general info, examples, special notes, etc. It is showed on the 'Info' tab in ct.IDE's modules section.

`DOCS.md` is shown on the 'Documentation' tab in ct.IDE's modules section and is a markdown file too.

`CHANGELOG.md` should contain a history of changes, if any.
comment
created
CosmoMyzrailGorynych
username_0
In GitLab by @CoMiGo on Mar 24, 2018, 15:55

## Adding injections

Injects are a powerful instrument to extend functionality of ct.js framework beyond adding methods or properties. It allows you to add logic to a game loop, load resources, create bundled Types, etc. 

The `injects` folder contains files which code should be injected while exporting a game. All of them are optional, and here is a list of all the possible injections:

**General events**:

* `load.js` – fired once when a game's code has loaded, but nothing still happened, e.g. no resources were loaded;
* `start.js` – fired once when all the game's resources have been loaded. No game logic have been run yet.
* `switch.js` – fired each time when a room is switched, but before any other code. Here, a `room` variable is a name of the new room.

**Room-specific events**:

* `roomoncreate.js` – fired after entering a new room. This code is evaluated *after* user-defined OnCreate code, when all the copies were created. Here, `this` equals to a new room.
* `roomonleave.js` – fired before leaving a room, but *before* any user's script.  Copies still exist here.
* `beforeroomdraw.js`
* `afterroomdraw.js` 
* `beforeroomstep.js`
* `afterroomstep.js`

**Copy-specific events**:

* `oncreate` – applied to a newly created Copy, right *after* its own OnCreate event.
* `ondestroy` – applied to a Copy before it gets deleted. This code is called *before* a Copy's OnDestroy event.
* `beforedraw.js`
* `beforestep.js`
* `afterdraw.js`
* `afterstep.js`

**Templating and utils**:

* `css.css` – injects CSS into an exported game.
* `res.js` – called once while parsing loaded images.
* `resload.txt` – a comma-separated list of images to load. This must start with a comma too, like `, 'img/ct.place.demoimg1.png', 'img/ct.place.demoimg2.png'`
* `types.js` – here you can place your own Types.
* `styles.js` – here you can place your own drawing styles. 
* `htmltop.html` – this code is placed right before the drawing canvas. 
* `htmlbottom` – this code is placed right after the drawing canvas.
comment
created
CosmoMyzrailGorynych
username_0
In GitLab by @CoMiGo on Mar 24, 2018, 17:14

## Structure of `module.json`

`module.json` is the only required file for your modules. It has the following format:

```json
{
    "main": {
        "name": "Module's name",
        "version": "1.0.0",
        "authors": [{
            "name": "Cosmo Myzrail Gorynych",
            "mail": "admin@nersta.ru"
        }, {
            ...
        }]
    },
    "fields": [{
        "name": "Field's name",
        "key": "field",
        "id": "field",
        "desc": "Field's description",
        "default": "default value",
        "type": "textfield"
    }, {
        ...
    }]
}
```

### Adding fields

Adding fields allows users configure your mods from inside ct.IDE, on a 'Settings' tab of your mod. You can have any numbers of fields and use them inside your main code or injects.

Fields are described in `module.json`, and can be one of these types:

* `input` – a simple text input for short strings;
* `textfield` – a large textarea for a long input;
* `number` – an input field for integers;
* `checkbox` – a checkbox for Boolean variables.

A field's `id` must be unique for a module. A `key` determines which parts of code should be replaced  with the field's value. If you have a field with a key `'enabled'`, then all matches with `%enabled%` will be replaced by a field's value.
comment
created
CosmoMyzrailGorynych
username_0
In GitLab by @CoMiGo on Apr 1, 2018, 16:07

closed
comment
closed
CosmoMyzrailGorynych
username_0
issue