"MemoryBlock.StoreToOffset" not found

[Mystik-Spiral]

@FortyTwoFortyTwo

The Packages -> Artifacts zip file only contain the include and gamedata files, not the source (.sp files) to build vscript.smx. If I separately grab the latest 1.8.6 code, it will compile with no errors, but when attempting to load it (with the latest SM 1.12), it fails with this error:

L 09/14/2024 - 08:30:01: SourceMod error session started L 09/14/2024 - 08:30:01: Info (map "c10m1_caves") (file "/home/l4d2prod/serverfiles/left4dead2/addons/sourcemod/logs/errors_20240914.log") L 09/14/2024 - 08:30:01: [SM] Unable to load plugin "vscript.smx": Native "MemoryBlock.StoreToOffset" was not found L 09/14/2024 - 08:30:37: Error log file session closed.

I switched to a pre-compiled 1.8.5.manual version of vscript.smx and it loads and runs fine. In case it matters, I am running on Ubuntu 22.04.5 LTS.

[FortyTwoFortyTwo]

The Packages -> Artifacts zip file only contain the include and gamedata files, not the source (.sp files) to build vscript.smx.

Package are supposed to only include files needed to directly upload to addons, which it has .smx file compiled and packed in, making .sp file unnecessary unless if you were to edit it.

L 09/14/2024 - 08:30:01: [SM] Unable to load plugin "vscript.smx": Native "MemoryBlock.StoreToOffset" was not found

Where are you getting sourcescramble plugin or include from? Latest include version has it as a normal function instead of a native.

[Mystik-Spiral]

I see what you mean. I was using the SourceScramble build from two months ago, version 0.8.0-pre2, under the Artifacts page here, which looks very different:

methodmap MemoryBlock < Handle { /**

• Allocates a fixed amount of memory, initializing the contents to zero.

• Size is in bytes. */ public native MemoryBlock(int size);

  /**

• Disowns the associated memory block, allowing it to remain allocated even when the handle
• is deleted. Disowning the memory does not invalidate the handle.
• Only use this if you are certain that something else will free (or has freed) the memory

• block. */ public native void Disown();

  /**

• Returns the address of the allocated memory block.
• @error Plugin is running on a 64-bit server; SourceMod does not support full usage of

• 64-bit addresses at this time. */ property Address Address { public native get(); }

  /**

• Returns the size of the allocated memory block. */ property int Size { public native get(); }

  /**

• Load up to 4 bytes from an offset to the memory block, performing bounds checks to ensure

• reads are contained within the block. */ public native int LoadFromOffset(int offset, NumberType size);

  /**

• Store up to 4 bytes to an offset to the memory block, performing bounds checks to ensure
• writes are contained within the block. */ public native void StoreToOffset(int offset, int data, NumberType size); };

I cannot check this now, but will try to build/test tomorrow with the 0.7.1.4 version from five months ago and see what happens.

[FortyTwoFortyTwo]

Oh I see that you are using the experimental version, which does have it changed from normal to native function. I'll wait for the experimental version to be stable before I recompile it for an official version in packages, otherwise you'll need to make sure that compiled plugin is using the same include version as the sourcescramble extension.

[Mystik-Spiral]

@FortyTwoFortyTwo

Updating to let you know there were no problems compiling VScript 1.8.6.manual when using SourceScramble v0.7.1.4, and also no problems loading the vscript.smx plugin. The issue was only when trying to use VScript 1.8.6 with SourceScramble v0.8.0. Closing this issue.