|
TesterOfLimitz Novice
Joined: 02 Jun 2007 Posts: 37
|
Posted: Sun Jun 17, 2007 10:53 pm
Data Record Overwriting? |
Ok, basically im setting all the settings for my system into one big data record, for cleanliness sake, taking 50+ variables like balance, equilibrium etc. and having them located in one place....the problem is When my prompt trigger fires, sometimes it deletes ALL the other settings in data record....This is a bigtime problem, since none of my other scripts will run if those settings arnt present (I also have another data record that keeps track of defences, and it overwrites that as well).......Here's my prompt trigger.
Code: |
Pattern: (%d)h, (%d)m, (%d)e, (%d)w ([cexkdb@])- |
Code: |
#noop --------------------------------------------------------------------------
#noop ---------- Stat Tracking
#noop --------------------------------------------------------------------------
syssettings.health = %1
syssettings.mana = %2
syssettings.endurance = %3
syssettings.willpower = %4
#if (%pos(e,%5)) {syssettings.equil = 1} {syssettings.equil = 0}
#if (%pos(x,%5)) {syssettings.bal = 1} {syssettings.bal = 1}
#if (%pos(c,%5)) {def.cloaked = 1} {def.cloaked = 0}
#if (%pos(d,%5)) {def.deaf = 1} {def.deaf = 0}
#if (%pos(k,%5)) {def.kola = 1} {def.kola = 0}
#if (%pos(b,%5)) {def.blind = 1} {def.blind = 0}
#if (%pos(~@,%5)) {def.phase = 1} {def.phase = 0} |
I used to use #addkey syssettings whatever 1 but it seemed like every time I opened/closed Cmud that it overwrote......right now it only overwrites every once and a while, but only AFTER i close and reopen the program. As always, any and all help is greatly appreciated
-- Tester
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Edit:
Ive found a temp. solution to the problem, I made a backup of @syssettings called @syssettingsdefault and use the following command:
Code: |
#loopdb @syssettingsdefault {#addkey syssettings %key %val} |
Any help would stilll be appreciated, as its kind of annoying to have to stop and backup the variable every time I go to close Cmud, especially since I add/remove settings from it all the time. |
|
|
|
Thinjon100 Apprentice
Joined: 12 Jul 2004 Posts: 190 Location: Canada
|
Posted: Sun Jun 17, 2007 11:52 pm |
Does your syssetting variable have a "default" value for some reason that's clearing it after each restart of CMud? I know I had a problem with that on one of my variables, and it turned out that was the case... I believe if you recreate the variable with
Code: |
#VAR syssettings {} _null
|
It'll remove any "default" setting and stop that, but I may be wrong
As an aside, or if that doesn't work, you might consider adding an "OnDisconnect" event that automatically does your copyover (your #Loopdb line).
Hope that helps |
|
_________________ If you're ever around Aardwolf, I'm that invisible guy you can never see. Wizi ftw! :) |
|
|
|
TesterOfLimitz Novice
Joined: 02 Jun 2007 Posts: 37
|
Posted: Mon Jun 18, 2007 12:06 am |
Ive tried it with and without a default, it resets correctly on the connect, but the first time my prompt fires (which is immediately after I sign in) it rewrites to JUST the Key's and Values from the Prompt Trigger. The #loopdb works, and from then on the values just update, but I would like to know why it rewrites the entire variable on the first prompt.
|
|
|
|
Zugg MASTER
Joined: 25 Sep 2000 Posts: 23379 Location: Colorado, USA
|
Posted: Mon Jun 18, 2007 5:09 pm |
One thing to keep in mind is that using database variables is not currently very efficient. Database variables are stored as giant string values (sort of like a string list, but with different delimiters between each item). Therefore, when you reference a particular key value in the variable, it needs to scan the entire string looking for that key. So, the larger your database variable gets, the slower it will get.
You'd have faster scripts if you used class folders and regular variables, such as
Code: |
/syssettings/health = %1
/syssettings/mana = %2
/syssettings/endurance = %3
/syssettings/willpower = %4
|
And stuff like that. |
|
|
|
TesterOfLimitz Novice
Joined: 02 Jun 2007 Posts: 37
|
Posted: Mon Jun 18, 2007 11:06 pm |
Hmmm....I didnt even think of that . Well, creating all the individual variables was easy enough (hooray for #loopdb) now i just gotta go back and change the variable calls in the script......Im still curious as to why it rewrites the record though, as I think im going to use the Data Record for certain key settings, like packnumbers that need updating regularly and such.
|
|
|
|
Larkin Wizard
Joined: 25 Mar 2003 Posts: 1113 Location: USA
|
Posted: Tue Jun 19, 2007 9:21 am |
Zugg wrote: |
One thing to keep in mind is that using database variables is not currently very efficient. Database variables are stored as giant string values (sort of like a string list, but with different delimiters between each item). Therefore, when you reference a particular key value in the variable, it needs to scan the entire string looking for that key. So, the larger your database variable gets, the slower it will get. |
I am actually quite sad to hear this. Database variables should be the fastest (and that's what I've always told people) because they should be implemented as hashtables with O(1) lookup time. I'd hate to re-write all my database variables to be simple variables because that detracts from the functionality of my scripts, such as looping through all the keys to reset or examine the values. How hard would it be to implement database variables as proper hashtables internally? |
|
|
|
Zugg MASTER
Joined: 25 Sep 2000 Posts: 23379 Location: Colorado, USA
|
Posted: Tue Jun 19, 2007 7:21 pm |
With the current design, it would be quite hard. It's the same reason the database module isn't a real SQL database. When the database module is rewritten, then you will see more efficient database variables (or maybe the Lua scripting will make all of this a moot point).
The problem is that all zMUD variables are stored internally as string values. CMUD expands upon this by also allowing a variable to have an integer or floating-point "cache". In other words, the value is still stored as a string, but if it represents an Integer, then the Integer value is cached to avoid repetitious string conversions (something that makes CMUD a bit faster than zMUD).
But variables still only store those simple types: string, integer, float. And everything needs to be able to be represented by a string value in order to be exported and imported via XML.
So, to implement a hash table, I'd still need to convert the hash table to/from a string value and just have it stored as a table when in memory, and then I'd need to modify the variables so that they can hold a pointer to this value (perhaps similar to how I currently hold pointers to COM objects). But since so much of the internal structure of CMUD is based upon string variables, there might be a lot of excessive conversions between the hash table and the string value and that might still cause it to be slow.
However, I shouldn't overstate this problem...database variables are still quite fast and are certainly not going to be a bottle neck. There are so many other areas in zMUD/CMUD that limit performance of scripting that I'm not saying everyone should convert their scripts. Database variables *are* convenient and should still be used in many cases. I didn't mean to open up a "can of worms" here, but sometimes people are interested in the low level details and whether A or B is faster. Just because B is faster doesn't mean A isn't useful. |
|
|
|
Larkin Wizard
Joined: 25 Mar 2003 Posts: 1113 Location: USA
|
Posted: Tue Jun 19, 2007 7:33 pm |
Thanks, Zugg, for the detailed explanation. I can see very well what you mean about storing things in the SQLite as a string. I don't know if it will be more efficient to serialize the data record variables as binary data when the real database module comes along.
As you say, though, they're not the big bottleneck for scripting in CMUD, and so I'll continue using my methods and believing that what I'm doing is for the best. It's certainly very readable, flexible, and more easily maintainable to use data record variables in so many situations. I'm really just glad they exist. I'll be interested to see how the Lua integration turns out and whether I should move more towards Lua tables for certain types of data manipulation. |
|
|
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
|