I've just updated sd_procs with a handful of procs for converting between text, hexidecimal text and base 64 encoded text. Base 64 encoding is the format that BYOND uses when writing a binary file as text with the ExportText() proc.
I first became interested in base 64 encoding for decrypting dmi files in BYOND. (That project is still on a back burner.) Thanks to wikipedia's documentation of the format, I made a base 64 to hex converter in DM.
Today I was working with Mike H's RC5 library and wondering how to minimize the bloating of the encoded string. Once I realized that his library was returning a hex string, it all clicked into place. I can cut the string length by 1/3 if I convert it to base 64. It's still 25% larger than the original string, but it is quite an improvement and URL safe. Well... I thought it was significant! :)
The nybble colors have been in sd_procs for a while, but I didn't give them a proper introduction when I made the update back in April. These procs convert between a 3 or 6 character RGB hexidecimal code and a 4 bit (aka nybble) color code. Obviously there is quite a bit of detail lost in the conversion, but it's great if you have to store a lot of approximated color info in as small a space as possible. I use it for the colored text maps in Darke Dungeon.
ID:21058
 Oct 17 2006, 4:58 am
|
|
Incidentally, good idea for the "Trigger()" default-inherited proc! Way more convenient than the snippet which allows me to do this -- the snippet amounts to a series of five procs: ReactToEntering(), ReactToEnter(), AffectPresent(), ReactToExiting(), and ReactToExit(). This way, you can define custom behaviour for any of the possible stages of movement (e.g., landmines that only explode when you try to step off of them). The AffectPresent() is just a convenience proc which is spawned by the snippet's handler and is cancelled when the objects are no longer in the same location. Trigger() is probably the closest analogue to ReactToEnter().
Like I said, a Trigger() proc is so much more convenient. Leave it to me to invent the tire, rim, wheel hub, brakes, suspension, internal combustion engine, and transmission before I get around to inventing the wheel. ;-) | |
Nice! I've been planning on making a base64 en/decoder for quite some time now, but like many other projects and project updates, I haven't gotten around to it <_< (but now I don't have to! =)).
I'd always thought it was called a "nibble" (as a pun on the word byte ("bite") =P). Is it also spelled "nybble" to make the spelling parallel with that of "byte?" | |
Jtgibson:
Wow, that's a very complete movement reaction system, a little too complete for most of my purposes. I notice my fix to the Trigger() proc to prevent an item from Trigger()ing itself managed to slip through the cracks. It was on my home computer while I made this update from the copy of sd_procs that resides on my flash drive. -.- I also need to include instructions on using specific library files instead of the whole package, for people who don't want Bumped(), Trigger(), or other chunks of the library. Wizkidd0123: I've seen nybble both ways and most programming terms sites agree that either is valid. I like it spelled with a y because it sets it apart from the mundane nibble and helps you associate it with a smaller byte. Edit: I updated again. Trigger is fixed, the base 64 stuff allows alternate padding characters, and I fixed a couple small bugs in the base 64 codec. What can you expect from version 13? :p | |
I've always spelled it "nybble" too. It just looks cuter. =)
| |
My "encryption" amounted to rot13(encode_base64(rot13(text))). "Decryption" was rot13(decode_base64(rot13(text))). This would prevent casual users from just being able to apply a base64 decoder in order to read the passwords file, which I figured was "safe enough".
I think Lummox JR also has a base64 codec which he hasn't released or publicly mentioned.