Friday, August 03, 2007

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.

Sunday, May 20, 2007

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!

Sunday, April 22, 2007

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.

Saturday, April 21, 2007

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.

Monday, February 12, 2007

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

Monday, October 16, 2006

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.

Saturday, May 20, 2006

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.

Tuesday, May 09, 2006

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.

Sunday, April 23, 2006

Reopening dSig

Well, Ive been working on the forum software for ThE NuBs. Its still not completely done, but its getting closer. I also finished Project Apex for now till the owner of it gets online again.

So, with those two monster projects done, Im ready to reopen an old code: dSig. I had said I would upgrade it back in the days when I wasnt so busy. I tried to open and edit the beta files of the work I had done towards the new version, but after reading through it a few times, I realized that the function and methods I had used in the old version wouldnt be able to work correctly with the ammount of data I would be passing it in the new version. As a result, Ive decided that it will be easier to completely recode the new version instead of just changing the structure of the function.

That means it will be a longer wait for the code, but will be definately worth it. As usual, Ill continue to post updates on the new versions progress as it unfolds.

Wednesday, April 05, 2006

Warn Logger Trouble

At first, the release of Warn Logger seemed like a big success. But then reports came in of a problem that was causing a board error. After cranking out the next version with the fix, I found out that for some reason one of the features, the one that allows you to post reports as new topics, wasnt working. I have no idea why that is as the code that deals with that feature was never even touched.

With this version came two more problems! The code now had some compatibility issues with Firefox and was causing "Aborted Action" errors in Internet Explorer. After talking with a friend, I figured out that the IE error was caused by dynamically knocking elements out of the DOM. I fixed the problem and it seems that the FF incompatibility was also being caused by the same problem.

So far, there have been no more bug reports. Hopefully it will stay that way and I can get some peace!

On a side-note, Ive started work on a "resource site" by a group called Project Apex. Its a pretty nasty little organization. The heads of the group are highly experienced web users, some including hackers, programmers, scripters, and other ranks from the "dark net". They all agree that there is no reason to fear them or not visit their site as their objective isnt to mess with innocent computers. Check it out at http://www.project-apex.com.