Баг или не баг вот в чем вопрос
Баг или не баг. Вот в чем вопрос
И так. на днях было замечено после боя на арте не был засчитан урон. Попадание по стоковому, фуловому кв 13 в момент исчезания его из засвета вызывает пожар, от которого он погибает спустя 1.5 секунды. Фраг засчитан мне. Пожар вызван мной, о чем свидетельствует поломка бака на скрине) Обратился на баг трекер, и модер судя по всему даже не удосужился пересмотреть реплей и скрин вынес вердикт Аккурат перед Вашим попаданием по нему попал кто-то ещё. Хотелось бы услышать мнение компетентнвх людей по этому поводу) Лью реплей и скрины
Ну и собственно сам реплей
Модер сори не там тему создал)
Видимо тот кто стоял на Б4, выстрелил по нему и как вариант могла накинуть ГВП, из-за твоих модов, могли не отобразиться трассера союзников, а ты просто добрал остатки ХП. Не понимаю в чем смысл жалобы? В том что тебе не засчитали большего сноса хп, или то что ты его не шотнул фуловым?
А вообще правильно сказал чел выше, удали моды, от них сплошной абзац, постоянные глюки, ради интереса поюзай форум и посмотри сколько подобных тем, тогда поймешь почему тебе написали про моды.
И вообще, научись нормально изъясняться, из твоего описания мало что понятно, одна вода, никакой конкретики.
UPD. поломка бака, не есть возгорание, мог быть просто крит модуля без прохода дамага, и на скрине у тебя снесенное ХП, а не криты модулей, так что чет ты приврал немного.
С уважением, к Вам, Vi5
Баг или не баг? вот в чем вопрос
Прикрепленные файлы
Напоминаю вам, что адм инистрация не гарантирует корректную работу игрового клиента при установке игровых модов. Все модификации клиента вы устанавливаете на свой страх и риск.
Для ответа на ваш вопрос можете обратиться в Центр Поддержки пользователей.
Перед поданием заявки настоятельно рекомендую проверить работоспособность клиента без модификации или в безопасном режиме, а также со сбросом графических настроек. Помн ите, что Компания Wargaming не несёт ответственности и не гарантирует нормальную работу игрового клиента с модифицированными файлами.
Пожалуйста, подробно опишите ситуацию в заявке, какая у вас проблема и что вы уже пытались делать для её решения и как именно.
Прикрепите все необходимые файлы к заявке ( файл DxDiag и Python.log, отчет WGCheck) при наличии предоставьте реплей или скриншот с отображением данной проблемы.
Скорость ответа сотрудников на заявку зависит от:
Создание новой или обновление старой заявки приводит к их объединению, в результате чего она смещается в конец очереди на рассмотрение.
Не баг, а фича. Что это значит и откуда появилась эта фраза?
Велик и могуч язык программиста. Иногда этот язык наполнен таким количеством сленговых слов, что его трудно понять не то чтобы простым пользователям, а даже молодым и начинающим программистам. Сегодня мы разберем, что значит довольно популярное выражение : « Э то не баг, а это фича» и когда оно применяется.
«Не баг, а фича!»
Что так ое «баг» в программировании?
Это довольно частый вопрос, потому что слово «баг» не всегда связано с программированием. В программировании «баг» — это ошибка в программе или в приложении, которая приводит к тому, что программа или приложени е не работают как следует. Само слово «баг» происходит от английского слова «bug». По причине воздействия бага на программу мы получаем продукт, при работе которого происходит нежелательный конечный результат.
Баг имеет широкую градацию по способу собственного возникновения и влияния на конечный продукт. Сегодня мы не будем на этом останавливаться, отметим лишь, что все возникающие баги объединя ю т следующие свойства:
Что такое « фича » в программировании?
Фича в программировании — это некая новая функция или особенность программы, которая ранее не была о г оворена, но в результате не нарушает функциональность программы, а приносит какое-то дополнение в ее работу. Фича происходит от английского слова «feature». Ее цель — улучшить характеристики программы или просто привлечь внимание пользователей своей необычной функцией.
Понятие «фича» существует не только в программировании, оно уже часто употребляется и в обыденной жизни. К примеру, фичами в быту именуют нестандартные функции или дизайн какого-нибудь устройства.
Фича в программировании — это контролируемый результат, который создается специально руками программиста, чтобы улучшить разрабатываемую программу или просто удивить пользователей или заказчика. Фичи часто не нужно исправлять, потому что они очень органично приживаются с самой программой.
Мы можем предположить, что такое выражение может употребляться в качестве оправдания разработчика перед заказчиком, когда тот обнаружил баг в программе. Но часто это совсем не так.
Мы будем очень благодарны
если под понравившемся материалом Вы нажмёте одну из кнопок социальных сетей и поделитесь с друзьями.
Баг или не баг вот в чем вопрос
Ну да, ссылка есть, все стандартно. Битрикс в этом разделе генерировать понятные урлы не обучен. Разработчик говорит: «норм». А SEO и впечатление от просмотра страдают.
8. Не указываем личные мнения
Частая ошибка — пишем не то, что надо сделать, а личные мнения. Такие комментарии покрасят серым и проигнорят.
Переформулировали. Видите, что это можно поправить — отлично, возьмите с полки пирожок. Нормальная формулировка, почти идеальная. Но пошлют. Потому что кое-кто забывает ставить приоритеты.
9. Расставляем приоритеты
Наши разработчики идут по баглистам в порядке приоритетов:
0 — критические баги, сайт не работает вообще или работает не так, как ожидается;
1 — критичное юзабилити, забытые фичи;
2 — некритичные баги;
3 — некритичное юзабилити;
4 — ошибки в текстах;
8 — хотелки.
Написали «Ссылочку мне сделай красиво». Ок. Баг без приоритета. Разработчик начнет делать вперемешку, если не проигнорит. И будет злиться и посылать в далекое пешее путешествие.
При таком подходе программист исправит баг, и даже не особо перенервничает. Ну ладно, раз просит — сделаю.
10. Не подкидываем посуду
Новый сайт Сибирикса тестировали ежедневно. Каждый день создавался новый лист. Баги отлавливались сразу.
В чем минус постоянной работы над проектом?
Терминальная стадия такого багтрекера — чат разработчика и тестировщика в режиме гуглодока. Вместо того чтобы пройти три метра и голосом задать вопрос, начинаются милые беседы — переписка по полчаса, где все считают друг друга уродами. Ну или не уродами, в зависимости от темперамента. Но обида копится. Поэтому ни в коем случае тестировщик не должен работать в одной вкладке с программистом. Вы в своей делаете, он пишет в своей. Это нормально и не бесит.
Баги и ошибки — как искусство
Введение
Баг или же ошибка, связанная с нарушениями в целостности программы или программного кода, в этом кратком пособии я хочу рассказать об этих странных, забавных и порой неизвестных вещах, надеюсь, что это пособие поможет вам понять, как я смотрю на этот чудесный мир ошибок и недоработок, многие воспринимают их как что-то бесящее и крайне надоедливое, с определённой стороны они все правы.
Что такое “БАГ”
В программировании баг (англ. bug — жук)— жаргонное слово, обычно обозначающее ошибку в программе или системе, которая выдает неожиданный или неправильный результат. Большинство багов возникают из-за ошибок, сделанных разработчиками программы в её исходном коде, либо в её дизайне. Также некоторые баги возникают из-за некорректной работы компилятора, вырабатывающего некорректный код. Программу, которая содержит большое число багов и/или баги, серьёзно ограничивающие её работоспособность, называют нестабильной или, на жаргонном языке, “глючной”, “глюкнутой”, “забагованной”, “бажной”, “баг (а) нутой” (англ. unstable, buggy). Термин «баг» обычно употребляется в отношении ошибок, проявляющих себя на стадии работы программы, в отличие, например, от ошибок проектирования или синтаксических ошибок. Отчет, содержащий информацию о баге, также называют отчетом об ошибке или отчетом о проблеме (англ. bug report). Отчет о критической проблеме (англ. crash), вызывающей аварийное завершение программы, называют крэш репортом (англ. crash report). «Баги» локализуются и устраняются в процессе тестирования и отладки программы. Возможны ситуации, при которых ошибки остаются во внутреннем коде или программе они могут остаться не замеченными и обнаруженными уже при тестировании или выпуске программы или игры. Такие ситуации исправляются так называемыми “патчами” (англ. patch), выпускаются они как можно скорее стараясь залатать все дыры и проблемы, когда патч готов разработчик или программист выпускает “патч ноут” (англ. Patch note) список изменений и исправлений. На этом с терминологией всё, приступим к практике.
Как выглядит баг
И как его исправить
Чаще всего их можно обнаружить на ранних стадиях разработки, например когда игра компилируется выскакивают ошибки или сообщения о неполадках, но бывает так что их можно и не заметить особенно когда было проделано много работы и ошибка не проявилась, для такого существуют тестировщики, люди которые 24 часа в сутки проверяют каждый угол на предмет ошибок, что бы при игре в условный Fallout 76 ваша игра окончательно не сломалась. Правда в конце концов люди не могут увидеть всё и для этого требуется ещё больше времени работы и труда, но даже при этом некоторые ошибки невозможно исправить, такие ошибки не критичны и ведь зачем их исправлять если это не приносит убытков, поэтому огромное количество багов не исправляются разработчиками, их исправляют игроки и просто не равнодушные люди. Эти вещи называются фиксами. Перейдём к виновнику этой книги. Самое простое это пропавшая текстура, это может быть прозрачная область или разноцветные пиксели, происходит если текстура пропала из игры. Более критичными являются ошибки в коде, прыгнул куда-то не туда и вот игра уже зависает, выдаёт ошибку и ломается, тут всё дело в том, что где-то есть сломанная частица кода, которая при активации выдаёт ошибку. Есть ошибки в тексте и звуке, к примеру вместо звука меча проигрывается звук курицы, а в субтитрах написано, что это была машина, тут играет человеческий фактор, ещё можно застрять в текстуре или сломать цепочку событий в игре. Всё исправить невозможно в силу того, что на таком уровне заметить их трудно, бывает они возникают из неоткуда, но всегда весело их находить если они не критичны.
Место без текстур в Fallout76 – источник
Творческие решения
Но у ошибок нашли хорошую соревновательную сторону, спидраны — забеги по играм на скорость, проходить игру просто это так скучно, а вот с ошибками это совсем другое дело, сократить игру в 3 раза прыгая за текстуры, профессионалам на это дело расплюснуть, разбирать спидраны я не буду всё это уже сделали за меня, хочу лишь сказать что это удивительно как люди используют ошибки и недоработки, рассчитывают всё до пикселя и всё это основано на ошибках, багах и глитчах.
Критические ситуации
За примером далеко ходить не надо, можно вспомнить лица из Assassin’s Creed Unity, проблема была вызвана несовместимостью с некоторыми видеокартами, это ошибка была исправлена в патче первого дня но оставила свой отпечаток на и так большом пласте ненависти ввиду отсутствия оптимизации и багов, вот что об этом говорит главный творческий руководитель Ubisoft Жан Жесдон:
Если вы поиграете сейчас, со всеми исправлениями, — это будет очень красивая и хорошая игра. Иными словами, вероятно, мы подлетели слишком близко к Солнцу и утратили самоконтроль.
Именно поэтому Syndicate концентрировалась на качестве, с чем команда отлично справилась. Жан Жесдон
В заключении хотел бы сказать что баги и ошибки порадили целые сегменты в разных культурах и стали большой частью игр и игровой индустрии. _DeVloPPeR_