Hi, im getting this error “Attempt to index nil with mouse” in your module whenever i call module.new()
Right on time mate! Just when i needed it.
idk why, but the module makes a huge delay between the actual scoring and the replay screen. I have to wait for some time. It may be a little error that i should fix. But all in all, its fast for what it can do.
The demo has a wait(1)
after you score in order to allow the players to see the actions before getting cut off by the replay. If you don’t want any delay, remove the wait. (Line 45)
It’s not good practice to actually use demo code, especially without reading it carefully first.
First of all, you should copy the exact error message. The module never indexes anything with “Mouse”. Nor does it error when you call .new()
, rather it errors when you require()
.
The real error is:
attempt to index nil with ‘GetMouse’
Because it used LocalPlayer:GetMouse()
and you are incorrectly using it on the server, which has no local player. This is a client side visual, not made to run on servers.
Can a zoom in or zoom out effect be added using tween service effect camera fov
That’s what I was gonna make, nice tho !
Maybe use this for moderation systems?(for example recording the player)
oh uh, i actually rewritten the entire demo code. Using the ZonePlus module, i was able to make a better version of the script. But due to my current level, i still consider it messy and kind of vulnerable to bugs. It still has a little delay though i had to use a repeat loop (with wait(0.5) due to lag possibility) to make sure that the module can have enough time to finish rendering the replay and play it. without that loop, it will keep saying that it cant find any replay to play.
I keep getting this error "Players.ultra_2033.PlayerScripts.Replay.ReplayModule:359: attempt to index nil with 'Recorded'"
. It happens to me after i do:
Replay:ClearRecording()
Replay:Destroy()
and then try to start recording again. Any help? (I’m using the workspace module btw)
You destroyed it. The recorder no longer exists, and cannot be used to record again. Don’t destroy things you’re still using!
Oh, i didn’t realize that the Replay was getting destroyed as well, thanks for your quick response.
I’m at a roadblock here, Is there any way to keep track of the players character during replay even when they reset/die? I need this functionality but i don’t want to stop the recording and register them every time. Thanks in advance.
you should make a tutorial on this module
just use CharacterAdded with the register function
Would u able to record on the client and send the replay object through the server, and play it there?
I needed a replay system to show how to do some obby mechanics so I decided to make that and want to share it in case anyone wants it.
New methods:
Replay:SetCharacter(character: Model) - Sets the primary focus character
Replay:Serialize() - Creates a folder inside of a folder called “PlaybackData” in ReplicatedStorage. This method first converts each CFrame property to a string, LZW compresses it, Base64 encodes it, then inserts it into said folder.
Replay.fromSerial(folder: Folder, character: Model, settings) - Creates a new Replay object from a serialized folder inside of ReplicatedStorage for playback.
Replay:GetRegisterIndex(cloneToFind) - Utility method to find a register’s index by clone inside of self.Registers
Replay:GetCopy(original: Instance) - Equivalent of doing Replay.CloneIndex[original]
Minor improvements & new functionalities:
- Uses metatables instead of creating methods per-object
- Can replay pre-recorded Replays
- Exposes a couple compression and (de)serialization methods (CFrames to string, numbers, colour to integer).
- Should be able to handle recordings of any length
(Potential) caveats:
- Serializes only the character’s parts (HumanoidRootPart, Torso, legs, arms, head), so custom mechanics like spinners’ orientations will not save.
- Accessories’ offsets cannot be changed (the module assumes accessories are static relative to the character)
- Works only in the workspace (does not create a ViewportFrame)
- May be slow to en/decode (you should create Replays from serial lazily). I used LZW compression for a good median between speed and compression, and a fast base64 en/decoder.
- Serializes only CFrames (if you change a part’s colour for example, it will not work)
- Storing a replay takes up a lot of data even after compression.
- You cannot change the order in which things are serialized after serializing them. Storing things in a new order post-serialization will cause issues without manual intervention.
- Designed to work with R6 only. Modifying somethings you should be able to get it to work with R15
I’ve created an example place (scripts are descendants of an Actor in StarterGui, doesn’t actually use parallel I was just testing things out and am too lazy to change references). Serialized recordings appear here in ReplicatedStorage, they can be copied from runtime and pasted in studio after recording.
viewport.rbxl (287.8 KB)
Anyway, that’s everything I think.
Special thanks:
Rochet2 on GitHub for their lualzw module: GitHub - Rochet2/lualzw: A relatively fast LZW compression algorithm in pure lua
Gooncreeper for their base64 en/decoder module: Insanely Fast Base64 Module
Great work! I really like the idea.