We’ve done a number of “quality of life” improvements to properties manipulation in the Castle Game Engine editor.

We simplified the display of floats and vectors. No need for excessive trailing zeroes. Instead of
0.00 0.00.0.00
or1.00 2.00 3.00
we now display0 0 0
or1 2 3
which is much easier to “parse” by a human eye. 
Editing vectors and components of vectors automatically updates everything immediately. E.g. if you edit
TCastleTransform.Translation.X
to10
, theTCastleTransform.Translation
will update immediately to10 0 0
. And if you edit the vectorTCastleTransform.Translation
to42 0 0
, theTCastleTransform.Translation.X
will update immediately to42
. 
The
TCastleTransform.Direction
andTCastleTransform.Up
are now exposed in the “Basic” tab. Thanks to above improvements, you can now clearly see they are synchronized withTCastleTransform.Rotation
— changing one changes the other. 
TCastleImageTransform.Size
is now more comfortable to edit: simply type single float to set both X and Y to the same value. E.g. type10
to set Size to10 10
(in Pascal this would meanVector2(10, 10)
). This is consistent withTCastlePlane.Size
,TCastleTransform.Scale
and similar properties: typing a single float sets all vector components to be equal. 
The display and input of angles and rotations now displays / accepts degrees.
Note that the Pascal API still accepts angles in radians. This is standard (in X3D, glTF,
Math
routines etc.). I experimented and looked at how others (Blender and Godot) present angles to make the end result useful and not confusing. To this end:
Angles are now displayed as degrees in CGE editor.
And the fact that they are in degrees is explicitly shown by wrapping them with
deg(xxx)
text. So the angle looks likedeg(45)
.We are deliberately explicit that the angles are in degrees, to avoid confusion.
This affects both angles displayed as angle of axis+angle rotation (like
TCastleTransform.Rotation
saying0 1 0 deg(45)
) or as single float number (e.g. if you expand theTCastleTransform.Rotation
to reveal theAngle (W)
component). 
When you input an angle value, you can keep the
"deg(...)"
wrapping, or you can input just the number. In the latter case, we will automatically add"deg(...)"
around, so we interpret input as being in degrees anyway.This is similar to what both Blender and Godot are doing too, likely for similar reasons (have API in radians, but for display and input in editor — degrees are easier to use).
This affects both singlevalue fields and 4D vectors. So for singlevalue field (like
TCastleTransform.Rotation.W
) typing"45"
is understood as"deg(45)"
. For editing rotation as 4D vector (axis + angle) typing"0 1 0 45"
is understood as"0 1 0 deg(45)"
. You will see the"deg(...)"
added immediately, so it is hopefully clear what happens. 
To be consistent, you can also use
Deg
in Pascal. It’s just an alias forDegToRad
.The
deg(....)
case doesn’t matter.Deg
ordeg
orDEG
are the same. To interpret expressions in editor, thedeg
is a function in Castle Script. 
This is also applied to 2D image rotations in
TCastleImageControl.Rotation
andTCastleImagePersistent.Rotation
. Degrees everywhere!

Start the discussion at Castle Game Engine Forum