Thursday, April 16, 2009
XRumer 5.0 Palladium
I'm most curious about how the hacking community will treat/mod this tool. We could be seeing an assortment of spambots like this in the future, which would cry for harsher security measures. I predict that in a few years some organizations will be merging advanced AI technologies into these bots and make them virtually impossible to tell apart from real accounts. Oh ho, porn spammers will be pollutting every public chat sites by the dozens. This is just the beginning, I hope someone comes up with a method of dealing with such a castrophe if it ever happens. Turning off account registrations everywhere would suck. :\
Friday, April 10, 2009
Monday, April 06, 2009
http://aviary.com/
I am so happy you decided to try out Aviary! Aviary represents the future of creation: a place where you can collaborate with other artists of all different skill levels to create incredible works. If only Michaelangelo and Picasso had Internet access as well...- avi
I discovered a link to this website today and found it pretty cool. For anyone interested in graphics design, it's like an online Adobe suite you can use right inside of your browser! It's Flash and JavaScript and maybe Ajax combined, so it can do some amazing things for a browser application. Once you register an account, you can save all of the files you create to a profile that other users can view. Also, if you want to, you can let other people import your work and make deviations of it, which can be pretty fun. Or you could have multiple people doing different parts of an image, like one draws, someone else colors, etc. From the description, you're probably thinking it's low quality stuff, but noooooooo. This was well made, check out for yourself.
Aviary has:
Raven - a vector editor
Phoenix - an image editor (it's like Photoshop without the plugins and price tag)
Peacock - an add-on for creating filters and mind blowing effects
Toucan - It even has a color scheme generator!
Total cost: Free.
Yeah, you read that right. This service and all of its professional quality web suite is free for you to use without even running an installer (unless you're back in the 56k age and you don't have the Flash plug-in...)
Now I've experienced drawing and vector applications in Flash before, and I can tell you that it can get laggy FAST. BUT I did not experience any lag with these tools. They ran just as they would in a win32 application. The only downside I could see was that it doesn't quite work right in Opera due to layout problems(?). It works fine in Firefox and I imagine IE though. Oh and editing pixel by pixel doesn't seem possible, unless there is some work around I am unaware of. Anyway, I don't mean to be an advert-whore but this stuff is just too cool! Never would I have imagined Flash being capable of emulating Photoshop without lacking... almost everything.
There are a couple of restrictions that require an upgraded account, but that's mostly just for privacy settings.
I imported and made this with Phoenix lawl.
Thursday, April 02, 2009
www.Flowchart.com
With my registration came 20 invites. So if anyone is interested, just leave a comment with your e-mail address and I'll try to get around to it.
Wednesday, April 01, 2009
The time is now...
That's all for now.
Friday, March 13, 2009
I'm still here!
Well, the name has been decided, but we're going to keep it low for a while because there's literally nothing to show for it yet. It's like cutting a ribbon to an empty field. Exciting eh?!
Anyway, next thing on the list is to bang out a logo for the group. Hey it only consists of two people but we plan for expansion eventually. I'm also fiddling around with developing a back end and web site, so everything is ready to start rolling.
As for the interpreter, there is some good news. I have almost everything planned out, and should be ready to start coding soon.
Well that's all I have for now, see you next post!
Saturday, February 28, 2009
[PROJECT AURORA] Announcement
Computer machines and software have been a major part in science fiction multimedia plots, and although not accurately depicted all of the time (*coughCSIcough*) it just looks plain awesome! One of my favorite type of scenes are when a person is at a computer screen, presented with a UNIX-looking type command prompt, and they would just start hammering in commands off heart that do something cool like hack into the system, unlock doors, initialize a system lockdown, control docking bays, fire external weapons at target(s), upload coordinates to a pilot, etc.
Another favorite of mine would be terminals used to interact with certain systems, such as the Aurora Units in Metroid Prime 3. :)
Now if you've never played the game and are wondering what the heck an Aurora Unit is, then allow me to explain. It's one of many sophisticated organic supercomputers originally used for scientific purposes, but later became widely used for government, business and military roles.
A vast network links all existing Auroras, allowing them to access a tremendous database without peer. - [source:http://metroid.wikia.com/wiki/Aurora]
So yeah I've got some thoughts and fantasies right now for LSL, but pulling out a project this huge could take over a year. I'll probably need some help from more mathematically evolved people but time for worrying about that is no where near.
If you haven't guessed, my network is now uh-hum... Aurora themed. :P
Don't worry about the interpreter, I haven't forgotten about it. Just finishing one of my other projects before I even touch it.
Tuesday, February 24, 2009
☼ IDEA
More details on the interpreter in a bit.
Friday, February 20, 2009
Working with Charts
Thursday, February 19, 2009
[LSL RUNTIME INTERPRETER] 2.Research
A little further thinking and overlooking on my part has sparked some potential issues with the interpretter and how information will travel between libraries. It sounded great at first using linked messages, but then I remembered that linked messages have their own triggered event (d'oh!). So instead of doing all of the work in the listen event (or data_server event regarding notecards), I would have to constantly wait for the library scripts to return the values I want, which would make things a bit tricky. Every call would trigger the event, so if the owner said a line of code in chat like say...
llSay(0, "Name of sim is: " + llGetRegionName() + " and the name of this script is " + llGetScriptName());
Okay, the interpreter checks if the owner said something on the main channel(channel 0). The owner did, so the script enters the listen event, carrying with it the parameter values: channel, name, key, and message. The first three are unimportant for this example, but the message parameter would be set to our line of code said above. Alright! Now, let's pretend there's some sophisticated syntax checking to make sure the line of code can be properly executed. The whole line of code contains three of LSL's functions: llSay(), llGetRegionName(), and llGetScriptName(). Okay, now let's say our none existant syntax checker determines that llSay is some kind of function call (just because it has parameters with it), but it doesn't really know what because it's just a string of characters and it doesn't care what it says until you tell it to with conditional statements. It would be cool and a lot easier if you could just typecast strings into lines of code by simply typing (code) or (function) infront of them. ;P
(code)"llSay(0, \"Hello World!\");"
As cool as that would be, it would be practically useless unless you were making something strange or a form of interpreter. It could also pose some security risks, but anyway...
Okay so the main interpreter script did some more parsing and comparisons on the input and identified the three function calls within that one string, smart huh? It realizes that we have some kind of function, that has two parameters, the first being of type integer or float(automatically typecasts integers), and the second being a string... a string concatenated multiple times with other functions... functions which presumably return string values. Okay, brilliant! Now what to do with this knowledge? If I go with the script library method (having all of LSL's functions listed and segregated into different scripts) then I would have to send llGetRegionName() and llGetScriptName() to the libraries with linked messages first. Otherwise llSay would treat the other functions as strings. Even the plus signs would be treated as characters! That's no good. So those two get sent first. Let's say llGetRegionName() gets sent first and link_message gets triggered in the proper library (maybe a script named sim.lib?). It compares the string with a list of strings that contain all of the simulator functions. The check matches, finds that there are no parameters with it, and performs the function. The value gets returned and immediately sent back to the interpreter script through a linked message, triggering a new link_message event... wait.. what was this script doing while waiting for that message? Well, whatever it was coded to do. Chancers are, it finished and exited the event, making all of the above pointless. So all of that syntax checking and identifying was wasted. So how do we rewind and fix it so that the current input being processed actually finishes and executes the way we want? Hm, good question.
There's the option of using a list to save our spot and everytime a new linked message is recieved, look inside of that list and replace the according function with whatever value was returned. Sounds good so far, but I'm sure there's something I'm overlooking again... Well, let's start from where we left off but only using this method of having our spot saved. Okay, the script enters link_message, looks inside of the cache list to see if anything was waiting for data to be returned. Oh look! llSay is waiting for llGetRegionName() to be returned! Bam, replace the string " + llGetRegionName() + " with whatever value was returned. Much better, but it's not done yet. There's still one function left in the string. So repeat the process and save our point to the list and send a linked message to whatever library for llGetScriptName(). Only problem with this function call is that it's going to give us the name of the library script and not the interpreter script... heh. Oh well. When it's all done we should have the string redone to this:
llSay(0, "Name of sim is: WHATEVER and the name of this script is script.lib");
Great. Now send our last function off to the libraries! Seems like a lot of work, but I'm still looking for other ways to make the interpreter able to handle functions within functions. This could all be done without my library method, but I want the main script to have a lot of memory available for those user instruction sets and saved variables that I have mentioned in my first post.
The important thing I'm focusing on now is research. I have an example of a runtime interpreter someone has already made in LSL, but it's very limited in what it can handle. It also has a load of scripts which I'm unsure of. She may have used the same idea of making 'libraries' to handle everything rather than one script and a gazillion if statements. That's another issue I'd like to address... How will this be possible without having a if statement for every function?
I think I'll take a small break on this, because it feels like it might be a much larger project than I had originally predicted. Doesn't mean I won't be thinking about it though, and any updates or ideas will be posted.
That's all for now!
Saturday, February 14, 2009
[LSL RUNTIME INTERPRETER] 1.The beginning!
It's here, the first project of the blog! All update entries concerning a project will have the following header format so if I ever start posting useless crap about my daily life, you can scan through pages for what you want. Anything concerning a project will have the title tagged with the project name in square brackets and in all capital letters. eg. [PROJECT NAME]
The entry number concerning the project's update status will be put after the project tag, and before the title of the post. That should be easy enough huh?
Now, the goal for this project is to code a LSL(Linden Scripting Language) runtime interpreter that functions nearly identical to the LSL virtual machine environment within Second Life. There will be a few limitations concerning states and function calling but I hope to work with it. A small amount of memory will be given to the user for variable declaration and storage (yeah it would have to store the name and data). I'm not even sure it's possible to create a fully functional LSL runtime written in LSL alone... If anyone knows how, leave me a message. :P
Since this is the beginning stage, I'm only at the phase of bouncing ideas around and how to go about predictable problems. At this point, I'm thinking one state for the user, and one state for clearing the instruction sets. "Instruction sets?" you might be wondering. Yep, now this is another idea of mine that might make or break the interpreter's overall usefulness (wasn't very useful in the first place). Basically whenever the user inputs an event name into chat, the compiler goes into a 'write mode', where it will store the function calls into a list dedicated to that event (list instruct_touch_start = []; for an example). It will continue to do so until the user inputs that he/she wants to exit the event, maybe by saying "exit event name" or something. Once the interpreter receives the call to exit the 'write mode' and go back to normal operations. The effect would be immediately put in place, so if that state is ever entered again, a procedure will check for any existing instruction sets and play through them like a recording.
Of course that idea is only going to complicate things two-fold but I really want to push the limits with LSL.
Two things already worry me. Script memory and speed. The amount of processing power that will be needed to perform so much parsing and conditional tasks to run a fairly complex block of code will make the waiting period for results so much more. Now the biggest problem is script runtime memory, which Linden Lab has limited to approximate 16kB. Not bad for a little server side script, eh? Yeah well that memory does not just account for variables... states and events also accommodate memory. Linden Lab really busted our balls with data types too. There are no such things as boolean, unsigned, doubles, shorts, longs, char... Efficiency wasn't on the list for the scripting department. Oh well.
Summary: Goal is to create a LSL runtime interpreter that accepts code from in world chat. Features include global variable declaration, event instruction set storage, functions called within functions, and state access (cannot create new states though). I'm going to try to code this all into maybe 2 or 3 large modules which use linked messages to communicate data to one another.
Well that's all for now!
Friday, February 13, 2009
[spank@localhost ~]$ blog successfully created
Greetings! I am someone of none importance and only made this thing to help me keep track of my thoughts and ideas for the projects I plan to begin shortly, most related to Linden Lab's Second Life virtual world. If you plan to read my incoherrent mumblings then feel free to do so. Hey even leave a comment if you want! I don't care if all you have to say is the N word repeatedly, at least someone's giving me attention. :P
Now why would I choose a platform such as Second Life you may be asking? Simple answer being, it's the only thing I'm useful in! Ha, I'm way behind on the serious programmer route I had planned to walk years ago, and I am even having reoccuring second thoughts. Programming in languages like C or Java just isn't as much fun for me as PHP or scripting languages. It's a matter of ability and dedication, which I lack both. Creating mathematical formulas ain't my thing for starters, and reading literally buttloads of API documentations is the last thing I want to do. But worst of all, working with polymorphism techniques sometimes just turns my brain into tar. Not sure how open source developers do it. They must get a rush from it or something. :(
Anyway back on to the question. Second Life uses a scripting language called LSL(Linden Scripting Language) and it is fairly easy to learn. There are so many things you can do to bring life to the virtual world using it that it has become a high-demanding job for in world entrepreneurs. I would even go as far as to say that LSL is probably the most complex thing about Second Life itself. I've been interested in it since I've joined the platform back in 2006 and I've made a lot of useless junk. My most famed accomplishment was my take on Second Life gun scripts. I've focused more-so on making the scripts low lag and with a fast ROF(rate of fire). They weren't the best out there, but those scripts were amongst the same range of quality as other famous and EXPENSIVE scripts on the grid. Price never matters much to me, not unless it involves someone snooping around my code who I don't want to be snooping around my code.
Ahem...
Well, Now that the new year has taken off, my hobbie as a scripter has evolved to the point where I feel the only road left to take is the one that leads me out of my comfort zone. I won't get any better until I explore new areas and maybe even outside into the vast realm of the open sourced client.
That is all for now, as it is 4:24AM AST and I could use some rest. Next post will talk about ideas for an almost fully-funtional interpreter written entirely in LSL.
Later!