Cache temporary or shared data painlessly, create 2-dimensional arrays, and more!
This is a data structure built on the premise of flexibility. Cache 2da files, store shared data, create parallel (2D) arrays, or simply use it as a repository for temporary data.
The system uses a collection of waypoints to store data. Bit fields track which elements are in use and which are available.
Check out the documentation in the packaged .PDF file for usage instructions and addition information.
For the moment, yes. Convenience was what got me started. Although, I continue dreaming up ideas for more practicall implementations.
My lastest idea is to cache nwnx DB calls. A (psuedo)heartbeat system would then fire the DB calls in a time-based fashion rather than on-demand.
In other words, it could be made into a sort of "incremental backup" system: where X amount of cached data is written to the DB every Y seconds, then cleared from the cache.
Or in treasure system, the treasure could be pulled from the DB while the party crawls rather than the moment a party member opens a chest (I'm still wondering if there's any real advantage here ... the idea is to take a heafty DB call--one which would cause noticable lag--and break it into smaller pieces ... but I'm leaning toward a better solution being better SQL)... but now I digress ....
Thanks for the support, I'll continue to update as my developments progress. _________________________ Lead Script Design The World of Palladium II DMFI GUI Guru
Just update with a second include file of convenience functions. These functions should make the system more intuitive. I also made a few performance tweaks. _________________________ Lead Script Design The World of Palladium II DMFI GUI Guru
I ran performance tests using nwnx4's timer.
Testing with a cache of 1024 waypoints:
-Creation ran in ~460000 microseconds.
-Population TMI due to the bit field tracking. But ignoring the tracking, it populated in ~20000us (microseconds).
-Access ran in ~19000us.
A store of localstrings on a single waypoint populated in ~15000us. Access took ~13500us.
So, the cache is a bit slower. It's much closer for smaller data sets. However, I think this system is going to be worth the cost. I'm still working out implementation strategies.
What I've been so far is caching my data, then creating integer arrays that point to it. This gives you 2D array functionality: where the pointer array indexes server as your rows; and the cache variable names make up your columns.
I'm just now wrapping up some convenience functions that make such a setup a snap. I'm looking at method to save/load a cache as well.
10 - A Masterpiece, Genuinely Groundbreaking 9 - Outstanding, a Must Have 8 - Excellent, Recommended to Anyone 7 - Very Good, Deserves a Look 6 - Good, Qualified Recommendation 5 - Fair, Solid yet Unremarkable 4 - Some Merit, Requires Improvements 3 - Poor Execution, Potential Unrealized 2 - Very Little Appeal 1 - Not Recommended to Anyone
Site
at 2006-12-31 20:17:37
