ECS

Майнось имеет в составе графические модули, затрагивающие аспекты, которые попросту не рассматриваются опеносью. Как я в подробностях описал выше, именно эти модули в совокупности с объектным интерфейсом и являются основным расходником памяти. А поскольку любой модуль - это самостоятельная единица, я не вижу никаких причин, по которым ты не смог бы "запустить более лучшие модули отдельно". Категорически не согласен. Обе системы работают на одной и той же хардварной платформе по абсолютно одинаковым принципам, на основе библиотек с практически аналогичным функционалом, разве что первая ориентирована на текстовое взаимодействие с пользователем, а вторая - на графическое. Я вполне уверенно могу их сравнивать по определенным критериям. Также я могу утверждать на основании собственного и, не постесняюсь этого высказывания, вполне богатого опыта разработки, что в опеноси абсолютно нечему расходовать память по описанным сообщением выше причинам. Это элементарная ось. О чем спор-то вообще? Не припомню, чтобы я утверждал нечто подобное. Сочту за слабый троллинг. Удобную для тебя в данном контексте. Я вообще плохо перевариваю личностей, скачущих в дискуссии с темы на тему, пытающихся намеренно запутать собеседника, впустую тратя его время. Сообщением ранее ты утверждал, что, цитирую, "майнось на робота первого уровня не поставить". Вот я и ответил, что ты и винду на атмегу не влепишь ввиду особых требований. В чем проблема? Есть аргумент - есть контраргумент. Зачем опять менять тему разговора на "нужность могучей графики в однопоточной ОС"? Нет, не вижу и не ощущаю. В качестве конечных продуктов я сравниваю исключительно майнось и опенось. Майнось - это абсолютно готовая опубликованная система, имеющая подробную документацию и регулярно поддерживаемая со стороны разработчиков, а версия Standalone была написана в виде эксперимента, и я понятия не имею, что тебя в ней так зацепило. Как я писал в своем изначальном сообщении, она отличается независимостью от базовых скриптов опеноси практически без потери функционала последней. Напомню также, что целью эксперимента было доказать, что буквально пара часов простого скриптинга отделяет майнось от полного соответствия термину "операционная система", и что данный термин крайне переоценен. Собственно, доказательство я считаю вполне успешным, а вот зачем пилить документацию к фановому эксперименту - убей не понимаю Если тебе нужен копипаст программными средствами, то он ничем не отличается от такового на опеноси, благо либа filesystem у них эквивалентна: filesystem.copy(fromPath: string, toPath: string): boolean or nil, string К слову, твой пример не универсален и работает медленнее, т.к. незачем затрагивать шелловские парсеры и тратить ресурсы на поиск скрипта. Вкусовщина. Использовать объектное UI или консоль - дело субъективное. И о каком сокрытом от человечества наброске речь? Майнось уже несколько лет как на рынке, а стенделон версия ничем от нее не отличается. Вы здоровы, батенька? Не можешь. Стандартная Lua io вынесена за пределы в опенкомповской песочнице в файле Machine.lua, а лишь затем заоверрайжена опеносовской версией.

Тем не менее, ты почему-то сравниваешь модули для оси с осью целиком. Модули, написанные мной, более легковесны, просты и лишены идиотического кода с генерацией тонны таблиц, так что да, они с куда большей охотой будут работать "на компе первого тира с минимальной планкой памяти". Если же говорить о самих осях, то я напомню, что опенось, имеющая элементарный интерфейс, в принципе не может иметь высоких требований. Откуда им взяться-то? Экранного буфера нет, вся отрисовка идет на прямых обращениях к GPU, объектно-ориентированного интерфейса нет, I/O-буфер жестко ограничен 512 байтами. Я бы удивился, если бы она не запускалась на первой плашке. Однако подобная простота критически уступает в производительности: при попытке отрисовать десктоп с несколькими приложениями через GPU ты вряд ли получишь больше 1 кадра в 3 секунды. Для серьезных графических систем требуется двойная буферизация графики, и даже при грамотной оптимизации библиотек экранный буфер будет жрать память, словно Скуби-Ду пончики на ярмарке. Сам посуди: экран третьего уровня имеет максимальное разрешение в 8000 псевдографических пикселей. Каждый пиксель - это цвета фона и текста по 3 байта каждый, а также символ в UTF-8, способный жрать вплоть до 4 байт памяти. Даже если взять идеальный случай, когда экран заполнен символами, занимающими в среднем 2 байта, выходит 64000 байт на один фрейм экранного буфера. А у него их два. Вот тебе и плашка памяти первого уровня, заполненная почти целиком. Повторюсь: ты сравниваешь несравнимое. Я что, утверждал обратное? Наоборот, я поддерживаю ту же точку зрения, контр-аргументируя товарищу нескольким сообщениями выше. Справедливости ради, ты и винду на атмегу не поставишь. Пожалуйста, хватит разводить полемику, сменяя тему на более "удобную". А сложность или простота разработки - понятие крайне относительное: для опеноси и опекомпов имеется OC Wiki, для майноси - документация по GUI. Лично мне не доставляет диких трудов вкратце ознакомиться с обоими источниками, чтобы сделать рабочий софт, ровно как и множеству авторов, выкладывающих свои творения в маркете. Стесняюсь спросить, что во фразе "результат разработки законсервирован до лучших дней" тебе не понятно? Во-первых, разумеется, при публикации, если она вообще произойдет, будет составлена полная документация по API. Во-вторых, разработанные либы крайне схожи с таковыми в опеноси, как по названию методов, так и по функционалу, так что переучиться не составит особого труда. Поверхностно судишь. Напомню о такой штуке, как социальная адаптация: ВК я общаюсь с людьми так, как они того заслуживают, без навязанных сверху ограничений и правил. Если человек адекватен, вежлив, не токсичен, то он получит аналогичную реакцию в ответ. В противном случае от приветов маме никто не застрахован. И если с тобой я вел себя не так, как ты ожидал/рассчитывал/желал - ну что ж. Мяу. Подтасовка фактов о трудозатратах на отсутствующую документацию к неопубликованному и никак не афишируемому софту, "законсервированному до лучших дней"? Интересная теория. А мне куда проще сделать ПКМ - Копировать, перейти в нужную директорию, ПКМ - Вставить, особенно это актуально для длинных путей, которые вручную вводить вообще не комильфо. Для любителей графического подхода и существует майнось, это уже вкусовщина на самом деле. Касаемо "огорода" мне хотелось бы подчеркнуть, что этот "огород" заранее огорожен авторами опеноси вместо тебя. Ты лишь пользуешься наиболее удобным результатом огораживания на основании собственных предпочтений, ровно как и при интерфейсном копировании файлов в майноси.

В целом - да, если не с первых, то с ранних релизов мы стали писать простенькие прожки, впоследствии ставшие основой текущего майносовского софта. Я могу даже точно сказать, когда именно, благо папка с игровыми скринами всегда под боком: Во-первых, в MineOS Standalone нет ни одного модуля из OpenOS. Откуда такие сведения вообще? Сомнительно, что можно поставить знак равенства между одинаковыми названиями модулей MineOS и OpenOS и их содержимым - все они были написаны с нуля с учетом собственных нужд. Во-вторых, трудозатраты на логическую часть, не связанную с интерфейсом и прикладным ПО, смехотворны и для OpenOS в том числе. Напомню, что OpenOS - это в первую очередь колоссальный набор скриптов для манипуляций с железом и взаимодействия с игровым окружением, и лишь во вторую - консольная текстовая оболочка со своей семантикой. Написание с нуля системно-библиотечной части с аналогичным OpenOS функционалом, а именно событийной либы с разномастными листенерами, либы для работы с файловой системой и виртуальными дисками, а также пакетной логики с последующей системной интеграцией лично для меня не составило никакого труда, и было завершено в указанные выше краткие сроки. Конкретизируй. Пустословить и оскорблять каждый горазд. Забавно: человек, дважды за сообщение контр-аргументирующий к тому, о чем я не говорил, обвиняет меня в подтасовке фактов. Я, вроде как, ни словом не обмолвился о наличии скопированных модулей из опеноси, а также не утверждал, что опенкомпы с опеносью - проще и менее универсальны, нежели майнось. И почему ты сравниваешь их вместе, а не по отдельности? С каких пор игровой мод стал сравним с софтом, написанном для этого мода? Тем не менее, продолжая нить беседы о софте для мода, я все равно не соглашусь: опенось крайне проста по концепции, и крайне усложнена в реализации. Система процессов бессмысленна в рамках однопоточной машины и лишь замедляет работу ПО, а для библиотек event/io/shell, не говоря уже о package с ее идеей отложенной подгрузки, идеально подойдет термин "over-engineered". Возможно, авторы слишком много работали с высоконагруженными системами и "взрослыми" языками, перестав видеть простые решения и пытаясь пропихнуть в массы устаревшие концепции из UNIX-систем. А, возможно, им просто по душе челленджи. В любом случае написать консольную операционную систему на чистой GPU и прикладной софт, работающий на крайне удобном API опенкомпов, сумеет каждый, не затратив при этом колоссальных усилий. Это не сложно. Совсем.

Я не понимать, что ты имеешь в виду

Ну... наверное, как и в любой другой контейнер? очко:addChild(GUI.layout(...)) Если требуется своеобразное переключение вкладок, то делай что-то типа этого: local GUI = require("GUI") local image = require("image") -------------------------------------------------------------------------------- local application = GUI.application() application:addChild(GUI.panel(1, 1, application.width, application.height, 0x0)) -- Окошечко для листа local window = application:addChild(GUI.filledWindow(40, 12, 80, 25, 0xE1E1E1)) -- Лист, содержащий кнопки-вкладки local list = window:addChild(GUI.list(1, 4, 22, window.height - 3, 3, 0, 0x2D2D2D, 0x696969, 0x2D2D2D, 0x696969, 0xE1E1E1, 0x2D2D2D)) -- Панель, визуально ограничивающая пространство скроллинга листа local listCover = window:addChild(GUI.panel(1, 1, list.width, 3, 0x2D2D2D)) -- Лейаут с содержимым вкладок local layout = window:addChild(GUI.layout(list.width + 1, 1, window.width - list.width, window.height, 1, 1)) -- Кнопки-вкладки local function addTab(text, doSomething) list:addItem(text).onTouch = function() layout:removeChildren() doSomething() application:draw() end end addTab("Показать пикчу", function() layout:addChild(GUI.image(1, 1, image.fromString([[0803D8EC00⣤D8EC00⣤D8EC00⣤D8EC00⣤D8EC00⣤D8EC00⣤D8EC00⣤D8EC00⣤FB7900⣤FB7900⣤FB7900⣤FB7900⣤FB7900⣤FB7900⣤FB7900⣤FB7900⣤185A00⣤185A00⣤185A00⣤185A00⣤185A00⣤185A00⣤185A00⣤185A00⣤]]))) end) addTab("Показать текст", function() layout:addChild(GUI.text(1, 1, 0x696969, "Я есть грут")) layout:addChild(GUI.text(1, 1, 0x696969, "И я тоже")) end) addTab("Показать кнопку", function() layout:addChild(GUI.adaptiveRoundedButton(1, 1, 2, 0, 0x969696, 0xFFFFFF, 0x696969, 0xFFFFFF, "Вдави меня полностью")) end) addTab("Ой, все", function() -- )))))))000 end) -- Поддержка скроллинга list.eventHandler = function(application, list, e1, e2, e3, e4, e5) if e1 == "scroll" then local horizontalMargin, verticalMargin = list:getMargin() list:setMargin(horizontalMargin, math.max(-list.itemSize * (#list.children - 1), math.min(0, verticalMargin + e5))) application:draw() end end -------------------------------------------------------------------------------- -- Чтоб кнопочки окна были поверх всех объектов window.actionButtons:moveToFront() -- Отображаем сразу первую открытую вкладку list:getItem(1).onTouch() -- Запускаем приложуху application:start()

Почти. Для этого есть заранее заготовленный объект GUI.list, по факту представляющий из себя модифицированный GUI.layout с возможностью добавления кнопок-айтемов. А скролл осуществляется через методы setMargin/getMargin: local GUI = require("GUI") local image = require("image") -------------------------------------------------------------------------------- local application = GUI.application() application:addChild(GUI.panel(1, 1, application.width, application.height, 0x0)) -- Окошечко для листа local window = application:addChild(GUI.filledWindow(40, 12, 80, 25, 0xE1E1E1)) -- Лист и крышка, визуально ограничивающая скроллинг local list = window:addChild(GUI.list(1, 4, 22, window.height - 3, 3, 0, 0x2D2D2D, 0x696969, 0x2D2D2D, 0x696969, 0xE1E1E1, 0x2D2D2D)) local listCover = window:addChild(GUI.panel(1, 1, list.width, 3, 0x2D2D2D)) -- Кнопочки list:addItem("Я почти кнопка") list:addItem("И я тоже") list:addItem("И я того же мнения") -- Поддержка скроллинга list.eventHandler = function(application, list, e1, e2, e3, e4, e5) if e1 == "scroll" then local horizontalMargin, verticalMargin = list:getMargin() list:setMargin(horizontalMargin, math.max(-list.itemSize * (#list.children - 1), math.min(0, verticalMargin + e5))) application:draw() end end -- Чтоб кнопочки окна были поверх всех объектов window.actionButtons:moveToFront() -------------------------------------------------------------------------------- application:draw(true) application:start() Результат:

@MisterFunny01, мяу, я так и не услышал, какие же фичи "фиг найдешь". Предположу тогда, что все они задокументированы. Фон - это своеобразная защита от "пустоты", предотвращающая эффект наложения кадров экранного буфера в стиле Windows XP. Если его убрать, то получится следующее: Происходит это потому, что при перемещении окно отрисовывается в экранный буфер по новым координатам. Однако окно, отрисованное по старым координатам, никуда не делось - его нужно "стирать" или заливать каким-то цветом перед отрисовкой нового. Этой цели и служит фоновая панель, которая иметь любой цвет - хоть черный, хоть фиолетовый, лишь бы не прозрачный/отсутствующий. Напомню также, что OpenOS работает не с экранным буфером, а напрямую с компонентом GPU, поэтому в буфере не будут содержаться данные о пикселях, установленных OpenOS. Так что вдвойне логично иметь фоновую панельку для стирания фона. 1) Открываем документацию: https://github.com/IgorTimofeev/GUI 2) Кликаем в содержании на пункт GUI.object 3) Смотрим, что каждый объект имеет метод :remove() 4) Profit Ежели требуется закрывать окно при клике, скажем, на кнопку отмены, то: layout:addChild(GUI.adaptiveRoundedButton(1, 1, 2, 0, 0xB4B4B4, 0xFFFFFF, 0x969696, 0xB4B4B4, "Отмена")).onTouch = function() -- Удаляем объект окна window:remove() -- Отрисовываем изменения сначала в буфер, а затем уже на экран application:draw() end

Какие именно фичи интересуют? Какие фичи фиг найдешь? Создание окошка с кнопочками - дело пары минут, описанное в деталях в документации: local GUI = require("GUI") -------------------------------------------------------------------------------- -- Создаем главный контейнер с черной фоновой палелью local application = GUI.application() application:addChild(GUI.panel(1, 1, application.width, application.height, 0x0)) -- Добавляем окошко в главный контейнер local window = application:addChild(GUI.titledWindow(50, 22, 60, 14, "Акошко", true)) -- Добавляем лейаут размером 1х2 в окошко local layout = window:addChild(GUI.layout(1, 2, window.width, window.height - 1, 1, 2)) -- Задаем размеры горизонтальных рядов для лейаута layout:setRowHeight(1, GUI.SIZE_POLICY_RELATIVE, 1) layout:setRowHeight(2, GUI.SIZE_POLICY_ABSOLUTE, 2) -- Задаем режим выравнивание объектов для второго ряда по правому нижнему углу layout:setAlignment(1, 2, GUI.ALIGNMENT_HORIZONTAL_RIGHT, GUI.ALIGNMENT_VERTICAL_BOTTOM) -- ... направленние layout:setDirection(1, 2, GUI.DIRECTION_HORIZONTAL) -- ... расстояние между объектами layout:setSpacing(1, 2, 3) -- ... и отступ от правого нижнего угла layout:setMargin(1, 2, 2, 1) -- Доавляем текст в первый ряд лейаута layout:addChild(GUI.text(1, 1, 0x0, "Я оч большой и важный текст")) -- Меняем дефолтный ряд, в который будут добавляться объекты (можно через layout:setPosition(object), но лень) layout.defaultRow = 2 -- Добавляем кнопочки layout:addChild(GUI.adaptiveRoundedButton(1, 1, 2, 0, 0xB4B4B4, 0xFFFFFF, 0x969696, 0xB4B4B4, "Отмена")) layout:addChild(GUI.adaptiveRoundedButton(1, 1, 2, 0, 0xB4B4B4, 0xFFFFFF, 0x969696, 0xB4B4B4, "Еще тык")) -- При "тыке" на эту кнопочку комп будет вырубаться layout:addChild(GUI.adaptiveRoundedButton(1, 1, 2, 0, 0x696969, 0xFFFFFF, 0x969696, 0xB4B4B4, "Тык")).onTouch = function() require("computer").shutdown() end -------------------------------------------------------------------------------- -- Разово отрисовываем содержимое главного контейнера в принудительном режиме (для полной отрисовки буфера, вдруг опенось чет свое нарисует) application:draw(true) -- Начинаем обработку событий application:start() Результат:

во первых, чтобы была конкуретность, а во вторых MineOS это не ось, а граф.оболочка. Эта фраза уже бичом нервов стала, а чертовы доморощенные эксперты-казуисты продолжают лезть изо всех дыр. Элементарная ОСь на платформе опенкомпов состоит буквально из нескольких сот строк кода, реализующих методы работы с файловой системой, позволяющих монтировать физические дисковые носители, грузить библиотеки по предустановленным путям, обрабатывать события и имитировать многозадачность. Все остальное - это графическая оболочка, в моем случае состоящая из десятка тысяч строк кода, вылизанных до предела, чтобы уложиться в строгие рамки ресурсов, выделенных под каждую виртуальную машину в кубаче. Интерфейс майноси с базовым прикладным софтом по типу проводника/настроек/пикчредакторов/магазинов/IDE мы писали с большой командой товарищей около четырех с фигом лет, постоянно его совершенствуя. Эксперимента ради я решил отвязать майнось от опеноси, сделав ее полностью независимой. Это заняло несколько часов. Ценой нескольких, мать их, часов, а также нескольких написанных либ суммарным объемом в две сотни строк майнось стала полностью удовлетворять определению "операционная система", загружаясь с очищенного от скверны жесткого диска и собственного EEPROM. Результат лежит на отдельном репозитории, законсервированный до лучших дней: https://github.com/IgorTimofeev/MineOSStandalone А теперь скажи мне, умник, не кажется ли тебе странным, что вся "ось" пишется на коленке за несколько часов, а "граф. оболочка" - пускай и не годами, но в значительно большие сроки? Может быть, термин "ось" переоценен, и основу современной интерфейсной операционной системы составляет все же графическая оболочка c прикладным софтом? Эх, мяу

@MisterFunny01, звучит несколько странно, но ладненько.

@MisterFunny01, меня полностью устраивают текущие иконки, я не собираюсь менять их из-за чьей-либо нетолерантности к мату. Все фиксы грамматических ошибок машинного перевода можно без проблем кинуть пулл реквестом на гит, если есть желание, я только рад буду. Что за установщик? Установщик чего? Установщик модифицированной оси с "православными" иконками без мата что ли? Повторюсь: мне подобные изменения не по нраву, сам кодь что пожелаешь, но меня не впутывай, мяу. Что за расположение ядра? Нет у оськи никакого ядра, либа "MineOSCore" названа так чисто по приколу, для симуляции "научности". Что подразумевается под "непереведенными" штуками? Настройки, да и вообще все локализованные приложения, с самого начала поддерживают все четыре системных языка, в том числе и украинский: Насчет прог для робота/дрона - их нет, я мало с роботами работал. Есть сборная солянка простеньких скриптов, оставшихся после выживания на сервере с поцыками, но никакой работоспособности не гарантируется: https://github.com/IgorTimofeev/MineOS/tree/master/Applications/Robot https://github.com/IgorTimofeev/MineOS/tree/master/Applications/DroneGrief https://github.com/IgorTimofeev/MineOS/tree/master/Applications/Drone farmer

Кстати о майноси: тут несколько занятных софтин подъехало. Например, YobaКалькулатрон9000, как его окрестил товарищ-шестиклассник. Умеет почти все: от работы с различными системами счисления и побитового редактирования чисел до базовых бинарно-тригонометрических операций с отображением символа по его коду. Во-вторых, слегка обновился местный проводник, заимев удобную панель навигации по текущему пути с кликабельными подпунктами а-ля Винда. Ну, и всякие кнопочки для ручного ввода пути появились, а также фича ресайза тулбара: Ну, и наконец не шибко сложная, однако довольно полезная в быту возможность интерфейсного привата компа по аналогии с useradd:

@MisterFunny01, та делай шо хочешь, хоспаде, не жалко ж. Только в маркете, скорее всего, заминусуют, после чего он публикация автоматом удалится

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

Если требуется получать время именно через интернет, то нет смысла поднимать собственный сервер, благо имеется тонна бесплатных API, мяу: -- Запрашиваем время у сервера в формате JSON local time = "" for chunk in require("internet").request("http://worldclockapi.com/api/json/utc/now") do time = time .. chunk end -- Выковыриваем timestamp в виде миллисекунд time = time:match("currentFileTime\":(%d+)") -- Обрезаем до секунд, т.к. 32-битная архитектура не поддерживает числа таких размеров time = tonumber(time:sub(1, -8)) -- Корректируем часовой пояс до требуемого. Москва - UTC+3. Один час - 3600 секунд time = time + 3 * 3600 -- Профит print("Времечко: " .. os.date("%H:%M:%S", time)) -- Можно и покомпактнее -- print("Времечко: " .. os.date("%H:%M:%S", tonumber(time:match("currentFileTime\":(%d+)"):sub(1, -8)) + 3 * 3600))

О, как раз на днях сеструха подобное писала, впервые осваиваясь в опенкомпах, да и майне в целом. Ах, какой пекрасный мир ее ждет впереди! Кстати, отображение времени работы можно выводить в более удобном виде ЧЧ:ММ:СС, если есть желание: print("Времечко: " .. os.date("%H:%M:%S", computer.uptime()))

@Asior, дык это, написано ж: file does not exists. Стопудова ты музло в корень диска положил, а запускаешь по относительному пути без /, находясь в /home/

Дык любой аргумент исходит от субъекта бытия, от индивида, лишь пытающегося познать и осознать внешний объективный мир. Любой аргумент есть субъективизм

dafaq!1111

@Fronun, мяу, однако ты ознакомлен с tonumber(), правда? Правда-правда?

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

Я уже описал свое видение ситуации самим перечислением проблем. Если нужна конкретика, то: Упразднить правила. Чем больше запретов и ограничений - тем меньше желания их изучать, им подчиняться и следовать, тем больше желания найти более достойный игровой проект. Большая часть местных правил абсурдна донельзя и обоснована по принципу, схожему с воспитанием ребенка: "потому что я так сказал и так считаю верным". Сейчас не 2014 год, челядь постепенно умнеет, и подобный принцип уже "не канает" Реализовать систему демократичного саморегулирования (votemute, votekick и т.п.) для минимизации человеческого фактора в лице предвзятых модераторов, да и вообще автоматизировать большинство модерационных процессов, как это сделано на всяких вортексах, террафирмах, экскалибурах и прочих. И только попробуй, @moderator, сказать что-нибудь насчет рекламы сторонних сервисов, смешно уже Разработать универсальный самописный гуишный мод для покупки донат-шмота, привата, чтения правил и инфы об ивентах, интеграции с сошл медиа и для минимизации локальных серверных чат-команд, как это сделано на дримаче. Если нет соответствующих навыков мододела - максимально кастомизировать существующие плагины для удобства или написать собственные Свести к минимуму искусственные ограничения контента, доступного "из коробки", не вводить собственных механик для кастомизации привычного геймплея с наиболее популярными модами, либо вводить их на высшем уровне с переписыванием мода и подробными интерфейсными гайдлайнами вместо "you don't allowed to do that" Вместо запрета имбалансного шмота, дюп-шмота или лаго-шмота писать фиксы модов самостоятельно или заказывать их на форж-форумах Мини-игры, регулярные ивенты и любые средства массового развлечения с системой поощрения победителей ДОЛЖНЫ присутствовать на любом сервере, заинтересованном в своей аудитории и привлечении новой. Старперам и олдфагам, возможно, подобное кажется глупым, однако школьники с толстыми кошельками категорически не согласятся Ни в коем случае не наказывать игроков за багоюз, а наоборот щедро поощрять рапортующих и публично афишировать свои намерения о поощрении. Недочеты и геймплейные дыры - это неучтенный фактор, ответственность за который лежит на плечах администрации. Фиксы, фиксы и еще раз фиксы Создать грамотную донат-систему и уметь играть в маркетолога, способного "продать воздух", не перегибая при этом палку. Максимально кастомизировать привилегии донатеров вплоть до emoji в чате и воспроизведения кастомных звуков а-ля дота+, создавать модели именного оружия и брони, разыгрывать их в местных рулетках и ивентах, просторы творчества тут бесконечны Наконец, необходим современный информативный сайт с картой сервера, донат-разделом, техподдержой в реальном времени и, в качестве приятного дополнения, форумными фичами, наградами и т.п. Но никак не классический форум с фиг-пойми-где запрятанной инфой а-ля 2000-ые в современной обертке Подытоживая, скажу, что ваша аудитория - это ваш хлеб, ваша честь и слава, ваша популярность. Поиграв на данном проекте, я увидел если не наплевательское, то, как минимум, безразличное к ней отношение с позицией "соблюдай правила или катись" вместо "клиенты - наше все, мы стремимся максимально адаптироваться и идти навстречу каждому". Зато как кодерский русскоязычный форум для ценителей узкой специфики он хорош, да, не спорю.

Я бы еще добавил, что местная система правил, модерации, искусственных ограничений и токсичность закоренелых игроков быстро отпугивает потенциальную аудиторию. Вспомнить, к примеру, концепцию покупки профессий за "голосовальную" валюту, чтобы получить доступ к стоковому функционалу индастриала или стильно-модно-молодежный мир "Улей" без графонистого спавна с блекджеками и средствами развлечения - бр-р-р! Лично я бы на подобном сервере играть в выживалку не стал и никому бы не посоветовал, в особенности типовым школярам, у которых требования гораздо более высоки ввиду наличия тонны серваков с аналогичным мод-листом и куда более лояльным порогом вхождения.

Ашыпка!1

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