Только в случае, например, с интерфейсом ОС ты что-то можешь потерпеть
Или, вполне возможно, пойти и нагуглить исправление, решение или сменить компоненты, что рисуют его неправильно. А у меня на ПК на Windows при включении любоого монитора рандомного отваливается таскбар на трехмониторной конфигурации. Что мне делать?
Меня оно ни разу не спасало. Во первых, когда оно действительно нужно, никогда актуальной точки под рукой нет, а в тот единственный раз, когда была - не помогла. Впрочем, возможно это только мой негативный опыт, и у остальных все в порядке. Но для меня в текущей ситуации появление какой-то серьёзной проблемы с виндой = переустановка, потому, что на попытки исправления чего-то уйдет значительно больше времени и зачастую это приведет к еще большей нестабильности системы (в то время как переустановка с нуля чаще всего гарантирует исправление проблемы). Такой же подход, каюсь, проповедую, когда мне приносят какое-то сломанное устройство на винде, ведь, учитывая информационную грамотность (точнее ее отсутствие) у большинства пользователей, пытаться что-то править в их системах гиблое дело. Однако шанс того, что что-то можно исправить на линуксе у меня гораздо выше - большинство проблем действительно поправляются, хотя, конечно исключать ситуацию, как в комментарии выше тоже нельзя, ведь всегда что-то может пойти не так. P.S. Это мой опыт, и если у вас ваш отключается в позитивную сторону: всегда апдейты винды ничего не ломают, точки восстановления работают или сброс системы "до заводских" штатными средствами системы (без переустановки с нуля) не приводит к появлению в системе необычных неопознаваемых багов - это прекрасно.
в случае проблем у юзера, нагуглить решение для windows намного вероятнее
Скорее вероятнее нарваться на очередную статью про "обновите дрова", "запустите scf scannow", "запустите dism /online", "не помогло - переустанавливайте винду". Я бы сказал, что найти работающее решение проблемы на линуксе гораздо проще, даже не смотря на то, что проблема/ос менее распространена.
Если нужно постоянно держать синхронизированной какую-то папку с файлами, то можно воспользоваться Synthing, который позволяет быстро сделать то, что требуется. Кстати, должен работать и в отсутствии интернета, устройствам достаточно быть в локальной сети.
Лучше иметь на выбор пачку сред рабочего стола, среди которых можно выбрать. Причем в большинстве которых можно поменять очень многое через GUI, а то что нельзя, наверняка можно поменять через какую-то xml'ку или код, чем иметь одну среду рабочего стола, в которой все настройки ограничены куцыми переключателями в GUI, и то, что там отсутствует поменять нельзя практически никак.
А на счет "анализа" программы, может конкретно вы этого делать и не будете, но это регулярно делают множество пользователей кроме вас. Интересно, в выборе между любой (но не я) может посмотреть код программы на предмет безопасности и никто не может посмотреть код программы на предмет безопасности, что вы выберете?
Да нет, достаточно давно все уже есть - Qt на C++ способен в запуск на большинстве популярных платформ. На Mono был Xamarin. С появлением .Net Core - Avalonia, с появлением .Net 5 - MAUI.
Несмотря на то, что основным языком Minecraft является Java — возможность писать моды на Lua есть. Инструментарий довольно обширный.
Основных ModAPI для майнкрафта, по факту, 2 — Forge и, с недавнего времени, Fabric. Оба используют для написания модов Java.
Писать что в майнкрафте на LUA можно только в одном случае — это компьютеры из OpenComputers/ComputerCraft (так-же я нашел некоторые упоминания пары модов, который интерпретировали вводимые в консоль LUA команды, но, судя по всему они все давно заброшены, да и по факту это скрипты, а не моды), но тем не менее на выходе получаешь всю ту-же "черную консоль" (Мы сейчас не будем говорить про MineOS и что-то подобное, ибо начинающий не будет писать свою графическую подсистему, как минимум), но при этом у тебя нет ни нормальной IDE, ни отладчика, да и API у них немного странный.
Поэтому простой ответ на вопрос — можно ли писать моды для майнкрафта на LUA — нет, нельзя.
поменять поведение какого-то предмета
Что поменять поведение уже, скорее всего, понадобится ASM.
В модах же много чего можно сделать на начальном уровне.
Ага, конечно. Для начала нужно вдумчиво покурить мануалы и доки по Forge/Fabric (не надейтесь на хорошую документацию), потом покопаться в API и найти что же нужно изменить для получения желаемого эффекта.
В итоге чаще всего большинство останавливается на каком-нибудь простом добавлении своего блока/предмета, ведь что бы сделать что-то большее зачастую нужны уже глубокие познания в API, ООП и многое другое.
Моды для майнкрафта пишутся на Java. Да и в принципе написание хоть сколь-нибудь что-то делающего мода — задача достаточно нетривиальная, новичку разобраться в ней будет крайне сложно.
Такое реализовывалось для WPF MVVM фреймворком MugenMVVMToolkit, который стал для меня незаменим при разработке WPF приложений. Там вообще можно было делать что-то такое и оно будет прекрасно работать: Text $string.Join($Environment.NewLine, $GetErrors())
Я связывался с автором MugenMVVMToolkit, он сказал что посмотрит в сторону портирования его для Avalonia.
Да, у нас, наверное, нет 100% соответствия гайдлайнам, однако мы стараемся придерживаться их.
Распишите, пожалуйста, конкретнее ваши замечания здесь, или, что будет еще лучше — оформите их в качестве ишью.
Было бы славно еще освоить гит и публиковать код нормально, а не архивом, загруженным в репозиторий.
Или, вполне возможно, пойти и нагуглить исправление, решение или сменить компоненты, что рисуют его неправильно.
А у меня на ПК на Windows при включении любоого монитора рандомного отваливается таскбар на трехмониторной конфигурации. Что мне делать?
Меня оно ни разу не спасало. Во первых, когда оно действительно нужно, никогда актуальной точки под рукой нет, а в тот единственный раз, когда была - не помогла. Впрочем, возможно это только мой негативный опыт, и у остальных все в порядке. Но для меня в текущей ситуации появление какой-то серьёзной проблемы с виндой = переустановка, потому, что на попытки исправления чего-то уйдет значительно больше времени и зачастую это приведет к еще большей нестабильности системы (в то время как переустановка с нуля чаще всего гарантирует исправление проблемы). Такой же подход, каюсь, проповедую, когда мне приносят какое-то сломанное устройство на винде, ведь, учитывая информационную грамотность (точнее ее отсутствие) у большинства пользователей, пытаться что-то править в их системах гиблое дело.
Однако шанс того, что что-то можно исправить на линуксе у меня гораздо выше - большинство проблем действительно поправляются, хотя, конечно исключать ситуацию, как в комментарии выше тоже нельзя, ведь всегда что-то может пойти не так.
P.S. Это мой опыт, и если у вас ваш отключается в позитивную сторону: всегда апдейты винды ничего не ломают, точки восстановления работают или сброс системы "до заводских" штатными средствами системы (без переустановки с нуля) не приводит к появлению в системе необычных неопознаваемых багов - это прекрасно.
Скорее вероятнее нарваться на очередную статью про "обновите дрова", "запустите scf scannow", "запустите dism /online", "не помогло - переустанавливайте винду".
Я бы сказал, что найти работающее решение проблемы на линуксе гораздо проще, даже не смотря на то, что проблема/ос менее распространена.
Если нужно постоянно держать синхронизированной какую-то папку с файлами, то можно воспользоваться Synthing, который позволяет быстро сделать то, что требуется. Кстати, должен работать и в отсутствии интернета, устройствам достаточно быть в локальной сети.
Лучше иметь на выбор пачку сред рабочего стола, среди которых можно выбрать. Причем в большинстве которых можно поменять очень многое через GUI, а то что нельзя, наверняка можно поменять через какую-то xml'ку или код, чем иметь одну среду рабочего стола, в которой все настройки ограничены куцыми переключателями в GUI, и то, что там отсутствует поменять нельзя практически никак.
А на счет "анализа" программы, может конкретно вы этого делать и не будете, но это регулярно делают множество пользователей кроме вас. Интересно, в выборе между любой (но не я) может посмотреть код программы на предмет безопасности и никто не может посмотреть код программы на предмет безопасности, что вы выберете?
Да нет, достаточно давно все уже есть - Qt на C++ способен в запуск на большинстве популярных платформ. На Mono был Xamarin. С появлением .Net Core - Avalonia, с появлением .Net 5 - MAUI.
Основных ModAPI для майнкрафта, по факту, 2 — Forge и, с недавнего времени, Fabric. Оба используют для написания модов Java.
Писать что в майнкрафте на LUA можно только в одном случае — это компьютеры из OpenComputers/ComputerCraft (так-же я нашел некоторые упоминания пары модов, который интерпретировали вводимые в консоль LUA команды, но, судя по всему они все давно заброшены, да и по факту это скрипты, а не моды), но тем не менее на выходе получаешь всю ту-же "черную консоль" (Мы сейчас не будем говорить про MineOS и что-то подобное, ибо начинающий не будет писать свою графическую подсистему, как минимум), но при этом у тебя нет ни нормальной IDE, ни отладчика, да и API у них немного странный.
Поэтому простой ответ на вопрос — можно ли писать моды для майнкрафта на LUA — нет, нельзя.
Что поменять поведение уже, скорее всего, понадобится ASM.
Ага, конечно. Для начала нужно вдумчиво покурить мануалы и доки по Forge/Fabric (не надейтесь на хорошую документацию), потом покопаться в API и найти что же нужно изменить для получения желаемого эффекта.
В итоге чаще всего большинство останавливается на каком-нибудь простом добавлении своего блока/предмета, ведь что бы сделать что-то большее зачастую нужны уже глубокие познания в API, ООП и многое другое.
Моды для майнкрафта пишутся на Java. Да и в принципе написание хоть сколь-нибудь что-то делающего мода — задача достаточно нетривиальная, новичку разобраться в ней будет крайне сложно.
Чёрное, как известно, и работает лучше
Скорее всего, если не делать что-то очень низкоуровневое, то столкнуться с тем, что что-нибудь перестало работать из-за обновлений не удастся.
Об этом я точно не знаю, лучше все-же задать этот вопрос в телеграме.
Такое реализовывалось для WPF MVVM фреймворком
MugenMVVMToolkit, который стал для меня незаменим при разработке WPF приложений. Там вообще можно было делать что-то такое и оно будет прекрасно работать:Text $string.Join($Environment.NewLine, $GetErrors())Я связывался с автором
MugenMVVMToolkit, он сказал что посмотрит в сторону портирования его для Avalonia.Это лучше спросить у kekekeks или в чате в телеграме или гиттере
Распишите, пожалуйста, конкретнее ваши замечания здесь, или, что будет еще лучше — оформите их в качестве ишью.