Does anyone have a good, working, XP log code out there that is PennMUSH compatible (or even one from a different system I can look at to tinker with for ideas) that doesn't use SQL? I have a mostly working one, but I'm having some trouble with the display options, so I'd like to take a look at someone's actually working code.
I only have sucky code or use SQL. Also, what data do you want stored? This will change a lot. Else:
<timestamp> <amt> <data>
Use | as a delimiter, keep | from being in the data part, and throw it on an attribute.
Maybe check for attribute length and start another attribute if it gets full.
Does that count as "good" for your purposes?
“If you wish to make an apple pie from scratch, you must first invent the universe.”
― Carl Sagan, Cosmos
Heh. Good is in the eye of the beholder. I just didn't know if there was maybe a common standard that some people used.The part I'm mostly stuck on is displaying it; I'd rather not have it display as just one big run-on page, and eventually a single attribute will run out of space.
I'm currently storing it as Date_With_Underlines|Earn#|Spend#|Reason_with_Underlines.
I suppose I could have it check words() to see how many entries, and if it's equal to a pre-defined max (maybe 25), have it start whatever the next in sequence would be, much like the BBS determines the next message number.
Sorry, “wing it” seems like the only standard here. I do have a log system that deals with rolling attributes, and put XP on top of it, but it stores all xp records on a single attribute set on a single object and that’s horrific.
Hopefully someone will notice and come up with something better.
@bobotron said in XP Log Code:
I'm currently storing it as Date_With_Underlines|Earn#|Spend#|Reason_with_Underlines.
While @Thenomain says "wing it", he himself has advised me numerous times in the correct way to store data in a MU. While I haven't done an XP system (I use Thenomain's), I have stored a lot of other data which is essentially the exact same thing. So...
Warning, this is all in MUX. I think Penn has the same stuff, or very similar, so please adjust accordingly!
d.repose.####10928372|... to start. No underscores, slashes, formatting issues. Timefmt() will handle the output.| is generally great, so that's good.120239837|14|null...|s it doesn't much matter to you. The output might be screwy, but it won't affect your code. It will always just grab the 4th thing, or the last thing.So, in conclusion... secs()|#|#|objeval( their reason here don't worry about underlines
And that'd get your data looking like: 12398382|14|null|Raising my strength
@skew is correct: I have very tetchy opinions on the best way to store data, but they are experienced best practices and “whatever works for you” is always the best way to get something done, if not always done best.
You will also need a second delimiter to go between records, for which I suggest ^.
This means you will also have to scrub user input to either edit out pipe and carrot, or do the aJobs thing of replacing those characters with ::pipe:: or ::carrot:: on input and display properly on output. (Putting user text last makes pipe less critical, but your record delimiter must be accounted for.)
If you’re going for a rolling attribute list (a decent idea), I would check strlen() of the attribute before appending to it to determine if you need to make a new attribute, not do a record count. You don’t know how long the user entered text will be, or if you alter the system later on.
If you’re using Rhost, you should even be able to get a check on the actual size instead of number of characters. Ansi and extended characters take up more space than the traditional English ascii set.
Otherwise, I’ll support Skew’s advice 100%.
Does anyone have a good, working, XP log code out there that is PennMUSH compatible (or even one from a different system I can look at to tinker with for ideas) that doesn't use SQL? I have a mostly working one, but I'm having some trouble with the display options, so I'd like to take a look at someone's actually working code.