От описания API к проверяемому результату
На примере Callable: исходные условия, ожидаемый результат, отложенный вызов и удалённый объект.
Проверить новый API на небольшой задаче
Пример задачи: выполнить расчёт через Callable, затем отложенно изменить надпись. Если Label удалён до обработки очереди, вызов не должен обращаться к освобождённому объекту. Это конкретные результаты, которые можно проверить отдельно от остальной игры.
1. Взять полный пример
Откройте Callable.Call и сохраните полный файл CallableSignalExamples.cs из статьи в своём C#-проекте. Это вспомогательный static-класс: прикреплять его к Entity не нужно. В уже существующем скрипте Entity, например внутри _Ready, вызовите:
ReckfellApi.Print(CallableSignalExamples.Twice(21));Соберите C# и запустите документ. Ожидаемый результат в выводе — 42. Сначала добейтесь этого результата без изменений в примере. Если класс не найден, проверьте сохранённый файл, пространство имён и ошибки сборки; если _Ready не вызывается — прикрепление скрипта и запуск нужного документа.
2. Разобрать контракт до изменения кода
У выбранной перегрузки смотрите типы аргументов и результата. В Twice локальный аргумент превращается в Variant, Call возвращает Variant, а результат читается как int. У CallDeferred результата нет: он только ставит вызов в очередь. Подмена одного метода другим меняет поведение, даже если передаются те же значения.
SetLabelLater из того же файла проверяет IsInstanceValid непосредственно перед обращением к Label. Это важнее, чем одна проверка объекта в момент постановки в очередь: между этими действиями объект может быть удалён.
3. Проверить обычный и граничный случаи
| Проверка | Ожидаемый результат |
|---|---|
| Twice(21) | 42 |
| SetLabelLater с живым Label | Текст меняется после обработки очереди, не синхронно |
| Label удалён перед обработкой | Обработчик не меняет освобождённый объект |
| Ожидание следующего ProcessFrame | Продолжение после следующего срабатывания сигнала |
Signal.GetAwaiter объясняет ожидание. Удаление владельца сигнала не обещает автоматического завершения await; это отдельный случай, а не признак успешно выполненной операции.
Затем перенести в свой проект
Меняйте одну часть: входное значение, обработчик или объект назначения. После каждого изменения повторяйте обычный и граничный случаи. Не начинайте с переноса всего проекта или переписывания большого класса.
Если результат отличается, сохраните минимальный документ, полный участвующий скрипт, последовательность действий, ожидаемый результат, первую ошибку и версию движка. Укажите имена и родителей объектов: они нужны для воспроизведения пути. Это полезнее одного снимка последней ошибки.
Для незнакомой сигнатуры откройте чтение C#-справочника, для неработающего проекта — диагностику.