Пожалуйста, войдите или зарегистрируйтесь.
1 час 1 день 1 неделя 1 месяц Навсегда
Войти

В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.

1

Прочее / Тема для оффтопа II

« : 20/10/2019 00:25:03 »

А почему форум не поддерживает https? Так было всегда? (

2

Прочее / Тема для оффтопа II

« : 19/10/2019 14:07:13 »

Здравствуйте, форумчане.
Рад видеть, что многие ещё бывают на этом форуме. Попробую что-ли запустить Nox и я.

3

Моддинг / Шифрование файлов Nox

« : 19/06/2018 09:45:38 »

Может пригодиться как компонент ПО работающего с файлами Nox-a (были такие программа noxPacker, NoXModSuit - они могли бы использовать), так как многие из них зашифрованы.
Использовать в сырую - очень ограничено, если только посмотреть на что-то.

4

Моддинг / Шифрование файлов Nox

« : 18/06/2018 23:58:42 »

Вытащил алгоритм зашифрования/расшифрования Nox-а, написал библиотеку для этого самого процесса и небольшую программу, которая может расшифровывать и зашифровывать файлы Nox-а. Кстати, кажется, там используется сеть Фейстеля.

https://github.com/Darkclainer/NoxCrypt

5

Моддинг / UniMod3

« : 04/06/2018 15:07:49 »

Большое спасибо! Если бы не нашлась бд, то было бы совсем грустно.
Сильно удивлён, что за последние три года форум так сильно исхудал. К сожалению, ничего не поделать - люди теряют интерес. Мало чего нового происходит и многие проблемы, чтобы были у игры с рождения устранены только недавно. Ещё сильно картину портит отсутствие полноценного WOL.
Как бы то не было, мне просто всё ещё нравится Nox и идея UniMod-а. Так что если у кого есть время и желание - присоединяйтесь.

6

Modding/Mapping/Scripting / UniMod3

« : 04/06/2018 11:17:08 »

Hello every one. You can read original post (with updated) on noxcommunity.

Spoiler: Old version (click to show/hide)

I am one of several developers of the UniMod (GitHub, project description on Russian) and I have offer for you.
First of all - sorry for my awkward English. I don't have much active skill's practice in everyday life.

The original UniMod have several serious problems inherited from the first stages of development. I will outline they but will not immerse in great detail.

• All your Lua code is absolutely insecure and unprotected. There is no way to guarantee that some code will not crash game. Indeed, code from one map can break code in another map. Undefined behaviour as it is.
• As one special case of the problem marked above: user interacts with objects via light userdata (in fact - raw pointer). Consequently, for Lua all game objects have no particular type. It is not only inconvenience for developers and users but also the major source of crash and errors.
• In the process of development was not used any of Lua wrappers. Code related to Lua part is totally unreadable.
• There was no goal we pursued in the process of development. All UniMod is - bunch of weakly related fancy features. Yes, you can do cool thing, but is difficult to do more.

I have to confess - it will be not first attempt to renew UniMod. I made one already (but it was around three years ago). You can notice strange branch on the GitHub page of the UniMod - UniMod2. There are some reasons why project abandoned: something important happened in my life, and I do not very like disassembling. But we can use my experience from both projects!

Next, I describe key important features (under spoiler) that must be in some form in the new UniMod - UniMod3. I think this description can paint image what is new UniMod can be and inspire you for actions. Or may be you will point on some crucial flaws.

Spoiler: features (click to show/hide)

Lua wrapper
This is not very bright feature for users, but for developers it is. Wrapper can provide cleaner code and faster development process. Now, I looking in the direction of sol2 (GitHub).

Four level abstraction of code execution
This is idea of code hierarchy. Like how in the operating system exist core level and user mode level, in the UniMod will be four levels. But do not be afraid it is not so complicated - there is some logic inside and Lua will do most work.

• C++ level
• Core-script level - scripts that can affect the whole game
• Mod-script level - users scripts
• Map-script level - scripts that affect only the current game on the current map.

Now I will try to explain each level. When it supposed to start and when - turn off.

C++ level
UniMod will use the follow method of loading: there are many dll that Nox load by default. We put one - fake dll in the Nox root folder. This dll will do two things: load UniMod3.dll and original one.
This will enable you to use your favourite Nox executable, of course if it's binary compatible with UniMod (last original update, if I correct remember - 1.2b).
The loading of UniMod3.dll consists of following process:

• Lua initialization.
• Loading configuration from UniModConfig.lua. This file contain values of important flags.
• With respect of setted flags some actions take place. (more about in flags section)
• Core-scripts loading.

Examples of flags:

• DebugMode - allow user to use unsafe functionality (standard debug module). It's necessary for debug purpose. In fact, this mode breaks safe code execution.
• AllowStartMultipleNoxs - allow to start another example of Nox if there is one already.
• EnvhanceConsole - activate enchanted console (in original UniMod were added some features: history and edit opportunity).
• CoreLevelFiles - list of Lua files that will be loaded on the core-script level.

Core-script
After the first stage of initialization (C++ level) done  - core-script scripts begin to load.
At this moment, I vaguely imagine what this scripts must do. I think it's part of C++ code that can and must be done in Lua for the purpose of flexibility. It's part of what developers write and configure - not users.
Maybe it's best place for mod loader part of UniMod.
Maybe it's best to form this scripts into modules and distribute like standard library with addition privileges - on that functionality can rely user's mods.

Mod-script
User's global mod scripts. It will be loaded after the core-level scripts finish its job. I don't think much about it - because I do not plan to include this feature in the first version of UniMod3.
But Mod-scripts planned as a addition user library for Map-scripts. As an example they may add particular functionality for several maps. Or may be they can... do what you want? It's like core-level but can be disabled and can't break level above.

Map-script
This scripts loaded with the concrete map. It's will be supplied with a map in .tar archive like in the original UniMod. When a map changes, or a player exit from game mod - all active scripts and effects that was started on this level will be turn off. All created object - destroyed.
In Lua will be several function that user can apply for initialization: before everything loaded (for way to affect process of loading, for example turn off standard scripts) and after that moment.

Full userdata for every object
Every object that you retrieved from Nox or created from Lua will be full userdata with it's own type. This will allow next advantages:

• Function that operate on an object can be implemented as object's methods (through Lua operator colon - ":").
• There will be no problems with "hanged" light userdata. If object deleted - its userdata will know about it.
• We can tight the Lua object and the Nox object not only in direction from Nox to Lua but in reversed too. More in the Event System section.
• Different types of object will offer different sets of methods. Like laser century can have method "setSpeed", or wizards and conjurers - "setMana".

Event system
In the original UniMod there was opportunity to execute scripts regarding to time, or when certain monster dies, but that was completely unmanageable. I even don't remember was it possible to set off timer or not (it was possible to break timer loop). Not speaking about that, setting script on monster death not allow you to control when original function called.
The new event system will be salvation. Every such event (timer expire or monsters dies) will be represented with handle object. Through this object you can control event. Turn it off or somewhat else. Nice bonus, that if you delete this object, and it will be garbage collected - it's possible to make that corresponding script will never be called. 

Lua scope - main security tool
By default if Lua debug feature is disabled then there is no way out of your environment table. We can use it to easily set up the code sand-boxing explained above!

Consider the following example for map-script level.
For the current loading map Lua table created. In that table all necessary function loaded (or they will be available through meta-method _index). Remember that there is no way for a user go beyond this table - she forced to save her objects in this table or in tables that original table contains (difficult moment here - we must guarantee that it is only place where strong references to object is). As soon as map destructed - we delete map table and ask to garbage collector do it's job. After that map can't leave any effect on other game in context of UniMod.

We can implement sand-boxing through Lua standard mechanisms. In fact this was intended by Lua developers.

Documentation
Original UniMod have a very very poor documentation. There was uncountable undocumented features. And it's not only about the user interface but about sources too.
Shhh! I didn't said this to my Russian fellows, but documentation must be in English...

I will be glad to any help, you suggestions or anything. But that is my particular favourite list.

• Nox disassembling. It's boring for me, and I not very good in this. There was somewhere good IDA database with a LOT of researches. I hope that I find it, because my own version disappeared.
• C++ developer.
• If there will be team.. Em... More than three person - way of development organisation will become important. I used to work with some task managers (Mantis, Redmine) but never configured it.
• May be someone know how in others game Lua scripting systems implemented? It will be interesting to ask about some details.

I want to formulate some goals for version 1.0 of UniMod3. It will be very nice if we can reach this, because it will mean that we have good instrument for scripting and base for move in any direction we want to.
Version 1.0 goals

• Code hierarchy levels as described above. May be without mod-script.
• Full userdata for most objects in game. And under minimum functionality I mean what you can do with original scripting system
• ?Functionality for servers?
• Map from original solo game, where all scripts implemented using UniMod3!

How to contact me?
You can post in this topic. Or you can write me email: Darkclainer@gmail.com
When and if people come - we choose communication method.

7

Моддинг / UniMod3

« : 03/06/2018 14:48:09 »

Здравствуйте друзья, меня уже давно не было. Я вернулся, чтобы предложить очередную больную идею.
Да, я всё ещё брежу UniMod и речь пойдёт именно о его дальнейшем развитии.
У первой версии UniMod есть масса проблем. Они касаются не только безопасности выполнения скриптов, но и поддержки разработки - весь процесс крайне неудобный и небезопасный.

Ещё года три назад у меня была идея как это преодолеть - использовать lua 5.2. Я начал другой проект, назвал его UniMod2. Идея была в том, чтобы собрать функционал с первого UniMod, но сделать всё безопаснее и красивее. С его помощью я хотел создать sandbox-ы для каждой карты: отдельно sandbox для модов, и отдельно глобальный. То есть выстроить некую иерархию, где скрипты карты не могли бы нарушить выполнение более высокоуровневых скриптов (допустим после смены карты, все таймеры должны были бы отключаться. Ещё была идея добавить события как объекты). Перейти на full userdata для внутриигровых объектов, там образом добавить им контекст, как следствие сделать безопаснее (playerLook мог бы проверять какой параметр игрок, а какой - объект, и не вызывать падение игры, если их перепутать).
Так же у проекта была четкая цель - как минимум создать альтернативу внутренним скриптам Nox. Как результат работы - переписать скрипты какой-нибудь карты из компании на UniMod2.

Прошло уже много времени, я увидел возможность сделать сам процесс разработки более продуктивным и понятным. Для связывания lua кода и C++ существуют разные проекты. Год назад я впервые услышал о sol2.

Что я предлагаю?
UniMod3!

Под спойлером я приведу ключевые идеи UniMod3, все они являются объектом для обсуждения. В целом если наберётся команда, дальнейшее документирование считаю целесообразным перенести на некую wiki (ту же с github).

Spoiler: Основные идеи UnidMod3 (click to show/hide)

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

Четыре уровня выполнения кода:
Иерархия уровней выполнения кода позволит обезопасить код, сделать отладку более дружелюбной, а выполнение скриптов более надёжным.
Каждый из уровней имеет свою точку (момент времени) загрузки и выгрузки из игры.
Предлагаю следующие уровни:

• Уровень C++
• Основные скрипты - core-script действующие для всей игры в целом
• Mod-script, скрипты которые пользователь может добавлять по желанию. Они так же действуют для всей игры в целом
• Map-scirpt, скрипты, действующие на конкретной карте.

Теперь чуть подробнее о каждом из уровней.

Уровень C++
UniMod3 будет использовать тот же способ загрузки, что и UniMod2 (что отличается от первой версии): загрузка ложной dll.
Хак следующий: выбирается одна из dll, загружаемых Nox: "a.dll", вместо неё кладётся другая с таким же названием. Она загружает UniMod3.dll и оригинальную dll.
Таким образом оригинальный файл выполнения Nox.exe остаётся нетронутым.

На этом уровне выполнения инициализируются все необходимые процессы. Предполагаемый порядок примерно следующий:

• Инициализируется Lua
• Загружается файл конфигураций UniModConfig.lua. В нём устанавливаются важные флаги.
• В зависимости от установленных флагов выполняются или не выполняются дальнейшие действия
• Загружаются скрипты уровня core-scirpt

Примеры флагов:

• DebugMode - активировать возможность исполнять небезопасные функции (например из lua.debug). Необходим для упрощения отладки при написании скриптов
• AllowStartMultipleNoxs - позволяет запустить несколько экземпляров Nox
• EnhanceConsole - активировать улучшенную консоль (в первом UniMod мы немного изменили консоль: добавили возможность редактирования введённого текста, историю)
• CoreLevelFiles - lua-файлы, которые будут загружены на уровне core-script

Core-script
После инициализации первого уровня загружаются эти скрипты.
Я пока слабо представляю основные их функции.
Если будет такая возможность, я бы хотел возложить на них инициализацию части lua-среды. То есть создание каких-то глобальные переменных и так далее.
Возможно именно тут будет реализована возможность загрузки модов.
Так же есть идея разделять эти скрипты на модули, чтобы была возможность поставлять их отдельно, обновлять и так далее.

Mod-script
Пользовательские глобальные скрипты. Действуют после core-script. Пока не знаю можно ли будет их включать и отключать во время игры и что им можно будет, а что нельзя.
Их можно использовать как некие библиотеки функций, которыми пользователи могут делиться друг с другом и использовать в скриптах карт.
Тема для активного обсуждения.
Для упрощения разработки, пока предлагаю обойтись без поддержки модов. Держать в голове мысль, что они могут быть добавлены позже.

Map-scirpt
Загружаются вместе с картой.
Предлагаю как в первом UniMod сделать .tar архив с возможностью сжатия для хранения всех связанных файлов.
В самом скрипте необходимо так же несколько функций инициализации. Вроде предварительной загрузки (чтобы как-то настроить загрузку карты - отключить стандартные скрипты). Постинициализации - после того, как все объекты были загружены на карту.
Выгружаются при переходе на следующую карту или выходе из режима игры.

Full userdata вместо light userdata.
В первой версии UniMod взаимодействие с объектами происходило с помощью light userdata (фактически - указатель). Теперь же каждому полученному с помощью lua объекту будет соответствовать userdata. 
Это даст следующие преимущества:

• Методы связанные с объектом будут реализованы как методы объекта (доступ через двоеточие ":" в Lua)
• Исчезнет проблема с "битыми" объектами. Например, есть удалить монстра из игры, его userdata узнает об этом и не даст выполнить код, вызывающий падение игры (например перемещение удалённого объекта)
• Есть возможность связать lua объекты с объектами из игры в направлении lua -> Nox. Чуть подробнее в Event System
• Для разных типов объектов можно добавлять специфичные для них функции. Например тот же playerLook только для игроков

Event system. Внутриигровые события
В оригинальном UniMod была возможность выполнять скрипт после какого-то времени, или выполнить скрипт при смерти монстра. Однако управлять этими событиями было совсем непросто.
Предлагаю каждому событию поставить в соответствие lua-объект: при создании таймера, создаётся объект taimer, с помощью него таймер можно остановить, перезапустить или удалить (и это удалит сам таймер).

Lua-scope как основной инструмент безопасности кода
Если отключить функции lua.debug, то по умолчанию нельзя выйти за пределы своей основной таблицы. То есть уже существует некий sandbox механизм.

Покажу как можно развить эту идею на примере map-script:
Для каждой карты создаётся отдельная lua таблица, куда загружаются все функции, что может использовать игрок через консоль (или они доступны через метаметод _index).
Игрок не может сохранить ссылку на объект за пределами этой таблицы (это очень тонкий момент, его необходимо гарантировать).
Таким образом, если игрок создал timer, то ссылку на него вынужден хранить он сам. При загрузке другой карты, lua таблица соответствующая карте удаляется, затем необходимо вызывать дважды garbage collector. Это и удалит все созданные таймеры и прочее. Поэтому скрипты уровня карты не смогут больше никак влиять на дальнейшую игру. По этой же причине игрок не может влиять на скрипты более высокого уровня.

Получается что механизмы sandboxing-а можно реализовать используя Lua и ничего более.

Что я жду в качестве помощи?

• Основное и самое болезненное для меня - помощь в дизассемблировании Nox. Конечно, многое уже сделано в этом направлении, но много всё ещё не хватает. Это было самой большой проблемой во время разработки UniMod2 (не считая моей безграмотности)
• Разработчик С++. Любая помощь или идеи
• Если наберётся больше одного человека, необходимо будет как-то организовывать процесс разработки. С этим тоже нужна помощь.
• Знаю, что идея UniMod не новая в мире игр. Уже есть подобные примеры (Garry's mod?). Если кто знает как они работают внутри, было бы интересно послушать

Хотел бы выделить некие цели для проекта. Достижение этих целей будет означать что проект дошёл до версии 1.0. Это не означает что кроме этого больше ничего не будет, но предлагаю сконцентрировать усилия именно в этих направлениях.

Spoiler: ToDo 1.0 (click to show/hide)

• Система загрузки скриптов по указанной выше иерархии
• Рабочая userdata для динамических объектов в игре. Необходимо именно поддержка не меньше, чем предлагают скрипты Nox
• ?Функции для сервера?
• Реализация на UniMod3 скриптов из какой-то карты компании

Куда писать?
Пишите в эту тему. Или мне на почту: Darkclainer@gmail.com
Если наберутся люди - придумаем как лучше организовать связь.

Ещё момент...
Зная, что осталось мало людей интересующихся Nox, планирую перевести этот призыв на английский и опубликовать ещё где. Расскажите, какие сейчас есть популярные международные форумы посвящённые Nox, а я пока сделаю перевод.
UPD: Нашёл noxcommunity.com, пост там. Перевод немного отличается, чуть более чётко сформулирвал мысли, но не уверен, что мой английский очень понятный.

А теперь неприятный момент...
Я потерял свою IDA бд для Nox. Надеюсь у кого осталась..?
UPD2: БД вернулась! Большое спасибо KirConjurer!

8

Картостроение / Картостроение. Вопрос - Ответ

« : 21/05/2017 19:32:09 »

Вряд-ли для этого есть какая-то стандартная возможность в Nox-e, по крайней мере я об этом ничего не знаю.
Могу лишь предложить идею:
Единственная вещь, которая точно переходит с карты на карту, при этом сохраняет с собой хоть что-то - это сам персонаж. В качестве информации, которая говорит, что выполнилось то или иное условие, можно положить какой-нибудь уникальный предмет в инвентарь, который нельзя выкинуть.
К сожалению, не знаю, что случается с параметром "script name" у предметов, при переходе с карты на карту, но могу предположить, что оно остаётся нетронутым.
Можно создать 10 различных предметов с какими-нибудь, наводящими на правильные мысли названием, вроде "IsBigVeryDangerousLookingSwitchTriggered", и поместить их на карту. При необходимости перемещать предметы в инвентарь игрока. А уже на другой карте смотреть нужным скриптом, есть ли такой предмет в мире в данный момент.

Надеюсь, всё вышесказанное можно сделать, или существует более лёгкий способ решить Вашу проблему. Совсем всё подзабыл.

9

Прочее / Тема для оффтопа II

« : 07/12/2016 17:12:17 »

Всё помню, только вот жизнь стала какой-то напряженной. Учеба, эм.. Не отпускает. Даже мышки сейчас нет.
Рад слышать, что люди ещё играют)
Как-то потерял интерес к unimod-у. Интересно разрабатывать новое, а копаться в Nox-e уже времени жалко, дорога в никуда.

10

Прочее / Тема для оффтопа II

« : 01/12/2016 23:08:06 »

Как дела у форума, ребята?
Кто-то ещё играет?

11

NoX / Вопросы-Ответы по Nox

« : 13/12/2014 18:59:10 »

MADARA, пункт 2-ой.

12

Прочее / Викторина "Вспомнить всё"

« : 30/11/2014 13:11:15 »

Интересно, пейзаж на картинке напоминает город исконных владельцев Земли из рассказ Говарда Лавкрафта "За гранью времён".

13

Прочее / Праздники и поздравления!

« : 22/11/2014 20:10:13 »

С днём рождения!

14

Картостроение / Редактор карт KirConjurer-а

« : 14/11/2014 08:25:08 »

Круто)
Можно, кстати, добавить свою библиотеку часто используемых скриптов.

15

Моддинг / Вопросы по UniMod-y

« : 10/11/2014 22:42:49 »

1. Ничего специального в unimod-e для этого нет.
2. Не знаю.

16

Моддинг / Моддинг. Вопросы - Ответы

« : 10/11/2014 19:04:03 »

KirConjurer, огромное спасибо. Похоже на то, что нужно.

17

Моддинг / Вопросы по UniMod-y

« : 10/11/2014 18:57:46 »

Не понял первого вопроса.
Не знаю, что такое "блокиратор пути".

18

Моддинг / Моддинг. Вопросы - Ответы

« : 09/11/2014 21:47:14 »

Там не то.

19

Моддинг / Моддинг. Вопросы - Ответы

« : 09/11/2014 19:41:18 »

Ребята, очень нужно знать расположение двух функций в Nox-e!
1. Срабатывает, когда запускается новая карта. Что бы работала и в мультиплеере и в соло, где угодно.
2. Когда карта меняется. Очень хочется, что бы срабатывала она после чистики, т.е. когда объекты удалены.
С меня как всегда.

20

Прочее / Тема для оффтопа II

« : 09/11/2014 18:00:00 »

А на какой карте лежат эти предметы (если можно скинь номер карты и координаты).

Не лежат они нигде. Их номера (ThingType или type_id, или номер по списку в thing.bin) 237-239.

21

Прочее / Тема для оффтопа II

« : 09/11/2014 14:57:18 »

Сегодня делал функцию создания объектов, начал тестировать. Случайно набрал номер 239-ого объекта.
Самое интересное, что никогда этой штуки не видел, даже когда просматривал все картинки nox-a. Кто-нибудь видел этот чайник?

P.S. Nox ещё может удивить.
UPD: Рядом стоящие объекты (238, 237) тоже не видел.

22

Картостроение, скриптинг и моддинг / Делимся скриптами

« : 08/11/2014 11:18:48 »

Если ты сделаешь вещь, которой реально можно будет пользоваться, то тут можно будет найти пару человек, которых она заинтересует.
Ты не хочешь тратить время на фикс библиотеки, а кто-то не хочет смотреть кусочки кода для глючного мода. Кажется, круг замкнулся.
Можешь не фиксить, а переписать, там в бранче UniMod2 лежит.... Остановился на создании юнитов.

23

Моддинг / Вопросы по UniMod-y

« : 01/11/2014 14:09:18 »

1. spellApply список параметров
target(userdata), type(number), carrier(userdata), source(userdata)
Если пятый параметр number, то и шестой должен быть number (это будут координаты x,y)
Если пятый параметр не число, то он не используется. Следующие параметры:
power или какая-то userdata, или и то и другое.
2. Не знаю как. Можно попробовать через setTimeout её постоянно кастовать.
3. Хорошего способа нет. Наверняка, KirConjurer копал в этом направлении.
4. Скорее всего, лучше вызывать функцию 0x4e4670. Как - к Кириллу.
5. Тебе нужно найти угол и перемести его в 255-ричный. Есть даже функция directGet(x,y,x1,y1). А потом записать его по смещению (как в word-ы) 0x7C и 0x7E.
Но sentryGlobe, вроде, статик, так-что сомневаюсь, что получится.

24

Прочее / Тема для оффтопа II

« : 29/10/2014 21:07:35 »

Я этот процесс называю оконсоливание.

Первая ассоциация на последнее слово.

Spoiler: картинка (click to show/hide)

25

Прочее / Тема для оффтопа II

« : 26/10/2014 20:58:14 »

Баг - это шесть команд в игре.
Висп просто молнией долбит всех подряд, вот его никто и не любит.