Cache:IsInUse(Object)
achieves what you are asking for. I feel reluctant towards adding more methods and properties because I want to keep the module more minimal and clean in terms of source code. You can always edit the module’s code in your own game to add the features you want to use.
Yes, but if you’d want a table of every part that’s in use without editing the module, you’d have to loop through every single one of them and call Cache:IsInUse(Object)
, sure I can edit the module, but it would still be useful to have by default. It’s still fine though, I feel like keeping it minimal is great for performance too and developers can edit it based on their own game’s code, I was only reccommending it for convenience
ObjectCache v1.3.0
Changes since v1.2.0
- Added
ObjectCache:Update()
method to force all the queued parts to move immediately. This can be useful when you need to make sure all parts move into vision right as you get them. For optimal use, it is recommended to only call it after getting all parts first.
Links
ObjectCache v1.4.1
Changes since v1.3.0
- Provide support for using models as the cache template. Maximizing the engine’s capabilities, BulkMoveTo is called on the PrimaryPart of the model - meaning you get much faster retrieval speeds than if you were to call
Model:PivotTo
, while remaining efficient! Note: you will have to weld all parts to the PrimaryPart for the other parts to teleport along with the PrimaryPart. - Optimize initialization of the cache; the cache container is now initially parented to
nil
, and is only parented into workspace once all cache objects have been parented to it. This significantly lessens the cost of cloning and moving the objects.
Links
Can you add a function of resetting this part’s properties to template part after returning to the cache?
Something like this
This would be hard to implement on my end, as I cannot know which properties you would like to reset, and to what values. This would also make the module suffer from performance issues. It is best to leave such implementations to the user.
No problem! Thanks for reply
Im using your module for my Scene Destruction System, its reduce a lots of performance cost, pretty useful module
ObjectCache v1.4.3
Changes since v1.4.1
- Fix type error with
Cache:ReturnPart
when used in strict mode - Removed useless comment (native enables optimize 2 already)
Links
does this module use similar methods to partcache? i will definitely use this but i was just wondering if i have to mass recode a bunch of stuff
Hi, yes. There is an API reference provided in the main post – you can see that the most used methods :GetPart and :ReturnPart are the same, with the exception of GetPart being able to be passed an additional CFrame argument.
I will take at face value that this functions better and/or differently compared to PartCache.
But obviously lots of people are aware of PartCache and when they stumble upon this, which seems to function similarly to PartCache, they will ask “Which one do I use?”. While I don’t think you’re required to explain how your module is different compared to PartCache I think it’d be a good idea to do so to help users and yourself if you’re looking for wider use by the community.
I use PartCache rarely, actually I can probably switch over to this module without much work. But I won’t because I’m currently not incentivized to. Is this module easier to use? Maybe. Is this module more performant? Maybe. But basically I don’t have a problem with PartCache, so there’s the old saying “Don’t fix what isn’t broken”, and this module doesn’t seem to provide enough benefits to switch over (as of my current situation).
Otherwise I’ll keep this module in mind and use it for future projects, but my current project will continue to use PartCache.
I do not like calling out specific modules, both out of respect to the original developer, and out of principle. I already explain in “Why ObjectCache?” and “Supports models” as to why it can be considered a better alternative; it is more performant, supports models, and is more up-to-date with Roblox’s APIs. You are free to make your own rational decision between switching and not – I’ve tried it in an existing game, and simply replacing the source of PartCache with ObjectCache seems to work seamlessly.
Sorry about that! I can’t believe I’m saying this, but I got an account warning because I uploaded a meme of this orange to Roblox:
(this isn’t me, its a public figure and isnt any personal identifiable information)
ObjectCache v1.4.4
Changes since v1.4.3
- Fix the module causing lighting to flicker. This is a now-reported engine bug, which was caused by the parts being moved too far away from the world origin.
Links
Hey Pyseph, I made a pull request to fix the $path for my rojo project, when will you able to merge it.
Why my parts anchor automatically? edit: nevermind
ObjectCache v1.4.5
Changes since v1.4.4
- Fix bug for the same first object being grabbed twice when expanding cache
Links
So quick question about the Destroy function. Will that destroy the whole cache that you send in, including all the data besides just the holder so you don’t have a bunch of unnecessary data being stored?
ObjectCache v1.4.6
Changes Since v1.4.5
- fixed IsInUse being incorrect, returning the inversed result
- fixed issues when installing ObjectCache with wally