v5.8.7 controller + fix + format

Author: NeoXider

Assets/Neoxider/CHANGELOG.md

@@ -1,60 +1,80 @@
-
 # Руководство по написанию документации
 
-Этот документ описывает правила и стандарты для создания и ведения документации по скриптам в проекте. Соблюдение этих правил обеспечит единообразие и высокое качество документации.
+Этот документ описывает правила и стандарты для создания и ведения документации по скриптам в проекте. Соблюдение этих
+правил обеспечит единообразие и высокое качество документации.
 
 ## 1. Общие принципы
 
 - **Язык**: Вся документация должна быть написана на **русском языке**.
-- **Цель**: Документация должна быть понятной, краткой и полезной. Ее главная задача — быстро объяснить, **зачем нужен тот или иной модуль и как он упрощает разработку**.
+- **Цель**: Документация должна быть понятной, краткой и полезной. Ее главная задача — быстро объяснить, **зачем нужен
+  тот или иной модуль и как он упрощает разработку**.
 - **Стиль**: Пишите интересно и по делу, избегая излишней детализации, но не упуская важные моменты.
 
 ## 2. Структура и организация файлов
 
 Вся документация по скриптам находится в папке `Assets/Neoxider/Docs`.
 
-- **Простые модули**: Для каждого самостоятельного модуля (например, `Audio`, `Bonus`), который находится в своей папке в `Assets/Neoxider/Scripts`, создается один `.md` файл. 
-  - *Пример*: `Assets/Neoxider/Scripts/Bonus` -> `Assets/Neoxider/Docs/Bonus.md`
+- **Простые модули**: Для каждого самостоятельного модуля (например, `Audio`, `Bonus`), который находится в своей папке
+  в `Assets/Neoxider/Scripts`, создается один `.md` файл.
+    - *Пример*: `Assets/Neoxider/Scripts/Bonus` -> `Assets/Neoxider/Docs/Bonus.md`
 
-- **Сложные модули**: Для модулей, содержащих множество скриптов и/или подпапок (например, `Extensions`, `Tools`), в `Docs` создается отдельная **папка** с тем же именем.
-  - Внутри этой папки создается:
-    1.  `README.md` с кратким описанием всего раздела и ссылками на документацию по каждому скрипту. Если модуль содержит подпапки, `README.md` также должен содержать оглавление со ссылками на разделы этих подмодулей для быстрой навигации.
-    2.  Отдельный `.md` файл для **каждого** скрипта в модуле.
-  - *Пример*: `Assets/Neoxider/Scripts/Extensions` -> `Assets/Neoxider/Docs/Extensions/`
+- **Сложные модули**: Для модулей, содержащих множество скриптов и/или подпапок (например, `Extensions`, `Tools`), в
+  `Docs` создается отдельная **папка** с тем же именем.
+    - Внутри этой папки создается:
+        1. `README.md` с кратким описанием всего раздела и ссылками на документацию по каждому скрипту. Если модуль
+           содержит подпапки, `README.md` также должен содержать оглавление со ссылками на разделы этих подмодулей для
+           быстрой навигации.
+        2. Отдельный `.md` файл для **каждого** скрипта в модуле.
+    - *Пример*: `Assets/Neoxider/Scripts/Extensions` -> `Assets/Neoxider/Docs/Extensions/`
 
 ## 3. Содержание файла документации
 
 Каждый файл документации (`.md`) должен иметь следующую структуру:
 
 ### 3.1. Введение
-- Начните с краткого и интересного вступления. Расскажите, какую проблему решает этот модуль и какие преимущества дает его использование.
+
+- Начните с краткого и интересного вступления. Расскажите, какую проблему решает этот модуль и какие преимущества дает
+  его использование.
 
 ### 3.2. Описание классов
+
 Для каждого ключевого класса в модуле необходимо предоставить следующую информацию:
 
-1.  **Название класса** (в формате заголовка, например, `### КлассНазвание`).
-2.  **Пространство имен (Namespace)** и **Путь к файлу**.
-3.  **Краткое описание**: 1-2 предложения о назначении класса.
-4.  **Ключевые особенности (опционально)**: Список основных возможностей.
-5.  **Публичные свойства и поля (Public Properties and Fields)**: Список всех публичных свойств и полей с кратким описанием их назначения и типа данных.
-6.  **Публичные методы (Public Methods)**: Список публичных методов с кратким описанием. **Обязательно** указывайте, какой тип данных возвращает метод и что означает возвращаемое значение (например, `Spend(float count)` возвращает `bool` — `true` при успехе).
-7.  **Unity Events**: **Обязательно** опишите все публичные `UnityEvent`. Укажите, когда вызывается событие и какие параметры (если есть) оно передает.
+1. **Название класса** (в формате заголовка, например, `### КлассНазвание`).
+2. **Пространство имен (Namespace)** и **Путь к файлу**.
+3. **Краткое описание**: 1-2 предложения о назначении класса.
+4. **Ключевые особенности (опционально)**: Список основных возможностей.
+5. **Публичные свойства и поля (Public Properties and Fields)**: Список всех публичных свойств и полей с кратким
+   описанием их назначения и типа данных.
+6. **Публичные методы (Public Methods)**: Список публичных методов с кратким описанием. **Обязательно** указывайте,
+   какой тип данных возвращает метод и что означает возвращаемое значение (например, `Spend(float count)` возвращает
+   `bool` — `true` при успехе).
+7. **Unity Events**: **Обязательно** опишите все публичные `UnityEvent`. Укажите, когда вызывается событие и какие
+   параметры (если есть) оно передает.
 
 ## 4. Рабочий процесс
 
 Чтобы обеспечить точность и полноту документации, следуйте этому процессу:
 
-1.  **Анализ папки**: Изучите целевую папку в `Assets/Neoxider/Scripts`, чтобы понять ее структуру и состав.
-2.  **Чтение по одному файлу**: Внимательно читайте **по одному файлу за раз**. Это критически важно для глубокого понимания каждого скрипта перед тем, как его описывать.
-3.  **Написание документации**: Следуя структуре, описанной в разделе 3, напишите текст документации.
-4.  **Запись в файл**: Сохраните готовую документацию в соответствующий `.md` файл.
+1. **Анализ папки**: Изучите целевую папку в `Assets/Neoxider/Scripts`, чтобы понять ее структуру и состав.
+2. **Чтение по одному файлу**: Внимательно читайте **по одному файлу за раз**. Это критически важно для глубокого
+   понимания каждого скрипта перед тем, как его описывать.
+3. **Написание документации**: Следуя структуре, описанной в разделе 3, напишите текст документации.
+4. **Запись в файл**: Сохраните готовую документацию в соответствующий `.md` файл.
 
 ## 5. Обновление документации при изменениях
 
 При перемещении или переименовании файлов скриптов необходимо обновить документацию:
 
-1.  **Обновление путей**: Если скрипт был перемещен в другую папку, обновите путь к файлу в документации.
-   - *Пример*: Если `ScoreManager.cs` был перенесен из `Tools/Managers/` в `Tools/Components/`, обновите путь в соответствующем `.md` файле.
-2.  **Обновление ссылок**: Проверьте и обновите все ссылки на перемещенный скрипт в других файлах документации (README файлы, связанные компоненты).
-3.  **Перемещение файла документации**: Если скрипт перемещен в другую подпапку, рассмотрите возможность перемещения соответствующего `.md` файла документации в соответствующую структуру папок.
-   - *Пример*: Если скрипт перенесен из `Managers/` в `Components/`, документацию тоже следует переместить из `Docs/Tools/Managers/` в `Docs/Tools/Components/`.
+1. **Обновление путей**: Если скрипт был перемещен в другую папку, обновите путь к файлу в документации.
+
+- *Пример*: Если `ScoreManager.cs` был перенесен из `Tools/Managers/` в `Tools/Components/`, обновите путь в
+  соответствующем `.md` файле.
+
+2. **Обновление ссылок**: Проверьте и обновите все ссылки на перемещенный скрипт в других файлах документации (README
+   файлы, связанные компоненты).
+3. **Перемещение файла документации**: Если скрипт перемещен в другую подпапку, рассмотрите возможность перемещения
+   соответствующего `.md` файла документации в соответствующую структуру папок.
+
+- *Пример*: Если скрипт перенесен из `Managers/` в `Components/`, документацию тоже следует переместить из
+  `Docs/Tools/Managers/` в `Docs/Tools/Components/`.

Assets/Neoxider/DOCUMENTATION_GUIDELINES.md

@@ -1,6 +1,6 @@
 # Neoxider Docs — документация и навигация
 
-Добро пожаловать в документацию **NeoxiderTools** (v5.8.6). Здесь собраны ссылки на все модули и инструкции по запуску.
+Добро пожаловать в документацию **NeoxiderTools** (v5.8.7). Здесь собраны ссылки на все модули и инструкции по запуску.
 
 ---
 

Assets/Neoxider/Docs/README.md

@@ -2,7 +2,7 @@
 
 ## 1. Введение
 
-`CameraAspectRatioScaler` — это важный инструмент для обеспечения корректного отображения игры на экранах с разным соотношением сторон. Он автоматически настраивает ортографический размер или угол обзора (FOV) камеры, чтобы сохранить задуманные пропорции и избежать искажений или нежелательного обрезания картинки.
+`CameraAspectRatioScaler` — инструмент для стабильной адаптации камеры под разные соотношения сторон. Компонент корректно работает и с ортографической, и с перспективной камерой: для 3D используется математически корректный пересчет FOV по горизонтали/вертикали, а для `FitBoth` доступен режим letterbox/pillarbox через `Camera.rect`.
 
 Компонент поддерживает несколько режимов масштабирования, что позволяет выбрать оптимальную стратегию для вашего проекта, будь то 2D или 3D игра.
 
@@ -22,8 +22,12 @@
 - **Режимы масштабирования**:
   - `FitWidth`: Сохраняет ширину обзора, подстраивая высоту.
   - `FitHeight`: Сохраняет высоту обзора, подстраивая ширину.
-  - `FitBoth`: Гарантирует, что в кадр попадет вся целевая область, добавляя черные полосы при необходимости.
-- **Работа в редакторе и рантайме**: Позволяет видеть результат как в реальном времени, так и при изменении настроек в инспекторе.
+  - `FitBoth`: Показывает целевую область целиком (без обрезки). Можно использовать:
+    - масштабирование камеры;
+    - `Camera.rect` для letterbox/pillarbox (`useViewportRectInFitBoth`).
+- **Работа в редакторе и рантайме**: Есть отдельные флаги обновления в Play Mode и Edit Mode.
+- **Оптимизация обновлений**: Перерасчет выполняется только при изменении параметров или размера экрана.
 
 **Публичные методы**
-- У данного класса нет публичных методов, предназначенных для вызова из других скриптов. Вся логика работает автоматически.
+- Основная логика работает автоматически.
+- Для инспектора есть кнопка `Apply Camera Scale` для ручного форс-обновления.