Jtgibson's site

A pie chart

Mon, 24 Nov 2008 22:38:34 +0000

http://www.graphjam.com/

client/AllowUpload()

Fri, 17 Oct 2008 18:14:50 +0000

New feature: The new /client/AllowUpload() proc allows you to decide whether to accept a file from a player or not. The two arguments are the filename, and the length in bytes. If you return a true value (the default) from this proc, the upload is allowed. Otherwise, the command or input() that was being used will send back null instead of a file reference.
--Lummox JR

This is a very cool-sounding feature. Very elegant way of handling that "as filesave" suggestion way back when.

However, is there going to be any way for the client to report what kind of file it is uploading (independent of filename, which is easily spoofed) and/or a way for the server to have a chance at verifying the file type upon receipt? BYOND still tends to trust the client far too much when it comes to invalid data, particularly during file uploads.

A random thought on online life simulation games

Wed, 15 Oct 2008 18:34:52 +0000

After thinking about life simulation games online (e.g., Wurm Online), I realised that one of the fundamental problems with online RPGs in general is that a player has no sense of what exactly s/he's getting into before jumping into the game. Players who join MORPGs typically have a character concept in mind based on what they've picked up from the website or what looks the coolest in the character creation system. However, if the game tends towards life simulation instead of adventure/fantasy (e.g., Hedgerow Hall), it is possible that the character that a player chose can prove uncompetitive at best or totally unviable at worst.

This got me to thinking: what if a player could join the game and explore the game world as a sort of "tourist" in order to check things out? As a tourist, the character would be unable to attack anyone and would have nothing of value, but could still be attacked (esp. by monsters). The goal is two-fold:

1) Playing as a tourist allows the player to survey the existing establishments in the game and see what industries are lacking. Casual conversations with the game's residents would also serve to let the player know what's in demand and what isn't.

2) The player gets a "wolfing tutorial" of sorts which puts him into real danger and warns him/her to stick to the safer areas. As the player ventures around and explores, s/he'll inevitably discover the areas that are most dangerous (the hard way) and will thus be able to measure the most settled areas versus the frontier areas.

The ultimate goal after learning these two pieces of information is to be able to design a character that would be more able to conduct a profitable business for a service that is in demand in the game.

Everyone in Hedgerow Hall wanted to be a smith, and because of this the smith occupation was balanced towards being more difficult (so the better smiths would turn a profit) when in essence the real problem was the overabundance of smith characters (too much supply, not enough demand).

If characters could go into a game in advance and see what exactly they might be able to play as, the play experience could be that much more fun.

Still another peek into the inner workings of my mind

Mon, 28 Jul 2008 16:22:38 +0000

    Omnicant //Spiders
        //Wordplay on "Omniscient" -- omni- for all (Spiders have lots of limbs),
        // cant for language.  Spiders are the know-it-alls of Newtopia.

The description is worse:

"The ability to speak and understand Omnicant, the language of the Spiders. Under cogitation Omnicant is perceived by nearly every sapient biological entity on Newtopia to epitomise as a unilateral archetype the eminently most-utterly complex and obfuscated linguistic communications instrument at one's dispensation."

Simple server-side Wiki

Wed, 18 Jun 2008 15:31:47 +0000

I'm presently engaged in the task of trying to find a self-contained Wiki which:

1) uses MediaWiki syntax, which is infinitely better than C2Wiki, Wikidot, or most other Wiki syntaxes,
2) requires almost no installation; resides in a single self-editing file or resides in a pair of files (a script and a database), and
3) resides server-side, meaning that users wouldn't ordinarily be able to edit the Wiki.

I'm so used to documenting in MediaWiki format now that just about everything I write is in MediaWiki syntax. It bothers me because to display it to an end user, I have to: 1) parse the file manually and convert it to HTML, or 2) create a whole Wiki, which is silly when I'm writing just one page for a project.

If all else fails, I wonder if there's a simple parser which takes a file with MediaWiki markup and spits out a static .htm corresponding to it (e.g., <h2> for every ==, <hr/> for every -----, <b> for every ''', etc.).

I'm almost tempted to get back into finishing my DM-format MediaWiki parser. I previously abandoned the parser as "possible but unfeasible", which doesn't bode well for my motivation.

Post as draft

Sat, 14 Jun 2008 04:10:58 +0000

For the BYOND Members blogs, there are some days where I've made a post and then want to make another... however, because I don't want to cheapen the former post, I tend to wait a few days before posting the second.

One feature that the BYOND Members site already has is the concept of submitting posts to other blogs, assuming you have the rank privilege. These posts go into an interim "submission" stage where they are reviewed by moderators and then accepted for posting.

People who have full posting privileges don't need to go through this review; when they make a post, it goes through immediately. I suggest allowing an option of posting as a "draft", which submits the post to the site as a "submission" even though you have regular posting privileges. Then the post is already made, and all you have to do is wait until you're ready to make the post and then click a link.

Saving it as a text file on your hard drive is a passable workaround, but because it isn't shown on your BYOND Members home base it's hard to remember to post it at all!

Why hello Mr. Scope, how shall I exceed you today?

Fri, 13 Jun 2008 20:35:16 +0000

Last night, I was browsing around ThinkGeek for all of the gadgets, and I started transcribing one or two down something like this:

Photographic Eyewear:
        A "pair of glasses" which can take a picture of what is currently being
        seen by the user when triggered, using a small camera embedded in the
        bridge.  No internal memory, must be connected to an external permanent
        memory by wire lead or a wireless network.

        Parts:
        
        (Frame)
        + Micro Photo Camera
        / Trigger Mechanism
                | Audio/Verbal Trigger
                | Button Trigger
                | Expression Trigger
                | Neural Trigger
                | Wire Input
                | Wireless Receiver
        / Output Link
                | Wire Output
                | Wireless Transmitter
        / Power Source
                | Electrical Input
                | Micro Power Cell
        * Eyeglass Lenses
        
        The lenses are optional; they can be any make of eyeglass lens, such as
        those curing myopia or hyperopia or those obscuring harmful ultraviolet
        radiation, or may simply be left out to allow the device to act as a
        portable and convenient camera only.
        
        As with optional parts in any other item, lenses are not included by
        default.  A purchaser of photographic eyewear should contact an
        ophthamologist for manufacturing a proper set of lenses.
        
        The device has no processor and thus cannot be used as smartglasses.
        
        Specific behaviour is as follows:
        
        ==Audio/Verbal trigger==
        
                Device takes and transmits a photo whenever it hears a certain
                noise.  Most users program it to the sound of a code word or a
                simple physical noise like a cluck or a snap of the fingers.

        ==Button Trigger==
        
                Device takes and transmits a photo whenever a small button on
                the frame is pressed.  This allows silent photo-taking, but
                requires a free hand.

        ==Neural Trigger==
        
                Device takes and transmits a photo whenever the user
                concentrates on the activity.  This is silent and does not
                require hands free, but requires practice and can result in
                missed photographs or accidental photographs.

        ==Expression Trigger==
        
                Device takes and transmits a photo whenever the user makes a
                certain expression for a certain amount of time.  The device
                uses small lasers to detect the contortions of the face.
                Typical gesture is a three-second wink, as if scrutinising an
                object.

        ==Wireless Trigger==
        
                Device takes and transmits a photo whenever the device receives
                a certain signal.  Continuous receipt of the signal will cause
                the device to repeatedly take photographs after a short delay
                each time.
        
        ==Wire Trigger==
        
                Device takes and transmits a photo whenever the device receives
                a pulse along an electronic circuit.  Continuous flow of the
                circuit will cause the device to repeatedly take photographs
                after a short delay each time.
                
                Usually the wire trigger is fed by a handheld button or switch.

I looked at it and looked at it and looked at it and thought, "Wow, that's actually a really good documentation format."

Then I got stupid:

/*
Name of the item or part:
        If a line includes no leading formatting, it is descriptive only.
                   Leading whitespace is ignored, but it is recommended to
                        make the format human-readable.
        
        If a description line ends in a period, the next line is considered
        part of the same paragraph and is led with a double-space.
        I always thought it was lazy how W3C recommends trimming everything
        to a single-space when it is improper grammar and improper typography
        to do so.
        
        A list of parts is handled with a certain syntax by using a special
        markup.  Whitespace leading up to the symbol and after the symbol is
        ignored.

        (Integral part, for display/repair purposes only)
        #Not interchangeable with other parts
        + Part that must be included for item to work (included by default)
        * Part that may optionally be included (not included by default)
        / Sub-inventory and is not an actual part itself
                | One of the possible parts that must be selected from
                | Second possible part that must be selected from
                | ...
                | Last possible part that must be selected from
                //Sub-Subinventory
                        || One of the possible parts in the sub-subinventory
                        || ...
                        || Last possible part in the sub-subinventory
                //Second sub-subinventory
                        ++ Mandatory part in the sub-subinventory
                        ** Optional part in the sub-subinventory
        * Another optional part at normal depth
        
        #It is not mandatory to list parts in a single block -- they should be
        # compiled from the whole item -- but it is strongly recommended to
        # ensure ease of readability.

        Each part in the item is created when the item is parsed, unless a
        part by that name already exists.  Parts of the same name are thus
        interchangeable between all items that use them.

        Parts cannot be installed or uninstalled while the item is being used
        or worn.  The item must be removed from the body and handled at a work
        bench (usually in a Machine Shop).

        All descriptions are compiled
        into a single string.  Two or
        more line breaks are considered
        syntax, but line breaks are not
        and are considered part of the
        same paragraph.
        
        #Lines prefixed with a pound are comments and are ignored.
        
        Items are normally handheld.  If they can be worn, they use a certain
        syntax to indicate all of the locations they may be worn in.  Each
        line of the syntax indicates one possible wear position, and each
        location in the syntax indicates the body parts that are covered by
        the object.
        
        #This example would say "Wear on Face" as a possible action for the
        # object, handled by the game engine.

        #Syntax:
        #Opening brace
        #Name displayed to player, followed by a colon
        #One or more of:
        # One of 'covers', 'layers', 'touches', followed by a hyphen, followed
        #  by a comma-separated list of location names.
        # A semi-colon is necessary unless the next symbol is a closing brace
        #Closing brace
        
        #Internal whitespace and linebreaks are ignored, but the first line
        # ignoring leading whitespace must start with a brace.
        
        #Example:       
        {Face: covers - human eyes; touches - human nose, human left ear,
        human right ear}
        
        #covers - list of locations that the object is worn on top of
        # (cannot have anything else over top)
        
        #layers - list of locations that the object is worn on top of
        # (but can still have something else over top)
        
        #touches - list of locations that the object rests against
        # (but cannot be equipped there if something is covering them or if
        #  too many layers are used)
        
        Special features are built-in symbols that determine what the object
        can do.  Special features are part of the game engine, and the parsing
        of each special feature line should also be handled by the game engine
        to determine what special properties the object should have.
        
        %Powersource
        %ElectricalAttachment(powersource, poweroutput)
        
        Scripts are the meat and potatoes of the item and are used to handle
        how the object behaves.

        
        ~Script label
        #Script labels can be called from the script as functions, or called by
        # the engine if they use certain hard-coded names.
        :line of script
        :line of script
        :line of script

        #A line beginning with a $ is a "verb" of this item that the player can
        # activate.
        $action
        :line of script
        :line of script
        #Lines prefixed with pound in the script are comments.
        #Lines of script must always be prefixed with colons.

        #Whitespace in a script is ignored.
        :#Lines prefixed with both a colon and a pound are also comments.

        #This is still considered part of the user-action, regardless of
        # intervening whitespace or comments!
        :lval = rval
        :condition {
        :       line of script
        :       line of script
        :       condition { #Inline comment
        :               nested line of script
        :               nested line of script
        :               #Infinite nesting should be fine.
        :       }

        Disabling an item in this file is done by surrounding the item with
        multiline Slash-Star and Star-Slash C-style comments.  Do not be
        tempted to use the C++-style Slash-Slash comments, as this indicates
        a sub-subdirectory.
*/

A self-documenting object definition language.

Estimated time to release: 14 years (assuming no setbacks)

Less yellow, more mellow

Tue, 27 May 2008 02:16:11 +0000

On a whim, I went ahead and adjusted the CSS of the site a little, mainly because the brown-ink that looks so good on my parchment background looks so terrible on the default blue forum background. I still need to tweak the contrast of the boxes that make up the Blogwatch and the Favourites, since those are way too dark for my tastes.

Cached Gaussian Random Number Generator

Mon, 26 May 2008 21:03:46 +0000

//Title: Cached Gaussian Random Number Generator
//Credit to: Jtgibson
//Contributed by: Jtgibson
//Special thanks to: Lummox JR


/*
This is a simple Gaussian random number generator, inspired by Lummox JR and by
the information presented at http://www.taygeta.com/random/gaussian.html

Use gaussrand.rnd() to return a Gaussian random number.  The system will
automatically generate two Gaussian random numbers at a time, returning one and
caching the other for later.  The second time, it will yield the cached number,
clearing the cached number so it can generate a new pair of numbers next time.
(If you simply use generate() each time, the cached number will always be
wasted.)

A Gaussian random number is a number which is centred around zero and can
theoretically progress from negative infinity to positive infinity.  However,
99.7% of the time, it will be greater than -3 and less than +3; 95.45% of the
time, it will be greater than -2 and less than +2, and 68.27% of the time, it
will be greater than -1 and less than +1.  These "waypoints" of +/- 1, 2, 3 are
considered "standard deviations".

See also:
http://en.wikipedia.org/wiki/68-95-99.7_rule
http://en.wikipedia.org/wiki/Standard_deviation#Rules_for_normally_distributed_data
*/

gaussrand
    var/tmp/alt = null

    proc/rnd()
        if(alt == null)
            . = generate()
            //usr << "DBG: generated numbers [.] and [alt], using [.]"
        else
            . = alt; alt = null
            //usr << "DBG: using cached number [.]"

    proc/generate()
        var/x1, x2, w, y1, y2
        do
            x1 = 2.0 * rand() - 1.0
            x2 = 2.0 * rand() - 1.0
            w = x1 * x1 + x2 * x2
        while(w >= 1.0)

        w = sqrt((-2.0*log(w))/w)
        y1 = x1 * w
        y2 = x2 * w

        alt = y2
        return y1


///*
//Testing code/sample implementation:

mob/verb/test_gaussrand()
    spawn()
        var/gaussrand/gaussrand = new
        var/iterations = 1000

        while(iterations--)
            usr << gaussrand.rnd()
            sleep(1)
//*/

Decrement Until/Increment Until

Wed, 21 May 2008 23:40:07 +0000

//Title: Decrement Until/Increment Until
//Credit to: Jtgibson
//Contributed by: Jtgibson


/*
Often in my code, I wind up writing a code construct which goes something
like this:

if(value - decrementor < 0)
    value = 0
else
    value -= decrementor

I realised that this was a common-enough procedure that I could write a
shorthand which didn't make excessive use of the min() and max() statements.

Note that you should use the proper procedure for the right circumstance.  For
instance, if you will never be absolutely certain you will be modifying the
number by only a positive number, you should not use the increment_until()
proc as it is designed to constrain to an upper limit only.

See the Bound Constraint snippet if for a slightly more intensive alternative
that works with both positive and negative modifications.  You would use:
value = CONSTRAIN(0, value+modifier, 100)
*/


proc/decrement_to_zero(value, decrement=1)
    return ((value-decrement>0)*(value-decrement))


proc/decrement_until(value, decrement=1, minimum=0)
    return ((value-decrement>minimum)*(value-decrement) + \
        (value-decrement<=minimum)*minimum)

proc/increment_until(value, increment=1, maximum=100)
    return ((value+increment<maximum)*(value+increment) + \
        (value+increment>=maximum)*maximum)



///*
//Testing code/sample implementation:

mob
    var/value = 50
    
    verb/test_random_decrement()
        //Read as "decrement 'value' by 'rand(1,5)' to zero"
        // or "decrement to zero 'value' by 'rand(1,5)'"
        value = decrement_to_zero(value, rand(1,5))
        usr << value
    
    verb/test_random_increment()
        //Read as "increment 'value' by 'rand(1,5)' until it equals '100'"
        // or "increment until 'value' plus 'rand(1,5)' equals '100'"
        value = increment_until(value, rand(1,5), 100)
        usr << value
    
    verb/test_custom_decrement(decrement as num)
        //Read as "decrement 'value' by 'decrement' to zero"
        // or "decrement to zero 'value' by 'decrement'"
        value = decrement_to_zero(value, decrement)
        usr << value
    
    verb/test_custom_increment(increment as num)
        //Read as "increment 'value' by 'increment' until it equals '100'"
        // or "increment until 'value' plus 'increment' equals '100'"
        value = increment_until(value, increment, 100)
        usr << value

//*/