'Corrupted header in binary project.binary (not ECFG)' with exported PCK over 2.1 GB (32-bit signed int) #44363
Comments
Yes, see this page in the documentation. You could try off-loading some of the largest files (typically textures) to a dedicated PCK file. Alternatively, you could ship the project files with the |
oh no. the PCK file exceed 2GB and when we run the export it doesn't work. we don't know how to reduce the import less than 2GB as this is the Godot bug in file system access. - godotengine/godot#27168 pck more than 2.1 gb error - godotengine/godot#44363 manually put an export template in root folder of this project - https://godotengine.org/qa/75329/game-over-and-not-working-what-best-handle-this-godot-stable - godotengine/godot-proposals#400 it seems that it will only fix in Godot 4.0 - https://docs.godotengine.org/en/stable/getting_started/workflow/export/exporting_pcks.html - godotengine/godot#44363 - godotengine/godot#47254 akien is fixing, but this PR here is still WIP for now unfortunately so now we added 2 export template: Windows and Linux, both 64 bit in the project root folder. simply run HexagonEngine.bat for Windows or HexagonEngine.sh for Linux respectively. those script will print "Hexagon Engine by Perkedel Technologies" then run respective export template.
This changes the types of a big number of variables. General rules: - Using `uint64_t` in general. We also considered `int64_t` but eventually settled on keeping it unsigned, which is also closer to what one would expect with `size_t`/`off_t`. - We only keep `int64_t` for `seek_end` (takes a negative offset from the end) and for the `Variant` bindings, since `Variant::INT` is `int64_t`. This means we only need to guard against passing negative values in `core_bind.cpp`. - Using `uint32_t` integers for concepts not needing such a huge range, like pages, blocks, etc. In addition: - Improve usage of integer types in some related places; namely, `DirAccess`, core binds. Note: - On Windows, `_ftelli64` reports invalid values when using 32-bit MinGW with version < 8.0. This was an upstream bug fixed in 8.0. It breaks support for big files on 32-bit Windows builds made with that toolchain. We might add a workaround. Fixes godotengine#44363. Fixes godotengine/godot-proposals#400. Co-authored-by: Rémi Verschelde <[email protected]>
This changes the types of a big number of variables. General rules: - Using `uint64_t` in general. We also considered `int64_t` but eventually settled on keeping it unsigned, which is also closer to what one would expect with `size_t`/`off_t`. - We only keep `int64_t` for `seek_end` (takes a negative offset from the end) and for the `Variant` bindings, since `Variant::INT` is `int64_t`. This means we only need to guard against passing negative values in `core_bind.cpp`. - Using `uint32_t` integers for concepts not needing such a huge range, like pages, blocks, etc. In addition: - Improve usage of integer types in some related places; namely, `DirAccess`, core binds. Note: - On Windows, `_ftelli64` reports invalid values when using 32-bit MinGW with version < 8.0. This was an upstream bug fixed in 8.0. It breaks support for big files on 32-bit Windows builds made with that toolchain. We might add a workaround. Fixes godotengine#44363. Fixes godotengine/godot-proposals#400. Co-authored-by: Rémi Verschelde <[email protected]>
|
Adding a comment to this because this is the top google search result for this error message and there is a totally unrelated reason why it can happen! How it happened: Apparently if you upload HTML5 builds to itch.io in multiple succession, and some people played on the intermediate build, their browser will cache some but not all of the HTML5 files, allowing them to attempt to play the game in an inconsistent state. The solution: tell them to Ctrl+F5 lmao. No idea if there's an automateable solution besides 'don't do that' |
Godot version:
3.2.3
OS/device including version:
Windows
Issue description:
When a PCK file is over 2.1gb godot will not run and throws this error:
This was raised back in the 3.1 days as #27168 and a PR was created.
Due to the large number of changes the PR was moved to 4.x as part of #27247 (proposal godotengine/godot-proposals#400) and the original 3.1 issue closed. However, due to age of the PR it was never merged into 4.0 as far as I can tell.
I think this means the problem is not fixed and also does not have an issue associated with it. The exported game runs on Linux but not Windows.
Now I have a PCK over 2.1gb and am searching for a solution or a workaround. Is it possible to merge that PR, even if it's for 4.0? Or is there some way to break the export up into multiple PCK files? Thanks
Steps to reproduce:
Create PCK file over 2.1gb
The text was updated successfully, but these errors were encountered: