Data corrupted when stored in a Vector3

I have a really strange problem here that manifests itself on the LIVE server only. Works fine in Studio. Consider the following code:

local function newValue(player, damage, folder)
	local tag
	tag ="Vector3Value")
	tag.Name = player.UserId
	tag.Value =, time(), damage)
	tag.Parent = folder
	print("Tag Create", tag, tag.Value)

This function is part of my player tagging system. So when a player damages another player or NPC, a tag is created that specifies the user id of the damaging player (X), the server time (Y), and the damage done (Z). If the tag already exists, then the Y and Z values are updated.

With that being said, somehow the player’s user id is getting mangled when stored in the Vector3. Here’s a partial screen shot documenting what I’m talking about.


I checked for a datatype mismatch between the player’s user id and the XYZ components of the Vector3. Both say that the base type are numbers. But, in the Vector3, it looks like the least significant bits are being mangled somehow as the first few numbers are the same. I realize that number is a floating point type, so could there be a representation problem? Or, could there be something inherent to Vector3 that’s causing it?

This is game breaking as it’s causing the script to error out and players don’t get their rewards. I could use a string value in place of the Vector3 if push comes to shove, but I would rather not use that solution unless I have to.

I’m not entirely sure why that would be happening. However, I would not recommend relying on various components of a Vector3Value to store individual/separate data.

The components of the Vector3 is single precision which is C’s float (usually IEE 754 binary32).
The number data type is double precision which is C’s double (usually IEEE 754 binary64).

When you insert a native VM number into one of the 3 arguments of the Vector3 constructor, it gets casted from double to float, which the rounds the value to the 24 most significant binary digits (in binary32 format as that has 23 physical bit for the significand with the hidden 1.) (ignoring edge cases which aren’t relevant here).

1 Like

I’m familiar with IEEE 734 standard for floating point numbers. It wasn’t mentioned in the Roblox documentation that a number for a Vector3 is a different datatype than a number for a player’s user id. That does answer the question. Now to figure out how to get around this.