Exception

> set new updater form as start up in the project properties and then its a matter of closing the form after the update and load frmmain or menu or water it is you want. OR you could have another program and when update is done or none you can exit on exit load game.exe **You cannot update a running program.** Your _only_ logical option is to have a seperate program update said program to run. Please, don't suggest things if you aren't fully sure of their use, otherwise you will mislead people to believe in something that doesn't work, and you will make it more difficult for the people trying to offer genuine, functional support.

>Implying Eclipse Origins is worth the effort to cheat. If you really wanted security, make use of checksums.

The 403 errors should stop now, as the datacentre for the website had it's security temporarily raised following an attack attempt during a vulnerable period. To anybody who had redirecting or forbidden issues on random pages, it should be fine now!

No. Already happening. Already happening. DX9 without the use of third party APIs is impossible in Vb6. No, it is inefficient and unnecessary. Supposedly happening, but in a less lazy way. Go away. Possible. Possible. Thank you Captain Obvious. Supposedly happening. Already hapenning. Possible. Possible. What? Already happening. Possible. Possible. Already happening. No. Done.

You can't update an open program =_=. Simply name your updater the main file, and either hide away the game itself, or rename it to imply it shouldn't be run, then make your updater use Shell when your update is done.

Hello, togekite. Remember doing Fyra Field about a year and a bit back? I'd like to request another song, please! - .OGG - Iron Prelude Returns, 2D ORPG. - Steampunk/Fantasy - Crown City; the overworld theme for the main city in a province. - It should loop seamlessly, the engine does this fine. Thanks! I hope you choose to do this. :>

uhm.

Well, by that, it's possible. Apologies, but we were under that pretense, as, you _did_ submit this in the suggestions board after all.

I don't think people here actually know what Mode 7 is. Anyway, ignore me, I'm being my usual pessimist self.

> **Heeeeell, no**! Corrected.

Bump. Still looking for some mappers and content developers. Don't miss the chance to come along! I also should've mentioned that in future, by being part of Glaciate, you'd **receive shared profits of any game you work on.**

http://www.soulzinc.com/forums/ That forum…does it even have a valid IPB license?

Uhm.

Your GUI is as mismatched as mismatched can be. Your font choice for the menu and buttons is also awful. Even if it's themed, it should still be readable. You're also using the default CSDE layout, at least diverge from it. As a start, it's not ultimately terrible as a design, but the same can't be said for how usable it'd appear to be to the end user.

> As Budweiser said. If we're going to do something like that, make it worth the while. I think that if you go as far as rewriting the engine you'd have to seriously come up with a better networking than it has now (Can't imagine you couldn't) and be able to make the editors and their functionality better. The byte array system itself already works as best as it can (well, minus the Nagle algorithm still being enabled.), and as a packet system it already has great functionaliy and uses. It's just -soooo damn stupidly used-, eg, Sending longs when bytes can be sent, constantly sending certain packets when they have no need to be sent so frequently, sending stupidly huge packets, etc etc. At the end of the day, Eclipse users should stop faulting the functionality, as really, it works fine for the most part (and we -will- fix the genuinely badly programmed systems), and there aren't as many problems as users like to exaggerate, often understanding next to little about what the hell is actually wrong. It's true, look at CSDE, we all know it's inherently bad to use, but how many here can actually describe in detail about what's wrong, and understand what the hell they're on about? From thinking about it, there are not many instances in Eclipse where it _is valid to blame bad programming or dated technology. The -only- bad systems within Eclipse recently that I can think of would be the event system, and… ...that's about it. Everything else works fine. Anyway, I'm done now. I just don't like seeing somewhat baseless comments on systems that are already functional._

Oh, good. Modmins! One of you should fix the few grammar mistakes, stick this, and have a direct link show in the header to Newbies!

Use GoTo . If you're using 2.3/7, then I'm not sure if it's in that. I'm fairly sure it's in 3.

Do you really think there is an existing tut on -pixel based movement-? When I've got it working as functional as possible, then 'll post one with a serious warning, but in all honesty, EO2/3 should stay tile-based, for a reason.

Rather than reply on the PM, I may as well reply here, so it adds to anybody who cares to reads' knowledge bank. Here's the function, effectively as Spodi taught me. The way pixel-based movement works is simple in concept, but quite difficult for some to wrap their head around. It works by utilising three packets from the client to server; one to handle starting movement, where the server then sends this flag to all clients on the map to process movement, one to handle stopping movement, where the server sends the flag to all clients to stop processing movement (and, to potentially sync it correctly), and one to handle changing direction. What I've done, is that I've left the tile-system intact, for the sake of mapping, but I've added a "subtile", a value out of 32 that acts as amatrix of tiles within a single tile. The server NEVER works out anything withtin it, it only synchronises and sends the subtile position. In terms of handling movement, the server -never- keeps track of players' ongoing movement, it is merely synced from the client, and prediction algorithms can be written to guess where a player'll be at a given point in time. The clients movement is also processed based on about 99% guesswork, and as a result, the higher the latency between the client to server to other clients, the more jumpier the game'll appear. Packets are never sent instantaneously, so, jumping is inevitable, but if syncing is timed right, you can manage this. In effect, you make the client handle all forms of colission and keep track of movement, the server merely corrects itself infrequently from what is provided by the client, so, it is possible to dupe the server, either by teleporting, or breaking colission. It's an unfortunate flaw, but it can be managed by using aforementioned prediction algorithms to work out if the new area is within range of the previously known position, and you can warp players out of blocked areas if they're standing there for too long (never make it instantaneous, you'll be met with tons of issues.). As you can see, I've pointed out a lot of flaws, but only because I wish for others to be educated in the matter, and to be aware of them. I'm currently in the process of writing it as fool-proof and preventing as possible, and I expect I'll be done shortly, and I'll most likely open up a test-server to see how it goes. Anyway, I've tried my best to concisely explain what I can. If anybody wants to correct, suggest, criticise, or question me, go ahead.

Thanks…so, anybody have any comments on the Ice Shard Credits system?

> The preferences at the registration page are hiden by the advertisements (i found out how to hide them after i registered  ) and sometimes when i hover over my name the lists shows but when i am moving my mouse to select one of the options some of them dissapear thats all i have noticed till now. i really like the design you have made and i love the color picker at the top it might only make little changes but it gives a different feel to the whole website. Nice work  Hm, I've found one other bug too. Audentio. v_v. Well, at least I can bug them to fix it for me. Also, I didn't make it, I just merely changed a few things around to make it more personal to me. :3 * * * Anyway, I need opinions. I've just posted what will eventually become an integral part of Glaciate, relating to the Store, and the existence of Ice Shard Credits. I'd like your opinions on the concept, how they're obtained, whether you think its fair, and how you think you would develop it onwards. http://glaciate.net/showthread.php?tid=76 http://glaciate.net/showthread.php?tid=77

You probably should say what you want, and how much you're willing to offer as a base amount.

Uhm…, you have a site? Set up PHP Paste or ownCloud in a personal hidden directory somewhere. You can install both easily through cPanel, provided you've got that.

Hm, I ordered a Pen & Touch Manga…was meant to be here yesterday, still hasn't come yet. ~_~ Anyway, draw a marshmellow dragon that craps Skittles.

> why not go for a more object oriented aproach? > > also getting rid of all the vb controls we are doing game not aplication programming Oh, you can count on me to ensure that is happening. I will personally make sure classes are used where structures should not.