-
-
Notifications
You must be signed in to change notification settings - Fork 21k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Backport HTTPRequest gzip decompression #48581
Closed
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Directly RC as we'll keep changes conservative to keep this branch usable in production at any time.
(cherry picked from commit a4423c8)
It's possible to link against system zlib on Linux, so we should use system paths. (cherry picked from commit 93b7406)
(cherry picked from commit 3d46f28)
* Better handling of the scene's environment energy in the lightmapper bakes. * Fixed a bug where ProceduralSky::get_panorama() returned a reference instead of a copy. * Removed includes to Embree's internal header files. (cherry picked from commit 2db2d11)
(cherry picked from commit b266cc2)
(cherry picked from commit 47f869b)
We need to propagate the hacky checks from the raycast config to the lightmapper config, as the failure of a `can_build()` check is not notified to other modules (which might even be checked further depending on the processing order in SConstruct). A more thorough fix would be to change SConstruct to do two loops on modules: one to check `can_build()` and disable modules which can't build, then another one to rechecked `can_build()` with the new lineup and do further config. But there would be more risk for regressions than with this ad hoc hack. Similar story for the `platform/x11/detect.py` change... oh my eyes :( (cherry picked from commit a2c68d9)
…ss too `tech_debt++`, that's what we get for not taking the time to cleanup all this and do it right... Follow-up to godotengine#48073 and godotengine#48102. (cherry picked from commit a14b51d)
Follow-up to godotengine#46810, this was missed in godotengine#47079 when fixing the issue for other platforms. Fixes godotengine#48135. (cherry picked from commit a09f383)
(cherry picked from commit 0c9a1a1)
(cherry picked from commit 188bd56)
(cherry picked from commit dbd4b45)
(cherry picked from commit 4d7f642)
…ript (cherry picked from commit ac91e2c)
- Modified classes: RigidBody, PhysicalBone, VehicleBody, RigidBody2D, KinematicBody2D - The input argument is untrusted even in release mode (cherry picked from commit e075b6b)
This updates global classes and exposes base member variables. Fixes godotengine#39713 (cherry picked from commit b16bb33)
The final_modulate was incorrectly being set in the uniform on light passes in GLES3 in situations where color was baked in the vertices. This was already correct in GLES2. This PR makes prevents setting final_modulate in this situation. (cherry picked from commit 35c5ccc)
The translation to larger vertex formats was assuming that batches were rects, and not accounting that the num_commands had a different meaning for lines and polys, so the calculation for number of vertices to translate was incorrect in these cases. Also prevents infinite loop if a single polygon has too many vertices to fit in the batch buffer. (cherry picked from commit d08cf5f)
(cherry picked from commit ccc375f)
(cherry picked from commit decdf4f)
(cherry picked from commit 4311c2f)
The min requirement was upped by godotengine#45618 to have proper support for C++14. Related to godotengine#48222. (cherry picked from commit 8851fa7)
After further testing it seems to work fine now when building binaries with GCC 5 on Ubuntu 16.04 (previously we were using GCC 9 on Ubuntu 14.04). Follow-up to godotengine#45629. (cherry picked from commit aa15ad7)
We still use Emscripten 1.39.9 for official Mono builds so ideally we want to test against an old Emscripten version to ensure we don't break compatibility. But then google-closure-compiler-linux broke compatibility for us and is not properly pinned, so we need to use a more recent version for now to fix CI. Cf. emscripten-core/emsdk#802 (cherry picked from commit 9571ae3)
(cherry picked from commit 7501c7f)
(cherry picked from commit a980bad)
Cf. godotengine#48269. (cherry picked from commit 562c6bd)
(cherry picked from commit d311c48)
Now correctly computes the timeout value in milliseconds. (cherry picked from commit 46f7b0f)
Ok thank you @aaronfranke! I've opened a new PR with the 3.x branch. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Sorry if creating incomplete PRs is not allowed! I can remove this if needed.
I was trying to handle the backport of this PR.
Most of the work seems to be done, however I've run into a few issues, and I'm not familiar enough with the Godot source to understand what's happening here.
I'm currently running into the following errors:
Does anyone have any idea how to bypass this issue?