# How to make a custom SkeletonModifier3D?

`SkeletonModifier3D` is a virtual class, so you can't add it as stand alone node to a scene.

![add skeleton modifier](/storage/blog/design-of-the-skeleton-modifier-3d/add_skeleton_modifier.webp)

Then, how do we create a custom `SkeletonModifier3D`? Let's try to create a simple custom `SkeletonModifier3D` that points the Y-axis of a bone to a specific coordinate.

## 1. Create a script

Create a blank gdscript file that extends `SkeletonModifier3D`. At this time, register the custom `SkeletonModifier3D` you created with the `class_name` declaration so that it can be added to the scene dock.

```gdscript
class_name CustomModifier
extends SkeletonModifier3D
```

![register custom modifier](/storage/blog/design-of-the-skeleton-modifier-3d/register_custom_modifier.webp)

## 2. Add some declarations and properties

If necessary, add a property to set the bone by declaring `@export_enum` and set the `Skeleton3D` bone names as a hint in `_validate_property()`. You also need to declare `@tool` if you want to select it in the editor.

```gdscript
@tool

class_name CustomModifier
extends SkeletonModifier3D

@export var target_coordinate: Vector3 = Vector3(0, 0, 0)
@export_enum(" ") var bone: String

func _validate_property(property: Dictionary) -> void:
	if property.name == "bone":
		var skeleton: Skeleton3D = get_skeleton()
		if skeleton:
			property.hint = PROPERTY_HINT_ENUM
			property.hint_string = skeleton.get_concatenated_bone_names()
```

The `@tool` declaration is also required for previewing modifications by `SkeletonModifier3D`, so you can consider it is required basically.

![bones enum](/storage/blog/design-of-the-skeleton-modifier-3d/bones_enum.webp)

## 3. Coding calculations of the modification in `_process_modification()`

```gdscript
@tool

class_name CustomModifier
extends SkeletonModifier3D

@export var target_coordinate: Vector3 = Vector3(0, 0, 0)
@export_enum(" ") var bone: String

func _validate_property(property: Dictionary) -> void:
	if property.name == "bone":
		var skeleton: Skeleton3D = get_skeleton()
		if skeleton:
			property.hint = PROPERTY_HINT_ENUM
			property.hint_string = skeleton.get_concatenated_bone_names()

func _process_modification() -> void:
	var skeleton: Skeleton3D = get_skeleton()
	if !skeleton:
		return # Never happen, but for the safety.
	var bone_idx: int = skeleton.find_bone(bone)
	var parent_idx: int = skeleton.get_bone_parent(bone_idx)
	var pose: Transform3D = skeleton.global_transform * skeleton.get_bone_global_pose(bone_idx)
	var looked_at: Transform3D = _y_look_at(pose, target_coordinate)
	skeleton.set_bone_global_pose(bone_idx, Transform3D(looked_at.basis.orthonormalized(), skeleton.get_bone_global_pose(bone_idx).origin))

func _y_look_at(from: Transform3D, target: Vector3) -> Transform3D:
	var t_v: Vector3 = target - from.origin
	var v_y: Vector3 = t_v.normalized()
	var v_z: Vector3 = from.basis.x.cross(v_y)
	v_z = v_z.normalized()
	var v_x: Vector3 = v_y.cross(v_z)
	from.basis = Basis(v_x, v_y, v_z)
	return from
```

`_process_modification()` is a virtual method called in the update process after the AnimationMixer has been applied, as described in the sequence diagram above. If you modify bones in it, it is guaranteed that the order in which the modifications are applied will match the order of `SkeletonModifier3D` of the `Skeleton3D`'s child list.

<video autoplay loop muted playsinline>
  <source src="/storage/blog/design-of-the-skeleton-modifier-3d/custom_modifier.webm?1" type="video/webm">
</video>

Note that the modification should always be applied to the bones at 100% amount. Because `SkeletonModifier3D` has an `influence` property, the value of which is processed and interpolated by `Skeleton3D`. In other words, you do not need to write code to change the amount of modification applied; You should avoid implementing duplicate interpolation processes. However, if your custom `SkeletonModifier3D` can specify multiple bones and you want to manage the amount separately for each bone, it makes sense that adding the amount properties for each bone to your custom modifier.

Finally, remember that this method will not be called if the parent is not a `Skeleton3D`.

## 4. Retrieve modified values from other Nodes

The modification by `SkeletonModifier3D` is immediately discarded after it is applied to the skin, so it is not reflected in the bone pose of `Skeleton3D` during `_process()`.

If you need to retrieve the modificated pose values from other nodes, you must connect them to the appropriate signals.

For example, this is a `Label3D` which reflects the modification after the animation is applied and after all modifications are processed.

```gdscript
@tool

extends Label3D

@onready var poses: Dictionary = { "animated_pose": "", "modified_pose": "" }

func _update_text() -> void:
	text = "animated_pose:" + str(poses["animated_pose"]) + "\n" + "modified_pose:" + str(poses["modified_pose"])

func _on_animation_player_mixer_applied() -> void:
	poses["animated_pose"] = $"../Armature/Skeleton3D".get_bone_pose(1)
	_update_text()

func _on_skeleton_3d_skeleton_updated() -> void:
	poses["modified_pose"] = $"../Armature/Skeleton3D".get_bone_pose(1)
	_update_text()
```

You can see the pose is different depending on the signal.

![modified pose](/storage/blog/design-of-the-skeleton-modifier-3d/modified_pose.webp)

### Download

[skeleton-modifier-3d-demo-project.zip](/storage/blog/design-of-the-skeleton-modifier-3d/skeleton-modifier-3d-demo-project.zip)

# Do I always need to create a custom SkeletonModifier3D when modifying a Skeleton3D bone?

As explained above, the modification provided by `SkeletonModifier3D` is temporary. So `SkeletonModifier3D` would be appropriate for effectors and controllers as **post FX**.

If you want permanent modifications, i.e., if you want to develop something like a bone editor, then it makes sense that it is not a `SkeletonModifier3D`. Also, in simple cases where it is guaranteed that no other `SkeletonModifier3D` will be used in the scene, your judgment will prevail.

# What kind of SkeletonModifier3D nodes are included in Godot 4.3?

For now, Godot 4.3 will be containing only `SkeletonModifier3D` which is a migration of several existing nodes that have been in existence since 4.0.

But, there is good news! We are planning to add some built in `SkeletonModifier3D`s in Godot 4.4, such as new IK, constraint, and springbone/jiggle.

If you are interested in developing your own effect using `SkeletonModifier3D`, feel free to make a proposal to include it in core.

## Support

Godot is a non-profit, open source game engine developed by hundreds of contributors on their free time, as well as a handful of part or full-time developers hired thanks to [generous donations from the Godot community](https://fund.godotengine.org/). A big thank you to everyone who has contributed [their time](https://github.com/godotengine/godot/blob/master/AUTHORS.md) or [their financial support](https://github.com/godotengine/godot/blob/master/DONORS.md) to the project!

If you'd like to support the project financially and help us secure our future hires, you can do so using the [Godot Development Fund](https://fund.godotengine.org/) platform managed by [Godot Foundation](https://godot.foundation/). There are also several [alternative ways to donate](/donate) which you may find more suitable.


---
title: "Multiplayer in Godot 4.0: Scene Replication (part 1)"
excerpt: "The long-awaited first post about the multiplayer replication system in development for Godot 4.0 is here!
Check out the design goals, concepts, initial prototype, and as always, stay tuned for more!"
categories: ["progress-report"]
author: Fabio Alessandrelli
image: /storage/app/uploads/public/61a/27f/881/61a27f8816a4e934017559.png
date: 2021-11-27 19:00:00
---

Howdy Godotters!

It's finally time for the long-awaited post about the new multiplayer replication system that is being developed for Godot 4.0.
Below, we will introduce the concepts around which it was designed, the currently implemented prototype, and planned changes to make it more powerful and user-friendly.

*See other articles in this Godot 4.0 networking series:*

1. [Multiplayer in Godot 4.0: On servers, RSETs and state updates](https://godotengine.org/article/multiplayer-changes-godot-4-0-report-1)
2. [Multiplayer in Godot 4.0: RPC syntax, channels, ordering](https://godotengine.org/article/multiplayer-changes-godot-4-0-report-2)
3. [Multiplayer in Godot 4.0: ENet wrappers, WebRTC](https://godotengine.org/article/multiplayer-changes-godot-4-0-report-3)
4. (you are here) [Multiplayer in Godot 4.0: Scene Replication (part 1)](https://godotengine.org/article/multiplayer-changes-godot-4-0-report-4)

## Design goals

Making multiplayer games has historically been a complex task, requiring ad-hoc optimizations and game-specific solutions. Still, two main concepts are almost ubiquitous in multiplayer games: some form of **messaging**, and some form of **state replication** (synchronization and reconciliation).

While Godot does provide a system for messaging (i.e. <abbr title="Remote Procedure Calls">RPC</abbr>), it does not provide a common system for replication.

In this sense, we had quite a few [#networking meetings](https://chat.godotengine.org/) in August 2021 to design a replication API that could be used for the common cases, while being extensible via plugins or custom code.

The design goals that emerged for such an API where:

- Provide an out-of-the-box solution for scene state replication across the network.
- Allow for (almost) no-code prototyping.
- Be extensible with game-specific behaviours (custom reconciliation, interpolation, interest management, etc).
- Allow ex-post (incremental) optimizations of network code.
- Be easy to use for game developers, of course :)

### Glossary

- `State`: The informations (properties) about an Object relevant to the multiplayer game.
- `Spawn`: Creating, or requesting remotely to create a new Object.
- `Sync`: Updating, or requesting remotely to update the state of an Object.

### Security

When dealing with computer networks, it's important to understand the security implication of transfering data across machines.
For instance, Godot does not allow [decoding objects](https://docs.godotengine.org/en/stable/classes/class_multiplayerapi.html#class-multiplayerapi-property-allow-object-decoding) by default, since they could carry scripts with them or force the receiving end to execute specific code during initialization. This is a security vulnerability, as arbitrary code execution of this kind would allow for servers to access or manipulate any file on the client's filesystem that the game process has access to.

In a similar way, the replication API will let you specify which scenes can be spawned by a remote peer. Tthe final implementation will also allow for fine-grained control over which node can be spawned at each specific path.

### Optimizations

Optimizations, and bandwidth optimizations in particular, are crucial to an effective networking protocol.

- Synchronizing multiple properties is very useful in the prototyping stage, but bad in terms of potential optimizations.
- A very quick way to optimize the network code later on is to replicate a single property that returns a tightly packed representation of the object state based on your game's unique characteristics.
  When done properly, this is also going to be the most optimized state possible that no tool can produce for you.
- The replication API will still try to squeeze the state size as much as possible with the information in its hands.


---
title: "Godot Engine reaches 2.0 stable"
excerpt: "Godot 2.0 is out! This release is special because our team has grown a lot. We have more regular contributors, a documentation team, a bug triage team and a much larger community! Godot keeps growing and becoming more and more awesome."
categories: ["release"]
author: Juan Linietsky
image: /storage/app/uploads/public/56c/bd3/9db/56cbd39dbdddc275301297.png
date: 2016-02-23 00:00:00
---

## Godot 2.0

A little more than two years ago, Godot was open sourced. It was meant to be an in-house tool and, while it worked for use in internal projects, it was far from the usability expected when you have thousands of developers working with it.

After a year of hard work and community feedback, Godot 1.0 was released, marking the first version that was ready for general consumption. This version worked well but we felt it was still far from the usability and features of a modern game engine. The more urgent issue was to improve the 2D engine so we worked hard again and released Godot 1.1, which did in fact improve 2D rendering considerably.

Usability still remained a pressing issue, so we made a long list of tasks to improve upon for 2.0. We worked hard and after about 8 months we now finally have a stable Godot ready for you!

This release is special because our team has grown a lot. We have more regular contributors, a documentation team, a bug triage team and a much larger community! Godot keeps growing and becoming more and more awesome.

[See the full list of changes](http://downloads.tuxfamily.org/godotengine/2.0/Godot_v2.0_stable_changelog.txt).

## New core features

While for 2.0 core changes were not a priority, there are some nice improvements on this release!

#### Improved scene instancing

Instancing is one of Godot's best features. For this version it has been further improved. Previously, only the root node of a scene was editable. Changes to sub-nodes would result in data loss.

It is now possible to edit any children node of the instanced scene and have the changes persist. Even sub-instances of instances can be edited with persistent modifications.

![](/storage/app/media/godot2_15.png)

#### Scene inheritance

Begining Godot 2.0 scenes can not only be instanced but also inherited. This allows many interesting use cases such as:

* Having a base scene (ie, enemy, collectable, obstacle, etc.) with a node hierarchy common to all (like explosions, shines, indicators, etc), and then extend it for each class.
* Making non-destructive changes to a scene that was imported (ie a 3D scene, etc.)
* Making non-destructive changes to a scene created by another team member.

![](/storage/app/media/godot2_16.png)

#### New text-based scene format

Godot supports the XML format for saving scenes and resources, but we had problems with it:

* Scenes are saved packed in xml, so the content is uncomprehensible.
* The format is not efficient to parse.
* It is not friendly to VCS (Git, SVN).
* XML is not easy to write manually, and it's easy to make mistakes.

Having this in consideration, Godot 2.0 adds a new text file format inspired by [TOML](https://github.com/toml-lang/toml). This new format is descriptive (human friendly) when saving scenes, and  Git/SVN friendly:

![](/storage/app/media/godot2_11.png)

For 3.0, this format will be the only text based format supported, and XML will be deprecated.

#### ``onready`` & singletons

Initializing class member variables can be quite of a hassle, code such as this is common in GDScript:

![](/storage/app/media/godot2_12.png)

The 'onready' keyword allows initialization of class member variables at the same time when _ready is called, saving some code:

![](/storage/app/media/godot2_12b.png)

But doing this for autoloaded scenes can still be a hassle, as it has to be done every time a script is created. To ease on this, it's possible to make an autoloaded scene or script a singleton variable (accessible at global scope) in the project settings:

![](/storage/app/media/godot2_12c.png)

All this, of course, working together perfectly with code completion.

#### Other new core features

Smaller new core features were also added:

* Support for ZIP packs on export instead of PCK
* Support for OPUS Audio Format
* Changed to a more compatible JPG decoder.
* Very improved gamepad support


cripting

### GDScript

With **GDScript** being the most used language among current Godot users, we wanted to really improve the coding experience in Godot 4 with some of the most requested language features.

You will find the static typing system is now more robust with no cyclic dependency errors and the ability to type arrays. You can reap the benefits of first-class functions, lambdas and signals, a new property syntax, the await and super keywords, and functional tools like map or reduce.

![Screenshot of a GDScript file showing some of the new syntax in Godot 4.0](/storage/blog/godot-4-0-sets-sail/05-scripting-new-syntax.png)

With less use of strings, your code can be much more reliable. New built-in annotations make the language clearer and improve syntax for exported properties. You can name variables and functions using unicode characters, making code easier to write and read for developers who rely on non-latin alphabets.

Error reporting improved considerably with the compiler's ability to report many errors simultaneously using more explicit error messages and new warnings for common mistakes.

![Screenshot of a GDScript file with multiple errors highlighted in red](/storage/blog/godot-4-0-sets-sail/05-scripting-multiple-errors.png)

To top it off, your scripts can now automatically generate documentation in the built-in help and the Inspector dock tooltips. This practical and time-saving feature was implemented by a student, Thakee Nathees ([ThakeeNathees](https://github.com/ThakeeNathees)), during the 2020 Google Summer of Code. You can read their report [here](/article/gsoc-2020-progress-report-1#gdscript-doc).

Despite growing in features, the GDScript runtime is much faster and more stable in Godot 4. This was achieved by a complete rewrite of the language backend by our main scripting maintainer George Marques ([vnen](https://github.com/vnen)). If you are interested in further reading, George provided several detailed reports on the new language features ([1](/article/gdscript-progress-report-new-gdscript-now-merged), [2](/article/gdscript-progress-report-feature-complete-40)) and on the decision-making process for the new language parser and runtime ([1](/article/gdscript-progress-report-writing-tokenizer), [2](/article/gdscript-progress-report-writing-new-parser), [3](/article/gdscript-progress-report-type-checking-back), [4](/article/gdscript-progress-report-typed-instructions)).

### C\#

The much-anticipated port to .NET 6 now allows users to target a newer framework that brings optimizations and new APIs. With .NET 6, projects use C# 10 by default and all features are available.

Of course, the 4.0 release is also a great opportunity to break compatibility and improve the API. If you’re a C# user we highly recommend checking out this [blog post by Raul Santos](/article/whats-new-in-csharp-for-godot-4-0/), to find out all that’s new in C# for Godot 4.0.

One of the most notable changes is the use of 64-bit types as scalar values. This means many APIs that used int or float now use long and double with the most noticeable being the `_Process` method. A Variant type is also now implemented in every API that takes variants where `System.Object` was used in the past. This brings some improvements such as avoiding boxing the values.

Another change worth mentioning is the ability to declare signals as C# events. Declaring signals is done by writing a delegate with the [Signal] attribute like in the past, but now the delegate name must end with the EventHandler suffix and an event will be generated. It can be used to connect to and disconnect from the signal. Speaking of signals, connecting them is easier than ever now that you can use C# lambdas without having to spread your code around files.

Finally, Godot 4 moves away from reflection, relying instead on source generators to improve performance, moving a lot of the work that we used to do at runtime to compile time. This also allows us to find and report errors when building the project instead of failing when running the game. We hope the new analyzers will help users write better code and avoid common pitfalls such as unsupported types in exported properties.

Currently, the .NET version of Godot still requires a separate build of Godot but a unified editor is planned for future releases.

**Important remarks:**

-   The C# version of the Godot editor requires the .NET 6.0 SDK to be installed on your computer to work.
-   Godot 4 doesn't support C# projects imported from Godot 3. It may be possible to edit your project files manually, but otherwise it's recommended to let Godot generate a new one.
-   Currently, mobile and web platforms are not available. Support for them will likely come in Godot 4.1.

### GDExtension - experimental

Sometimes user-level scripting is not enough. Being an open-source project, Godot has always valued extensibility.

With the existing GDNative API layer, you could already extend the engine without forking or recompiling it. But it was our first attempt at making a nice abstraction layer for engine internals that you could plug and play into. And so for all its benefits, GDNative didn't feel quite there yet.

With Godot 4, we introduce a new system called **GDExtension**. By design, it takes the best parts of creating GDNative extensions and writing custom engine modules using high performance languages such as C, C++ or Rust.

The code that you make with GDExtension can be ported into the engine if need be, and vice versa: Some engine parts can be made into a GDExtension library, reducing engine bloat. It also offers tighter integration into the editor now as you can expose your extension code as nodes and the engine will automatically generate help pages.

GDExtension was implemented by Juan and George, and further improved by many contributors, especially while porting the [official godot-cpp C++ bindings](https://github.com/godotengine/godot-cpp). Resident XR enthusiast and Godot contributor Bastiaan Olij ([BastiaanOlij](https://github.com/BastiaanOlij)) took the time to write a blog post to [introduce GDExtensions](/article/introducing-gd-extensions).

**Important remarks:**

-   This feature is still experimental so it's reasonable to expect breaking changes as the API gets polished.
-   Godot 3 GDNative libraries are not automatically compatible.
-   Documentation is still a work in progress.

## Physi


nalization

### Extended Language Support

Localization is probably the most straightforward way to allow more people to experience your game or use your tool efficiently. As a tool itself, Godot 4.0 is the first to benefit from the new added support for bidirectional text and font ligatures. This means you can not only create games for a worldwide audience, but developers who use right-to-left languages themselves (Arabic, Urdu, Farsi, etc.) can now use Godot in the language they are most comfortable with.

<video autoplay loop muted playsinline>
  <source src="/storage/blog/godot-4-0-sets-sail/08-ui-text-in-different-languages.mp4" type="video/mp4">
</video>

### Easier Translation Workflow

The second challenge of distributing your project to a wider audience is, of course, translation. Godot 4's editor can now generate Portable Object Template (or POT) translation files directly from your project's scenes and scripts. This makes it easy for translators to work with your content and produce complete translations. If your workflow uses other file formats, you can also add your own parser.

Godot 4's translation system is now context-aware. It allows you to have multiple translations of the same string depending on the context. It also supports plurals allowing for correct translation depending on the quantity.

Your localization efforts are further assisted by a built-in pseudolocalization tool. Implemented by Angad Kambli ([angad-k](https://github.com/angad-k)), a Google Summer of Code 2021 student, it allows to easily test the effects of diacritics and other font permutations on your UI without having to rely on actual translations to stress test your project. You can learn more about pseudolocalization features in the student's report [here](/article/gsoc-2021-progress-report-1#pseudolocalization).

## Editor & UX

Many of the exciting new features you can now leverage in your projects have also been applied to the editor itself to improve your experience. The new text rendering system and bidirectional text support is not the only example.

Further improving accessibility to a wider pool of users, the editor now features enhanced touch support for Android devices.

Another example of a practical feature you can already use in your own projects and that is being added to the editor itself is multi-window support. You can already move docks like the Inspector to other monitors, and more parts of the interface should support popping as separate windows in upcoming Godot 4 releases.

![](/storage/blog/godot-4-0-sets-sail/10-editor-floating-dock.png)

### Easier Importing

Importing is finally much easier. Resolving a major past pain point associated with importing 2D and 3D assets, Godot 4 now comes with a [dedicated import dialog](https://github.com/godotengine/godot/pull/47166). It allows you to preview and customize every part of the imported scene, its materials and physical properties. Scripts can still be used for additional tweaks, thanks to the [new plugin interface](https://github.com/godotengine/godot/pull/53813).

![](/storage/blog/godot-4-0-sets-sail/10-editor-import-window.png)

You should also notice a [significant bump](https://github.com/godotengine/godot/pull/47370) in textures import speed thanks to the etcpak library, and the new multi-threaded importer. Additionally, you can now [import your glTF files](https://github.com/godotengine/godot/pull/52541) at runtime, allowing for more modular 3D projects and tools made with the engine.

Give it up to K. S. Ernest Lee ([fire](https://github.com/fire)), who brought in his expertise as an import and usability specialist.

### New Editor Features & Widgets

You will notice a myriad of new editor features and widgets created to simplify your workflow and give you better control.

The new command palette, added by a student during Godot Summer of Code this year, provides quick access to a lot of editor operations for keyboard-proficient users. Read a report by Bhuvaneshwar ([Bhu1-V](https://github.com/Bhu1-V)) [here](/article/gsoc-2021-progress-report-1#command-palette) to learn more about this feature.

The “default_env.tres” which added a fallback environment to all projects has been replaced by an in-editor default DirectionalLight3D and WorldEnvironment. This makes it easy to tweak lighting and effects and preview assets in the editor without the hassle of having to remember to manually disable your in-editor nodes at runtime. For more information, see the [blog post](/article/editor-improvements-godot-40).

The new color pickers with different picker shapes and color modes allow you to quickly select or update your project's color palette.

![](/storage/blog/godot-4-0-sets-sail/10-editor-color-picker.webp)

The new history dock shows your undo and redo history and lets you jump to any step very quickly. The undo history now works per scene, so pressing Ctrl Z will stick to the active scene.

### Inspector Dock Improvements

The inspector dock has received its share of attention too. You can finally export your custom resource types from your scripts and directly reference nodes in the inspector, saving you time during development. Similarly, you can use annotations to draw sections and organize properties. You will also find it easier to edit arrays, dictionaries, and complex resources in the inspector, complete with pagination.

### Scene Dock Improvements

The scene dock offers new ways to search and filter nodes quickly, which is a big time saver for large scenes. Another big time saver has got to be the new and improved script templates, which can now be [customized per node type](https://github.com/godotengine/godot/pull/53957). The editor even comes with some handy physics body templates, courtesy of Fabrice.

### Script Editor Improvements

The script editor has also leveled up. It now features greatly improved syntax highlighting, font ligatures, and multiple cursor support. You'll notice new icons in the margin indicating when you override a function and linking you to the parent implementation or to the documentation.

<video autoplay loop muted playsinline>
  <source src="/storage/blog/godot-4-0-sets-sail/10-editor-multiple-cursors.mp4" type="video/mp4">
</video>

You can now edit various text-based data files in the script editor, such as JSON, YAML, and more.

One of the features already backported to Godot 3.5 is the ability to mark a node as unique in your scene. You can now apply this to multiple nodes simultaneously and quickly access these nodes in your scripts without writing their full paths. Nodes marked as unique are cached so the performance when accessing them is great.

Also, everything supports drag and drop to the script editor. You can control-click and drag multiple nodes to create on-ready variables, or just click and drag nodes or files into the script editor to get their path.

### Easier Version Control

You will encounter fewer merge conflicts when using a version control system because resources are now assigned unique identifiers instead of relying on file paths.

The editor will also store the version last used to edit a project inside the project.godot file. This way you will be able to quickly check what version of Godot a project was created with. Additionally, the project manager will show a warning if you try to edit a project made with a different version of Godot, or a project made using unavailable engine features.

### New Movie Maker Mode

Showcasing your progress is of course an integral part of your experience with a game engine. For that, Godot 4 introduces the new movie maker mode. It allows you to render scenes frame by frame at the maximum quality settings to record videos or trailer footage using the engine. Godot can render frames to a compressed AVI video or as a sequence of PNG images for lossless rendering.

### New Editor Theme

Finally, because design deeply matters when you're staring at your screen for hours, Hugo has also created a [new editor theme](https://github.com/godotengine/godot/pull/45607) with a more modern feel and improved color schemes for better accessibility. It can be tailored to your preferences through multiple theme customization options.

## Navigation

<a


Editor

#### Node copy-pasting

Being able to easily cut/copy and paste nodes sounds like a basic feature to have, but it is only now that it [could finally be implemented in a reliable way](https://github.com/godotengine/godot/pull/34892), thanks to the hard work of Tomasz Chabora ([KoBeWi](https://github.com/KoBeWi)). Previously, to copy nodes within the scene, they had to be duplicated and dragged under the desired parent. Moving nodes between scenes was only possible by using the clunky "Merge from scene" feature. Being able to copy nodes as easily as you can copy text was probably one of the most-wanted features since the first release of Godot!

There were multiple attempts at implementing it, but it took time to refine them into someting reliable that could be merged, especially due to the need to take into account the full complexity of the scene tree (instanced scenes, editable children, shared or unique resources and subresources, etc.). In Godot 3.3, the dream has come true: nodes can be cut, copied and pasted, both within the same scene and between scenes. Manipulating the scene tree has never been this convenient.

![Node copy-pasting in action!](/storage/app/media/3.3/copy-paste.gif)

*Hello again, [`logo.png` stickman!](https://twitter.com/01lifeleft/status/959761839897767936)*

#### Improved Inspector sub-resource editing

[After much discussion](https://github.com/godotengine/godot-proposals/issues/2230), Juan Linietsky ([reduz](https://github.com/reduz)) implemented a change to the Inspector to [better highlight sub-resources visually](https://github.com/godotengine/godot/pull/45907), so that it's easier to know which resource you're editing when there are more than two levels.

This was implemented for Godot 4.0 but was fairly easy to backport, so here you go! The colors and contrast can be customized in the editor settings.

![New colored sub-resource edition in the Inspector](/storage/app/media/3.3/inspector-subresource.png)

#### Import presets configuration

When you add assets to a Godot project, most of them get imported to engine internal formats on the fly based on options configured in the Import dock. There are some pre-existing presets for all asset types, and you can define which preset should be used for all resources of the same type (e.g. "2D Pixel" preset for textures), but until there was no easy way to configure all presets easily in a unified interface.

For Godot 4.0, Juan implemented a new tab in the Project Settings dialog to [configure those "Import Defaults"](https://github.com/godotengine/godot/pull/46354), and this was backported to Godot 3.3.

![Import Defaultsconfiguration in the Project Settings](/storage/app/media/3.3/import-defaults.png)

Additionally, a new ["Keep" import mode](https://github.com/godotengine/godot/pull/47268) was added to configure specific files to be left as-is (i.e. not imported) by Godot's import system. This is particularly useful for files which you intend to process yourself from scripts based on their raw contents (e.g. using the `File` API, loading it as text or bytes), such as CSV files used as database (as opposed to Godot's default CSV import preset as translation catalogs).

!["Keep" import mode for files you don't want to import](/storage/app/media/3.3/import-keep.png)

#### 3D editor improvements

Contributors such as Aaron Franke ([aaronfranke](https://github.com/aaronfranke)), Joan and Hugo did a significant amount of work improving the usability of the 3D editor for 4.0, and most of it was backported to the 3.3 branch.
This includes changes such as:

- [Dynamic infinite 3D grid](https://github.com/godotengine/godot/pull/43206) ([further improved here](https://github.com/godotengine/godot/pull/45594)).
- [A much-improved 3D rotation gizmo](https://github.com/godotengine/godot/pull/43016), with [increased opacity for better visibility](https://github.com/godotengine/godot/pull/44384).
- [A better 3D selection gizmo](https://github.com/godotengine/godot/pull/40106).

![Infinite 3D grid with far away lines fading out](/storage/app/media/3.3/infinite-3d-grid.png)

*To infinity and beyond!*

#### Detect external scene changes

One of the biggest hurdles when working with Godot projects in a team was that it's very easy to overwrite changes made by another person if they modified a currently opened scene. How often did you pull changes from Git to only see them discarded, because Godot didn't detect that the scene had changed? While with scenes you just had to reload them, modifications to `project.godot` by another team member required you to restart the Godot editor to properly apply changes. This was especially problematic during game jams where multiple people work on the same small project simultaneously.

Thanks to Tomasz again, with Godot 3.3, any external changes to opened scenes or `project.godot`, be it VCS pull or external text editor modification, are [properly detected by the Godot editor](https://github.com/godotengine/godot/pull/31747) and you get an option to either reload the affected files, discard the changes or do nothing (which in most cases means another prompt when the editor is re-focused).

![Dialog when external scene changes are detected](/storage/app/media/3.3/scene-reload.png)

Do note that due to how built-in resources (resources saved within the scene instead of separate files) work, some of them might sometimes not get reloaded correctly (this especially applies to built-in scripts). It's a known infrequent issue, already fixed in Godot 4.0.

### Scripting

#### GDScript

No big change for GDScript in this release as all the focus has been on the rewrite and optimization of GDScript for Godot 4.0.
Still, there's been a [number of bugfixes](https://github.com/godotengine/godot/pulls?q=is%3Apr+sort%3Aupdated-desc+milestone%3A3.3+label%3Atopic%3Agdscript+is%3Amerged) which should make the experience more stable.

As for eye candy, Yuri Roubinsky ([Chaosus](https://github.com/Chaosus)) implemented a feature to [preview `Color` constants in the auto-completion drop-down](https://github.com/godotengine/godot/pull/43026):

![Color constant preview in the GDScript auto-completion drop-down](/storage/app/media/3.3/gdscript-colors.gif)

#### Mono/C#

C# users will benefit from a [redesign of the solution build output panel](https://github.com/godotengine/godot/pull/42547) made by Ignacio Roldán Etcheverry ([neikeq](https://github.com/neikeq/)):

![New C# solution build output panel](/storage/app/media/3.3/mono-output-panel.png)

There have been further fixes to the solution and build system, allowing users to [target .NETFramework with the Godot.NET.Sdk and .NET 5](https://github.com/godotengine/godot/pull/44135).
Moreover a 3.2.2 regression was fixed for [`System.Collections.Generic.List` marshalling](https://github.com/godotengine/godot/pull/45029), and [Unicode identifiers are now properly supported](https://github.com/godotengine/godot/pull/45310).

There's also been [extensive](https://github.com/godotengine/godot/pull/44373) [work](https://github.com/godotengine/godot/pull/44374) on Mono compatibility with WebAssembly.

### O


---
title: "Core refactoring progress report #2"
excerpt: "As promised in my previous post, the core refactoring work I am undertaking took two months to complete. This means rewriting large parts of the core engine for consistency and features."
categories: ["progress-report"]
author: Juan Linietsky
image: /storage/app/uploads/public/5e7/f74/307/5e7f74307ce34896455561.jpeg
date: 2020-03-28 00:00:00
---

As promised in my previous post, the core refactoring work I am undertaking took two months to complete. This means rewriting large parts of the core engine for consistency and features.

### Core refactoring

Core refactoring is mostly work on the most low level, critical and shared parts of the engine. This work is done only on major versions because it implies breaking compatibility and introducing instability and bugs (because of all the new added code), which is actually the case right now. The major refactoring undertaken for Godot 3.x, two years ago, changed a large part of the internals, but we were unable to do everything we wanted to do.

The migration to Vulkan already implied breaking compatibility and, together with all the user feedback we got since 3.x was released, we have a very good idea of what needed to change in this time.

So following is the list of what changed during March:

#### OS / DisplayServer split

One of the largest singletons in Godot is the [OS](https://docs.godotengine.org/en/3.1/classes/class_os.html) class. It allows access to low-level OS functions as well as window management.

This was cumbersome for many reasons and also imposed limitations, such as:

* Having a large, bloated OS class on every platform.
* Inability to support different display APIs in a single binary. This is specially visible in Desktop Unixes, where you can use X11, Wayland or even EGL directly on Raspberry PI.
* Proper support for multiple windows. This not only allows the editor to make some docks float so you can move them to another monitor (a very requested feature by users). This is also useful for games developed for certain types of dedicated hardware, or just for tools created with Godot as the base platform (which is something several users do).
* Impossible to run the engine as headless (with a dummy display driver) in all platforms. The "server" platform had to be used as a workaround (and will now be deprecated).
* Difficult to abstract window management functions to users, which had to access the OS class directly (and which is not as user friendly as working with nodes).

The new implementation moves all low level window management to a new singleton, **DisplayServer**, which handles everything regarding display. To make implementation simpler and more portable, Godot will always assume you have one _main window_ and, if platform supports, allow you to create _sub windows_.

#### Window node

The new **DisplayServer** allows managing multiple windows, but using it directly is still too low level and unfriendly for most users. To compensate, a new **Window** node has been introduced. This node inherits **Viewport** and gives it the ability to appear as a floating window. Working with it is easy: just place your nodes as children of Window!  You can create UIs (with controls), or display the 3D world on it (just adding a **Camera** node). It' s basically the same as a Viewport, so Using this new node is extremely easy and straightforward.

![embedded2.jpeg](/storage/app/uploads/public/5e7/f73/7eb/5e7f737eb5c64127870073.jpeg)

Additionally, the root node in Godot (```get_tree().get_root()```), which used to be of type **Viewport**, has now changed to be of **Window** type. If you want to manage the game window, simple access this node directly.

All input events, which were previously sent to the *MainLoop* class, are now sent directly from **DisplayServer** to *Window* (so MainLoop and hence, *SceneTree* have been stripped of this functionality).

#### Multiple Window Support in Editor

Likewise, the Godot Editor now supports making the docks float. For now, only docks and existing windows are supported but we will extend support for other parts of the editor.

It is important to note that by default **docks will remain *docked* ** and nothing will change. Some users expressed concerns that we would now force them to always use floating windows. This **is not the case**, you can make windows separate from the main one **only if you want** (like as an example, you have a second monitor and you want to make use of more screen-space), but by default **nothing will change**.

#### Embedded mode

But, what if you are working on a full-screen game and need to use windows? Or what about platforms which don't support floating windows such as iOS, Android, HTML5 or even consoles?

One of the new features of this system is that the **Viewport** class can now be instructed to embed all children **Window** nodes and provide internal windows for them, so it will emulate a window manager within it, including decorations, resizing, title bar, close button, etc. This can be done manually by toggling the "embed subwindows" property.

At the same time the new **DisplayServer** can be queried for features and one of them is *subwindow* support, so the new root **Window** will check whether this is supported on each platform and toggle the property automatically. This is completely transparent to the user, so games (or the editor) don't need to be change to run on platforms that don't support subwindows.

![embedded3.png](/storage/app/uploads/public/5e7/f73/92d/5e7f7392d353b123436098.png)

If, for debug purposes, you want to run the editor (or your game) using subwindows instead of hardware windows, use the ```--single-window``` command line flag.

### Node renames

The Godot scene system is known for its ease of use and its ability to represent your mental map as a data and file structure. That said, many node names were not clear or confusing. This is mainly evidenced when comparing their 2D and 3D counterparts.

Contrary to what many believe, Godot started as a 3D engine, but soon migrated to be a 2D one. This is why the 3D nodes don't have any suffix (like Area) while the 2D ones do (Area2D). This made it very misleading for users, where its not always obvious whether you are using the 2D or 3D versions.

To solve this, Godot 4.0 will rename all 3D nodes and give them proper suffixes. Nodes like "Area","RigidBody" or "Light" will become "Area3D", "RigidBody3D" and "Light3D" respectively.

Additionally, due to popular demand, the "Spatial" node will be renamed to "Node3D", to further enhance consistency with the 2D engine.

![nodenames.png](/storage/app/uploads/public/5e7/f74/038/5e7f74038bd23290506434.png)

A compatibility system has been added so older scenes will convert the node types to the new ones on load.

### Server renames

Most servers in Godot are very old, and their naming conventions were by now obsolete. Because of this, most are being renamed:

* **VisualServer** (a name that became even more ambiguous thanks to the introduction of DisplayServer) has been renamed to **RenderingServer**.
* **NavigationServer** and **PhysicsServer** have been renamed to **NavigationServer3D** and **PhysicsServer3D** respectively.
* Likewise, to add more consistency, **Physics2DServer** and **Navigation2DServer** are now **PhysicsServer2D** and **NavigationServer2D**.

### Future

My work on core refactoring is mostly done, so next month (April) I will go back to working on Vulkan as promised. Hope to have new and exciting stuff to show by the end of next month!

And as always, please remember than our work on Godot is done out of love for you and the game development community, we want to provide you with a top notch free and open source game engine, so you can own your work down to the last line of engine code. If you are not yet, please consider becoming [our patron](https://www.patreon.com/godotengine) and help us realize this dream sooner.


---
title: "Current state of C# platform support in Godot 4.2"
excerpt: "How the transition to a unified .NET has impacted platform support, and re-adding the ability to port to mobile."
categories: ["progress-report"]
author: Raul Santos
image: /storage/blog/covers/progress-update-csharp-2.webp
date: 2024-01-26 17:00:00
---

With the recent release of Godot [4.2](/article/godot-4-2-arrives-in-style), projects that use C# can now export to Android and iOS. Let's take a look at the current platform support for C# projects and what to expect from future releases beyond 4.2.

## Background

First a bit of history. Godot 3 supports exporting C# projects to all the platforms supported by the engine. The C# implementation uses the [Mono embedding APIs](https://www.mono-project.com/docs/advanced/embedding/) and the [Mono runtime](https://www.mono-project.com/docs/advanced/runtime/). **Mono** is an open source cross-platform implementation of the Windows-only .NET Framework.

With the [4.0 release](https://godotengine.org/article/godot-4-0-sets-sail/), the C# integration moved away from the Mono embedding APIs and replaced it with the .NET Core hosting APIs (using the `hostfxr` library). This allowed us to modernize the codebase and prepare for [.NET 5](https://devblogs.microsoft.com/dotnet/introducing-net-5/), the first release in the .NET unification journey. Unfortunately, in this move C# projects lost the ability to export to platforms other than Desktop (Windows, macOS and Linux).

Before **.NET unification** there was the Windows-only .NET Framework and the cross-platform Mono and .NET Core. Unification means there will be just one .NET going forward, so the next release after .NET Core 3.0 was named .NET 5, and Mono and .NET Framework won't have any new major releases.

The term **Mono** can be used to refer to a collection of technologies. With .NET unification, the Mono framework is deprecated, but the runtime is still supported. Unified .NET uses both the CoreCLR and the Mono runtimes, but Mono is the only runtime that supports mobile and web platforms.

However, in .NET 7.0 a new runtime became available, [**NativeAOT**](https://learn.microsoft.com/en-us/dotnet/core/deploying/native-aot), which allows publishing native binaries built for a specific platform, instead of the JIT-based portable binaries. In .NET 7.0, NativeAOT only supports Windows and Linux, but in .NET 8.0 it adds support for macOS and experimental support for Android and iOS. This means in .NET 8.0 NativeAOT can be used as an alternative to Mono for mobile platforms.


---
title: "Web Export in 4.3"
excerpt: "With single-threaded builds and sample playback, it's now easier than ever to export your game to the Web with Godot 4.3. And more!"
categories: ["progress-report"]
author: Adam Scott
image: /storage/blog/covers/progress-report-web-export-in-4-3.webp
image_caption_title: "Catburglar"
image_caption_description: "An open source game by @JohnGabrielUK and his team"
date: 2024-05-15 13:15:00
---

Have you ever begun some type of work, and only after realized how little you actually knew? That happened to me during [the last GDC](https://godotengine.org/article/gdc-2024-retrospective/).

A few months ago, I took over [Fabio Alessandrelli's (@faless)](https://github.com/Faless/) responsibilities as [Web Platform Lead](https://godotengine.org/teams/#platforms) for Godot to reduce his task load and accelerate the pace at which our Web platform exports continue to improve.

I'm well used to the Web and its quirks. I began creating websites in XHTML and (vanilla) JavaScript, back in the days. Flash games were my jam! Enough so that I even worked for a video game studio as an ActionScript 3 developer in 2010. And I didn't really stop caring about the Web platform ever since.

Since then, Flash may have died, but online games didn't.

# The new situation
But what I realized at the GDC is that we're entering into a sort of Golden Age of Web games. Not only websites like [Poki](https://poki.com/) or [Crazy Games](https://www.crazygames.com/) are super popular, but big players are starting to integrate Web games into their services, such as
[Discord Activities](https://support.discord.com/hc/en-us/articles/4422142836759-Activities-on-Discord) or [YouTube Playables](https://www.youtube.com/playables). All these entities want developers to create games for their platform, and they are all asking how Godot can bring a first-class development experience to it.

# G


odot 4.3
Making games for the Web using Godot 4.x still isn't as seamless as we would like it to be. Unfortunately serious revisions are needed to improve the experience to the extent that we want.

Godot 4.3 promises to be one of the best recent releases for Web exports. One of the biggest issues relating to this has been properly fixed: single-threaded exports.

## Single-threaded Web export

### Betting on the wrong horse
[`SharedArrayBuffer`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/SharedArrayBuffer)s were supposed to revolutionize the Web. And they did. That API permits to share memory between [Web Workers](https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API/Using_web_workers) (which are the Web native "threads").

Unfortunately, we live in the same timeline that includes the [Spectre and Meltdown exploits](https://meltdownattack.com/).

The result of this is that [browsers greatly reduced where and how you can use that API](https://developer.chrome.com/blog/enabling-shared-array-buffer?hl=en). Namely, browsers nowadays require websites to be [cross-origin isolated](https://web.dev/coop-coep/). When isolated, it does unlock the potential of `SharedArrayBuffer`s, but at what cost?

At the cost of having the capacity to make remote calls to other websites. _Adieu_ game monetization. _Adieu_ interacting with an external API.

The issue is that during the development of Godot 4, we bet on the wrong horse: we went all-in with using threads with `SharedArrayBuffer`s. We thought it was mainly a question of [browser support](https://caniuse.com/sharedarraybuffer) (which took a step back due to the aforementioned security issues), so when all browsers finally shipped stable releases with `SharedArrayBuffer`, we streamlined everything around multi-threading.

But we underestimated the difficulty of configuring cross-origin isolated websites.

We know it has been a hurdle for a lot of users trying to publish their jam games on [itch.io](https://itch.io), which has an experimental `SharedArrayBuffer` option, but relying upon another feature ([`coep:credentialless`](https://caniuse.com/mdn-http_headers_cross-origin-embedder-policy_credentialless)) not supported by Safari or Firefox for Android).

Likewise, most Web games are being published on third-party publishing platforms where the game authors may not even be able to set the required headers for `SharedArrayBuffer` support.

### Backporting the single-threaded feature from Godot 3.x
At the end of the development of Godot 4.2, [the Foundation](https://godot.foundation/) tasked me to find a way to backport the ability to build Godot without using threads in order to export Godot games without the pesky COOP/COEP headers.

This was not easy because 4.0 was made with threads in mind. It maybe explains why we were so hesitant to go ahead with this change. Fortunately, with the help of our thread guru [Pedro J. Estébanez (@RandomShaper)](https://github.com/RandomShaper), I was able to tame the beast and put back single-threaded builds.

[My PR](https://github.com/godotengine/godot/pull/85939) was finally merged at the beginning of the Godot 4.3 development period.

![Web export thread support option](/storage/blog/progress-report-web-export-in-4-3/thread-support-export-option.webp)

It even had some unexpected benefits. Apple devices (macOS and iOS) were long known to have issues when playing Godot Web exports. Well, when you do export your game single-threaded, these issues fortunately disappear.

However, it came with a downside too: it introduced a new, virtually unsolvable bug:

The single-threaded build introduced garbles in the audio of games, making them unplayable on low-end machines such as laptops or phones, or high-end machines with high frame rates.

When I mean unplayable, I mean it. [Try it yourself.](https://adamscott.github.io/2d-platformer-demo-main-thread/){:target="_blank"} (Consider yourself lucky if it doesn't glitch out.)

_Please note: we know that there's some issues running Platformer 2D on Safari, namely the browser reloading the page complaining that "this webpage is using significant memory". We're currently investigating to fix this ASAP._

Yes. Web single-threaded audio stream playback with Godot 4.2 is that bad. It is marginally better on Godot 3.x, but the problem exists there as well.

## Sample playback to the rescue!
[Here comes my PR](https://github.com/godotengine/godot/pull/91382) (not yet merged at the time of writing) for the rescue. [Here's the same demo without sound issues.](https://adamscott.github.io/2d-platformer-demo-main-thread-samples/){:target="_blank"}

### What are samples?
Using samples for games is not a novel idea. In fact, for a long time, it was the _de facto_ way to play sound and music on game consoles. As they didn't have the processing power to do the mixing on the CPU, you could send audio clips (hence the term "sample") to a special chip and tell it how and when to play them.

Since the audio chip was operating on its own, the sound would never lag nor glitch out if the game is lagging.

### (Re)introducing samples to Godot
When open sourced, the Godot engine offered two ways to emit audio: streams for music and samples for sounds.

![The long gone SampleLibrary resource and SamplePlayer2D node on Godot 2.1](/storage/blog/progress-report-web-export-in-4-3/sample-library.webp)

But when Godot 3 released, it was decided that samples support was not needed anymore. Game consoles nowadays ask developers to mix themselves the samples using the CPU. And for the Web, we could mix the audio using a dedicated thread, like other platforms since `SharedArrayBuffer`s exist.

This is why there's audio garbles in single-threaded builds (without my "fix"). Audio rendering is tied with the frame rate. And if it drops, there's not enough audio frames to fill out the buffer, hence the glitches.

What [my PR](https://github.com/godotengine/godot/pull/85939) does is to reinstate sample playback. At least at the time of writing, for the Web platform only.

### Near seamle


---
title: "Dev snapshot: Godot 3.0 alpha 2"
excerpt: "One step closer to the release of Godot 3.0! With this alpha 2 development snapshot, Godot users will be able to preview the upcoming C# support and continue testing the advanced 3D features introduced in Godot 3.0. This snapshot is of course expected to be buggy and unstable, so please be aware that it does not reflect the final state of what Godot 3.0 will be like."
categories: ["pre-release"]
author: Rémi Verschelde
image: /storage/app/uploads/public/59f/8c3/c91/59f8c3c91a87f065753289.png
date: 2017-10-31 18:23:17
---

A little treat (or is it a trick?) for our community on this Halloween eve: Godot 3.0 *alpha 2* is out, ready for your testing! It's already been 3 months since our previous [official development snapshot](/article/dev-snapshot-godot-3-0-alpha-1), and lots of bugs have been fixed, making us one big step closer to the final 3.0 *stable* release.

It's also the first build to include the long awaited support for the C# programming language using [Mono](http://mono-project.com/)! This is of course still pretty rough, though usable, and we are looking forward to your feedback and bug reports. Some caveats are documented below as well as in the [introduction blog post](/article/introducing-csharp-godot), so make sure to read them before filing issues.

## Disclaimer

**IMPORTANT: This is an *[alpha](https://en.wikipedia.org/wiki/Software_release_life_cycle#Alpha)* build, which means that it is *not suitable* for use in production, nor for press reviews of what Godot 3.0 would be on its release.**

There is still a long way of bug fixing and usability improvement until we can release the stable version, and this release comes with incomplete documentation: the in-editor and [online Class Reference](http://docs.godotengine.org/en/latest/) is quite complete thanks to the awesome work of our documentation team, but there aren't many tutorials about using Godot 3.0 yet. For the Mono build, there is no specific documentation yet. This release is exclusively for testers who are already familiar with Godot and can report the issues they experience on GitHub.

There is also no guarantee that projects started with the alpha 2 build will still work later builds, as we reserve the right to do necessary breaking adjustments up to the *beta* stage.

**Note:** New Godot users should *not* use this build to start their learning. Godot 2.1 is still supported and [well documented](http://docs.godotengine.org/en/stable/).

## The features

Since the previous alpha build, there have been hundreds of bugs fixed, as well as many usability enhancements to make the new features as easy to use as possible.

There was also a [strong focus on the documentation](https://godotengine.org/article/first-godot-3-docs-sprint-sept-9), with the Class Reference close to 70% complete now (which is already much higher than the completion level of the 2.x API documentation).

### Quick Mono howto

Of course, the main feature many have been waiting for is the Mono support. It comes in separate binaries with an additional system requirement: the Mono SDK. You need to install the [current stable version](http://www.mono-project.com/download/) of Mono to use with Godot, as you will be developing applications which require the .NET Framework.

If you installed Mono in the classical system directories (using the upstream macOS or Windows installers, or the Linux repositories), everything should work out of the box.

If you installed Mono in a specific directory, things might get a bit more complex. You can override the `MONO_PATH` environment variable to point to the location of your .NET Framework 4.5, typically `/path_to_mono_root/lib/mono/4.5/`. You will also need `msbuild` in your `PATH`, so if you installed it in a location which is not included in the `PATH`, you can either override the latter or create a symbolic link.

## Downloads

The download links are not featured on the [Download](/download) page for now to avoid confusing new users. Instead, browse one of our mirrors and download the editor binary for your platform and the export templates archive:

- Classical version: [[HTTPS mirror](https://downloads.tuxfamily.org/godotengine/3.0/alpha2)] [[HTTP mirror](http://op.godotengine.org:81/downloads/3.0/alpha2)]
- Mono version (requires the Mono SDK): [[HTTPS mirror](https://downloads.tuxfamily.org/godotengine/3.0/alpha2/mono)] [[HTTP mirror](http://op.godotengine.org:81/downloads/3.0/alpha2/mono)]

**Note:** Export templates are currently missing due to a last minute regression in the HTML5 platform (**Edit 2017-10-31 23:00 UTC:** They are now available for the classical version).
Export templates for the Mono flavour will not be provided, as exporting Mono games is not completely implemented yet.

Also clone the [godot-demo-projects](https://github.com/godotengine/godot-demo-projects/) repository to have demos to play with. Some of them might still need adjustments due to recent changes in the *master* branch, feel free to report any issue.

## Bug reports

There are still many open bug reports for the 3.0 milestone, which means that we are aware of many bugs already. We still release this snapshot to get some early feedback while we work on fixing the known issues.

As a tester, you are encouraged to open bug reports if you experience issues with alpha 2. Please check first the [existing issues](https://github.com/godotengine/godot/issues), using the search function with relevant keywords, to ensure that the bug you experience is not known already.

Have fun with this alpha 2 and stay tuned for future, more stable releases :)


## Downloads

{% include articles/download_card.html version="4.1.4" release="rc2" article=page %}

**Standard build** includes support for GDScript and GDExtension.

**.NET 6 build** (marked as `mono`) includes support for C#, as well as GDScript and GDExtension.
- .NET build requires [.NET SDK 6.0](https://dotnet.microsoft.com/en-us/download/dotnet/6.0) or [7.0](https://dotnet.microsoft.com/en-us/download/dotnet/7.0) installed in a standard location.

{% include articles/download_card.html version="4.2.2" release="rc2" article=page %}

**Standard build** includes support for GDScript and GDExtension.

**.NET build** (marked as `mono`) includes support for C#, as well as GDScript and GDExtension.
- .NET build requires [.NET SDK 6.0](https://dotnet.microsoft.com/en-us/download/dotnet/6.0), [7.0](https://dotnet.microsoft.com/en-us/download/dotnet/7.0), or [8.0](https://dotnet.microsoft.com/en-us/download/dotnet/8.0) installed in a standard location.
- To export to Android, .NET 7.0 or later is required. To export to iOS, .NET 8.0 is required. Make sure to set the target framework in the `.csproj` file.

{% include articles/prerelease_notice.html %}

## Known issues

There are currently no known issues introduced by these releases.

With every release we accept that there are going to be various issues, which have already been reported but haven't been fixed yet. See the GitHub issue tracker for a complete list of [known bugs](https://github.com/godotengine/godot/issues?q=is%3Aissue+is%3Aopen+label%3Abug+).

## Bug reports

As a tester, we encourage you to [open bug reports](https://github.com/godotengine/godot/issues) if you experience issues with this release. Please check the [existing issues on GitHub](https://github.com/godotengine/godot/issues) first, using the search function with relevant keywords, to ensure that the bug you experience is not already known.

In particular, any change that would cause a regression in your projects is very important to report (e.g. if something that worked fine in previous 4.x releases no longer works).

## Support

Godot is a non-profit, open source game engine developed by hundreds of contributors on their free time, as well as a handful of part or full-time developers hired thanks to [generous donations from the Godot community](https://fund.godotengine.org/). A big thank you to everyone who has contributed [their time](https://github.com/godotengine/godot/blob/master/AUTHORS.md) or [their financial support](https://github.com/godotengine/godot/blob/master/DONORS.md) to the project!

If you'd like to support the project financially and help us secure our future hires, you can do so using the [Godot Development Fund](https://fund.godotengine.org/) platform managed by [Godot Foundation](https://godot.foundation/). There are also several [alternative ways to donate](/donate) which you may find more suitable.


---
title: "Godot 3.1 will get many improvements to KinematicBody"
excerpt: "One of the features that make Godot stand out is how easy it is to use the physics engine for non-physics games. For Godot 3.1, several improvements are being worked on."
categories: ["progress-report"]
author: Juan Linietsky
image: /storage/app/uploads/public/5b4/de9/702/5b4de97024c77681425121.gif
date: 2018-07-17 00:00:00
---

## KinematicBody

One of the features that make Godot stand out is how easy it is to use the physics engine for non-physics games.
KinematicBody allows controlling a character entity around with a single function (`move_and_slide`). Simply pass a linear velocity, and it will be returned back adjusted while the player moves around the level.

```
velocity = move_and_slide(velocity)
```

This function tries to move the character using that velocity and every time a collision is found, it will slide against it (and adjust the velocity accordingly). Some extra features are also present, such as specifying the floor direction:

```
velocity = move_and_slide(velocity, Vector2(0, -1)) # floor points up
```

After the call, detecting if a character is on floor can be done with a call to:

```
is_on_floor()
```

Likewise for walls. This allows adjusting the player animation accordingly. Godot also detects if the floor below is moving, and it will adjust the character accordingly too.

Unfortunately, despite the ease of use, this approach had a few limitations that could (or not) be evident depending on the type of game you were working on.

## Snapping

The most obvious problem with this approach is snapping to the floor. As the character slides around the level, some situations may lead to the player flying around:

![ramp_normal.gif](/storage/app/uploads/public/5b4/ddc/4ca/5b4ddc4ca68ec721602355.gif)

In some games, this effect may be desired (looks kind of cool), but in other types of games this is unacceptable.

To easily solve this, Godot 3.1 will introduce a new function: ***`move_and_slide_with_snap`***

This function allows a third parameter for a snap vector. It means that, while the character is standing on the floor, it will try to remain snapped to it. If no longer on ground, it will not try to snap again until it touches down.

The snap argument is a simple vector pointing towards a direction and length (how long it should try to search for the ground to snap)

```
# snap 32 pixels down
velocity = move_and_slide_with_snap(velocity, Vector2(0, -1), Vector2(0, 32))
```

This works very well in practice:

![samp_snap.gif](/storage/app/uploads/public/5b4/ddd/89c/5b4ddd89cf5ab658278686.gif)

Of course, you must make sure to disable snap when the character jumps. Jumping is usually done by setting `velocity.y` to a negative velocity (like -100), but if snapping is active this will not work, as the character will snap back to the floor.

Disabling snap can be done by just passing a snap of length 0 (`Vector2()`) to `move_and_slide_with_snap()` or just by calling `move_and_slide()` instead.

A common trick for this is to have a `jumping` boolean variable and toggle it on when the character jumps:

```
# jump logic example with snapping
if is_on_floor() and Input.is_action_just_pressed("jump"):
    # can jump only when on floor
    velocity.y = -100
    jumping = true

# disable jumping when character is falling again
if jumping and velocity.y > 0:
    jumping = false

# preset for snap, 32 pixels down
var snap = Vector2(0, 32)

# oh, but are we jumping? no snap then
if jumping:
    snap = Vector2()

velocity = move_and_slide_with_snap(velocity, Vector2(0, -1), snap)
```

## RayCast Shapes

Another common situation (when using `move_and_slide()`) is that the character incurs more effort going up slopes than it does going down.

![samp_snap.gif](/storage/app/uploads/public/5b4/ddd/89c/5b4ddd89cf5ab658278686.gif)

This is physically correct, but some types of game expect velocity to be constant when moving up and down in slopes.

The solution for this is now the same as when creating a dynamic character controller (physics-based), which is using RayCast shapes. They work now with KinematicBody.

RayCast shapes separate the body in the direction they are pointed to, and will always return a collision normal along their ray, instead of the one provided by the floor (because, again, their goal is to separate). Yes, the name is confusing, maybe they should be renamed to SeparationRayShape in Godot 4.0 :)

In any case, change the collision shape in your body to include a ray pointing down:

![separator_ray.png](/storage/app/uploads/public/5b4/de1/39c/5b4de139c8635728849121.png)

And now, when moving around the stage, the speed will remain constant:

![snap_raycast_snap.gif](/storage/app/uploads/public/5b4/de1/715/5b4de1715ad28642795319.gif)

Keep in mind that the maximum slope angle where this will work will be geometrically determined by the length of the ray, so make sure to adjust the ray length according to the approximate slope you want to support:

![slope_angle.png](/storage/app/uploads/public/5b4/dee/e3b/5b4deee3bc5bf782874519.png)

As you can see in the picture above, the right slope is so steep that it hits the capsule before the ray, so this effectively disables the ray effect and makes the character incur a lot more effort. It happens naturally, without a single line of code needing to be written.

## Sync to Physics

When a KinematicBody is moved around (be it using `move_and_slide`, or just moved around by modifying the `position`, `rotation`, etc. properties), it automatically computes its linear and angular velocity. This means that if either a box with physics (RigidBody) or a KinematicBody (that moves with `move_and_slide`) are standing over it, they will be moved along together.

This makes KinematicBody also very useful for moving platforms, elevators, scripted doors, etc.

The main limitation until now is that, when used as moving platform, its motion was always a frame ahead than the physics, so the character appears to slowly slide over it:

![moving_plat_old.gif](/storage/app/uploads/public/5b4/de7/118/5b4de71180c66281786233.gif)

To compensate with this, a new option "*Sync to Physics*" was added. This option is useful when animating via AnimationPlayer or tweaking the position/rotation properties manually in the object:

![sync_to_physics.png](/storage/app/uploads/public/5b4/de7/7cf/5b4de77cf3819709564138.png)

When enabled, objects will appear in sync with the KinematicBody:

![moving_plat_new.gif](/storage/app/uploads/public/5b4/de7/c23/5b4de7c231685692508567.gif)

## Future

After these functions are well tested, they will be ported to the 3D engine, where they should work in the exact same way.

Once again, please remember that all this done with love for everyone. Our aim is to make a 100% free and open source game engine where the games you make with it are truly yours.

This progress is made possible thanks to the infinite generosity of our patrons. If you are not one yet, please consider [becoming our Patron](https://www.patreon.com/godotengine). This way, you don't need to be an expert engine programmer to aid with Godot development :)


---
title: "Godot 3.0 switches to Bullet for physics"
excerpt: "When Godot started (a decade ago), there were not many good physics engine available and Godot always had quite demanding API requirements for them (such as Area nodes, KinematicBody, RayCast shapes, etc.), so they were not usable without a lot of modification. This led us to implementing our own custom engine. Now, thanks to the work of Andrea Catania, we are introducing Bullet as a new and better maintained backend for the 3D physics!"
categories: ["progress-report"]
author: Juan Linietsky
image: /storage/app/uploads/public/59f/f1b/66d/59ff1b66d1fbe773318157.png
date: 2017-11-05 00:00:00
---

***Update:** Due to several circumstances (such as a shift of focus from upstream Bullet developers away from game development), Godot 4.0 is going back to its in-house physics engine for 3D (GodotPhysics). Bullet is no longer available in Godot 4.0, but it (or other physics engines like [Jolt](https://github.com/godot-jolt/godot-jolt)) may be implemented as an add-on using [GDExtension](https://godotengine.org/article/introducing-gd-extensions).*

___

## Godot's physics engine

Back at the first versions of Godot (a decade ago), not many physics engines existed or were available. Even if a few were, Godot always had quite demanding API requirements for them (such as Area nodes, KinematicBody, RayCast shapes, etc.), so they were not usable without a lot of modification. This led me to do some research and write my own.

Over time this became quite a hassle, because maintaining a physics engine and keeping it up to date with the new techniques and algorithms is time consuming.

## Introducing Bullet

Godot always supported an abstract physics interface, so Andrea Catania (Odino) volunteered to add Bullet support as a backend. I initially though it would not be possible to replicate Godot's API in Bullet faithfully, but Andrea proved me wrong and did a fantastic job. He also finished before the Beta deadline, so his work was just merged and will be present in Godot 3.0.

Physics should work just like before, and no code should change, except Bullet is being used internally.
Godot's old physics engine is provided for compatibility and can be selected in the project settings, but will likely be removed by the time 3.1 is out.

## New possibilities

With Bullet as physics backend, new possibilities emerge, such as soft body, cloth support and GPU (OpenCL) physics.
This will be added after 3.0 is out, likely for 3.1.

## Will it work for 2D physics?

No. Godot 2D and 3D physics engines are separated. Our 2D physics also has considerably more customization code, such as one way collisions for both kinematic and rigid bodies. The 2D physics engine will likely remain custom and be improved after 3.0 is out.


new Variant type

Previous versions of C# in Godot have used `System.Object` to represent Godot's Variant type, which is a special container for various data types supported by the engine. The problem with that is that `System.Object` is the base type for all .NET types, including types that are not supported by Godot. This means that the Godot API allowed using types that would fail at runtime since we wouldn't be able to convert it to a type that Godot would understand.

Now we have a dedicated `Variant` struct that represents all the types that Godot supports. This means our API is more strict about which types you can use, and you will get errors at compile time before executing your game.

The way the `Variant` struct is implemented also avoids boxing value types (such as `int` and `float`) in cases where it was unavoidable in Godot 3.

When using `System.Object`, users have been able to take advantage of .NET features such as pattern matching and generics. The new `Variant` struct no longer allows to use those features directly. Pattern matching can be replaced with checking the `Variant.VariantType` property, while generics can be supported using the `[MustBeVariant]` attribute.

For more information about how Variants are supported in C#, take a look at the new documentation page about [_C# Variant_](https://docs.godotengine.org/en/latest/tutorials/scripting/c_sharp/c_sharp_variant.html).

#### Relevant links

- C#: Represent Variant as its own type instead of System.Object ([GH-3837](https://github.com/godotengine/godot-proposals/issues/3837)).
- Merge .NET 6 branch with master ([GH-64089](https://github.com/godotengine/godot/pull/64089)).
- C#: Optimize Variant conversion callbacks ([GH-68310](https://github.com/godotengine/godot/pull/68310)).

## Collections changes

Just like in 3.x, `Array` and `Dictionary` collections are supported in C# through the types defined in the `Godot.Collections` namespace. Godot's packed arrays, a special type of arrays optimized for memory usage, don't have their own representation in C#, and normal C# arrays should be used (e.g. `byte[]`).

Godot APIs are only able to understand these Godot collections, which means anything that interops with Godot's native side needs to use one of the supported collection types.

In 3.x, the non-generic collections used `System.Object`, just like .NET non-generic collections. However, thanks to the new [`Variant`](#the-new-variant-type) type, Godot C# collections now implement the generic collection interfaces where `T` is `Variant`. This means that the non-generic collections now only support Variant-compatible types, so you'll get compile errors when using an invalid type rather than a runtime exception.

The generic collections will also validate that the generic `T` parameter is one of the Variant-compatible types, since it's annotated with the new `[MustBeVariant]` attribute.

Godot collections now implement more utility methods that expose similar functionality to what can be done in other supported languages. Using these instance methods is generally faster than Linq because it avoids marshaling every item in the collection. On top of that, collections also provide an extra utility method, `MakeReadOnly`. It allows you to freeze the collections so modifying them is no longer possible.

You are not limited to using Godot collections in your own internal logic, of course. The Base Class Library in .NET includes many other collections that can be used. These collections are not going to work with Godot's API but can still be useful. In 3.x, some .NET collections were supported in very specific scenarios (such as exporting properties). This is no longer supported in 4.0 since it required reflection. Support for .NET collections may be re-introduced in the future, implemented with source generators instead of reflection.

To help you choose which collection type to use and when, we have a new documentation page all about [_C# Collections_](https://docs.godotengine.org/en/latest/tutorials/scripting/c_sharp/c_sharp_collections.html).

#### Relevant links

- Merge .NET 6 branch with master ([GH-64089](https://github.com/godotengine/godot/pull/64089)).
- C# Export on List not possible anymore ([GH-70298](https://github.com/godotengine/godot/issues/70298)).
- Sync C# Array with Core ([GH-71786](https://github.com/godotengine/godot/pull/71786)).
- Sync C# Dictionary with Core ([GH-71984](https://github.com/godotengine/godot/pull/71984)).

## Signals as events

Godot signals are a great way to implement the Observer pattern. It's possible to use Godot signals by using the common engine API, such as the `Connect` and `EmitSignal` methods. But C# developers are more used to using events, as they are more idiomatic.

For Godot 4.0, we now generate C# events for all Godot signals, which allows developers to use the event syntax that they are used to and love. As a consequence, subscribing to Godot signals using the event syntax is type-safe.

These generated events differ from normal C# events in two ways:

* These events are disconnected from automatically upon freeing the Godot type that contains the signal.
* Using the `Invoke` method to raise the event is not allowed.

We are looking into ways to allow raising events in a type-safe way, so keep an eye out for that in the future.

For more information on how to use signals in C#, take a look at the new documentation page about [_C# Signals_](https://docs.godotengine.org/en/latest/tutorials/scripting/c_sharp/c_sharp_signals.html).

#### Relevant links

- Fix C# bindings after recent breaking changes ([GH-37050](https://github.com/godotengine/godot/pull/37050)).
- Create a dedicated "C# Signals" page ([GH-6643](https://github.com/godotengine/godot-docs/pull/6643)).

## Callable support

In Godot 4 we introduce the new `Callable` type that represents a method in an object instance or a standalone function. This may sound familiar, because C# already supports a similar concept with delegate types, the `Action` and `Func` types, and lambdas.

In order to support interoperability with the engine, Godot's C# API implements a `Callable` type that can be created from an `Action` or a `Func`. This also allows developers to use C# lambdas with Godot API.

`Callable`s can be invoked by using the `Call` or `CallDeferred` methods. We currently don't support binding values to the parameters in C#. This shouldn't be a problem when using C# lambdas since they can use closures to support this scenario.

```csharp
string name = "John Doe";
Callable.From(() => SayHello(name));

void SayHello(string name)
{
  GD.Print($"Hello, {name}");
}
```

#### Relevant links

- Fix C# bindings after recent breaking changes ([GH-37050](https://github.com/godotengine/godot/pull/37050)).
- C#: Reflection-less delegate callables and nested generic Godot collections ([GH-67987](https://github.com/godotengine/godot/pull/67987)).

## Int


and Float changes

In Godot API the names `INT` and `FLOAT` are used to mean 64-bit integer and floating types, respectively. This is true even in Godot 3, but in C# we used to marshal those types as 32-bit C# types `int` and `float`. This led to [marshaling issues](https://github.com/godotengine/godot/issues/39609) and potential precision loss. This has been fixed in Godot 4.0, as now we use the same bit-ness as the engine does. This means some APIs have changed from `int` to `long` and from `float` to `double`.

For vector types, Godot uses 32-bit floats by default (this can be changed by building the engine with `--precision=double`). This may lead to some inconvenient situations where values must be converted to `float` before using them with vectors. This limitation also applies to some engine core APIs, the most common one being the `delta` parameter in `_Process` and `_PhysicsProcess`. The `Mathf` API has been updated to support both `float` and `double` overloads, which should reduce friction with these changes.

#### Relevant links

- C#: _Process / _PhysicsProcess receive delta as float instead of double ([GH-65139](https://github.com/godotengine/godot/issues/65139)).
- C#: Assume 64-bit types when type has no meta ([GH-65168](https://github.com/godotengine/godot/pull/65168)).
- Reduce the amount of casting required for floating points in C# ([GH-5403](https://github.com/godotengine/godot-proposals/issues/5403)).
- C#: Add float and double overloads to Mathf ([GH-71583](https://github.com/godotengine/godot/pull/71583)).

## Renames

A lot of types and members have been renamed in Core with the intention to make names clearer. In C# we took the opportunity to also rename a bunch of APIs in order to more closely follow the [.NET naming guidelines](https://learn.microsoft.com/en-us/dotnet/standard/design-guidelines/naming-guidelines).

The [_Capitalization Conventions_](https://learn.microsoft.com/en-us/dotnet/standard/design-guidelines/capitalization-conventions) guidelines indicate that C# should use PascalCase for all identifiers except parameter names (including acronyms over two letters in length). As a result, some types have been renamed (e.g. `CPUParticles2D` is now `CpuParticles2D`, `DTLSServer` is now `DtlsServer`).

The `Godot.Object` type is now named `GodotObject` in order to avoid conflicting with the `System.Object` type. This follows the [_Namespaces and Type Name Conflicts_](https://learn.microsoft.com/en-us/dotnet/standard/design-guidelines/names-of-namespaces#namespaces-and-type-name-conflicts) guidelines:

- Types in two different namespaces shouldn't have the same name if those namespaces are often used together.
- Type names should not conflict with the names of types in the .NET Core namespaces (such as `System`).

The [_General Naming_](https://learn.microsoft.com/en-us/dotnet/standard/design-guidelines/general-naming-conventions#using-abbreviations-and-acronyms) guidelines also recommend to avoid abbreviations or contractions as part of identifier names. Acronyms should only be used when they are widely accepted, and even then, only when necessary.

This should make Godot's API more consistent with the rest of the .NET ecosystem, and hopefully avoid some conflicts.

#### Relevant links

- PascalCase naming inconsistencies with C# ([GH-28748](https://github.com/godotengine/godot/issues/28748)).
- C#: Renames to follow .NET naming conventions ([GH-69547](https://github.com/godotengine/godot/pull/69547)).

## Exported property improvements

A lot of highly requested features have been implemented in Godot to improve exported properties and the inspector. These features are also supported in C#.

In 4.0, you are now able to export properties of type `Node` or any derived type directly, without the need to export a `NodePath` and retrieve it manually.

It's also now possible to group properties with the new `[ExportCategory]`, `[ExportGroup]` and `[ExportSubgroup]` attributes. Take a look at the updated [_C# Exports_](https://docs.godotengine.org/en/latest/tutorials/scripting/c_sharp/c_sharp_exports.html) documentation page to learn more about the new attributes.

Support for flag enums (annotated with the `[System.Flags]` attribute) has also been improved. Exported properties for such enums now show up as checkboxes in the Inspector.

Due to [engine interop improvements](#engine-interop-with-source-generators) we now use source generators instead of reflection. This means that the attributes are not retrieved at runtime. Instead the source generators generate different code based on the attributes found from the source analysis. This makes it much more difficult to support custom user attributes derived from the Godot attributes. With our current source generator implementation, derived attributes have no effect on user scripts.

To prevent a possible confusion, we've sealed the attributes to disallow inheriting from them. We are looking into ways to support extending our source generators to allow custom user attributes to affect scripts, so keep an eye out for that in the future.

In Godot 4.0, a bunch of new export annotations were added to GDScript. However, we didn't have time to add equivalent attributes in C#. All those annotations can be replicated with the `[Export]` attribute using the right combination of `PropertyHint` and `HintString` values, until we implement these convenient attributes in a future version of Godot 4.

The much anticipated support for exporting [custom resources](#global-classes) hasn't made it in time, unfortunately, and is still in development, but you can expect it to arrive very soon.

#### Relevant links

- Ability to export Node types instead of just NodePaths ([GH-1048](https://github.com/godotengine/godot-proposals/issues/1048)).
- Add ability to export Node pointers as NodePaths ([GH-62185](https://github.com/godotengine/godot/pull/62185)).
- C#: Enable exporting nodes to the inspector ([GH-62789](https://github.com/godotengine/godot/pull/62789)).
- Add grouping annotations for class properties in GDScript ([GH-62707](https://github.com/godotengine/godot/pull/62707)).
- C#: Add an easy and accessible way of organizing export variables ([GH-3451](https://github.com/godotengine/godot-proposals/issues/3451)).
- C#: Add grouping attributes for properties ([GH-64742](https://github.com/godotengine/godot/pull/64742)).
- C#: Preserve order of exported fields/categories ([GH-64852](https://github.com/godotengine/godot/pull/64852)).
- Support explicit values in flag properties, add C# flags support ([GH-59327](https://github.com/godotengine/godot/pull/59327)).

## Improved C# documentation

A lot of Godot tutorials and tips you can find online contain samples of GDScript code. To help you with interpreting them into C# equivalents the official documentation has a [C# differences article](https://docs.godotengine.org/en/latest/tutorials/scripting/c_sharp/c_sharp_differences.html), which has also been updated. It now features a complete set of tables with the C# equivalent for every common GDScript API. Sometimes a Godot C# equivalent does not exist because there are more suitable methods in the .NET Base Class Library.

The new equivalence tables try to encompass every possible case, and should be a great tool for developers looking to port GDScript code to C#. Let us know if this can be improved!

#### Relevant links

- C#: Add table with equivalent string methods ([GH-6442](https://github.com/godotengine/godot-docs/pull/6442)).
- C#: Add table with equivalent GlobalScope methods ([GH-6721](https://github.com/godotengine/godot-docs/pull/6721)).
- C#: Add table with equivalent Array methods ([GH-6677](https://github.com/godotengine/godot-docs/pull/6677)).
- C#: Add table with equivalent Dictionary methods ([GH-6676](https://github.com/godotengine/godot-docs/pull/6676)).
- Add Color section to C# differences page ([GH-6679](https://github.com/godotengine/godot-docs/pull/6679)).

## NuG


ure

Some features didn't make it in time for Godot 4.0, but are already on our roadmap for a future release (and some are already in the works).

### Global classes

Global classes, also known as named scripts, are classes registered in the editor so they can be used more conveniently. These classes appear in the _Add Node_ and _Create Resource_ dialogs. GDScript supports this feature with the `class_name` syntax.

We tried, but ultimately failed, to bring this feature to C# in time for 4.0. Luckily, there's already a PR open, so it's very likely it is going to be ready for the next minor release, Godot 4.1.

#### Relevant links

- Add first-class custom resource support ([GH-18](https://github.com/godotengine/godot-proposals/issues/18)).
- Allow exporting custom resources from/to GDScript, VisualScript, C#, and PluginScript ([GH-48201](https://github.com/godotengine/godot/pull/48201)).
- Script-class-aware Inspector & related controls ([GH-62413](https://github.com/godotengine/godot/pull/62413)).
- Enable QuickOpen to see scripted resources ([GH-62417](https://github.com/godotengine/godot/pull/62417)).
- Add C# resource export ([GH-72619](https://github.com/godotengine/godot/pull/72619)).

### Mobile and web support

We aim to support C# on all the platforms that Godot is available on. Unfortunately, we were unable to implement support for mobile and web platforms for 4.0. These platforms gained support upstream somewhat recently so we didn't have much time to work on it. The new workloads in .NET 6 should allow us to support the mobile and web platforms really soon, so keep an eye out for that.

#### Relevant links

- [Announcing .NET 6 — The Fastest .NET Yet](https://devblogs.microsoft.com/dotnet/announcing-net-6/).

### Full AOT and trimming support

Support for these features can greatly reduce binary size and enable further performance optimizations. In order to support them, we need to ensure that our libraries are prepared. Dynamically accessed types can't be trimmed, so we need to avoid reflection as much as possible.

Some target platforms don't support JIT, so we are definitely looking into supporting AOT. We'll be working on this as we add support for more platforms in future 4.x releases.

#### Relevant links

- [App Trimming in .NET 5](https://devblogs.microsoft.com/dotnet/app-trimming-in-net-5/).
- [Native AOT deployment](https://learn.microsoft.com/en-us/dotnet/core/deploying/native-aot/).

### GDExtension support

The ability to create GDExtensions using C# will enable new and powerful workflows. This would allow us to avoid the limitations of a scripting language implementation, such as [relying on file paths](https://github.com/godotengine/godot/issues/15661) to reference C# classes. Users are going to be able to implement C# types that can be registered in Godot's internal type database, ClassDB, and that would behave as built-in Nodes and Resources.

GDExtension is still very new to the engine, and is subject to change. It also has some limitations that would result in UX regressions, if C# moved away from the scripting language implementation. But it also has the potential to reduce some pain points that users have had in the past. In Godot 4.0, C# is still implemented as a scripting language, but we are planning to add support for GDExtension creation using C#. We will be keeping the scripting language implementation for your regular game scripting needs.

Consuming APIs provided by a GDExtension is also currently unsupported. We'll keep working on bridging the gap between GDExtension and C# in future 4.x releases.

#### Relevant links

- [Introducing GDNative's successor, GDExtension](https://godotengine.org/article/introducing-gd-extensions/).

### Improve source generators extensibility

As mentioned throughout this article, several areas can benefit from allowing users to create their own third-party source generators that can extend what's currently available. For example, allowing our source generators to be affected by custom user-defined attributes.

This is tricky to get right, but we'll be exploring some ideas in future 4.x releases to see how we can provide some extensibility without requiring users to disable and re-implement all of our source generators.

### Editor unification

Just like Godot 3 before it, Godot 4.0 is going to come with two versions of the editor, one "standard" and one with extra support for C# and .NET. However, the plan for 4.x is to provide one unified editor, that support everything the .NET build currently supports. If you're a GDScript user, this doesn't come at any cost for you. But for maintainers and C# developers it greatly simplifies things and allows for more efficient editor development and testing. To keep things slim and flexible, components required to support .NET projects would be downloaded on-demand when the user needs them.

#### Relevant links

- From embedding Mono to Godot as a library and the future ([GH-2333](https://github.com/godotengine/godot-proposals/issues/2333)).

### Godot as a library

The concept of Godot as a library and C# being the entry point is something that a lot of users seem to be interested in. We think this could bring many benefits to C# users, it would make it easier to support all the platforms where .NET is available, and stay up-to-date with newer .NET versions.

We started exploring this area in 4.0, but it still requires more investigation and work. It's unlikely to be finished any time soon but we'll keep working on it in the future.

#### Relevant links

- From embedding Mono to Godot as a library and the future ([GH-2333](https://github.com/godotengine/godot-proposals/issues/2333)).

---

As you can see, a lot of work has been done, and more work is in the pipeline. We are constantly looking into more ways to improve performance and usability of the API, and we keep fixing all the bugs that you can find. We are looking forward to see what you think of the .NET module in Godot 4.0. Don't hesitate to reach out with your feedback! 🙂