InnerCore/Стандартный шаблон модов

2018-02-05T15:56:00Z

145.255.22.57: /* Заключение */

В большинстве случаев вам не потребуется импровизировать со структурой мода. Для этого тут описан шаблонный файл построения и то, какую структуру должен иметь мод с таким построением.

Здесь приведено содержимое файла build.config:
<syntaxhighlight lang="javascript">{
"defaultConfig":{
"buildType":"develop",
"api":"CoreEngine",
"libraryDir":"lib/"
},

"resources":[
{
"path":"res/",
"resourceType":"resource"
},
{
"path":"gui/",
"resourceType":"gui"
}
],

"buildDirs":[
{
"targetSource":"main.js",
"dir":"dev/"
}
],

"compile":[
{
"path":"main.js",
"sourceType":"mod"
},
{
"path":"launcher.js",
"sourceType":"launcher"
}
]
}</syntaxhighlight>

 

== Структура мода ==

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

Если вам нужно подключить какие то библиотеки, вы можете создать директорию lib в директории мода и копировать их туда, после чего их можно будет подключить из любых исполняемых файлов мода.

Все ресурсы мода должны находиться в директории res, если их нет, она должна быть пустой. Аналогично для текстур интерфейса, только они должны находиться в директории gui. Как конкретно работают ресурсы вы сможете прочитать [[InnerCore/Ресурсы|здесь]].

В директории мода должен присутствовать файл launcher.js, который по-умолчанию должен содержать только команду Launch(); Более подробная работа с лаунчером мода будет описана в другой главе.

== Исходный код мода ==

Так же в моде обязана присутствовать директория построения dev, в которой должен быть файл построения .includes, в нем прописаны все локальные пути файлов, которые участвуют в построении в нужном порядке, так же он может содержать комментарии (// или #) и пустые строки

Пример содержимого .includes:
<pre>// Предположим, что .includes находится в директории dev/ в моде

// Этот файл должен находиться на пути dev/header.js
header.js

// Эти файлы соответсвенно должны находиться в dev/source/
source/blocks.js
source/items.js</pre>

Все эти файлы будут собраны в файл main.js и запущены, как основной код мода.

== Заключение ==

Как говорилось в начале данная структура подходит для большинства модов и если вам не нужно ничего особенного, то оптимально использовать именно её.

InnerCore/Модуль ModAPI

2018-02-05T15:52:48Z

145.255.22.57: /* Другие методы ModAPI */

Core Engine имеет модуль для обмена объектами API между различными модами - ModAPI, обмен API осуществляется с помощью методов регистрации и публикации API и с помощью методов его получения.

 

Чтобы сделать объект API доступным для других модов используется метод ModAPI.registerAPI("имя API", объект API) - после вызова этого метода, остальные моды смогут получить объект API по данному имени.

 

Чтобы получить объект API нужно добавить специальное событие на имя объекта API, который требуется получить. Событие используется потому, что моды загружаются в произвольном порядке и неизвестно, зарегистрирован ли данный API на момент загрузки мода, который в нем нуждается, даже если мод, который регистрирует, присутсвует.

Для этого используется такой метод:
<pre>ModAPI.addAPICallback("имя API", function(api){

// api является объектом api, зарегистрированным под данным именем

})</pre>

 

Это событие произойдет 1 раз после добавления, при этом если API уже зарегистрирован, то событие произойдет сразу после добавления, иначе оно будет ожидать регистрации.

В этом событии вы можете произвести какие-то действия, связанные с работой с данным API, например при получении ThaumAPI (api таумкрафта), добавить предметам вашего мода аспекты. Если событие не произойдет, значит таумкрафт не установлен и аспекты регистрировать не надо.

 

 

=== Использование событий в скрипте-лаунчере ===

Если мод не может работать без какого-то объекта API (например это дополнение к какому-то моду), то разумно будет сделать так, что мод запускается по событию регистрации данного API и сразу передать ему объект API.

 

К примеру вот код лаунчера мода, который является дополнением к таумкрафту и которому обязателен ThaumAPI:

 
<pre>ModAPI.addAPICallback("ThaumAPI", function(api){

// по событию регистрации ThaumAPI запустить основной мод

Launch({

ThaumAPI: api // в качестве дополнительного значения при запуске под именем ThaumAPI передать полученный объект api

});

});</pre>

 

 

=== Другие методы ModAPI ===

*ModAPI.requireAPI("имя API") - отдает объект API по данному имени, если он зарегистрирован. Несовершенен, потому что порядок загрузки неизвестен. Лучше используйте ModAPI.addAPICallback.
*ModAPI.getModByName("имя мода") - отдает объект мода, отвечающий за его файлы и загрузку, если мод загружен. Несовершенен, потому что порядок загрузки неизвестен. Лучше используйте ModAPI.addModCallback.
*ModAPI.addModCallback("имя мода", function(mod){  <br/>   // mod является объектом мода<br/> }) - добавляет событие, которое произойдет при загрузке мода под данным именем, которому будет передан объект мода. Аналогичен по действию ModAPI.addAPICallback, только для модов.
*ModAPI.isModLoaded("имя мода") - проверяет, загружен ли мод с этим именем. Актуальна в событиях PostLoaded и ModsLoaded, которые происходят после загрузки всех модов.
*ModAPI.requireGlobal("имя переменной или исполняемая строка") - возвращает переменную с данным именем из самого Core Engine, если передана исполняемая строка, выполняет ее в пространстве имен Core Engine и возвращает результат, при возникновении ошибки возвращает null и пишет ошибку в лог. Может быть использована для получения скрытых модулей или значений ModPE (они могут работать некорректно).

mineprogramming wiki - Вклад участника [ru]

InnerCore/Стандартный шаблон модов

InnerCore/Модуль ModAPI