5. Теперь будем рассматривать различные составляющие инвентаря.
5.1. Drag&Drop, что дословно значит «Перетащить и Выкинуть», т.е. здесь рассмотрим поднятие, замену, выкидывание предмета обратно в инвентарь.
Что бы поднять предмет мы должны «взглянуть» на него, в смысле мышку на него навести. Значит, делаем условие сразу в том же рисовании, внутри тех двух циклов:

Теперь определяем нажатие ЛКМ:

Ну и последнее условие:

Здесь надо пояснить: drag = 0 – значит что мы не перетаскиваем предмет, а can_alarm = 1 – значит что можем запустить аларм (таймер). И далее пишем что, предмет успешно поднят, освобождаем ячейку, запихиваем поднятый предмет (т.е. всю информацию о нём) во временной (дополнительный) массив (мой называется temp_item):

Итак, для чего нужен аларм? А в аларме мы пишем:

Так почему же это нельзя написать в событии поднятия? Ну вот напишете выкидывание предмета в инвентарь без аларма и получится что предмет не будет «выкидываться». Я думаю, сами поймете почему.
Осталась замена:
И тут тоже всё предельно просто. Заводим еще один массив (мой назван temp_temp_item), делаем условия и при нажатии ЛКМ производим следующие события:
В temp_temp_item кидаем инфу о cell[I,k] -> в cell[I,k] помещаем инфу от temp_item -> и наконец, всё из temp_temp_item кидаем в temp_item.
Ну и напоследок не забываем рисовать предмет, который перетаскиваем (if drag=1 …).

5.2. Добавление предмета в инвентарь.
В моём примере это функция, названая add_item. Имеет два аргумента: имя предмета и его количество. Т.е. с помощью этой функции я ввожу имя предмета и его количество и получаю данный предмет в данном количестве в инвентарь. Вы, конечно, можете по-другому сделать, но всё же основываться буду на свою функцию.
Значит, имея при себе имя предмета и количество, нам надо добавить его в инвентарь. В моей базе данных предметов у каждого предмета свой идентификатор (не только имя), а точнее его первый элемент массива (более подробнее см. в Items_Help). Итак, определим же этот идентификатор:

E<255 – максимальное кол-во предметов в моей БД (это для начала).
И поскольку у вас уже отложился опыт с пункта 4 и пункта 5.1, то думаю, справитесь сами, а я просто немного уточню:
Для начала необходимо определить: если ли добавляемый предмет в инвентаре и что бы количество не равнялось максимальному количеству. Да? То добавляем второй аргумент функции к текущему количеству (так же можно проверку на максимальное количество сделать, см. пример). Нет? Создаем новый.

5.3. Одевание предметов.
Создаем массив схожий с массивом cell, только на один аргумент больше. Массив я назвал equip_cell, а новый аргумент содержит информацию о типе ячейки, т.е. какой на неё предмет можно одеть (меч, щит, шлем, ботинки…).
Итак, идем в рисовании к нашим двум циклам. Ищем наведение условия для наведения мышки на объект. Ну а дальше уже должно быть понятно: проверка на ПКМ, проверка на занятость слота и далее как и с Drag&Drop’ом: если занято, то помещаем во временной массив, нет – equip_cell[l]=cell[n].
Насчет двуручного оружия и щита... Пусть это будет вашим домашним заданием =).
А так, успехов в создании своего инвентаря.
Если ничего самостоятельно не получается, то мой пример вам в помощь.

Про архив:

Прочитал все до 5.1 (включительно), неплохо. Для начинающего вполне поможет.
P.S.

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

Dragon33 +1 за стараиния. Но блин...Полностью солидарен с мнением luxorix, тут в примере все как то нудно и не понятно...

до пункта 5 всё доходчива спасиба

а дальше мне кажется станет яснее если поковырять

В своей игре тут наковырял новый инвентарь, немного по-другому сделал. Если кому интересно:
Через редактор я делаю вещи, они сохраняются в виде строки

и потом зашифровываются.
Далее в игре читается строка, расшифровывается и такой передается в ячейку инвентаря.
Т.е. инвентарь у нас состоит из одномерного массива(был еще вариант с динамическим листом, но они медленние и неудобно обращаться к значениям):


Значения считываю через функцию:

Позицию нужного нам элемента определить легко, если ты заранее указал все позиции в константах:

А дальше логическое программирование.

Постоянный парсинг строк не самое лучшее занятие для процессора во время игры. В двоичном виде сохранил (они уже будут непонятны 99% пользователей, при этом гораздо быстрее в производительности), эти же данные загрузил и распихал по двумерному массиву (на самом деле он одномерный, но выводить можно как одномерный, так и двумерный).

P.S.: Вообще, в играх нужно использовать только цифры, если какое-то описание или повествование, тогда да - текст. А так, только лишняя работа на проц. и код программы.

Ang3L, не, там не постоянно парсит. Я использую поверхности для отображения хар-ок предметов(да и вообще для всего интерфейса), т.е. парсинг идет только когда открываем инвентарь, не думаю что это сильно нагружает.
Можно конечно протестировать, создать 100 предметов и посмотреть на какое время подвиснет.
з.ы. а с двоичными файлами еще не работал(как в с++(редактор), так и в gml).

Хорошо, тогда такой вариант. А почему ты не делаешь парсинг всего 1 раз при загрузке игры? Тогда не надо было делать каждый раз при открытий инвентаря. Была строка, парсируем в "клеточки" массива, работаем с ними, выходим из игры, парсируем из клеточек обратно в строку. Получается парсинг работает только при входе и при выходе из игры. Считай, экономия на пустом месте. Конечно, в строке (как в структуре) есть свои плюсы, допустим скопировать предмет или перенести его в другую клетку будет гораздо проще. Тут уж надо взвесить все плюсы и минусы.


В С++ нет такого понятия как записать текстовый файл, там данные есть данные. Поэтому здесь ты лукавишь. Ты можешь попробовать писать сразу цифры друг за другом они будут записываться ровненьким строем в шестнадцатиричном варианте (бинарном), читать точно также. С ГМом, конечно же придется повозится, т.к. встроенное чтение/запись бинарных файлов относится только к одному байту. Остальные, написанные нами функций, могут работать, но могут и сбоить, т.к. я не уверен что мы соблюли все стандарты (плюс обратная запись байтов).

Почему я за бинарные файлы? Причём многим это советую. Приведу аналогию. Предположим у нас есть 2 человека разговаривающих на китайском, и нам нужно перенести данные от одного к другому. И вместо того чтобы передать данные напрямую, многие начинающие делают так:
1) берут у первого китайца данные,
2) переводят с китайского на русский
3) эти данные подносят ко второму китайцу
4) переводят с русского на китайски
5) дают второму китайцу его родные записи

Наш пример:
1) берем бинарные данные у редактора
2) переводим их в текст
3) кладем в файл
4) загружаем из файла, переводим из текста в бинарные
5) передаем игре

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

P.S.: Dragon33, если необходимо, ты можешь обновить исходничек для текущего поколения.

Вот тут и правильно сказал, со строкой проще работать, если допустим взять инициализация инвентаря. И да, вопрос в оперативной памяти очевиден: в случае со строкой - инициализируем 100 пустых строк, в случае с разными типами - я делаю двойной массив(как в первом примере). Как мимним начальная потребляемая память в пользу строк.
Теперь насчет начальной загрузки. Для этого надо будет(как ты и сказал) делать двойные массивы для хранения - лишние потребление памяти, я же строки уже делаю, в противном случае мен надо будет вернуться в первый пост. Вопрос вот только что выгоднее использовать - лишний раз проц нагреть или память.
А так у меня что-то типа того: draw_text(x, y, inv_valueGet(..))


А как же классы StreamWriter и fstream, там же можно писать строки, лайны, числа. Или я чего-то не понимаю?)


Тут что не понятно. Наверно наоборот.

Это потом вырежу, если все-таки это будет хороший пример.

Ага! Мы пришли всё к той же палке оптимизаций: память <-> производительность. Что-то больше жрёт того, но меньше второго, либо наоборот. Вечный вопрос и всегда актуальный!


Это неважно. Важно только направление, которое уже выбирает сам пользователь. Т.е. не важно из редактора в игру или наоборот, последовательность действий будет одинакова (единственная разница, как потом эти данные будут использованы).


Для нас (для людей) они выглядят по разному, а для машины они выглядят как последовательность единиц и нулей (жёстких носителях выемки, принципиально других технологий нет, либо они совсем не массовые). Любая сложная структура состоит из базовых типов, поэтому их можно скинуть в файл как последовательность базовых типов. В свою очередь, базовые типы скидываются в файл как единицы и нули (ну бинарный тип, что понимает комп. и HDD, конечно). Если в шестнадцатиричной системе эти данные лежат от 30 до 39 (эквивалент в десятичной от 48 до 57) то мы видим их как числа, а чуть дальше пойдут буквы. Просто люди в какой-то момент договорились, что вот такие-то числа будут отображать такие-то данные и всё это назвали таблицей ASCII (одна из). Поэтому никаких текстовых файлов не бывает, там просто подобраны шестнадцатиричные данные так, что в таблице ASCII они соответствуют буквам для отображения и нам виден текст, хотя в файле все те же цифры от 0 до 255 (байты). Это в ГМ сделали такое разграничение, чтобы было проще школьникам (и мне кажется, многих это вводит в заблуждение, а потом ещё в индусский код не даёт покоя нашим пионэрам).

Видел такие перлы в С++. Func() - что-то делает и возвращает строку, а код примерно след.:

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

Другой вопрос, тебе записывать в бинарнике или в текстовом варианте? Я бы предпочел всё же именно бинарник ещё по той причине, потому что ты сделал редактор. Т.е. у тебя есть инструмент которым ты можешь работать (смотреть и редактировать файл) и нет необходимости использовать блокнот для редактирования. А раз нет необходимости ни редактировать, ни просматривать файл блокнотом, то сразу бинарничек (и он у тебя как бы будет автоматически зашифрован).


Ок.

Намеки на то, что мне все переписывать надо .
Ладно, я все понял, только скажу что, в чем разбираешься, в том и проще работать.
Спасибо за советы.

Вообщем не стал я выдирать инвентарь, я так, весь проект кину.
Секция: скрипты->InGame->Inv
Самое забавное, что у меня инициализация инвентаря идет через строку и массив, там просто где-то ошибка и я не могу через ф-ю считывать последнюю хар-ку предмета(в данном случае - кол-во).
Рисование: скрипты->Tech->Menu->menuDrawInv

Не-не-не, я не к тому. Все так считают почему-то... Я ж не пишу тебе: "Стирай всё и делай как я - это догма!" Просто выражаю некий опыт с которым знаком, ты же можешь его рассмотреть, и принять либо нет на вооружение. Чисто ещё одна точка зрения и всего.

Можна вопрос /что за файл ILF у архиве
тоесть что он делает?