Не работает дебаг камера раст

не работает полет и админская камера!

#1 Lyce4er

Пользователь

2 сообщений

Проблема в том, что админку прописал все работает, но не работает палет и админская камера подскажите команду или сочетание клавишь для активации!

(P.S. сочетание клавиш Shift+L и Shift+P не срабатывают)

#2 slava1232

Пользователь

172 сообщений

Проблема в том, что админку прописал все работает, но не работает палет и админская камера подскажите команду или сочетание клавишь для активации!

(P.S. сочетание клавиш Shift+L и Shift+P не срабатывают)

Полёт команда noclip

Можно поставить настройку на кнопку, введите команду в консоли игры bind x » chat.say noclip » после этого нажимайте кнопку x чтобы включать и выключать полёты.

#3 Lyce4er

Пользователь

2 сообщений

Источник

Rust Wiki

Debug camera is a freecam view which can be used by server administrators and developers.

Enabling Debug Camera

Use the command debugcamera to toggle between the debug camera and player camera. By default the camera will be positioned inside the head of the player triggering the command.

The command is best used when bound to a key — eg. bind p debugcamera

Transform Controls

The controls for the debug camera are fairly straightforward and mostly mimic existing movement keys.

w a s d — Position the camera

mouse — Adjust the pitch and yaw of the camera (i.e. look around)

q — Raise camera height

e — Lower camera height

space — Slows down the movement speed of the camera by half when held down.

right arrow — Roll / rotate camera right or clockwise

left arrow — Roll / rotate camera left or anti-clockwise

ctrl + mouse left / mouse right — Adjust roll / rotation of camera on the fly

up arrow / down arrow — Adjust pitch of the camera angle (i.e. aim up or down)

Field of View

z or + — Zoom in (increase FOV amount)

c or — — Zoom out (decrease FOV amount)

right mouse + mouse up / mouse down — Adjust zoom (FOV amount) on the fly

FOV Command

You can also use the command debugcamera_fov to set the zoom/FOV to a particular value.

Reset Camera

Use the r key to reset the field of view and roll of the debug camera to it’s default state.

Speed Controls

Below are the available commands for controlling speed properties of the debug camera.

Camera Speed

Look Speed

An amount of 0 will lock the camera angle and prevent mouse movement to aim the camera.

Zoom Speed

Lerping

These commands are useful for adding smoothed movement to certain properties of the debug camera.

Camera Lerp

camlerptilt — Enable/disable tilt and roll locomotion for lower lerp values.

Zoom Lerp

Useful for adding smoother movement to FOV adjustments. Lower values = smoother motion.

Save Points

Use the command debugcamera_save to save the position, angle, fov and roll of the camera.

You can also use the command debugcamera_savetofile to save the camera state as a .cam text file, which is stored in a folder called «camsaves» in the game’s root directory.

Load a camera save point or .cam file by using the command debugcamera_load

Auto Save

debugcamera_autosave — Automatically save the debug camera state when toggling it.

This will save / retain the position, angle, fov and roll of the camera.

Auto Load

debugcamera_autoload — Automatically load the debug camera state when toggling it.

Preserve

debugcamera_preserve — Preserve the initial debug camera state through game restarts.

List Save Points

debugcamera_list — Prints out all of the saved camera points; including name, position, rotation and zoom.

The total number of saved camera points is printed at the bottom of the list. A separate section labelled ‘files’ is listed for all .cam files stored in the «camsaves» directory.

Clear Saves

Use the command debugcamera_clear to remove all camera save points.

Camera Unfreeze

Use the command debugcamera_unfreeze to unfreeze player controls whilst remaining in the debug camera view.

This also currently causes the debug camera to track the movement origin of the player.

Camera Parenting

Use the command bind +debugcamera_targetbind to bind a key of your choosing to toggle camera parenting.

When using debug camera, press your key bind to parent the camera to an entity being looked at. Press the same key to un-parent the camera from the entity and return to normal free-cam.

Orbit Controls

Once parented, move the mouse to orbit the camera around the entity and targeted bone.

up arrow / down arrow keys will orbit the pitch axis of the targeted entity.

ctrl + left arrow / right arrow keys will orbit the yaw axis of the targeted entity.

left arrow / right arrow keys will roll / rotate the camera as normal.

You can also dolly the camera in/out of the targeted entity (aka move closer or further away) by using the following commands:

• bind +debugcamera_dollyforward
• bind +debugcamera_dollyback

Orbit speed can be specified using the camlookspeed command. Additionally, the camera lerping commands will also affect the smoothness of the orbit’s movement.

Here’s an example of the debug camera orbiting around a parented player and dollying in/out.

Parent Offset

You can offset the position of the parented camera by using the basic camera transform controls, which can be particuarly useful if you still want to target an entity but re-position the camera’s origin.

Use ⇧ shift + r to reset the offset transform and return the debug camera to it’s original orbit position.

Bone Targeting

By default when parenting to an entity the camera will target the root bone of the nominated entity.

Use the tab key to cycle between different bones on the entity. The console will print out the name of the newly targeted bone which the debug camera is parented to.

Use the command cambone to manually parent the debug camera to a particular bone.

Running the command cambone without a specified bone name will return the name of the current target bone.

Bone Rotation

debugcamera_bonerotation — Applies the target bone’s rotation to the debug camera. Default value is 0 .

Here’s an example of the debug camera targeting the head bone of a Horse with bone rotation enabled.

Camera Guides

Use the command debugcamera_guide to enable different types of camera guide overlays. These are useful for helping frame particular compositions in your videos and images when using the debug camera.

Default value is 0 which disables the guide overlay. You can also assign a custom color to the guide overlay.

Rule of thirds

Use debugcamera_guide 1 to enable a rule of thirds guide for the debug camera.

Golden Ratio

Use debugcamera_guide 2 to enable a golden ratio fibonacci guide for the debug camera.

Aspect Ratio

Use debugcamera_guide 3 to enable an aspect ratio guide for the debug camera.

Set a custom aspect ratio by using debugcamera_guide_aspectratio — for example 1 1 will be a square ratio. The aspect ratio being applied is printed in the top-left corner of the guide.

Crosshair

Use debugcamera_guide 4 to enable a crosshair guide for the debug camera.

Guide Color

Use debugcamera_guide_color to set the color of the above guides.

The value parameter is measured in RGBA values.

Источник

Обработка ошибок в Rust

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

Содержание

Что делать с ошибкой?

Для начала, порассуждаем о возможных вариантах действий при возникновении ошибки в ходе выполнения программы. Вариантов у нас, в конечном счёте, всего три:

Завершить работу программы. Это самый простой вариант, не требующий больших усилий от разработчика. Он применим в случаях, когда ошибка не позволяет программе корректно выполнять свои функции. В качестве примера можно рассмотреть приложение, представляющее собой обёртку над некоторой динамической библиотекой. Скажем, графический интерфейс. Приложение поставляется с этой библиотекой и не несёт какой-либо пользы в отрыве от неё. Разумно предположить, что приложение не должно работать без этой библиотеки. Поэтому, вполне обосновано, при ошибке загрузки библиотеки, прерывать работу приложения.

Обработать ошибку. Чтобы программа могла продолжить выполнение после возникновения ошибки, требуется отреагировать на эту ошибку так, чтобы корректная часть программы могла далее выполнять свои функции, потеряв, возможно, доступ к некоторым возможностям. Рассмотрим приложение, использующее модули в виде динамических библиотек. В данном случае, отсутствие библиотеки модуля, необходимого для выполнения выбранного пользователем действия — это повод отменить выполнение действия, а не прерывать программу. Как вариант, сообщим пользователю об отсутствии требуемого модуля и предложим другие варианты работы.

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

Ошибки, после которых приложение должно завершить работу называют неустранимыми. Остальные — устранимыми. Тип конкретной ошибки не зависит от самой ошибки (некорректный ввод, файл не найден, . ). Он зависит от решения разработчика: стоит ли продолжать работу программы при этой ошибке, или программа больше ничего не может сделать. Нужно искать компромисс, исходя из требований к надёжности системы и имеющимися ресурсами для разработки, так как восстановление после ошибки требует от разработчика некоторых усилий. В лучшем случае, достаточно просто сообщить о ней пользователю и продолжить работу. Но бывают ситуации, когда для восстановления от ошибки требуется создать целую резервную систему.

Механизм обработки ошибок в Rust требует явно указывать, как вы классифицируете каждую ошибку. Для того чтобы разобраться, как этот механизм устроен, давайте рассмотрим некоторые особенности синтаксиса Rust, которые в нём применяются.

Немного о синтаксисе Rust

Механизм обработки ошибок включает себя две особенности языка Rust: перечисления с данными и трейты.

Трейты

Трейты схожи с концепцией интерфейсов в других языках. Их можно реализовывать на типах, расширяя их функционал. Также, функции могут накладывать ограничение на трейты принимаемых аргументов. Ограничения проверяются при компиляции. Например:

В данном примере мы определили трейт Print и реализовали его для встроенного целочисленного типа i32 . Также, мы определили функцию print_value() , принимающую обобщённый (generic) аргумент value , ограничив варианты его типа только теми, которые реализуют трейт Print . Поэтому в main() мы можем вызвать print_value() только с i32 аргументом.

Более того, при определённых условиях, можно создавать трейт объекты (trait objects). Это динамический объекты, которые могут быть созданы из любого типа, реализующего данный трейт. Конкретная реализация метода трейта выбирается динамически (dynamic dispatch). Например:

В данном коде нет необходимости делать функцию say_something() обобщённой, так как конкретная реализация, скрытая за трейт объектом разрешается во время выполнения программы, а не при компиляции.

Также, стоит упомянуть о том, что трейты могут наследоваться. То что трейт Mammal унаследован от трейта Animal означает, что реализовать трейт Mammal может только тип, реализующий Animal .

Данный код не компилируется, так как мы пытаемся реализовать трейт Mammal на типе Dog , не реализовав Animal , от которого Mammal унаследован.

Перечисления с данными

Данный элемент синтаксиса позволяет привязать данные разных типов к разным вариантам перечисления. Например, вы можете принимать в качестве аргумента IP адрес, не уточняя версию:

Ключевое слово match позволяет описать действия для различных вариантов перечисления и их содержимого.

Перечисления могут быть обобщенными:

Разобравшись с типажами и перечислениями, можно переходить к механизму обработки ошибок.

Обработка ошибок в Rust

В Rust есть два перечисления на которых строится, практически, вся обработка ошибок: Option и Result . Рассмотрим их подробнее.

Option

Семантика его проста: либо мы имеем некоторые данные, либо они отсутствуют. Таким образом, возвращая из функции Option мы, тем самым, выражаем мысль, что, возможно, мы не получим ожидаемый результат.

Result

В отличие от Option , Result позволяет установить не только отсутствие данных, но и причину, в связи с которой они отсутствуют.

Рассмотрим теперь, как в Rust выразить три действия при ошибке, которые мы перечислили в начале статьи:

Завершить работу приложения.

Пропустить ошибку на более высокий уровень.

Завершаем работу приложения

Rust требует от разработчика явно демонстрировать своё намерение прервать программу в случае ошибки. Аварийное завершение работы программы в Rust называется паникой. Вызвать её можно с помощью макроса panic!() , позволяющего указать сообщения об ошибке для вывода.

Так как для обработки ошибок, обычно, используются Option и Result , для завершения работы программы нужно писать что-то вроде:

Для удобства, Option и Result содержат ассоциированную функцию unwrap() , позволяющую не повторять приведённый выше код. Если перечисление находится в состоянии успеха, то unwrap() достаёт данные из перечисления и позволяет с ними работать. В случае ошибки, unwrap() вызывает панику. У unwrap() есть аналог, позволяющий добавить произвольный текст к выводу: expect() .

Обрабатываем ошибку

Вызывая функцию, которая может не сработать, мы получаем в качестве результата Option или Result . Если нам известно, что делать в случае неудачи, мы должны выразить свои намерения через конструкции языка. Рассмотрим пример:

В данном примере мы используем разные способы замены строки настроек, в случае неудачи при её получении:

s1 — явно сопоставляем Option с шаблоном и указываем альтернативу.

s2 — используем функцию unwrap_or_default() , которая в случае отсутствия данных возвращает значение по умолчанию (пустую строку).

s3 — используем unwrap_or() , возвращающую свой аргумент в случае отсутствия данных.

s4 — используем unwrap_or_else() , возвращающую результат вызова переданного в неё функтора в случае отсутствия данных. Такой подход позволяет вычислять значение резервного варианта не заранее, а только в случае пустого Option .

Перечисление Result предоставляет аналогичные методы.

Пропускаем ошибку выше

Для начала, сделаем это вручную. Для Option :

Как видно в примерах, такой подход требует большого количества match конструкций. Это усложняет код, ухудшает его читабельность и добавляет разработчику дополнительной рутинной работы. Во избежание всего этого, создатели языка ввели оператор ? . Расположенный после Option или Result , он заменяет собой match конструкцию. В случае наличия значения, он возвращает его для дальнейшего использования. В случае ошибки, возвращает её из функции. Воспользуемся им в наших примерах. Для Option всё очевидно:

Для Result всё обстоит немного сложнее. Ведь в случае, если происходит LoadDllError , то компилятору нужно как-то преобразовать её в InitModuleError для возврата из функции. Для этого оператор ? пытается найти способ преобразования для этих ошибок. Для того, чтобы создать такой способ, в стандартной библиотеке существует трейт From . Воспользуемся им:

Иными словами, Rust требует явно описывать способы преобразования ошибок друг в друга при передаче их верхним уровням иерархии вызовов.

Динамические ошибки

В случае, если нет необходимости использовать конкретный тип ошибки, а достаточно просто иметь текстовое сообщение о ней, то можно передавать ошибку в виде трейт объекта std::error::Error , завёрнутого в умный указатель Box (подробнее). Трейт Error определён так:

Как видно из определения, он требует реализации трейтов Debug и Display . Таким образом, Rust вводит требования для всех типов реализующих Error : уметь выводить отладочную и текстовую информацию о себе. Рассмотрим на примере:

Как видно из примера, при использовании динамических ошибок, нет необходимости создавать промежуточные типы ошибок, объединяющие несколько типов ошибок нижнего уровня. У такого подхода есть свои недостатки. Во-первых, отсутствует возможность определить конкретный тип ошибки, произошедшей на нижнем уровне. Во-вторых, снижается производительность, так как для создания ошибки требуется аллокация в куче, а, при выводе сообщения об ошибке, используется динамическая диспетчеризация.

Полезные библиотеки

Рассмотрим две популярные библиотеки, упрощающие обработку ошибок: thiserror и anyhow.

thiserror

Данная библиотека предоставляет макросы, позволяющие упростить рутинные действия: описание способов конвертации ошибок через From , и реализация трейтов Error и Display . Рассмотрим на примере:

В данном примере, трейт Error реализуется автоматически с помощью макроса #[derive(Error)] . Используя макрос #[error(«text to display»)] генерируем реализацию трейта Display. Макрос #[from] создаёт реализацию трейта From для конвертации ошибки нижнего уровня в ошибку текущего.

Данные макросы значительно сокращают объём boilerplate кода для обработки ошибок.

anyhow

Данную библиотеку удобно использовать, когда единственное, что интересует нас в ошибке — её текстовое описание. anyhow предоставляет структуру Error . В неё может быть сконвертирован любой объект, реализующий трейт std::Error , что значительно упрощает распространение ошибки по иерархии вызовов. Помимо этого, anyhow::Error позволяет добавлять текстовое описание контекста, в котором произошла ошибка. Эта библиотека сочетается с thiserror. Пример:

Макрос anyhow::bail!() в примере создаёт anyhow::Error с заданным описанием и возвращает её из функции. Псевдоним anyhow::Result определяется так:

Заключение

В начале статьи мы рассмотрели три возможных варианта действий, при получении ошибки: завершить работу программы, обработать ошибку и передать ошибку вверх по иерархии вызовов. Далее, разобравшись с особенностями синтаксиса, мы разобрались на примерах, как выразить наши намерения по отношению к ошибке на языке Rust. Мы увидели, что любой из вариантов поведения должен быть выражен явно. Такой подход повышает надёжность приложения, так как не позволяет разработчику случайно проигнорировать ошибку. С другой стороны, явное описание своих намерений требует дополнительных усилий. Минимизировать эти усилия позволяют библиотеки thiserror и anyhow.

Благодарю за внимание. Поменьше вам ошибок!

Статья написана в преддверии старта курса Rust Developer. Приглашаю всех желающих на бесплатный урок, в рамках которого на примере построения простого веб сервиса рассмотрим популярный веб-фреймворк actix-web в связке с MongoDB + Redis и другие полезные библиотеки для backend разработки.

Источник