Output в Roblox Studio: найти причину ошибки и проверить исправление

Начните с воспроизводимого случая #

Когда кнопка не отвечает или награда не появляется, запишите три вещи: что вы сделали, какой результат ожидали и что произошло. Например: «Запустил тест, нажал кнопку один раз, ожидал сообщение о покупке, сообщения нет». Такая запись задаёт конкретную проверку и помогает повторить проблему после исправления.

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

1. Откройте Output и подготовьте сообщения #

В текущей документации Roblox окно Output открывается через меню Window или панель вкладки Script. Найдите Output и разместите его так, чтобы во время теста были видны новые строки. Если ваше расположение панелей отличается, ориентируйтесь на название окна.

Проверьте фильтры типа сообщения, контекста и текста поиска. Для первого упражнения уберите текстовый фильтр и разрешите сообщения сервера, обычные сообщения и предупреждения. Включите Show Source, чтобы видеть имя скрипта и строку, где это применимо. Перед очисткой сохраните нужную запись; очистка удаляет сообщения из окна, но не исправляет код.

2. Создайте один серверный Script #

В Explorer найдите ServerScriptService и добавьте обычный Script с именем OutputPractice. Для этой серверной учебной проверки подходит стандартный RunContext Legacy; можно также явно выбрать Server. Вставьте первый пример ниже и убедитесь, что скрипт включён.

Запустите тест из панели Studio. После запуска ожидаются сообщение coins с числом 8 и предупреждение Unexpected coin count. Посмотрите контекст: этот Script работает на сервере. Если вы видите несколько одинаковых пар сообщений, проверьте, не создали ли несколько копий упражнения. Каждый дополнительный скрипт может добавлять свои строки.

local expectedCoins = 10
local actualCoins = 8
print("coins", actualCoins)

if actualCoins ~= expectedCoins then
    warn("Unexpected coin count")
end

3. Отличайте сообщение, предупреждение и ошибку #

print() помогает увидеть значение или отметить пройденный этап. warn() выделяет условие, которое автор кода решил показать как предупреждение. В нашем примере предупреждение появляется потому, что 8 не равно 10; оно само по себе не доказывает поломку движка.

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

4. Исправьте условие и повторите тест #

Остановите тест. В исходном OutputPractice измените actualCoins с 8 на 10, оставив expectedCoins равным 10. Начните новый тест с чистой историей или отметьте время нового запуска. Теперь обычное сообщение должно показывать 10, а предупреждение из этого условия — отсутствовать.

Это проверка ровно одного изменения. Если одновременно поменять условие, имя переменной и место скрипта, успешный результат не покажет, какой шаг помог. Изменения объектов во время теста могут сбрасываться после Stop, поэтому редактируйте исходный проект после остановки. Сохраните окончательную исправленную версию, когда повторная проверка дала ожидаемый результат.

5. Разберите безопасную учебную ошибку выполнения #

Замените содержимое того же скрипта вторым примером ниже и запустите новый тест. inventory здесь намеренно равен nil, поэтому обращение inventory.Coins не может получить поле таблицы. Ожидается ошибка, относящаяся к строке обращения. Точная формулировка может отличаться, но источник должен вести к нашему примеру.

Остановите тест и замените строку local inventory = nil на local inventory = {Coins = 10}. Запустите заново: обращение теперь получает число, и Output должен показать 10. Исправление задаёт корректные входные данные. Простое удаление print() скрыло бы упражнение, но не объяснило бы причину неправильного обращения.

local inventory = nil
print(inventory.Coins)

6. Если сообщение отсутствует, проверьте путь запуска #

Вернитесь к первому примеру и добавьте в начало временную строку print("OutputPractice started"). Если она не появляется, сначала проверьте, начался ли тест, включён ли Script, где он находится и подходит ли RunContext. Затем проверьте фильтры Output и правильный контекст. Не начинайте с переписывания арифметики, если код до неё ещё не дошёл.

Для реального LocalScript учитывайте клиентский запуск и его контейнер. Сообщение сервера не подтверждает, что клиентский обработчик тоже сработал. Полезно ставить короткие метки до действия и после него. Если видна только первая, исследуйте участок между ними; если ни одной — ищите проблему запуска или отображения сообщений.

7. Читайте источник и сохраняйте полезные сведения #

При ошибке найдите имя скрипта и номер строки. Включённый Show Source помогает увидеть эту связь; доступная ссылка на источник позволяет перейти к коду. Если показана цепочка вызовов, смотрите также, откуда был вызван проблемный участок. Номер строки — отправная точка для чтения, а причина может быть в значении, полученном раньше.

Для записи проблемы сохраните шаги, ожидаемый и фактический результат, текст ошибки, скрипт и контекст Client или Server. Добавьте минимальный относящийся к делу фрагмент кода. Перед отправкой уберите ключи, пароли и данные игроков. Не засоряйте Output сообщениями на каждом кадре: повторяющийся поток затрудняет поиск первой полезной записи.

8. Проверьте исправление тем же сценарием #

Повторите исходные шаги из начала статьи. Проверьте два результата: нужное поведение действительно произошло и относящаяся к нему ошибка больше не появилась. Для учебного примера это число 10 и отсутствие предупреждения; для кнопки — её ожидаемое действие. Чистый Output при неработающей кнопке ещё не подтверждает исправление.

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