ScorpioT1000
Работаем
 
online
Опыт: отключен
|
prog, а математические функции? а всё, вижу, там дофига всего ) ну давай, дерзай) |
24.02.2012, 07:11
|
Alex_Hell
Mapmaker 'N' Programmer
  offline
Опыт:
6,885Активность: |
ScorpioT1000:
Вот как раз структуры удобней. К тому же сразу обеспечивает строгую типизацию. В структуре может быть:
string Name int Health float Other
Заполнить хеш-таблицу элементарно, написал пример заполнения выше, а использовать тоже просто. А ты написал кучу своего кода, зачем, если все уже сделано? Хеш-таблица как раз для быстрого поиска - то что нужно.
Все эти define, OE_LOAD() и способ сохранения в массивах - это процедурное программирования. ООП давно его вытеснило. Хоть в vJass - эмуляция, но выглядит удобно, и ООП оно обеспечивает как надо, и потери скорости незначительны. |
|
24.02.2012, 19:33
|
|
ScorpioT1000
Работаем
online
Опыт: отключен
|
Alex_Hell, потому что это в десятки раз быстрее работает. Сложность алгоритма не зависит (почти, кроме жассовых аллокаций массивов) от числа элементов.
Кроме того, я не очень хорошо знаю эти хеш-функции =) т.е. вот что выше я написал за час и оттестировал за 15 минут) а с хешами провозился бы часа 4. (я имею ввиду конкретно эти функции конечно)
ScorpioT1000 добавил:
|
|
24.02.2012, 19:41
|
|
J64_
offline
Опыт:
4,724Активность: |
Alex_Hell:
Короче, уменьшаем 256-ое число путем чтения его как 16-ое, чтобы он был в диапазоне от 0 до 8191. И это число используем в качестве структуры. структуры в vJass'е - это обычные числа (с) К.О.
в принципе можно было обойтись и без структуры - я использовал её просто для удобности.
Если так делать, то: вначале не нужно будет вызывать конструктор структуры + сэкономишь несколько хендлов + имхо, это будет БЫСТРЕЕ |
|
24.02.2012, 20:43
|
|
Alex_Hell
Mapmaker 'N' Programmer
offline
Опыт:
6,885Активность: |
ScorpioT1000:
Ну это все решает))
SaveInteger(hashtable, string key1, string key2, int value); LoadInteger(hashtable, string key1, string key2); Хеш-таблица: ru.wikipedia.org/wiki/Хеш-таблица К тому же хеш-таблица - нативная сруктура данных, а если ты создаеш свою структуру данных для поиска на jass - интерпретируется медленнее.
Ты против? Сам то программируеш не на ООП? На асме или си?
Именно так, ведь в итоге будет jass код после трансляции из vJass. Там есть лишние операции, именно они будут немного замедлять.
******
Кстати кто-то там спрашивал зачем массив хеш-таблиц?
Я не говорю что не нужно самому ничего писать. В той же википедии написано что если ID известны заранее - можно написать свою хеш-функцию с разделением без коллизий, но это опять же будет не нативная таблица. Отредактировано Alex_Hell, 24.02.2012 в 21:37. |
|
24.02.2012, 21:26
|
|
ScorpioT1000
Работаем
online
Опыт: отключен
|
Alex_Hell, если я говорю, что не очень хорошо что-то знаю - это не значит, что я это знаю хуже тебя =) не разводи оффтоп плиз, если так хочется - напиши свою версию и сравним скорости. |
|
24.02.2012, 21:35
|
|
Alex_Hell
Mapmaker 'N' Programmer
offline
Опыт:
6,885Активность: |
ScorpioT1000, ОК, напишу свою версию проги (c++), которая все данные возьмет из txt-файла с разделителями, сгенерит на его основе jass-код, положит его в txt-файл.
Потом эти 2 системы сгенеренного jass положим на одну карту (по очереди) и узнаем какая круче. К тому же я почти все написал выше - что в этих табицах хранится (индексы к массивам) и еще массив структур. |
|
24.02.2012, 21:38
|
|
ScorpioT1000
Работаем
online
Опыт: отключен
|
я не буду писать никакие программы |
|
24.02.2012, 21:42
|
|
prog
offline
Опыт:
32,865Активность: |
Анализировал структуру хранения данных по способностям. Столкнулся с проблемой - возможных полей для способностей в слк таблице несколько сотен. Для меня то это не проблема - храню в Map по строковому ключу, но запихнуть такое многообразие в jass представляется малореальным. Похоже придется или отказаться от доступа к некоторым экзотическим полям и ограничиться универсальными или извращаться с хранением данных. Для всего остального проще - там выбор полей намного меньше и они практически все используются в большинстве объектов. |
|
24.02.2012, 22:45
|
|
Alex_Hell
Mapmaker 'N' Programmer
offline
Опыт:
6,885Активность: |
prog, хотели же сделать сохранение в jass только используемых полей (если в jass идет обращение -> используемое). Но потенциально юзер может использовать хоть все поля - нужно его ограничить. С моим способом - хранение в структурах - в структуре оставить только некоторые параметры, тогда юзер не сможет прочитать из нее других параметров (которые есть в slk но нет в структуре), соответственно они окажутся не задействованными в jass а значит и не будут считаны прогой. Да и через defin-ы способ - также.
Ты сам то думаеш нужны ли все те поля? Они хоть в редакторе изменяемые? В редакторе вроде не больше пары десятков. |
|
24.02.2012, 23:05
|
|
prog
offline
Опыт:
32,865Активность: |
Alex_Hell, открой редактор и просмотри пару способностей. В JNGP id поля добавлен к описанию названию. Удивишься сколько полей являются уникальными или используются всего несколькими способностями. Кстати, обычно это поля, напрямую влияющие на поведение способности.
UPD:
Общих для всех способностей полей всего 65 (без учета разделения на способности для героев, для предметов и для войск, за счет которого половина этих полей обычно скрывается) Всего полей в таблице, описывающей возможные поля способности, ровно 631 поле и не факт что я от той версии таблицу выдрал."
Кстати, там-же указано для каких способностей это поле отображается в РО. Надо будет провести эксперимент - прикрутить поля от одной способности к другой и посмотреть что получится, скорее всего вар проигнорирует эти данные или упадет, но зато новые поля можно использовать для хранения кастомных данных.
UPD:
кажется нашел решение - таких уникальных полей не больше 5 для способности, более того для каждого не общего поля задан номер от 1 до 5 занимаемого столбца в таблице. Таким образом за способностью можно резервировать 5 ячеек под уникальные поля и не париться.
А вот мне, похоже, придется научить свою утилиту читать slk прямо сейчас, а не откладывать это до лучших времен. А заодно поковыряться в UMSWE входящем в пакет JNGP. Отредактировано prog, 24.02.2012 в 23:49. |
|
24.02.2012, 23:13
|
|
Alex_Hell
Mapmaker 'N' Programmer
offline
Опыт:
6,885Активность: |
prog, Например способность Буран, имеет 6 своих полей:
DataA (Hbz1) = Количество волн DataB (Hbz2) = Урон DataС (Hbz3) = Количество вихрей DataD (Hbz4) = Уменьшение скорости строительства DataE (Hbz5) = Урона в секунду DataF (Hbz6) = Макс урон на волну DataA - F пишется в редакторе для всех способностей именно такие (Ctrl+D)
Hbz1 - 6 пишется в скобках рядом с именем поля - это специальное поле для данного скилла - занимает отдельную ячейку в slk? Я бы на месте близзов сделал всего 6 особых полей в slk = DataA - F а не для каждого скила специальные, чтобы вышло 600+ Меня насторожил скилл вызов феникса.
Там в скобках пишется Hwe1, Hwe2. А при нажатии на ctrl+D пишется UnitID, DataA. У бурана равкод = AHbz, т.е. скилы с ним связаны по его равкоду (Hbz1 - 6). У других скилов посмотрел - также по равкоду связь. А вот равкод скила феникса = AHpx, а поля в нем Hwe1 - 2. Отредактировано Alex_Hell, 24.02.2012 в 23:55. |
|
24.02.2012, 23:45
|
|
prog
offline
Опыт:
32,865Активность: |
Alex_Hell, прочти мой предыдущий пост со всеми дополнениями. Я уже разобрался в чем дело и как с этим справиться. В формате w3a содержится как ID поля которое изменено, так и смещение этого поля (A-F) если поле из числа уникальных. В общем формат далек от оптимального - куча лишних данных и это сбило меня с толку. Паника по поводу 100500 полей отменяется - решение найдено.
UPD:
учить утилиту читать slk прямо сейчас не придется - экспериментально установлено что для всех полей способности хранится уровень и смещение, даже если это поле не использует ни первого ни второго. Т.Е. формат унифицирован в ущерб компактности. UPD: по поводу связи по равкоду - это было сделано исключительно из соображений удобства - никаких ограничений на ID полей на самом деле нет. За исключением их уникальности, конечно. Я не знаю что подтолкнуло разработчиков к такому решению, видимо возможность задать уникальные настройки каждому уникальному полю, а не ебать себе мозг с шестью фиксированными полями непонятного типа. Ведь DataA в одной способности может быть целым, а в другой внезапно оказаться строкой, не говоря уже о диапазоне допустимых значений, проверке на null и использовании поля способностью в зависимости от флагов "для героя", "для предмета" и "для боевой единицы". Отредактировано prog, 25.02.2012 в 00:18. |
|
25.02.2012, 00:08
|
|
ScorpioT1000
Работаем
online
Опыт: отключен
|
prog, юзай мою либу, я сделаю на 16 массивов = 8192*16 если надо, 32 |
|
25.02.2012, 01:13
|
|
prog
offline
Опыт:
32,865Активность: |
ScorpioT1000, я иначе сделаю - раз уж прикручивать FreeMarker - код будет по шаблонам генериться - я тебе объясню как это делать и ты шаблон под свою либу сам напишешь. |
|
25.02.2012, 01:16
|
|
ScorpioT1000
Работаем
online
Опыт: отключен
|
prog, по шаблонам нельзя делать обход массива. Заюзай мою либу, там все с умом сделано) |
|
25.02.2012, 02:33
|
|
prog
offline
Опыт:
32,865Активность: |
ScorpioT1000, допилю - увидишь о чем речь. Если получится - шаблоны прямо в коде карты можно будет писать. И да, обход массива там есть - смотри пример с описанием способности.
Подход с использованием шаблонов хорош тем что не будет жесткой привязки к какой-то конкретной системе хранения данных (это не мешает предложить готовую тем кто не хочет писать свою), а будет гибкий и простой в использовании инструмент для созданий собственной базы любой сложности.
Через пару дней, думаю, уже будет что пощупать. Не уверен успею ли всякие навороты вроде дублирования файлов с данными допилить - дублировать то их не проблема, но что с подменой делать не знаю пока. А вот скармливать описания FreeMarker-у и прогонять код через него-же это, в принципе, уже есть - осталось отрефакторить и подправить пару багов. |
|
25.02.2012, 03:40
|
|
prog
offline
Опыт:
32,865Активность: |
Немного поковырял хранение данных в памяти утилиты и приучил FreeMarker принимать данные об объектах. В общем, чтобы не вдаваться в подробности, запилил доступ из шаблона к данным по объектам в виде
${XXXX.YYYY*} где XXXX это равкод объекта, YYYY - равкод поля, * - уровень способности или вариация декорации (для других типов объектов, естественно, * не указывается) Поддерживаются арифметические операции в блоке ${} и весь синтаксис FreeMarker, включая обход массивов и условные операторы.
В процессе столкнулся с тем что редактор выносит все текстовые описания и названия в отдельный файл и обращается к ним через TRIGSTR_.
Это временно решает проблему необходимости в двойном наборе данных по объектам - как шаблон FreeMarker-у будет скармливаться непосредственно файл со строками. А еще благодаря этому шаблоны будут поддерживаться везде, где используются ссылки TRIGSTR_, как минимум, в ГУИ, и в описании карты.
Таким образом, прогнав через FreeMarker файл строк и файл с кодом карты, получаем поддержку шаблонов в описаниях юнитов и в коде.
Теперь надо еще немного доработать структуру данных чтобы можно было из шаблона пройтись циклом по всем уровням способности (сейчас это возможно, но не очень красиво) и можно выкладывать для ознакомления.
UPD:
Правда проблема в том, что теперь придется дублировать и извращаться с подстановкой файла строк. Но это все-же намного лучше чем головняк со всеми файлами данных. UPD:
Нет желающих портировать мне библиотеку с C++ на Java? Вопрос риторический prog добавил:
Столкнулся с проблемой - на каком-то этапе в файлах появляются лишние символы. Если для триггеров это не критично, хотя и не приятно, то для файла строк это очень и очень неприятно, возможно даже фатально. Да и то что карты вырастает в размере на несколько десятков байт каждый раз когда ее открывают в редакторе и пересохраняют не может радовать, особенно если учесть что этот прирост будет тем больше, чем больше в файле строк. prog добавил:
ScorpioT1000, есть мнение что это дело рук твоей утилиты, которой я пользуюсь чтобы запихивать файл обратно в карту Кстати, выяснил - код карты это не затрагивает, а вот в файле со строками каждый раз добавляется куча пустых строк.
prog добавил: пока напишу костыль, который будет приводить файл строк в норму Отредактировано prog, 26.02.2012 в 03:37. |
|
26.02.2012, 05:27
|
|
ScorpioT1000
Работаем
online
Опыт: отключен
|
мотороллер не мой, я просто разместил объяву! попробуй winmpq или другой утилитой сделать это, там вроде тоже есть комманд лайн, но не такой каноничный. если беда в тулзе, то надо искать свдн |
|
26.02.2012, 05:41
|
|
prog
offline
Опыт:
32,865Активность: |
все, файл war3map.wts безжалостно чистится от пустых строк.
Осталось придумать как подменять файлы чтобы не терять шаблоны. Никогда бы не подумал что скажу это, но я рад тому что есть такая вещь как триггеры - это спасает шаблоны в коде от уничтожения.
А вот все остальное без извращений, увы, не получится.
Подведу итог на данный момент:
Внедрение в JNGP - готово
Получение данных об объектах - готово Представление данных в виде, удобном для заполнения шаблонов - готово Подстановка данных в шаблоны - готово Использование файлов .j и .wts как шаблонов - готово Внедрение .j и .wts обратно в карту - готово Очистка .wts от пустых строк - готово Механизм подстановки для того чтобы не терять шаблоны - в разработке
Конструкция для обхода уровней способности по циклу - в разработке Механизм ограничения области данных - в разработке Механизм получения значений полей "по умолчанию" - в разработке В итоге, есть утилита, которая считывает все нестандартные данные по всем объектам и использует эти данные для заполнения шаблонов, которые берет из кода и файла строк. При этом при повторном открытии карты теряются все шаблоны, кроме тех что записаны непосредственно в коде - остальные заменяются подставленными значениями. При запуске карты в игре отображаются подставленные значения для всех шаблонов.
Проблему составляет подмена файла строк. Если бы был хук, выполняющийся в момент попытки открыть карту (желательно после всех проверок и перед непосредственным обращением редактора к файлу), то эта проблема решалась бы элементарно. |
|
26.02.2012, 05:59
|
