LeetBoard Tech: "Is Read?" Issue

A feature that is familiar to everyone who uses any sort of forum software is the "Is Read?" or "Is New" feature. This feature is responsible for telling you what posts you have and havent read every time you log into or visit a board. Every forum software has a different way of accomplishing this. LeetBoard uses its own unique style, utilizing a database and cookies.

When you first log into LeetBoard, a blank cookie is set. When you read a topic, the ID of the topic and its newest reply is saved to the cookie. If a topic was made between your previous login time (your last login) and the time you just now logged in, and that topic does not appear in the cookie, the topic is marked as new. Similarly, if a new reply was made between your previous login and your recent login, and the parent topic's ID and the reply's ID dont appear together in the cookie, the topic is marked as new. Logically, this should be a perfect method for checking if a post is read or not, but for some reason it does not work correctly. I am not sure why this is, but I am currently working to figure out what the problem is and fix it.

Edit: The problem was due to a conflict with how posts were decided as being read or unread. Each member has a "last login" time saved with their account. This time is saved each time the user logs in, and its previous value is used to see if posts were made between the previous last login and the current time. The issue has been resolved by adding a query that updates the last login time to the current time when the user logs out. Issues may still occur if the user explicitly deletes the cookie which stores the forum session or lets the session expire without logging out.

LeetBoard Tech: Smiley Issue

An issue has been found concerning the smilies. When rendering the smilies from textual to graphical, some smilies are not correctly rendered. For example, if we have two smilies available, :( and >:(, and we have a post containing the text ">:(", the sad smiley is rendered with a preceding greater-than sign (">").

This is called a collision; when two conditions are similar, and one is checked before the other, the other is not met or is overridden. It is due to the renderer checking the whole text and replacing all occurrences of the sad smiley then checking the whole text and replacing all occurrences of the angry smiley. In order to fix this issue, the renderer must check each character of the text one by one and compare it to all possible smiley conditions. This is rather tedious and will add anywhere from half a second to two seconds, depending on how many smilies your board has, to the renderer's runtime.

Edit: All current smiley-related issues have been fixed. Smiley functionality is now complete.

LeetBoard Status

I didnt get a chance to post about my newest code back when I started work on it, but heres a little catch-up post. Ive created some forum software affectionately called LeetBoard. It is actually a further build on a bit of forum software I designed about a year about for a gaming clan called ThE NuBs, at which time the software was called ThE NuBs Chat.

Now, it is up and running for the Habbo Hotel in-game corporation Myishi Corp and is a prime feature of their site. You can find the Myishi Corp website, also done by me, at MyishiCorp.com. LeetBoard is currently in beta stages of development as a private project, and is just now on the verge of entering version 1.2. However, upon completion, it will be made public.

My Space on MySpace

Well, Matt threatened to make a MySpace for me that would make fun of my mother, or something. So, I decided to make one just to keep him from doing one for me. You can find it at this page.

Dont bother adding me to your group or friend list or whatever, as I wont go on it much. Its really a terrible website. I dont understand what everyone else likes so much about it. Well, at any rate, enjoy!

Update: Warn Logger

Ok, after roughly 12 hours of the release of Warn Logger v1.3, its now time to release the second edition to it. Introducing Warn Logger v1.3.1!

The only added feature is the long-awaited "New Topic" mode, in which logs are saved as individual topics instead of replies to an existing topic. Along with this mode comes some dynamic tags used to show helpful data to the administrators who review the logs. Check out the installation instructions for more info.

Update: Warn Logger

Warn Logger v1.3 was released today. It fixes a few compatibility issues with FireFox and actually works a lot smoother with both FF and IE now. One of the major issues fixed was the bug with the onLoad event.

The Frame responsible for loading post data and external links during Warn Logger's execution is required to load a page and let Warn Logger know when the page is done loading and execution can continue. The easy way of doing this is to use the onLoad event. Unfortunately, the onLoad event has some serious issues, especially when trying to dynamically change the function it calls. So, I swapped out the onLoad event with a substitute function that seems to work just as well. Here's the function:

function waitForLoad(nextcall)
{
// Since there are issues with the onLoad event, this function recurses until the document has no updated content
if (currentdoc == ""){ currentdoc = window.frames['wlframe'].location.toString() }

if (currentdoc == window.frames['wlframe'].location.toString()){ setTimeout("waitForLoad('" + nextcall + "')", 500) }
else
{
try
{
if (olddoc == window.frames['wlframe'].document.body.innerHTML){ currentdoc = ""; olddoc = "" }
else{ olddoc = window.frames['wlframe'].document.body.innerHTML; setTimeout("waitForLoad('" + nextcall + "')", 100) }
}
catch(e){ setTimeout("waitForLoad('" + nextcall + "')", 100) }
if (currentdoc == "" && olddoc == ""){ eval(nextcall) }
}
}

I call this function and pass the function to run after the page is loaded to it. Then, I change the frame SRC (document.getElementsById('wlframe').src), and ta-da! A custom onLoad event! Feel free to use this code as you please.

A New Support Approach

Howdy! Well, it's time to blow the dust off this blog with another new idea.

Ok, so, I've been getting a lot of support requests lately from people with problems with good ole Warn Logger. Now, I love helping people out and am in no way trying to tell people to back off with this concept, but the same problems keep reoccurring. So, heres what I plan to do.

I'm going to design a new chunk of code to allow the user to troubleshoot the code before they contact me. The troubleshooter will allow the user to fix the problem theirself or tell the person exactly what kinda information I need to get from them in order to fix the problem quickly and efficiently.

Here's a run-down of how I immagine it to work. The code starts by writing a try block on every line. If an error occurs, the try block will know of it and alert the user. The code will also be aware of the common errors encountered and common remedies the user should perform. The code will also check to make sure the code to test is installed properly. If all else fails, the user will be alerted with run-time reports from the code that need to be sent to me in order to fix the problems.

It's a bit low-tech, but I'm thinking up different ways of going about doing this without all the try blocks and such. If you see any codes pop up utilizing this concept, guess who the coder most likely stole it from! :p

Code Census

Wow, its been a while since Ive updated the blog. Ive been busy with a bunch of things.

Recently I launched a code counter with all of my public InvisionFree codes (as of this posts writing, three) to get an idea of just how many people use my codes. The counter was left on for a full 24 hours, give or take a few minutes. Im pretty happy with the results of the census; approximately 150 individual active boards have my codes installed and working. I say approximately because the results included about 2 google caches and 4 duplicates, and also did not count any of my codes which are self-hosted by the board owner. The next time I activate the counter, I hope to see even more boards in the results. The counter ate my bandwidth a bit, so I cant release a link to the results at this time. Sorry.

Also, I just updated to Beta Blogger and added an AdSense bar.

Two Code Updates for Reply-Blocker and dSig

Reply-Blocker has a few updates in store for it. Most of them are similar to the ones applied to dSig. They are listed below:

Make individualized (private per-user) cookies
Fix manager feature
Fix loadpoint
Confirm compatability with FF
MAYBE disallow Mod/admin blocking


dSig will also be receiving a small update to its cookie feature. The cookies use a character to distinguish different users and blocked names. The problem is if any user has that character in their name they cant be blocked and also cant use dSig! My solution is to change the character into something that IF boards dont allow to be in their user names. I havent figured out what yet, but when I do Ill let you know. This update will be included with the new version of Reply-Block as well.

Finished: dSig Update

I released dSig v3 about a week ago. It was going well until I got reports of an incompatibility with Firefox. Today I pushed out dSig 3.0.1, which features support for Firefox and a new runtime expansion that allows dSig to run faster than before.

The main reason behind the runtime expansion was not a concern of speed, but of conflicts with other codes. dSig uses a User CP addition called dSig Manager. In the method before 3.0.1 the code was run through the window.onload event, which can only hold one value per loaded page. Meaning if there is another code using the onload event, only one of the codes will run. In the new method, I check to see if the page is already loaded. If it is, dSig is run immediately. If it isnt, dSig is added to the onload event. I would like to make the immediate running mandatory, but that would mean becomming unavailable to boards with previous versions installed.