начну с небольшого предисловия.
Я старый манчкин. мне уо доставляла радость как академическая штука где можно програмно делать управление и многие другие крутости.
щас уже не играю, но память осталась.
Итак
Суть проблемы :
Императив. в это понятие я вложил то что по сути все действия происходят в один поток, и все изменения улавливаются только вызовом функций. конечно сейчас в полной мере можно обойтись тем что проверяются состояния на "граничных точках", когда чар закончил что то делать и готовится к следущей итерации. это неестественно, например в тех случаях если нужна скорость реакции(попробуйте представить скрипт который бы на бегу одновременно смотрел за врагами, хп, усталостью, и принимал на ходу действия)
Будьте ближе к реальному миру. в мире важны события. надпись в чате - событие. изменилась вещь - событие. пришол гамп - событие.
так как чар может одновременно и бежать и трекать, и включать\выключать боевой режим, на некоторых серваках и кастовать то можно предположить что будут рулить потоки...
вы думаете я щас несу бред который только усложнит всё, и не будут разрешимы ресурсы, блокировки и тд ?
а вот и нет. в Эрланге например такая же архитектура(собственно изучение этого прекрасного языка побудило меня написать тут).
итак фишка в том что программа состоит из легковесных процессов на уровне интерпретатора, которые обмениваются сообщениями. а еще фишка в том что язык функциональный(хвостовые рекурсии, паттерн-матчинг, и куча прочиш прелестей)
Forum in READ ONLY mode! All questions and discussions on Discord official server, invite link: https://discord.gg/VxsGzJ7
Вас правда всё устраивает ?
Re: Вас правда всё устраивает ?
соглашусь с тем, что императивный язык накладывает свои ограничения, но он и проще для начинающих, коих тут большинство и переучиваться на что-то новое, думаю, не горят желанием.
Но почти все из выше перечисленного реализуется и в рамках текущего состояния.
Я сделал нечто вроде нескольких потоков в рамках одного, которые могли запускаться и останавливаться по событиям производимх ими. Это конечно требует дополнительных усилий от программиста, но я думаю возможно написать фреймворк который будет соответствовать твоим требованиям, с некоторыми оговорками конечно.
Но почти все из выше перечисленного реализуется и в рамках текущего состояния.
Я сделал нечто вроде нескольких потоков в рамках одного, которые могли запускаться и останавливаться по событиям производимх ими. Это конечно требует дополнительных усилий от программиста, но я думаю возможно написать фреймворк который будет соответствовать твоим требованиям, с некоторыми оговорками конечно.
Потоки - это мечта. Недостижимая в стелсе, быстрее всего. Я пока себя ограничиваю только одной задачей - напрячь всех пишущих что-то для стелса сделать хотя бы одну следующую версию. С тем набором изменений, который много раз обсуждался и является наиболее востребованным (поддержка новых клиентов, правка ошибок, работа с мулами, встроенная удобная ходилка с трассировкой пути, обработка еще некоторых пакетов, трейд-окна). О прочем можно будет думать потом.
порадовали меня.. признатся не ожидал реакции вообще...
вы конечно правы что надо решать конкретные задачи по мере поступления.
Но так как тут тихо, я позволю себе немного поразмышлять о будущем. я уже задумывался какие можно языки использовать. Нравится питон. как лёгкий для новичков, и сильный для остальных но все его возможности применительно к уо - всеголишь синтаксический сахар..
чем мне приглянулся Эрланг в контексте УО: основная идея в том что потоков как таковых и нету!. главная фишка этого языка то что процессы(коих может быть миллионы) работают внутри интерпретатора и не едят ресурсов вообще. тоесть слушающий сигналы поток кушает даже меньше чем вечный цикл в идле. он просто не работает. также не бывает состояний гонок... и фактически у нас новая парадигма - процесс-ориентированное програмированье.
еще одна фишка потоков - они общаются по сигналам, которые могут накапливатся в очереди и все выполнится. как вы понимаете в функцилональном языке паттерн-матчинг это одно из краеугольных камней, и обработка любого сигнала это всеголишь "свич"
recieve
{signal1,Proc1,[D.,..]} -> сделать что то
{signal2,Proc2,[D.,..]} -> сделать что то другое.
с внешним миром интерпретатор общается через низкоуровневые интерфейсы на Си. опять же - фишка в что ненужна никакая синхронизация обращений к библиотекам и тд.
Такой может быть вариант применительно к стелсу:
реализовать стелс как Эрланг-поток(это вполне естественно и подробно описано в документации), который бы слал выполняющему потоку на уже чистом эрланге сигналы, любого рода.
стелс бы выглядел просто как модуль который бы дешифровывал траффик в осмысленные сигналы(любые изменения в мире), хранил бы обьекты, и декодировал сигналы(команды) в пакеты. и я описал только интерфейс.
что говорить о возможностях непосредственно скриптинга.
делаю пример на лету
крафтинг. я тут конечно очень сильно извратил. многие скажут - нам итак нравица 5 проверок в конце каждой итерации
вначале вызываем процессы которые полностью следят за количеством инградиентов в рюкзаке(по каждому инградиенту по процессу) - если код этого процесса написан должным образом, то о инградиентах мы вообще забываем. запускаем еще пару потоков контроля за едой и смертью, и всё, скрипт готов...
всё продумано вплоть до того что чар будет сам бегать за регами, ресаца, и кушать.
контролировать главным процессом могут впринципе все...
он также может вначале слушать, потом по таймауту, который может быть сразу - выполнятся непосредственно то что должен выпонять главный процесс.
вы конечно правы что надо решать конкретные задачи по мере поступления.
Но так как тут тихо, я позволю себе немного поразмышлять о будущем. я уже задумывался какие можно языки использовать. Нравится питон. как лёгкий для новичков, и сильный для остальных но все его возможности применительно к уо - всеголишь синтаксический сахар..
чем мне приглянулся Эрланг в контексте УО: основная идея в том что потоков как таковых и нету!. главная фишка этого языка то что процессы(коих может быть миллионы) работают внутри интерпретатора и не едят ресурсов вообще. тоесть слушающий сигналы поток кушает даже меньше чем вечный цикл в идле. он просто не работает. также не бывает состояний гонок... и фактически у нас новая парадигма - процесс-ориентированное програмированье.
еще одна фишка потоков - они общаются по сигналам, которые могут накапливатся в очереди и все выполнится. как вы понимаете в функцилональном языке паттерн-матчинг это одно из краеугольных камней, и обработка любого сигнала это всеголишь "свич"
recieve
{signal1,Proc1,[D.,..]} -> сделать что то
{signal2,Proc2,[D.,..]} -> сделать что то другое.
с внешним миром интерпретатор общается через низкоуровневые интерфейсы на Си. опять же - фишка в что ненужна никакая синхронизация обращений к библиотекам и тд.
Такой может быть вариант применительно к стелсу:
реализовать стелс как Эрланг-поток(это вполне естественно и подробно описано в документации), который бы слал выполняющему потоку на уже чистом эрланге сигналы, любого рода.
стелс бы выглядел просто как модуль который бы дешифровывал траффик в осмысленные сигналы(любые изменения в мире), хранил бы обьекты, и декодировал сигналы(команды) в пакеты. и я описал только интерфейс.
что говорить о возможностях непосредственно скриптинга.
делаю пример на лету
крафтинг. я тут конечно очень сильно извратил. многие скажут - нам итак нравица 5 проверок в конце каждой итерации
вначале вызываем процессы которые полностью следят за количеством инградиентов в рюкзаке(по каждому инградиенту по процессу) - если код этого процесса написан должным образом, то о инградиентах мы вообще забываем. запускаем еще пару потоков контроля за едой и смертью, и всё, скрипт готов...
всё продумано вплоть до того что чар будет сам бегать за регами, ресаца, и кушать.
контролировать главным процессом могут впринципе все...
он также может вначале слушать, потом по таймауту, который может быть сразу - выполнятся непосредственно то что должен выпонять главный процесс.
на самом деле это очень маленький и лёгкий язык
немножко на тему...
http://www.erlang.org/doc/reference_man ... esses.html
+у синганлов есть приоритеты..
тоесть если
recieve
{proc1}->
{proc2}->
даже если proc2 пришол раньше чем текущий процесс одуплился, выполнится всёравно proc1, если он есть
немножко на тему...
http://www.erlang.org/doc/reference_man ... esses.html
+у синганлов есть приоритеты..
тоесть если
recieve
{proc1}->
{proc2}->
даже если proc2 пришол раньше чем текущий процесс одуплился, выполнится всёравно proc1, если он есть
Обсуждение подключения других языков - почти оффтоп. Стелс использует паскаль скрипт и это не будет изменяться ни в каком ближайшем или не ближайшем будущем. Слишком там все увязано. Под другой интерпертатор надо фактически переписывать весь стелс. Так что рассуждения типа "неплохо бы перейти на другой язык" лучше даже не развивать.
Вообще, тема не в том разделе. Потом перенесу в Request.
Вообще, тема не в том разделе. Потом перенесу в Request.
да модульно однако...похоже ты не осилил мои сочинения. это не подключение других языков, это принципиально новая концепция, парадигма. впринципе да, я предлагаю переписать стелс с нормальной модульной, расширяемой архитектуройСтелс использует паскаль скрипт и это не будет изменяться ни в каком ближайшем или не ближайшем будущем. Слишком там все увязано.
ну собственно мне всёравно. просто представляет академический интерес. да и тема вроде имеет название.
когда надо будет на ходу принимать решение в зависимости от ситуации, я посмотрю какие костыли вы будете писать на вашем импиративном паскаль-скрипте со строгой типизацией )) так что потом уже будет позно.
крутая ходилка с поиском пути на пол-мира будет разве что поспособствует унылому перемещению трупика по карте, после встречи с любым красным животным
скажу как плэер, а, извините, нах это надо, чтоб стэлс всё делал за тебя...
кто играть в уо то будет ?
таким образом убиваем уо до конца, товарищи программисты, я понимаю что вам это интересно, но не стоит убивать игровой процесс, который единственный в мире и ни что не сравнится с ним.
а то: пусть стлс делает то, пусть делает это
зачем он нужен будет если никто не будет играть в уо потому что не будет интересен один макрос
пвп тоже на стэлсе ?...
мда...
кто играть в уо то будет ?
таким образом убиваем уо до конца, товарищи программисты, я понимаю что вам это интересно, но не стоит убивать игровой процесс, который единственный в мире и ни что не сравнится с ним.
а то: пусть стлс делает то, пусть делает это
зачем он нужен будет если никто не будет играть в уо потому что не будет интересен один макрос
пвп тоже на стэлсе ?...
мда...
ваша цель - убить игровой процесс
и чем это лучше игры руками?
растолкуй...
повторюсь - зачем нужен будет стэлс если будет один макрос и никто не захочет играть в уо, смысл от уо будет каков ?
тогда админам придётся лепить антимакросы, что собственно на многих шардах замечено.
разве это хорошо что чар сам бегает копает\рубает, скидывает ресы и ресается при необходимости?
да, базара нет, это радует, но в корне это не правильно !
и чем это лучше игры руками?
растолкуй...
повторюсь - зачем нужен будет стэлс если будет один макрос и никто не захочет играть в уо, смысл от уо будет каков ?
тогда админам придётся лепить антимакросы, что собственно на многих шардах замечено.
разве это хорошо что чар сам бегает копает\рубает, скидывает ресы и ресается при необходимости?
да, базара нет, это радует, но в корне это не правильно !
Возможно сделать подключение ерланга, через длл допустим, но Вам прийдеться самому обрабатывать входящие пакеты и пользоваться только теми функциями, для передачи команд на сервер, которые есть в скриптах.ParadoX wrote:да модульно однако...похоже ты не осилил мои сочинения. это не подключение других языков, это принципиально новая концепция, парадигма. впринципе да, я предлагаю переписать стелс с нормальной модульной, расширяемой архитектуройСтелс использует паскаль скрипт и это не будет изменяться ни в каком ближайшем или не ближайшем будущем. Слишком там все увязано.
ну собственно мне всёравно. просто представляет академический интерес. да и тема вроде имеет название.
когда надо будет на ходу принимать решение в зависимости от ситуации, я посмотрю какие костыли вы будете писать на вашем импиративном паскаль-скрипте со строгой типизацией )) так что потом уже будет позно.
крутая ходилка с поиском пути на пол-мира будет разве что поспособствует унылому перемещению трупика по карте, после встречи с любым красным животным
Попробуйте для начала потренироваться на гендальфе, там автор для меня делал плагин памп, к которому можно подключиться по TCP/IP и получать и отправлять пакеты ввиде хекса-текста.
в общем я начал разработку. чар уже вобщем то логинится на сервер, правда там где нет энекрипшена...
так как я представил работу в голове, получается вполне неплохо...
основные концепции скриптов это то что чар реагирует на события мира, хотя есть возможность выполнять последовательности действий.
каждый скрипт это модуль, которой будет работать как поток в эрланг-потоке. с подключением его ему можно дать доступ слушать сообщения чата, сообщения итемов, движения - по одному контроллеру этих вещей. тоже в эрланг-потоках.
можно сделать полную независимость. пока чар идёт, трекать врагов, и выполнять что то. это будет асинхронная хотьба.. можно конечно сделать синхронные действия, которые будут перекрывать всё.
вобщем идея состоит в том что "скрипт" это что то вроде конечного автомата. и всё зависит только от состояния чара, а не от строки вашего паскаля, или бейсика.
кто хочет может присоединится к проекту. стучите в асю
так как я представил работу в голове, получается вполне неплохо...
основные концепции скриптов это то что чар реагирует на события мира, хотя есть возможность выполнять последовательности действий.
каждый скрипт это модуль, которой будет работать как поток в эрланг-потоке. с подключением его ему можно дать доступ слушать сообщения чата, сообщения итемов, движения - по одному контроллеру этих вещей. тоже в эрланг-потоках.
можно сделать полную независимость. пока чар идёт, трекать врагов, и выполнять что то. это будет асинхронная хотьба.. можно конечно сделать синхронные действия, которые будут перекрывать всё.
вобщем идея состоит в том что "скрипт" это что то вроде конечного автомата. и всё зависит только от состояния чара, а не от строки вашего паскаля, или бейсика.
кто хочет может присоединится к проекту. стучите в асю