etrepum: Aaah... OK. I don't think the iBook I ordered is a new product. I will quit worrying now. ;-)

Of course, the Apple Store isn't too far away...

Why am I an Idiot?

Don't answer that.

Seriously, I tend to preach a lot about proper coding discipline and techniques and all that. And never follow my own advice. Example....

AweMUD Accounts

So, just after ripping out the UserDB code in AweMUD and moving all the account information into the individual players, I realized this sucks and am now implementing an account system. Now, had I actually thought out ahead about the design of this stuff, I'd have likely just morphed the UserDB code straight into the account code. Silly me.

Anyways, the new behaviour will mean that upon logging in, users will now be presented with an account menu, versus going straight into playing.

Accounts will have one (or more) characters attached. Players could create new characters, delete characters, or start playing with a character.

The other nifty thing about this will be that we can enforce limits like how how many players an account can have (default 3), how many can be logged in at once (default 1), etc. The main configuration can over-ride the defaults, and the individual accounts can have over-rides as well.

For example, a game might only let free accounts have one characters, but might allow paid members to have two/three characters, and perhaps even more for "gold" members or whatnot.

Code could even be added for IP tracking restrictions based on account type. For example, perhaps free accounts would not be able to play if another player (even from a different account) connected to the same IP is already logged in. This would prevent people from making several free accounts to get around the multi-play restrictions. Paid for accounts wouldn't have such a restriction, at least not beyond the built in limits used to protect against DoS attacks.

Scriptix Security

The current access permission flags in Scriptix are set per-thread. Whenever you start a new thread, you specify the access permissions if different from default. The fork() call and such can just copy the originating thread's permissions, perhaps applying a "non-inheritable" mask. At least, that was the idea.

Now, tho, I've thought of some problems with this approach. First, it requires the C++ code launching the thread to have some knowledge of where the code came from. I.e., in AweMUD, scripts in the scripts/ folder should have full access, as they are administrator/coder scripts, while scripts loaded from AweMUD zone files should have greatly reduced privileges. In this case it's easy for AweMUD to keep track of these things, but in other theoretical cases it may be difficult to track this metadata.

Additionally, there is a potential security hazard. Say that a function was made by a scripter that shouldn't have file I/O capabilities, as the function is found in a zone file. Some Scriptix thread that has full privileges might be tricked into calling the zone file function (perhaps it was added as a callback somewhere), and that function gets full access. Now it could do file I/O. Bad.

The first solution which I've been thinking of would be to tell the compiler which privileges to have, and as a function/method is compiled the privileges are embedded in it. So, the functions in the zone would always have reduced privileges; if a thread has a function with full privileges, and it called the function with reduced privileges, it wouldn't matter because the privileges would be based on the current function, not the whole thread.

The problem with that approach is that a function compiled with full privileges could be easily in most cases called by a function with reduced privileges. This makes coding any function with advanced privileges more difficult, because the scripter would then be required to do their own privilege checking to see if the caller should be allowed to access the function.

Of the course, the logical next step is to do this automatically. The idea there is, each function again has privileges compiled in. But when function A calls function B, function B's privileges will be only the common set of privileges shared by function A and function B. I.e., if function A has fork and net privileges, and function B has file and net privileges, then when function B is called by function A it will only have net privileges. And it a function C is called from B, it will use the running B's privilege list. (i.e., if C also had file and net privileges, it still only get the net privileges as the calling instance of B didn't have the file privileges.)

Hollywood

jdhildeb: I was recently participating in a discussion about "Fedex" style quests in role playing games. The argument is that these style quests (which by definition consist of taking an item from point A to point B, usually embellished by having to find point A first or kill some creature there to get the item) are horrendously boring, and that all quests matching this pattern are, thus, boring.

The problem is, there are almost no quests you could possibly think up that doesn't fall into this pattern. With a little (too much?) thought, you could map any quest to the pattern, no matter how intricate or entertaining.

I would dare say this sounds like your description of Disney movie plots. Pirates of the Carribean has a rather unique plot, and is definitely unlike any other Disney movie I've seen. You however claim that, "stripped down", the plot is unoriginal. Unfortunately, *any* movie, including the indy movies, could also be stripped down to one of a few basic plots. The thing that differentiates movies isn't the underlying basic plot, but the details of that plot. (And perhaps any meaningful underlying message trying to be delivered with that plot; those are just as rare in indy movies as mainstream movies, I'd argue, however.)

I would dare say that you are perhaps biased against mainstream movies, and thus (subconsciously) put in the effort to strip down the mainstream movie plots in ways you don't try to do with indy movies you enjoy. Ya, Hollywood shovels out a lot of crap, but so do indy movie producers. Eschewing mainstream films because of a prejudiced feeling that big budgets are only for bad movies is just as bad as refusing to watch anything but Hollywood movies because you think that only a big budget can make a movie good. ;-)

Also, on a bit of a side note, no good pirate movie *could* have a female as a true main character, as it wouldn't fit in with the culture of the period. If I have anything against Pirates of the Carribean, it's that they did make Elizabeth such a modern-times kind of girl, as chances are that kind of behaviour/spirit would've been schooled out of her long before she grew up. Were we talking about a movie in a different period/culture, then the lack of an indepth female character would've been a real shame.

It also rather bothered me that the skeletons had eyeballs; that didn't make much sense. I suppose the truly terrifying way they *should've* looked, however, would've made the movie classified as horror and not a family adventure film. ~,^