Optimize the code and fix the problem of the search box being stuck.
Revert "Optimize the code and fix the problem of the search box being stuck."
This reverts commit 210561eebdd0638e3e67f00a2d0ec72596ee4e52.
Revert "Revert "Optimize the code and fix the problem of the search box being stuck.""
This reverts commit 0f714b5fd3503cdc7d06f692ce267b712510b4a0.
Revert "Revert "Revert "Optimize the code and fix the problem of the search box being stuck."""
This reverts commit ef9e0ff596b6773c86e9d245e73d71386c4ab350.
We've made several updates to improve our codebase and application performance.
- Clang format was applied for better readability and consistency, aiding other developers in understanding and contributing to the code.
- We resolved issues that were causing visual script compilation failure. The visual script now compiles successfully, ensuring application functionality.
- Broken sections within the codebase were fixed, improving overall stability.
- Built-in functions from the visual script were removed to simplify the code and enhance readability.
- Generic search performance was improved to provide faster results, enhancing user experience.
- Missing flow nodes were added to the Visual Script, ensuring all necessary components are present for correct functioning.
In an effort to streamline the codebase:
- `VisualScriptComment` class and related code were removed, reducing complexity and improving maintainability.
- Error messages were optimized for quicker feedback when errors occur.
- Licenses were updated to reflect recent changes, ensuring legal compliance and project transparency.
- The `get_global_name()` override in `visual_script.h` was fixed, and `TYPE_BUILTIN_FUNC` in `visual_script_expression.h` was removed, improving code functionality.
- Search logic was refactored to avoid double searching, enhancing performance.
- Documentation was updated to reflect recent changes, providing accurate information to users and developers.
- Property selection logic in `VisualScriptPropertySelector` was refactored for easier understanding and modification.
- Code was refactored to avoid variable shadowing, improving readability and reducing potential errors.
- `.clang-format` and `.clang-tidy` configuration files were added to ensure consistent code styling.
To make the code more robust and easier to understand:
- Variable names were corrected for clarity, and error handling in `visual_script_expression.cpp` was improved.
- Function and variable names were refactored for better readability and maintainability.
- Member editing logic in `VisualScriptEditor` was simplified.
- Name variables were updated to be unique, avoiding potential conflicts and errors.
- The `VisualScriptSubCall` class was refactored for simplicity and ease of understanding.
For macOS workflow:
- It was updated to use the latest version and correct path for installing Vulkan SDK, enabling the application to leverage the latest features and improvements from the Vulkan SDK.
- Mac Vulkan SDK was installed to support Vulkan-based functionalities.
Lastly, we made necessary changes to pass CI/CD tests, ensuring the code quality and stability of the application.
The function tried to rearrange properties but that lead to problems with duplication or deleted properties. Implemented the logic that that function did inside the get_property_list both for tool scripts and non-tool scripts.
- RPC configurations are now dictionaries.
- Script.get_rpc_methods renamed to Script.get_rpc_config.
- Node.rpc[_id] and Callable.rpc now return an Error.
- Refactor MultiplayerAPI to allow extension.
- New MultiplayerAPI.rpc method with Array argument (for scripts).
- Move the default MultiplayerAPI implementation to a module.
Implement built-in classes Vector4, Vector4i and Projection.
* Two versions of Vector4 (float and integer).
* A Projection class, which is a 4x4 matrix specialized in projection types.
These types have been requested for a long time, but given they were very corner case they were not added before.
Because in Godot 4, reimplementing parts of the rendering engine is now possible, access to these types (heavily used by the rendering code) becomes a necessity.
**Q**: Why Projection and not Matrix4?
**A**: Godot does not use Matrix2, Matrix3, Matrix4x3, etc. naming convention because, within the engine, these types always have a *purpose*. As such, Godot names them: Transform2D, Transform3D or Basis. In this case, this 4x4 matrix is _always_ used as a _Projection_, hence the naming.
For this to work safely (user not call queue_free or something in the expression), a const call mode was added to Object and Variant (and optionally Script).
This mode ensures only const functions can be called, making it safe to use from the editor.
Co-Authored-By: reduz <reduzio@gmail.com>
* Ensures thread safety when resources are destroyed.
* Simplified API by always forcing `ResourceCache::get_ref`, which needs less hacks and is fully thread safe.
* Removed RWLock for resources because its not possible to use for the new logic. Should not be a problem.
Supersedes #57533
