XP Log Code

Bobotron

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.

Thenomain

@bobotron

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?

Bobotron

@thenomain

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.

Thenomain

@bobotron

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.

skew

@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!

Make sure to use a relevant prefix in the attribute. For me, it was things like d.repose.####
Use secs() for a timestamp. Then use timefmt() to read it. You end up with something like 10928372|... to start. No underscores, slashes, formatting issues. Timefmt() will handle the output.
Using a pipe | is generally great, so that's good.
Earn# and Spend # should be just fine, so now you got something like 120239837|14|null...
Always run the free-form text through objeval(). Is that in Penn? I hope so. This will read the text as if it came from the submitter, which will strip out any funny code business.
Always put your free-form text last. You already have it, but to make clear, if you put the free-form text last, it doesn't much matter what characters they use. You can grab the 4th element or the last element on the list, and if they use a million |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

Thenomain

@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%.