Хотелось бы понять....

[SAdTN]

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

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

Понятно, что создание большого программного проекта связано и тем, что в него будут вкрадываться ошибки, это естественное явление. С версией 6.0.0 стали заметны и попытки отловить фатальные вылеты программы, когда предлагается заполнить окно аварийного вылета информацией пользователя и это шаг в правильном направлении. Кстати, хочется напомнить, что версия 4.х.х к концу своего существования была доведена до очень стабильного состояния, но вот 5.х.х - это было нечто жуткое. Наверняка работа над 4-й версией могла выявить причины падений, обычные ситуации их возникновения. Навскидку можно предположить, что в большинстве случаев это некорректности работы с памятью, прямые или косвенные, например, в операциях ввода-вывода.

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

Задам еще несколько вопросов, вызывающих недоумение.

---------- Сообщение добавлено в 20:26 ---------- Предыдущее сообщение было в 20:23 ----------

Хотелось бы понять, почему за год работы, с самого начала 5-й версии и, соответственно, модификации ЦС телепорты на них работают через пень-колоду? Точнее, то работают, то бежишь к нему, но никакой шестерёнки на нём нет и в помине. И давай релогайся на этом месте с непонятно какой стати. Логика работы тут проста как мычание:

if ((Персонаж в бою) or (Персонаж по любым причинам в инвизе)) then
exit // Выйти из обработчика
else
Выполнить телепортация
endif

Персонаж в бою - вы прекрасно диагностируете это наличием скрещенных мечей на иконке персонажа. Персонаж в инвизе из-за классовых умений или за счет использования синей умелки маунта - всё это визуально отображается и, следовательно, доступно программистам. И умудрится за год не исправить то, чем пользуются подавляющее большинство игроков??? Вот как это так??? И, к слову, европейская версия игры (хотя можно ли сейчас вообще говорить о европейской версии...) в этом месте работает лучше, хотя далеко не на 100%. Народ и там высказывается по этому поводу на большом количестве языков. Вы что, присваиваете программистам звания "Программист-пофигист" 1-го, 2-го, 3-го классов, за которые они в поте лица борются??? И сколько еще сезонов игроки должны матерится, подходя к телепортам ЦС?

Честное слово, вот уже без всяких эмоций, вот просто уже интересен ответ на этот вопрос с проффесиональной точки зрения.

---------- Сообщение добавлено в 20:29 ---------- Предыдущее сообщение было в 20:26 ----------

Хотелось бы понять, выписана ли премия программистам, реализовавшим новую версию некроманта за их творческий вклад в развитие идей некритянского классдизайнера? Как можно понять, некрам "предложили" (практически пинками) новую умелку для набора крови - венесекцию, которая должна работать за счет жизни самого некра (это вообще новое слово в теории и практике вампиризма, ну да ладно), давая кровь и понижая жизнь со 100% до 35%. Что-то типа:

if ((Текущее ХП персонажа / Максимально возможное ХП персонажа) > 0.35) then
Отработка венесекции
endif

Программисты прекрасно эту мысль продолжили, не реализовав проверку начального уровня здоровья персонажа. Действительно, что стоит игроку посчитать в бою, сколько процентов составляет какое-нибудь текущее 282365 от 809432 ? Ну, а не подсчитали процент - сами и виноваты. Тут уж чемодан - вокзал - чистилище... Нечего клювом щелкать... или что там у некров есть. По крайней мере, венесекция прекрасно работает и при здоровьи некра меньше 35%. Честно, вот хотелось бы увидеть комментарий программиста-разработчика к этой части программы.

[nekromail2011]

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

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

Понятно, что создание большого программного проекта связано и тем, что в него будут вкрадываться ошибки, это естественное явление. С версией 6.0.0 стали заметны и попытки отловить фатальные вылеты программы, когда предлагается заполнить окно аварийного вылета информацией пользователя и это шаг в правильном направлении. Кстати, хочется напомнить, что версия 4.х.х к концу своего существования была доведена до очень стабильного состояния, но вот 5.х.х - это было нечто жуткое. Наверняка работа над 4-й версией могла выявить причины падений, обычные ситуации их возникновения. Навскидку можно предположить, что в большинстве случаев это некорректности работы с памятью, прямые или косвенные, например, в операциях ввода-вывода.

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

Задам еще несколько вопросов, вызывающих недоумение.

---------- Сообщение добавлено в 20:26 ---------- Предыдущее сообщение было в 20:23 ----------

Хотелось бы понять, почему за год работы, с самого начала 5-й версии и, соответственно, модификации ЦС телепорты на них работают через пень-колоду? Точнее, то работают, то бежишь к нему, но никакой шестерёнки на нём нет и в помине. И давай релогайся на этом месте с непонятно какой стати. Логика работы тут проста как мычание:

if ((Персонаж в бою) or (Персонаж по любым причинам в инвизе)) then
exit // Выйти из обработчика
else
Выполнить телепортация
endif

Персонаж в бою - вы прекрасно диагностируете это наличием скрещенных мечей на иконке персонажа. Персонаж в инвизе из-за классовых умений или за счет использования синей умелки маунта - всё это визуально отображается и, следовательно, доступно программистам. И умудрится за год не исправить то, чем пользуются подавляющее большинство игроков??? Вот как это так??? И, к слову, европейская версия игры (хотя можно ли сейчас вообще говорить о европейской версии...) в этом месте работает лучше, хотя далеко не на 100%. Народ и там высказывается по этому поводу на большом количестве языков. Вы что, присваиваете программистам звания "Программист-пофигист" 1-го, 2-го, 3-го классов, за которые они в поте лица борются??? И сколько еще сезонов игроки должны матерится, подходя к телепортам ЦС?

Честное слово, вот уже без всяких эмоций, вот просто уже интересен ответ на этот вопрос с проффесиональной точки зрения.

---------- Сообщение добавлено в 20:29 ---------- Предыдущее сообщение было в 20:26 ----------

Хотелось бы понять, выписана ли премия программистам, реализовавшим новую версию некроманта за их творческий вклад в развитие идей некритянского классдизайнера? Как можно понять, некрам "предложили" (практически пинками) новую умелку для набора крови - венесекцию, которая должна работать за счет жизни самого некра (это вообще новое слово в теории и практике вампиризма, ну да ладно), давая кровь и понижая жизнь со 100% до 35%. Что-то типа:

if ((Текущее ХП персонажа / Максимально возможное ХП персонажа) > 0.35) then
Отработка венесекции
endif

Программисты прекрасно эту мысль продолжили, не реализовав проверку начального уровня здоровья персонажа. Действительно, что стоит игроку посчитать в бою, сколько процентов составляет какое-нибудь текущее 282365 от 809432 ? Ну, а не подсчитали процент - сами и виноваты. Тут уж чемодан - вокзал - чистилище... Нечего клювом щелкать... или что там у некров есть. По крайней мере, венесекция прекрасно работает и при здоровьи некра меньше 35%. Честно, вот хотелось бы увидеть комментарий программиста-разработчика к этой части программы.

Все не так просто как вы тут описываете.

если для каждой механики писать код в клиент\сервер, то упоротся можно.

есть xdb шки, их более 200к+, не скажу точно сколько.

клиент\сервер хавает что там написано и запускает один "обработчик xdbшек" каждый раз, как ему подсовывают новую xdb шку

и это вам не программка на паскале сложить два числа, чтобы не падать. В том же сервере 2кк сток java кода, и где угодно может что-то пойти не так, из-за чего весь остальной результат не сложится и программе придется упасть

все то, что вы пишите, происходит на стороне сервера, проверка комбата персонажа, умений(венисекция)
как можно рассуждать о таких вумных вещах, не понимая концепции "клиент ->>> сервер"?


в клиенте только рисуется красивая картинка, все проверки\подсчеты только на сервере.


Да, физика и просчет ВСЕХ координат персонажей лежит в АО на клиенте, вот это и печально.
но то, что вы описываете, там точно нету(скорее всего)

---------- Сообщение добавлено в 23:02 ---------- Предыдущее сообщение было в 22:55 ----------

if ((Персонаж в бою) or (Персонаж по любым причинам в инвизе)) then
exit // Выйти из обработчика
else
Выполнить телепортация
endif

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

ХавательХдбшек("хдбшки\цс\телепорт.xdb")
(* работает хавательхдбшек *)
(* хаваем из хдбшек условия *)

вызываем функию проверки состояния персонажа в бою
и проверяем условие_1, которое мы скавали из xdb шки

if(avatarInCombat = false(подставляем сюда условие из хдбшки)) then
Телепортация
ждем...
if телепортация = удачно, то
ответ_на_клиент(и тут пошла инфа о изменении локации и новый координат аватара)

[SAdTN]

Все не так просто как вы тут описываете.

Конечно, если иметь в виду то, что у меня написан некий псевдокод, понятный подавляющему большинству программистов. Конкретная ревлизация для данного проекта будет на языке проекта, который мне не известен, я не разработчик АО.

Главное, на что хотелось обратить внимание, так это на логику соответствующих обработчиков событий.

и это вам не программка на паскале сложить два числа, чтобы не падать. В том же сервере 2кк сток java кода, и где угодно может что-то пойти не так, из-за чего весь остальной результат не сложится и программе придется упасть

Намёк понял
Тогда скажу, что не знаю, как складывать числа на Паскале. Больше всего программ пришлось писать на Си, причём какое-то время и на японскую софтверную фирму. На Си - больше всего, но приходилось сталкиваться и с другими языками, в том числе Perl и PHP, которые, надеюсь, вы не будете отрицать, предназначени именно для клиент-серверной архитектуры.

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

Но вот в данном случае какая разница, кто на чём пишет и сколько строк кода написано? Речь в данном случае идет о нарушении логики работы программы, т.е. о багах. И ладно было бы что-то сверхсложное.... Обнаружился как-то баг, который вносил компилятор Watcom C, когда в одном редком случае неправильно передавал параметры процедур.... Но тут-то что?

Баг с телепортом на ЦС висит ГОД. Целый ГОД игроки топ лвл ВСЕХ серверов ходят по граблям. Ага, вот наши взяли последнее место силы на ЦС, быстрее сдать квесты... и хлоп тебе по фейсу, телепорт не работает. Быстрее перезайти.... а тут уже и ситуация изменилась, и не факт, что тебя после релога не встретит "дружеский" моб и не вынудит выяснять с ним отношения...

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

в клиенте только рисуется красивая картинка, все проверки\подсчеты только на сервере.

Да, физика и просчет ВСЕХ координат персонажей лежит в АО на клиенте, вот это и печально.

но то, что вы описываете, там точно нету(скорее всего)

В этих фразах точно нет никаких противоречий???

Но неважно. По здравому смыслу на каждое конкретное событие у вас должен быть один обработчик этого события, если вы не хотите получить не 2, а 22 КК строк кода и привести программу в непригодное для сопровождение состояние. И совершенно не важно, реализован этот обработчик в виде отдельного программного модуля, ddl или хдбшки. Программист по любому пишет код на языке высокого уровня. И вот почему не включить вот в этот программный код достаточно элементарную проверку, может ли персонаж телепортироваться или нет, вот честное слово, не понимаю. Просто в самом начале обработчика проверить, нет ли препятствующих телепортации условий? Есть хоть одно условие - выход из обработчика. Нет препятствующих условий - безусловный телепорт. То, что сейчас мы там имеем возможность ощущать на своей щкуре, говорит только об одном - о хаосе в программном коде этого фрагмента. Вот 100% гарантия, что это так. Обратите внимание - другие телепорты нормально работают. Проблема - только в локальной системе телепортации на ЦС.

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

И проверить это можно хоть на сервере, если обработчик находится на сервере, или на стороне клиента, где есть ВСЯ необходимая для проверки информация (и состояние здоровья некра - смотри числа текущей и максимальной ХП на иконке, и факт нажатия на иконку включения/выключения венесекции - для этой информации клиент вообще первичен), чтобы не нагружать сервер. Проверить можно, но не нужно - так, что ли?

Да, можно сказать, что эти баги не настолько смертельны, они не приводят к BSOD, а лишь раздражают. Как кусачие мухи, они же не цеце, от них не умирают. Но, когда таких мух становится много, а прибить их самим по неким причинам нельзя - вот какие мысли у вас могут появится?


К слову, если уже упоминалась японская фирма, то там была обязательная процедура проверки исходного кода одного программиста проверяющим, тоже программистом. И они оба отвечали за работу программы. И была процедура тестирования программы, на которое выделялось и время, и деньги. А вот если программа не работала как должна, то.... денег за неработающие программы почему-то не платили. Странно, да?

[nekromail2011]

"В этих фразах точно нет никаких противоречий???"

Никак не могу понять где там вы их нашли)

"И совершенно не важно, реализован этот обработчик в виде отдельного программного модуля, ddl или хдбшки."

А xdb шка это не обработчик, это ресурс. Как, например, текстура. То есть клиент берет текстуру и рисует её. При этом сама текстура ничего не делает. Тоже самое и в xdb шке, в ней содержатся только сведение о том или ином объекте в мире, а уж одна функция(или десяток, или сотня, это неважно), эти сведения каким-то образом использует.

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

В игре 200к xdb шек, вы предлагаете написать 200к обработчиков?)
Обработчик всегда один, (скорее всего), он лишь обрабатывает то событие, которое сейчас конкретно надо обработать

"но приходилось сталкиваться и с другими языками, в том числе Perl и PHP, которые, надеюсь, вы не будете отрицать, предназначени именно для клиент-серверной архитектуры. "

тогда почему такие странные выводы? на клиенте только картинка, он отправляет события на сервер, а обработчик на сервере.

"И вот почему не включить вот в этот программный код достаточно элементарную проверку, может ли персонаж телепортироваться или нет, вот честное слово, не понимаю."

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

...


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

В игре десятки тысяч спелов. И если в программный код для каждого спела вводить проверку, то упороться можно.
этим занимаются дизайнеры

так вот, я не думаю, что дизайнеру так трудно добавить одну проверку.

все может быть гораздо сложнее

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


вообще, это все по идее должно работать так.


1. Клиент получил позицию x = 100 y = 100 z = 100.
2. Сервер пришел к выводу, что в этих координатах клиент может использовать спел. О чем он и информирует клиент.
3. Клиент запускает обработчик событый "нажать контекстную кнопку".
4. Как только событие произошло, клиент отправляет инфу на сервер, что игрок нашал на кнопку.
5. На сервере произошли проверки.
6. Сервер поменял координаты игрока.
7. Сервер отправил клиенту положительный ответ.

на самом деле, у нивала клиент сам считает кооринаты аватара и физику. Ибо сервер и так жрет 32 гб оперативы, а если еще для каждого из аватаров будет считать координаты?))

[Aberon82]

В том же сервере 2кк сток java кода, и где угодно может что-то пойти не так, из-за чего весь остальной результат не сложится и программе придется упасть

Если сервер действительно написан на java то это очень печально.

[SAdTN]

И совершенно не важно, реализован этот обработчик в виде отдельного программного модуля, ddl или хдбшки.

Конечно, тут мой баг, о чём честно говорю и оперативно исправляю. Т.к. не могу отредактировать свой пост, исправлю его тут. Конечно, имелась в виду dll - dynamic link library.
И еще раз - это тема не о наличии багов, которые всегда были, есть и будут. Проблема в реакции разработчиков на баги. Или об отсутствии таковой реакции.

А xdb шка это не обработчик, это ресурс.
...................
В игре 200к xdb шек, вы предлагаете написать 200к обработчиков?)
Обработчик всегда один, (скорее всего), он лишь обрабатывает то событие, которое сейчас конкретно надо обработать

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

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

так вот, я не думаю, что дизайнеру так трудно добавить одну проверку.

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

Тем не менее утверждение "И если в программный код для каждого спела вводить проверку, то упороться можно." непонятно. А что, в большинстве спелов не декларируются какие-то условия типа
"Если жрец находится в Аспекте света или Аспекте ярости, то получаемое им исцеление увеличивается на 10%, когда его здоровье опускается ниже 50%"
"Урон, наносимый "Дыханием смерти", увеличивается на 12%, а время восстановления снижается на 12%"
В каждом - куча проверок и расчётов.
И что, нормально будет декларировать что-то, а реализовать какую-то часть, ссылаясь на объем проекта, упоронность и сложности реализации? Вот по здравому смыслу казалось бы, что, когда до нас, игроков, доезжает некий анонс нововведений, то это означает, что работа над ними уже выполнена на 95-99% и разработчики (программисты, дизайнеры, ...., начальники наконец) на 100% уверены, что АОтим в состоянии реализовать анонсируемое.

Теперь немного по шагам.

Венесекция.
1. Где-то обрабатывается факт запроса на её включение/выключение? Да, обрабатывается.
2. Где-то по факту включения начинается набор крови, решимости и самодамаг? Да, начинается.
3. Где-то обрабатывается факт достижения ХП некра до 35% максимального ХП с выключением венесекции? До, обрабатывается.

Надо ли включать венесекцию безусловно, если она была выключена? Сейчас работает именно так и включение венки на 34% ХП спокойно унесет некра в Чистилище. Очень сложно реализовать правильную работу? Не думаю.
Вот в том месте, где реализованы п.п. 1-3, между п.п. 1 и 2 поставить проверку на значение текущей ХП некра:
1-2. Если текущее значение ХП некра <= 35%, п.п. 2-3 не выполнять.

Можно было заранее о такой проверке подумать? Ну, да, это дело субъективное, но мне казалось, что такая проверка - дело достаточно очевидное.

АОтим говорит, что проект тестируется (и правильно, как же иначе?), для больших обновлений существует и ПТС. В чем смысл тестирования? Проверить реакцию программы на соответствие техзаданию (описанию спела). Например, вклчение и отработка венки, условно говоря, на 100% (крайнее значение), на каких-нибудь 50% (число не важно). И тут казалось бы естественным проверить спел еще на одном, некорректном значении типа 30%. На мой взгляд, для нормального тестировщика это естественно - попробовать погонять программу на некорректных значениях и посмотреть реакцию. Именно некорректные действия пользователя часто приводят к непредсказуемым последствиям, поэтому и надо блокировать эти некорректные действия.

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


Теперь о телепорте на ЦС.

вообще, это все по идее должно работать так.

1. Клиент получил позицию x = 100 y = 100 z = 100.
2. Сервер пришел к выводу, что в этих координатах клиент может использовать спел. О чем он и информирует клиент.
3. Клиент запускает обработчик событый "нажать контекстную кнопку".
4. Как только событие произошло, клиент отправляет инфу на сервер, что игрок нашал на кнопку.
5. На сервере произошли проверки.
6. Сервер поменял координаты игрока.
7. Сервер отправил клиенту положительный ответ.

на самом деле, у нивала клиент сам считает кооринаты аватара и физику. Ибо сервер и так жрет 32 гб оперативы, а если еще для каждого из аватаров будет считать координаты?))

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

Теперь о птичках. Первичным для определения координат персонажа является клиент. Игрок определяет, какую клавишу нажмет в следующий момент и жмет её на своей клиентской клавиатуре или мыши. Локация прорисована на клиенте, поэтому клиент и должен определять координаты персонажа, отправляя на сервер минимум информации в виде x, y и z персонажа.

Нынешняя проблема сидит в указанном Вами п.2, п.4 и/или 5. Попробуем разобраться.

"2. Сервер пришел к выводу, что в этих координатах клиент может использовать спел. О чем он и информирует клиент."
Сейчас, подойдя к телепорту, условно говоря, в каждом втором случае персонаж не может использовать спел (телепорт). Иногда чаще, иногда реже - кому как повезет. Ну, к рандому мы уже привычные. Получается, что, не давая персонажу возможность использовать телепорт, сервер пришёл к ошибочному выводу.

Так ли это? Стоим на телепорте, шестеренки нет, использовать телепорт не можем. Что делать? Релог. Входим заново и, стоя на этом же месте (ведь состояние персонажа в момент выхода запоминается, не так ли?), не делая никаких движений, телепорт оказывается доступен.

Так что очень похоже, что сервер по п.2 смотрит еще что-то, а далеко не только координаты. Были бы только координаты, то, стоя на телепорте, была бы и шестеренка.

Рассуждаем дальше, пытаясь понять логику. Допустим, игрок в бою (это видно по скрещенным мечах на иконке). Надо ли программе в этот момент игроку показывать шестеренку, как бы предоставляя ему возможность использовать телепорт, хотя прыжок в состоянии боя запрещен правилами игры? Достаточно логично, что шестеренка в этот момент и не показывается. Ровно то же самое касается и инвиза, когда у игрока шестеренки телепорта быть не должно.

Поэтому, скорее всего, в существующей реализации предлагаемые Вами п.2 и 5 объединены, что достаточно логично и отвечает правилам. И именно в этом месте и сидит неисправляемый неделями, месяцами, годами баг.

Дальше все просто. Если п.3 выполнен, т.е. игрок нажал на кнопку, должно произойти событие 4 и сервер должен безусловно отработать п.п.6 и 7. П.5 уже объединен с п.2, соответственно, он лишний после п.4.

Сложно ли правильно написать этот объединенный п.2,5 ? Моя оценка - нет. Просто надо сесть и разобраться с логикой этого фрагмента. Попробуем по пунктам.

2.1 Персонаж находится на ЦС? Да - работаем дальше, нет - дальше ничего не делаем.
2.2 Персонаж находится в зоне действия телепорта? Да - работаем дальше, нет - дальше ничего не делаем.
2.3 Персонаж НЕ находится в бою? Да - работаем дальше, нет - дальше ничего не делаем.
2.4 Персонаж НЕ находится в состоянии инвиза по любым причинам? Да - работаем дальше, нет - дальше ничего не делаем.
2.5 Делаем вывод, что персонаж имеет право использовать телепорт и на клиенте может быть отрисована шестеренка для безусловной портации.

Вполне возможно, в конкретной реализации п.2.1 и не нужен, если программа уже "знает" о нахождении персонажа на ЦС. Не в этом суть.

К слову, чтобы не перегружать сервер, эти проверки вполне могут быть выполнены и на стороне клиента. Не так ли? Но опять-таки - где и в каком виде они могут быть выполнены, не имеет никакого отношения к самой логике работы. Факт тот, что достаточно простая логика нарушена длительное время, доставляя куче игроков неприятные эмоции.

[Jean-Luk-Picard]

Если сервер действительно написан на java то это очень печально.

Да это так, было выступление одного из разработчиков, можно найти на тытубе и на хабре.

Но все же думаю что критичные к производительности элементы не на ней...

[Kosenko]

Автор нуб и опозорился!Тему нужно закрывать.

[SAdTN]

Автор нуб и опозорился!Тему нужно закрывать.

Гениально по своей краткости и, главное, очень убедительно.

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

---------- Сообщение добавлено в 18:30 ---------- Предыдущее сообщение было в 18:24 ----------

Да это так, было выступление одного из разработчиков, можно найти на тытубе и на хабре.

Но все же думаю что критичные к производительности элементы не на ней...

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

[Hromonoga]

Баг с телепортом на ЦС висит ГОД. Целый ГОД игроки топ лвл ВСЕХ серверов ходят по граблям. Ага, вот наши взяли последнее место силы на ЦС, быстрее сдать квесты... и хлоп тебе по фейсу, телепорт не работает. Быстрее перезайти.... а тут уже и ситуация изменилась, и не факт, что тебя после релога не встретит "дружеский" моб и не вынудит выяснять с ним отношения...

Ну давайте заведём баг

Обходной путь есть? Есть - клубок автоперемещения. Он работает по своей логике и перемещает даже персов в бою через телепорты на ЦС. Значит приоритет у бага не блокер.

Сколько человек о нём репортнуло? 1,5? На критикал не тянет.

Поставим нормал. И попробуем воспроизвести. Воспроизводится? Чёт не очень (сам не ловил подобного бага на ЦС ни разу). Значит статус у него либо "Не воспроизводится", либо "Нужна дополнительная информация".

И оп! баг завис. И будет он там висеть до скончания веков - никогда не видели багтрекер с 18 тысячами незакрытых нормалов?

[Aberon82]

Ну давайте заведём баг

Обходной путь есть? Есть - клубок автоперемещения. Он работает по своей логике и перемещает даже персов в бою через телепорты на ЦС. Значит приоритет у бага не блокер.

Сколько человек о нём репортнуло? 1,5? На критикал не тянет.

Поставим нормал. И попробуем воспроизвести. Воспроизводится? Чёт не очень (сам не ловил подобного бага на ЦС ни разу). Значит статус у него либо "Не воспроизводится", либо "Нужна дополнительная информация".

И оп! баг завис. И будет он там висеть до скончания веков - никогда не видели багтрекер с 18 тысячами незакрытых нормалов?

С тем же ЦС очень интересно получается. Клубок автоперемещения перемещает даже персов в бою, но не с нового острова где черволицые. Там такой фокус не прокатывает (если в бою то пишет невозможно проложить маршрут, и соответственно сбивает клубок при любом перемещении и т.п.). А из этого можно сделать вывод, что у каждой руинины (или по крайней мере у старой и новой частей острова) разный алгоритм, обрабатывающий перемещения. Или разные настройки, или объекты, с разным поведением.

[nekromail2011]

...


то, что дважа, это еще ни о чем не говорит.

"И если в программный код для каждого спела вводить проверку, то упороться можно." непонятно.

Вот движок. Его написал программист. Вот текстура. Её нарисовал художник. В Аллодах более 10000 текстур.

Логично, если программист будет писать 10000 функций, каждая из которых рисует только одну текстуру? То есть функция №6561 может рисовать только одну текстуру "Oko_Mira_6561" и никакую другую. Логично? Нет. Программист напишет одну функцию, которая сможет нарисовать ЛЮБУЮ из 10000 текстур. Программист не будет в программный код закладывать, каким щас цветом рисовать ЭТУ КОНКРЕТНУЮ текстуру. Он в функции запрашивает цвет ИЗ текстуры, и функция может нарисовать любую из 10к текстур, любого цвета, а не только того, что внес программист в программный код. И ему не нужно в программном коде 10000 раз писать, какого цвета будут текстуры 1..10000. Если художнику захочется нарисовать текстуру за номером 10001, ему не нужно просить программиста "а адоптируй код свой под мою текстуру 10001", потому что код этого программиста сможет нарисовать ЛЮБУЮ текстуру, какую ему подсунет художник.


Тоже самое дизайн любых объектов в игре. Программисты лишь пишут отстутствующую механику. А на эту механику можно накрутить хоть миллион спелов.

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





"Первичным для определения координат персонажа является клиент. Игрок определяет, какую клавишу нажмет в следующий момент и жмет её на своей клиентской клавиатуре или мыши."

КАК ДОЛЖНО БЫТЬ:

1) Клиент пишет серверу "юзер нажал W"
2) Сервер думает "ага, значит клиент продвинулся по х на 10 условных единиц"
3) Сервер информирует об этом клиента

Как примерно реализовано в АО

1) Юзер жмет W
2) Клиент думаю "ага, значит мои координаты изменятся на 10 у.е"
3) Клиент информирует об этом сервер.

Почему это неправильно. Как МОЖЕТ быть:

1) Читер запускает программу.
2) Клиент говорит серверу "Юзер сделал один шаг и продвинулся на 100000000000 у.е"
3) Сервер это принимает...

На клиенте вообще не должно быть никаких механических проверок. Только проверки движка на отображение красивой картинки. А все остальное должно быть только на сервере.

[SAdTN]

Ну давайте заведём баг

Обходной путь есть? Есть - клубок автоперемещения. Он работает по своей логике и перемещает даже персов в бою через телепорты на ЦС. Значит приоритет у бага не блокер.

Сколько человек о нём репортнуло? 1,5? На критикал не тянет.
...............
Поставим нормал. И попробуем воспроизвести. Воспроизводится? Чёт не очень (сам не ловил подобного бага на ЦС ни разу). Значит статус у него либо "Не воспроизводится", либо "Нужна дополнительная информация".

Нормальный вопрос требует нормального ответа Поэтому поясню свою позицию.

1. Баг проявляется на WinXP, на Vista. Железо разное. Баг проявляется рандомно, после использования инвиза на РУ версии практически наверняка, на евроверсии примерно в половине случаев.

2. Баг проявляется у многих знакомых людей как тут, так и в евроверсии. У Вас не проявляется? Мне бы Ваше счастье Думаю, и не только мне.

3. Баг, естественно, не критический. Аналогию уже проводил - как кусачая муха, но и мухи тоже могут достать. С какой стати нужно ежедневно терять время, нервы, реликвии ЦС из-за ухода лучшего состояния мест силы во время релога, иногда - мирру из-за изменения ситуации на телепорте после релога?

4. "Сколько человек о нём репортнуло?" Да, конечно, это агрумент, не спорю. Могу сказать только про себя, что желание общаться с техподдержкой отсутствует напрочь, тем более по некритическому багу. Если тут воспроизвести моё мнение о техподдержке АО, то ооооочень долгий бан будет обеспечен. Если воспроизвести бы тут последнюю разборку (что, к сожалению. запрещено правилами), то будет понятно, чего стоит получение внятного ответа по достаточно простому вопросу.

Могу только предположить, что у остальных игроков также есть подобный опыт общения с техподдержкой.

И уж тогда к теме - есть полуфабрикат возможности сообщить о баге в процессе игры (правый верхний угол, там, где "Безвыходное положение"). Как раз очень бы и подошло для сообщений о некритических багах, было бы очень удобно. Вопрос - почему такая реально замечательная возможность и не работает? Боюсь, ответ слишком очевиден. И отговорки тут не пройдут - за некорректные сообщения влепят игроку хороший бан и он в следующий раз задумается, что и как писать.

И оп! баг завис. И будет он там висеть до скончания веков - никогда не видели багтрекер с 18 тысячами незакрытых нормалов?

Ой, каких только ошибок не бывает И существуют более известные в стране, чем АО, системы, в которых хотфиксы (по разным причинам) выходят примерно с той же регулярностью. При этом, как ни удивительно, но ПО своё отрабатывает. Да, разработчик очень часто считает свой продукт непогрешимым . Каюсь, всегда считаешь, что в готовом на взгляд разработчика продукте нет ошибок Кстати, и вирусная дыра "buffer overflow" идёт по причине излишней самоуверенности разработчика Но вот, когда нормальному разработчику демонстрируешь ошибки, вообщем то удаётся их исправить. Правда, там и мера ответственности немного другая. А вот пофигизм, когда его слишком много, почему-то достает... Может, это просто лирика?

[SAdTN]

...
Вот движок. Его написал программист. Вот текстура. Её нарисовал художник. В Аллодах более 10000 текстур.

Логично, если программист будет писать 10000 функций, каждая из которых рисует только одну текстуру? То есть функция №6561 может рисовать только одну текстуру "Oko_Mira_6561" и никакую другую. Логично? Нет. Программист напишет одну функцию, которая сможет нарисовать ЛЮБУЮ из 10000 текстур. Программист не будет в программный код закладывать, каким щас цветом рисовать ЭТУ КОНКРЕТНУЮ текстуру. Он в функции запрашивает цвет ИЗ текстуры, и функция может нарисовать любую из 10к текстур, любого цвета, а не только того, что внес программист в программный код. И ему не нужно в программном коде 10000 раз писать, какого цвета будут текстуры 1..10000. Если художнику захочется нарисовать текстуру за номером 10001, ему не нужно просить программиста "а адоптируй код свой под мою текстуру 10001", потому что код этого программиста сможет нарисовать ЛЮБУЮ текстуру, какую ему подсунет художник.


Тоже самое дизайн любых объектов в игре. Программисты лишь пишут отстутствующую механику. А на эту механику можно накрутить хоть миллион спелов.

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

Слава богу, что меня пока не обвиняют в том, что я предлагаю каждый из 256 * 256 * 256 пикселей рисовать своей программой

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

К тому, что Вы написали в этом фрагменте, полностью присоединяюсь. Вы правы. Я тоже не пишу отдельных программ для х=4. х=10,5 и для х=25.

"Первичным для определения координат персонажа является клиент. Игрок определяет, какую клавишу нажмет в следующий момент и жмет её на своей клиентской клавиатуре или мыши."

КАК ДОЛЖНО БЫТЬ:

1) Клиент пишет серверу "юзер нажал W"
2) Сервер думает "ага, значит клиент продвинулся по х на 10 условных единиц"
3) Сервер информирует об этом клиента

Как примерно реализовано в АО

1) Юзер жмет W
2) Клиент думаю "ага, значит мои координаты изменятся на 10 у.е"
3) Клиент информирует об этом сервер.

Почему это неправильно. Как МОЖЕТ быть:

1) Читер запускает программу.
2) Клиент говорит серверу "Юзер сделал один шаг и продвинулся на 100000000000 у.е"
3) Сервер это принимает...

На клиенте вообще не должно быть никаких механических проверок. Только проверки движка на отображение красивой картинки. А все остальное должно быть только на сервере.

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

Вот тут слава богу, что к вам не приёдет комиссия ФСТЭК по вопросу о нарушении Яскером Закона о государственной тайне или Айденусом - Закона о персональных данных Проект чисто коммерческий и было бы логично ожидать, что и критерии безопасности системы должны быть соответствующими.

Предложите, пожалуйста, Ваши критерии.

В свою очередь, как я понимаю, для коммерческой системы существует достаточно очевидный критерий:

Стоимость средств, выделяемых на обеспечение безопасности, не должна превышать стоимость охраняемого объекта.

Другими словами, было бы странно потратить 10 млн.$, защищая объект стоимостью 1 млн.$ (опять-таки, если мы не госструктура)

Напомню Ваш же пост:

на самом деле, у нивала клиент сам считает кооринаты аватара и физику. Ибо сервер и так жрет 32 гб оперативы, а если еще для каждого из аватаров будет считать координаты?))

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

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

А, если еще точнее, поскольку исходное состояние персонажа определяется в момент загрузки (как нам пишут на клиенте, с 92%), то передавать только изменения параметров персонажа так, чтобы все поместилось бы в один IP пакет, т.е. уложиться примерно в 1,5 К информации, если уж мы боремся за производительность.

Думаю, в каком-то виде это так и делается. Интересно видеть двух персонажей на двух экранах, при том, что в некоторых деталях при этом отличия есть. Не всё передается с клиента на сервер и с сервера - на клиенты других компьютеров

Читтер страшнее - так нечего ныть, ставьте на сервер 256 ГБ, 1 ТБ, запускаёте всё в облаке, обеспечив при этом приемлимое время реакции, используйте закрытый протокол.


И уж раз пошла такая пьянка, напомню эпизод из жизни АО. Помните массовую закупку кузниц перед одной обновой, о повышении цены которой стало известно на ПТС и последующие долгие "банные" разборки с внезапно возникшими миллионерами? На евросервере эта история повторилась ровно точно так же через несколько месяцев, только там не было ПТС, а миллионерами стали те, кто знал историю на РУ серверах.

Теперь вопрос - кто виноват в истории на евросервере? На мой взгляд, те же пофигисты АОтим, которые прекрасно знали ситуацию и палец о палец не ударили, чтобы предотвратить её повторение.

Теперь - как там это трактовалось? Оказывается, был виноват некий эксплоит, а игроки, которые читают русскоязычный форум, все повально суперхакеры. Блин, да хоть бы для начала Википедию посмотрели, что слово exploit означает и какое отношение оно имеет к бардаку при установки обновления. Если уж на то пошло, то правильно было считать экспоитом само установленное обновление.

На мой взгляд, основная проблема в том, чтобы в голове разработчиков эксплоитов не было...

И напоследок - эта тема не о безопасности, это точно не наше дело.
Эта тема - о нескольких багах (если обобщать - о качестве разработки. Хотелось написать - программирования, но нет, не буду ) и о длительном сроке присутствия этих багов.

[Hromonoga]

И уж тогда к теме - есть полуфабрикат возможности сообщить о баге в процессе игры (правый верхний угол, там, где "Безвыходное положение"). Как раз очень бы и подошло для сообщений о некритических багах, было бы очень удобно. Вопрос - почему такая реально замечательная возможность и не работает? Боюсь, ответ слишком очевиден. И отговорки тут не пройдут - за некорректные сообщения влепят игроку хороший бан и он в следующий раз задумается, что и как писать.

Во-первых, Allods_online уже отвечал на этот вопрос - многие путают кнопку "Сообщить о баге" с кнопкой "Поплакаться о трудностях игры".


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


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

1. Баг проявляется на WinXP, на Vista. Железо разное. Баг проявляется рандомно, после использования инвиза на РУ версии практически наверняка, на евроверсии примерно в половине случаев.

2. Баг проявляется у многих знакомых людей как тут, так и в евроверсии. У Вас не проявляется? Мне бы Ваше счастье Думаю, и не только мне.

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

Ой, каких только ошибок не бывает И существуют более известные в стране, чем АО, системы, в которых хотфиксы (по разным причинам) выходят примерно с той же регулярностью. При этом, как ни удивительно, но ПО своё отрабатывает. Да, разработчик очень часто считает свой продукт непогрешимым . Каюсь, всегда считаешь, что в готовом на взгляд разработчика продукте нет ошибок Кстати, и вирусная дыра "buffer overflow" идёт по причине излишней самоуверенности разработчика Но вот, когда нормальному разработчику демонстрируешь ошибки, вообщем то удаётся их исправить. Правда, там и мера ответственности немного другая. А вот пофигизм, когда его слишком много, почему-то достает... Может, это просто лирика?

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

[SAdTN]

Во-первых, Allods_online уже отвечал на этот вопрос - многие путают кнопку "Сообщить о баге" с кнопкой "Поплакаться о трудностях игры".

Да, вероятно, так. Возможно, для использования этого средства должна быть разъяснительная работа среди игроков, для особо злостных можно вспомнить, что "доброе слово и пистолет гораздо убедительней, чем просто доброе слово"

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

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

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

Этот пункт самый простой. Если у Вас почта на Мэйл, то Вы входите в форум по адресу почты, а дальше пишете посты под своим акком, правильно? Если Вы пользуетесь Лавкой редкостей, то покупку производит Ваш персонаж, а кри списываются со счета Вашего аккаунта, правильно? Т.е. цепочка от персонажа к e-mail есть.
Конечно, мы не знаем структуры базы данных, но, думаю, одного далеко не самого сложного SQL-оператора вполне достаточно, чтобы получить адрес почты просто на автопилоте.

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

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

Понятно, что с АО ситуация для тестирования, пожалуй, самая сложная - у всех клиентов своё железо и своя операционка.

Подход к багам, наверное, зависит от критичности программы и бага. Если вспомнить лицензию Микрософт, то Микрософт вообще ни за что не отвечает, кроме как за качество болванки с дистрибутивом, требуя от потребителя согласия на использование продукта "as is".

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

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

Что касается конкретно телепортов ЦС, то повторюсь. В игре есть корректно работающая система глобальных телепортов, к которой ни у кого нет претензий. И есть некорректно работающая система локальных телепортов ЦС. Проблема именно в начальной стадии портирования, когда игрок в корректном состоянии подходит к телепорту, а возможности портирования у него нет.

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