Yxxe

@Bonk: > [/Stupid argument] http://www.youtube.com/watch?v=teMlv3ripSM

You forgot the Spells Index over 35 fix for EO. The link is in my sig. Otherwise, fairly good. ;P

@Mr.LLoyd: > i had an old eclipse origins engine when i did pvp it should me the hp bars or is just me O_o It may be in an old EO Engine, but not 2.0\. I had to implement that myself.

@Mr.LLoyd: > i found a problem when your doing pvp you can see your hp bar under your char when you lose hp but you dont see the enemy hp bar. That's because it was never implemented.

@Socuine: > I remember .. Yes, I remember that I still owe you a GUI. > > :3! As you do with me. xD

@Bonk: > I suppose I'll have to wait until Eclipse C comes out. Maybe that will be the touchpaper for an Eclipse we can use effectively. Or how about you quit complaining and go and learn? I didn't get to programming things I really wanted into [OTLR](http://www.touchofdeathforums.com/smf/index.php/topic,55661.msg803296.html#msg803296) until I actually learned how to use VB. (I'm sure Robin will provide a few embarrassing posts I made when I was a newbie here.) Making a game takes dedication and a lot of time. After jumping from version to version (TE, EE 2.6, 2.7, ES and then EO), EO is by far the easiest engine to work with. Even if you can't code very well, there are some sweet tutorials in the 'Source Tutorials' section to get you started. That's how I pretty much began with VB6\. I take a look at a few tutorials and see how bits of code actually worked, then I started working on bits of my own. Sure, I can look back at the first pieces of code I wrote three years ago and have a heart attack looking at them, but that's how you learn. You write something, implement it and make sure it works. When you're done with that, you can come back in the future and improve on it. My Item upgrades system has gone through three versions and quest system has gone through at least four, just to name a few. So in summary, have the drive to make something brilliant and have the dedication to make it a reality.

@N000B!!: > I don't think you understand the changes I make to the source don't show unless I run the source in vb6 You need to compile. >_>

@Bcm27: > Stop quoting Gunthorian. It doesn't suit you. I AM GONTHORIAN.

@Kusy: > [Carmack confirmed positive for being an unwashed, full of himself cunt.](http://www.escapistmagazine.com/news/view/113564-John-Carmack-PC-Is-Not-the-Leading-Platform-for-Games) rofl. "PC is inferior because most PC systems are 10 times more powerful than consoles." XD

EO 2.0\. Too many CS look-alikes with games made in CS:DE anyway. >_>

If you want to give more customisation, do something like the socketing system I have in OTLR.

@ShinGamix: > Does Eclipse use Ruby for Coding too? Just VB6.

If she ask you to make cupcakes, RUN AWAY!

WOOT! Spline + Lathe + Weld Core! XD

1\. New tile type. 2\. Store sign number in tile data for the new tile type. 3\. Cache sign data server-side. 4\. Whenever a person "talks" to a sign send the cached string to the client, which has been accessed using the sign number. Come on, it isn't that difficult.

Sorry, but the only thing I see different from older screenshots is the text. o_o

@Akatsuki_1: > -snip- Unforturnately Nick, I haven't been seeing that. You make the game for your players, not for yourself.

What a shame. With those old graphics you had I was actually considering playing the game. Sorry guys, but this has put me right off. Best of luck in the future, Lightning

@Robin: > Better off dumping file list in to an array, loop & kill, then use rmDir to get rid of the directory itself. > > No reason to add more dependencies for it. > > Also, the RAR system causes huge amounts of unneeded data transfer due to download old versions of files. Looking in to caching the check-sum of files on the server and having the updater compare against the ones in the client and only download files which have changed. > > I'll release a copy of it once I'm done. So basically instead of hosting patches, you would hold the most up-to-date copy of the client on your patch file host. I'm guessing you would go about comparing file dates (or something along those lines) or a checksum like you stated. You'd then just go and take the files that have changed from the client on the patch site?

@Robin: > You're face. 

@Robin: > -snip- They're all poo and they don't make any sense. :3

@Robin: > No thanks. Other people's code never sits well with me. I like to program things myself. Whatever floats your boat.

@Robin: > I have no idea. Was simply curious. I'll be re-writing my updater for Crystalshire soon. If I come across anything ground breaking I'll throw it your way. Or I might just re-release an updated version of my updater. This stuff should really be in by default. Well that's what I thought. The basis of just downloading and extracting files seemed a little primitive, so I thought I'd release this source code so the patcher had a little more control over the client files. I'll send you the source to the Patcher Updater if you like.

@Robin: > Make it so the autoupdater can update itself. That's something I'll be adding to my own updater. Very useful for big changes like a new interface. I wrote an application for that already, but was planning to keep it to myself. ;] It's untested, but once I test it I may release the source for it. @Robin: > Isn't there a better way to delete a directory without adding more dependencies? If you do then I'll gladly update the tutorial.

Bump! ;]