Перейти к содержанию

Troubleshooting

Эта страница помогает разбирать проблемы по симптомам: что вы видите, что это обычно значит и что проверить.

Предмет не берётся

Чаще всего причина одна из этих:

  • исходный слот пуст
  • CanStartDrag вернул отказ
  • данные не загрузились в UI
  • в слоте лежит adapter не того типа

Что проверить:

  • назначен ли DataBinding на нужный UniversalInventory
  • вызывается ли ReloadUI()
  • что возвращает GetItems() / GetOccupiedSlots()
  • нет ли правила, запрещающего drag из этого слота или инвентаря

Предмет не кладётся в слот

Типовые причины:

  • слот запрещает этот тип предмета
  • стек в целевом слоте уже полный
  • CanDrop вернул отказ
  • DropPolicySettings настроен на Reject
  • предмет был сконвертирован не в тот adapter-тип

Что проверить:

  • правила на слоте и инвентаре
  • CanDrop в вашем binding-е
  • настройки DropPolicySettings
  • конвертер, если перенос идёт между разными типами инвентарей

Предмет кладётся не в выбранный слот

Обычно это не ошибка, а результат policy.

Проверьте:

  • включён ли FindAlternative
  • включён ли поиск другого слота внутри того же инвентаря
  • не отпускается ли предмет на область инвентаря вместо конкретного слота
  • какой PlacementCandidateOrderer выбран

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

После переноса данные не обновились

Если UI изменился, а ваши игровые данные нет, почти всегда проблема в binding-е.

Проверьте:

  • назначен ли binding на правильный inventory
  • реализованы ли AddToData / RemoveFromData
  • меняют ли эти методы именно тот список или объект, который вы ожидаете
  • не меняете ли вы данные напрямую, забывая вызвать ReloadUI()

Появляется Неверный тип предмета

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

Частые причины:

  • не настроен CreateItemConverter()
  • конвертер возвращает не тот adapter
  • swap оставил в слоте adapter чужого инвентаря
  • данные после переноса синхронизировались в одном формате, а слот хранит другой

Что проверить:

  • converter у source и target binding-ов
  • CanDrop / CanStartDrag в fixed-slot или equipment binding-е
  • какой adapter реально лежит в слоте после переноса

Первый swap работает, второй ломается

Почти всегда после первого swap один из слотов хранит предмет в неправильном adapter-типе.

Проверьте:

  • есть ли конвертация в обе стороны
  • не делаете ли вы обмен как простую замену двух стеков
  • обновляются ли данные и UI одним и тем же типом adapter-а

CanDrop вызывается много раз

Это нормально, если система ищет подходящее место:

  • drop был на область инвентаря
  • включён FindAlternative
  • проверяется swap
  • система перебирает слоты для auto placement

Это подозрительно, если вы точно отпускаете предмет в конкретный слот и policy не разрешает поиск альтернативы.

В таком случае проверьте:

  • попадает ли pointer именно на слот
  • есть ли InventoryDropArea поверх слотов
  • какой BlockedTargetResolutionKind используется

Стек ведёт себя как один и тот же предмет

Так бывает, когда несколько экземпляров в стеке используют один и тот же adapter-объект, хотя должны быть разными предметами.

Проверьте:

  • создаётся ли отдельный adapter для каждого уникального экземпляра
  • сохраняет ли converter runtime-состояние предмета
  • соответствует ли ItemId вашей логике stacking

С чего начать отладку

  1. Сформулируйте симптом: не берётся, не кладётся, данные не обновились, swap ломается.
  2. Проверьте настройки в инспекторе: strategy, slot management, drop policy, rules.
  3. Проверьте binding: загрузка данных, CanStartDrag, CanDrop, add/remove методы.
  4. Если инвентари используют разные модели данных, проверьте converter.
  5. Если проблема только при торговле, серверной проверке или золоте, проверьте domain handler.

См. также: