Skip to content
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

Bug: Save files become corrupted when large vscript file(s) are ran inside them. #1200

Open
Rip-Rip-Rip opened this issue Aug 3, 2024 · 5 comments
Assignees
Labels
Type: Bug This is a problem with something that should be working one way, but isn't. What: Scripting ChaosScript or VScript related issues

Comments

@Rip-Rip-Rip
Copy link
Member

Describe the bug

When you attempt to load a save/quick save with a large vscript file active, the game crashes on load, and that save file becomes corrupted (you cannot load it).
This is a major issue for mods which have vscripts present inside them, which are quite large in size and/or use large vscript libraries. (this has been the bane of my existence lol)

The error that appears varies. It seems to be about 50/50 whether no error appears, and the sentry crash report menu just pops up, or if an error box appears stating Allocator error 12: unable to allocate memory (<some obscenely large number> bytes), and no sentry crash report menu pops up. - The number of bytes can vary, however its always stupidly large.

Screenshot 2024-08-03 204618

This issue occurs regardless of whether the script was executed using the script_execute console command, or with the script being included in an entity's "Entity Scripts" kv inside hammer.

The issue also gets more common, the more complex the vscript file becomes. (If it's slightly less complex, then it can crash only some of the time, not 100% of the time, if that makes sense).


I've tested this on the stable branch, the unstable branch and the workshop branch, in both legacy_ui and panorama modes, and the result is the exact same.

This issue is also present in base Portal 2, however from what I can tell it seems to happen slightly less often.


I have provided a download to a save file which has been corrupted as a result of this issue here: https://drive.google.com/file/d/11n3W6XphS5UvBnmYXz--kJAufcv4d5lx/view?usp=sharing

Make sure you have the grapple gun mod installed when trying to open it, as without it even more unrelated issues might occur - more info in the "To Reproduce" section).

To Reproduce

A way to easily get this to occur is to use my grapple gun mod. Download can be found here (this version is more complex than the previously available public version, and makes the game crash near 100% of the time from my testing): https://drive.google.com/file/d/1dT6egf6vCGQeaUigUoRGk5nARHLrz5dU/view?usp=sharing

After you have downloaded it, place the grapple_gun folder into Portal 2: Community Edition/p2ce/custom, and follow these steps:

  1. Open the game in either legacy_ui mode or panorama mode (does not make a difference from my testing).
  2. Load the map sp_a2_laser_intro (any map has the issue, however this is the map i've been doing my testing on, and had the save corrupt 100% of the time on).
    2.5. Make sure you installed the mod correctly lol.
  3. Perform a quick save, then attempt to load the quick save.
  4. Observe the game crashing.

If you then attempt to load that quick save again after the game has crashed, the game will crash again, meaning the save file has corrupted.

Issue Map

This issue can appear on any map.

Expected Behavior

The game should not crash, and the save file should not get corrupted and should load like any other save file would.

Operating System

Windows 11 23H2 Build 22631.3880

@Rip-Rip-Rip Rip-Rip-Rip added the Type: Bug This is a problem with something that should be working one way, but isn't. label Aug 3, 2024
@Rip-Rip-Rip
Copy link
Member Author

After doing some more investigating, the cause of this issue seems to be when a lot of scripts are included using the IncludeScript() function, and those scripts which are included, also include scripts themselves (if that makes sense).
So it's like layers upon layers upon layers of scripts being included, and ig the game doesn't like that.

@Rip-Rip-Rip
Copy link
Member Author

Oops wrong button, closed by accident

@Rip-Rip-Rip Rip-Rip-Rip reopened this Aug 12, 2024
@TeamSpen210
Copy link

When saving, all the objects in the Squirrel namespaces (including functions) get saved. So there must be some limit on the amount of data. Included scripts just means it'll be bigger, you could probably get the same issue with just a single really big script file.

@Rip-Rip-Rip
Copy link
Member Author

Rip-Rip-Rip commented Aug 12, 2024

When saving, all the objects in the Squirrel namespaces (including functions) get saved. So there must be some limit on the amount of data. Included scripts just means it'll be bigger, you could probably get the same issue with just a single really big script file.

For the current script i'm working on (which also had this crashing issue), I swapped out the version of the library I was using (https://github.com/IaVashik/PCapture-LIB) for the single script version (rather than the version which was made up of a lot of smaller scripts), and the issue completely went away.
Not sure if there's anything extra included in the split up version which caused it to tip over the edge (or if its just the extra data needed to store it all as multiple scripts), but yeah just thought i'd mention this.

@ozxybox ozxybox added the What: Scripting ChaosScript or VScript related issues label Sep 9, 2024
@pivotman319-owo
Copy link
Member

pivotman319-owo commented Oct 7, 2024

most possibly the same issue as #581, which I filed in late 2022 - this also happened in sp_a4_finale1 iirc

@ozxybox ozxybox self-assigned this Oct 17, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Type: Bug This is a problem with something that should be working one way, but isn't. What: Scripting ChaosScript or VScript related issues
Projects
None yet
Development

No branches or pull requests

4 participants