вполне ясно и очевидно, что отсутствие импорта чем-то обучловлено и явление точно временное

обожаю этот класс "суперочевидныхникомуненужных идей"

попробовал - мир проработан качественно. правда пропадающие декорации из-за угла обзора камеры всё скрашивают =(. в принципе, прикольно сделано, по крайней мере, мир не отторгает (как цветастый ужас пувера к примеру), хотя кажется излишне мрачным.

не понял как пользоваться инвентарём =). 2 пустых слота и ничего не жмётся.

в какой-то момент игры просто пропала музыка и какие-либо звуки окружения, как-то всё очень мёртво смотрелось. для просто путешествий (без боя диалогов) пригодилась бы такая композиция www.youtube.com/watch?v=DLyqSQhS6E0 из г3, думаю никто на это ругаться не станет =).

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

лалка в каталке

ты же был нам как брат!

Таки изучить джасс

ммм, видать ты столько всего интересного и уникального на гуи делал 3 года, как интригует

никто уже не ждёт

пара моментов:

• лучше сделать не вопросник (1 или 0), а загрузку из ини файла. если будешь оставлять в таком варианте - то лучше будет 1 и 2 (до нуля тянуться далекоооо)
• у деформации в генераторе не стоит "call" в вызове функции
• cjass умирает при проверке. больше проблема парсера, конечно, но это делает загрузку ланда неюзабельной. хотя с другой стороны видимо падает от большого количества повторяющегося кода лишь в одной функции, видимо поделив главную функцию на части - будет всё норм. я бы тоже умер от 37к вызовов.
• высоты клифов считаются как-то не так. деформация делает их выше в 2 раза чем должны быть (видимо в 2, но точно не известно)
• сама замена клифам не торт по причине, что клиф блокирует путь. с одной стороны это контрится блокираторами, с другой ставить их везде - олололлолололо
• рисовка деформацией внешне отчасти напоминает то что было, но сама функция деформации достаточно долго работает, и когда их запускается 15к - это провисание даже на мощном компе 2 секунды.
• видимо игра с высотами не юзабельна для каких-либо целей

по поводу прорисовки текстурами - нужно в карту тогда вставить в3е файл, что не рисует текстуры, возможно ли это? иначе получается, что допустим "полупустышка" одной текстурой нарисует всё + поставит высоты/клифы, а затем джасс перерисует это. если тут и можно где-то выйграть, то надо каким-то образом сделать пустой в3е, что не будет ставить текстуры на загрузке + чтобы всё не разваливалось на загрузке (фаталал).

не качается

соль в том что от русских игроков иногда огорождаться десятиметровым забором
надо

вес проги не так важен. не стоит за этим гоняться, как делал, например, Алексей с мдлвисом

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

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

но есть и положительная сторона - при пересохранении карты редактор перетыкает все декорации и собирает ду файл, 3-5 секунд. можно сделать обработку не предрелизной, а постоянной, тогда и пересохранение и тестзапуск будет быстрее. а если понадобится декор - восстановить ду файл, залить в редактор и вырубить триг на создание. в принципе, это малоюзабельно (т.е. проще просто хранить оригинальный ду файл), но если не трудно - то можно и сделать в придачу ко всему =).

я пустышку брал как раз с в3м файла =)

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

хмм, откуда у него другая "версия" и что там другого?

из 4к строк создания декора были 2 такого вида:
call CD( 'YOks', -7040, 832, 128, 4.76837e-007, 0.956, 0 )
call CD( 'YOks', -7040, 128, 128, 4.76837e-007, 0.956, 0 )
соответственно парсер "e-007" моя не панимат. вручную убрал. мёртвые декорации создаются действительно такими как нужно. правда присутствует сей эффект - при таком создании в тумане войны видно живую декорацию, подходишь - а она мёртвая. в принципе это легко пофиксить временным микропросветом всей карты
для фикса достаточно:
FogEnable(false)
FogEnable(true)
после создания всего декора. видимо не для всех карт это будет отличным вариантом (если кто-то что-то прячет с начала игры), но для меня годится вполне.

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

в вжассе/сжасс надо вырубать оптимизатор синтаксиса - иначе пропадает "оборачивание" функции. быстрота создания декора от оптимизации никак не окупается (эффект незаметен), а вес заметен. сами эффекты оптимизаторов восстанавливаются тем же векс оптимизатором, так что проигрыша тут никакого не будет (оптимизатор векса "оборачивание" не убирает без доп. вмешательства в опции).

новые тесты: благодаря новому состава кода, экономия веса карты 9 Кб, это конечно не 1 Мб, но теперь это ощутимо.
экономия скорости загрузки составила 0.5 секунд. всё тестировалось вместе с виджитайзером + оптимизатором векса. 0.5 сек на их фоне это очень неплохое дополнение. строго рекомендую использовать это для релизных версий.

я бы даже сказал это лучшее что сделано за всё последнее время, которое прошло после того как был сделан видж с оптимизатором векса. если сюда ещё и создание ланда подцепить - будет очень круто.

есть мысль по незначительному байтодрочингу по этому способу.

если 4к декора = 4к строк = 4к полного имени нативной функции, что никак не сократить оптимизаторами. поэтому нативку можно обернуть внешней функцией типа

function O2 takes... внутри этой функции - нативка, с теми же аргументами. вызов будет дольше, это очевидно.

итого наши 4к строк кода теряют огромное количество знаков = вес в архиве теоретически меньше. теоретически потому что полная строчка нативного вызова так или иначе повторяющийся сектор, именно такие сектора очень хорошо сжимаются.

==================================
и ещё по поводу нового обновления (хп объектов)

есть смысл в том чтобы:

1. ставить хп только если там стоит не максимум. иначе смысла просто нет для 99% декора ставить 100%. это и строчки кода и + к весу и + к времени работы если это не ставить в загрузку карты
2. косяк в использовании GetLastCreatedDestructable. оно возвращает бж глобалку, но "возвращение" будет правильным, если в эту глобалку записать предыдущее создание, чего не делается. т.е. если это делать то надо bj_lastCreatedDestructable= создать декорацию. сейчас это работать не может. ещё лучше локальную декорацию с обнуление в конце - опять же экономия на знаках.
3. всё ещё создаются лишние знаки в указании типа декора - то что есть в скрине. могу дать свой ду файл, если это нужно

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

если смотреть глобально, то предрелизная обработка с исправленными 3мя пунктами - это: небольшая экономия веса карты 3-4 Кб, 0.1-0.7 уменьшение времени загрузки. в принципе, это неплохо.
^ хз что там с форматированием :О:

боже, как можно быть таким тупым

а ну может кому то понадобится - микроэкономия на весе в карте - 2 Кб. как это приятно, когда кто-то объявляет себя мегапро и позорится в каждом посте

вручную пофиксил все глючные знаки. выявилась ещё глюка - прога не определяет состояние объекта - т.е. срубленное дерево = просто дерево после обработки ду файла. это что было видно на 1й взгляд.

итого: средняя экономия на скорости загрузки составила от 0.1-0.7 секунд. оно и вообще как бы очевидно любому картоделу - если вынести что-то из загрузки и поставить на потом - загрузка уменьшится, в замен на микролаг в начале игры (НУ ЭТО ЖЕ ПРОСТО ЛОГИКА). но 4к декораций создаются мгновенно без лага. в принципе, разменивать фактическую невозможность затем нормально редактировать декор на микроэкономию скорости загрузки = плохое решение.

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

^ генерируемые знаки не перевариваются парсерами

msvcr100.dll - не найден. а где он ищется собственно? ибо во всех нужных папках винды он есть, в папку проги положил - ноль реакции
^ фикс msvcr100*D*.dll

как можно быть таким глупым как автор комментариев 1 и 4? хотя бы на основе существования слк возможностей можно было сделать хоть КАКИЕ-ТО ВЫВОДЫ.

автор, есть какие-то данные по производительности методов загрузки такого и стандарта, без предположений? и каким образом декор затем править

что тут не понятно может быть? вы карты вообще не делали? или вы из поколения хгм, что карты делало для себя, и потом вообще забило? разжую уже РАЗЖЁВАННОЕ

перенесли иконку в микс файл. в карте стандартный путь

1. игрок БЕЗ архива видит стандарт, всё ок
2. игрок С архивом видит иконку, супер

но он пошёл в другую карту, где такой же путь где-то используется и БАЦ - там иконка из микс файла, что приятно быть не может

перенесли иконку в микс файл. в карте НЕстандартный путь

1. игрок БЕЗ архива видит зелёный квадрат
2. игрок с архивом видит иконку из микс файла

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

какое здесь решение, о великие боги дела картодельства? или это поколение может сказать лишь "ВАУ, КРУТО ЧО. НУ ЛАН ПОШЛИ В ДОТУ".