All streams
Search
Write a publication
Pull to refresh
-30
@LordDarklightread⁠-⁠only

Пользователь

Send message

Движки как раз разные

У рефорджа движок от Стар крафта 2

Лицензионное соглашене для моддинга у рефорджа жёстче!

На рефордже большинство моддов классического варкрафта не идёт!

дистрибутивов на hiveworkshop размещено бы не было бы.

Вроде бы дистрибутивы тут ни причём - они вроде как и на оф. сайте близарда лежат (если покопаться).

Другое дело лиц. ключи....

И Близзард очень щепетильна по поводу лиц. прав! Путь классический Warctaft 3 и не продаётся - но "DOTA" AllStars то ещё вроде как жива (хотя DOTA2 уже давно её затмила) - а права на AllStars заграбастала себе как раз Близард

В остальном причины отсутствия адаптаций под Reforged могут быть очень разными

Там в три причины

  1. Язык разработки - формально классический WC3 - это только Jass - но были плагины, которые надстраивались и предлагали писать на расширенных диалектах cJass, vJass и ещё паре менее известных. Reforged - официально поддерживает vJass (обратно совместимый с Jass) и Lua. Вот, только даже я - вроде бы не использовавший cJass в своих основных проектах, столкнулся в них с тем, что без cJass - они не работали - оказалось - коде были мелкие синтаксические баги - которые ранее переваривал cJass компилятор(обрабатывающий после vJass компилятора).

  2. Совместимость библиотек как сторонних так близардовских - да - у WC3 тоже есть JASS библиотеки и есть проблема совместимости API от версии к версии. Более того в старых версиях ещё есть и разные хаки и хуки - которых попросту нет в новых версиях! Есть и некоторые скрипты (на Lua - даже в классике WC3) постобработки и инициализации - дающие дополнительные возможности моддинга - которые не работают (напрямую)в Reforged

  3. WC3 Reforged более ограничен в графической базе (в классическом WC3 было куда больше моделей), не говоря уже о том, что для WC3 классики сторонних моделей и граф. ресурсов наклепали "мама не горюй" - и все они не просто далеки от HD, но по формату не совместимы с Reforged. Да и в API Jass скриптах там в части анимации есть нюансы в различиях.

Так что переносить модды из классики на Reforged очень не просто - порой проще с нуля сделать!

Ну и лиц. ограничения на моддинг для Reforged Близзард наложила просто драконовские - кому это важно - напрочь отбивает всё желание!

Ну и Reforged не сыскал популярности - его аудитория несравнимо меньше, чем у классики - так зачем корячиться - когда в основном все потребляют классический Warсaft3 - пуская большинство и без купленной лицензии

Если, говоря об актуальной версии WC3, Вы говорите о Reforged - то там с моддингом всё сложнее, чем чем с классикой - и нет прямой совместимости по старым проектам (которые начинались задолго до аносна Reforged; и есть коек какие жёсткие перегибы близарда по лицензионным правам на моддинг) - так что для Reforged нужно проекты заново мутить, включая большую проблему с подготовкой графических HD ресурсов. Но и с версиями классики тоже есть нюансы - там кое-что в некоторых версиях сильно меняли - и без переделки старые версии моддов не будут работать с неподходящей версией движка!

Прикольно, тема модинга под Warcraft3 ещё жива! Думал я уже совсем один из немногих, кто периодически этим интересуется, и даже пилит от года к году пару проектов боле чем 10-летней давности... Ознакомился со статьёй и на душе сразу тепло и лампово стало! Спасибо за публикацию!

Это очень спорно. Скорее всего вся сложность - именно в ломке сознания и уже освоенных паттернов!

В ANSI С++ 98 работать с памятью очень просто - там основныхоператоров раз два и обчёлся! А вот эффективно и надёжно работать с памятью даже в ANSI С++ 98 очень непросто! И если бред на Rust либо не скомпилируется либо просто сразу не заработает как надо. То бред на C++ может проявить себя спустя годы успешной работы! Не говоря уже о мелки недочётах. И выливающихся в гигантские отложенные затраты!
Впрочем, и без бреда, чтобы код на С++ скомпилировался - это тоже надо будет очень постараться, даже после незначительных изменений!

А уж последние стандарты C++ столько в него внесли - что чтобы это всё эффективно и надёжно применяться нужно очень сильно мозг напрягать!

И в C++ очень много пережитков прошлого и очень много разных библиотек и паттернов - всё это тоже не добавляет простоты кодирования и отладки!

А уж какую головную боль там обеспечивают шаблоны - что применяются налево и направо!

Но итог тут такой:

Профессионал C++ не будет иметь больших сложностей в кодировании - он 1001 собаку уже съел и знает большую часть тонкостей и нюансов!

Аналогично про Rust профессионала - только тонкостей и тут на порядок меньше, если не на два порядка!

А вот переходить между этими ЯП будет очень больно - это так же больно как переходить, скажем между чисто функциональным и чисто императивным ЯП, и даже убери тут слово "чисто" - по сути ничего не изменится!

Начать с Kotlin как раз проще, чем с Java не имея практики ООП.

Вот, с С++ безусловно проще на Java перейти, но ещё лучше - перейти на C# - а потом уже, по необходимости, на Kotlin

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

Но Rust даёт высокую надёжность при практической такой же производительности!

Я не говорю - что Rust - идеальный ЯП - он просто первый в своём роде - со статическим управлением памятью! Он просто брутальный революционер, обративший на себя взгляды большой части IT-аудитории!

А вот C++ просто ужасный ЯП - учить его для повседневного применения врагу не пожелаешь! Да - у него есть своя и позитивная репутация - и она даёт хлеб тем, кто на нём программирует, и для ряда задач у него, по сути, нет альтернатив (связываться с Rust пока боятся чуть ли не так же как с С++, да и с компиляторами там всё не густо для различных платформ).
И альтернатив тут почти нет

Тут скорее другие задачи. Вот есть ЯП Python - он сейчас очень популярен и имеет кучу библиотек, вот только местами тормознут... и тормознут там - где как раз очень максимальная производительность - не критично, но "время-деньги". Да - безусловно - кто-то сразу решает такие задачи на других ЯП, но есть уже не мало тех, кто терпит и остаётся верен Python - с его плюшками! Вот ради них и затеяли сугубо локальную Mojo-революцию! Просто она пока не увенчалась даже призрачной победой, пока только планы строят по захвату мостов и телеграфов! Ну а как удастся - вот тогда и с других ЯП начнут переманивать...

А глобальные революции - оставьте другим, экспериментальным ЯП, как Rust

Выглядит слишком хорошо, чтобы быть правдой! Да и дата публикация явно намекает...

России нынче не до то таких изделий - не ну рисовать красивые картинки и делать громкие лозунги-то - всегда ПОЖАЛУЙСТА - но фактически ни проектировать ни производить ни получать комплектующие ни финансирование ни инженеров - попросту не от куда! Но маркетологи в стране ещё пока есть....

Маркетплейсы сами успешно торговали поставками из-за рубежа.

При лимите в $200 теперь там имеет смысл покупать только всякую безделицу - типа чехольчиков и шнурочков. Остальное всё будет слишком дорого - оно и так было не дёшево (на фоне гигантских объёмов серого импорта).

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

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

Интересный материал. Вот вопрос - сколько по времени заняла разработка вышеприведённых схем от момент первичной постановки задачи?

А почему именно трансляция на Си (ЯП которому, то уже тоже читай полтинник лет) , а не на что-то более современное - Kotlin например, который и Native есть (ну на Rust было бы очень сложно) или Python (Mojo).

ИМХО, тут бы конечно лучше выбирать систему с управляемой памятью, а-ля Java (и да в статье и про этот проект тоже пара строчек есть), но всё-таки лучше выбрать современный ЯП (XXI века), а не устаревающие нишевые ЯП. Но тут уже надо глубже понимать среду выполнения - может ли она тянуть доп CLR исполнитель или нужен чистый машинный код?

Вот, приведённый мной вариант с Kotlin - вполне себе может и так и эдак.

Python (с Mojo) тоже вроде как, условно, может в любой среде исполняться

Вообще тут по сути достаточно в IR в модели LLVM компилировать - и далее уже под любое железо и среду исполнения бакэнд-комплятор сделать не проблема!

Даже C# сейчас учится в rutime компилироваться - так что выбор его, мне кажется, тоже более перспективным чем ЯП Си

Или я что-то не понимаю?

Жаль не показали содержательный пример такой трансляции!

Кстати, интересно, насколько COBOL актуален в России?

Ничего не фантазировал и уж тем более никаких претензий не предъявлял. Просто искал смысл

Ну а ради одного пиара только идиоты так бабки закапывают.... вернее сбрасывают с неба на льдину! А в остальном - обычно всегда есть другие цели в т.ч. и скрытый смысл

Причём в прямом смысле - с неба

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

Кстати, в Арктике ещё холодно круглый год - меньше проблем с охлаждением ЦОД. И обслуживание, наверное, проще чем подводой и уж тем более, чем на орбите.

Главное с электроэнергией вопросы решить

Тогда смысл так и остался не ясен. Ну разве что самопиар и продолжение тестирование возможности разместиться там где не достанут "плохие дядьки" с какой бы стороны они не лезли. Впрочем.... история с "Северным потоком" показала - если местоположение известно - то "плохие дядьки" достанут где угодно - вопрос только сочетания сложности этого процесса и фактической выгоды.

Но, вот, если на Марсе размещать.... то там пока только США хоть как-то достать может.... у остальных пока всё в грунт уходит.... обычно не долетев даже... и пока денег на большее не предвидится!

Так сегодня или с 1-го апреля?

А из своих продуктов OneDrive тоже уберут - что бы не мешался, а то уже достал - лезет из всех щелей...

Information

Rating
Does not participate
Location
Москва, Москва и Московская обл., Россия
Date of birth
Registered
Activity