Message alerts.

[Jfloyd]

Oh lord what have I done D:
I actually wouldnt want a sound, just the flashing pl0x.

[loftar]

I figured as much, no worries, just know the offer is there

Oh certainly. As I said, I would love nothing more than to give the coding of the client to someone else, so don't consider it impossible that we might make the client code public. I've been considering it for a long time. :)

The protocol is also designed in such a way that the client is more or less just a graphical terminal, so there isn't a whole lot of cheating made possible from it. The most obvious point of cheating would be, as I said, removing the light mask.

[theTrav]

The most obvious point of cheating would be, as I said, removing the light mask.

Which you could of course enforce on the server side by only sending data for tiles that the client can actually see, however that's a performance trade off.

The other related big one you'd want to decide on is the resolution. If the client code becomes public, first thing I'd be likely to do is give it a flowing layout to support multiple resolutions, so you'd probably want to lock down the available tiles to what the user can actually see (unless you wanted to open that up a bit too)

[loftar]

The other related big one you'd want to decide on is the resolution. If the client code becomes public, first thing I'd be likely to do is give it a flowing layout to support multiple resolutions, so you'd probably want to lock down the available tiles to what the user can actually see (unless you wanted to open that up a bit too)

That's already done. ;)

[Ferinex]

I must admit that I have considered making the client open source and everything. I wouldn't mind it with regards to ownership of the code.
* It could be argued that one should be able to see and interact with stuff behind other things. I do like the possibility of hiding behind trees, though.

Easy fix. Only update and show the user that which he can see in a straight line from his character. Similar to adventure mode in DF. For instance, if you are standing to the east of a tree, there would be a 'triangle' spreading out from the tree to the west - of terrain you cannot see (or rather the terrain does not update from the last time you saw it; perhaps grayed slightly).

[Trafalgar]

It would mean that it would be free game to do such things as removing the light mask for full visibility on even the darkest of nights; or implementing wall hacks*; or implementing auto-grind macros; or maybe something else that I can't think of right now.

But I'll keep considering it. Maybe some middle ground could be struck, like allowing access to a few trusted ones or something. I don't know. At the very least, I'd need to discuss it with Jorb.

* It could be argued that one should be able to see and interact with stuff behind other things. I do like the possibility of hiding behind trees, though.

On removing the light mask: Yes, that is a downside, but: people can get around that right now anyways with gamma settings and such (and I normally keep my monitor very dark, but set it to what most people consider normal during the H&H night), and someone will eventually figure out how to fake a light level command from the server anyways and someone may write a program like UOAssist that sits between the client and server and filters traffic (and could alter the packets which have light level commands).

On wall hacks, if you mean walking through walls, which was also a problem in UO for a while:
Rule #1 in MMOs is: Do Not Trust the Client. Anything the client is saying it wants to do MUST BE checked by the server to see if it's actually legal. Every parameter to every command needs to be verified as being within a legal range. Be overly paranoid. Someone can alter the client, alter the client's data files (in UO's case, either the map data, or the tiledata files that specifies what objects block movement), fake a request from the client, or reverse-engineer the client or packet system. UO's data files and packet system were reverse-engineered so well that fully functional server emulators were able to be written from it.

I like hiding behind things, but I don't like losing items (mainly buckets) behind things. I think the best thing might be to give large objects such as buildings and trees a 'shade' radius similar to their current cover, in which someone can hide from view, becoming invisible, using their stealth skill. A ranger using their perception or exploration or whatnot could have an ability that allows them to look for hidden people. (UO had a hide, stealth, and detect hidden system, but you could hide *anywhere*, even in the middle of an empty graveyard in broad daylight with no cover, so it was a bit unrealistic)

Personally I've got more experience with working with and on UO server emulators - both modifying their source code in a team and working on scripts for a UO shard in a team (although I think most people here who know me wouldn't know that), and very little with client development.

[loftar]

On removing the light mask: Yes, that is a downside, but: people can get around that right now anyways with gamma settings and such (and I normally keep my monitor very dark, but set it to what most people consider normal during the H&H night), and someone will eventually figure out how to fake a light level command from the server anyways and someone may write a program like UOAssist that sits between the client and server and filters traffic (and could alter the packets which have light level commands).

Yes, I know, and of course I have been a little bothered by it; but there is, of course, little that I can do about it. The point I was trying to make was more of a psychological one; while the client's source code is closed, at least, many more people would probably think twice before doing that. Having an open client might get people thinking that it's more or less alright.

On wall hacks, if you mean walking through walls, which was also a problem in UO for a while:
Rule #1 in MMOs is: Do Not Trust the Client. Anything the client is saying it wants to do MUST BE checked by the server to see if it's actually legal.

Hehe, why, yes thank you. I may not be the perfect programmer, but I don't consider myself quite that stupid, and the implication of it is almost insulting. ;) As I mentioned above, the client is more or less just a graphical terminal; it doesn't even use bounding box information.

I like hiding behind things, but I don't like losing items (mainly buckets) behind things. I think the best thing might be to give large objects such as buildings and trees a 'shade' radius similar to their current cover, in which someone can hide from view, becoming invisible, using their stealth skill.

Those kinds of stealth skills are indeed something considered for the near future, but with regards to object occlusion, my long-standing thought has been that the player, when having stood still for long enough behind an object (say, for half a second or so), would be able to see the outlines of other objects behind that same object, and interact with them through those outlines. I do realize, of course, that that is bordering on implementing game mechanics in the client, but nevertheless, it is how I'd like it to be. (And I don't really want to check sprite data in the server to enforce it; at least not for now.)

[Raephire]

Jorb codes Hello world, goodbye server.

[Trafalgar]

On wall hacks, if you mean walking through walls, which was also a problem in UO for a while:
Rule #1 in MMOs is: Do Not Trust the Client. Anything the client is saying it wants to do MUST BE checked by the server to see if it's actually legal.

Hehe, why, yes thank you. I may not be the perfect programmer, but I don't consider myself quite that stupid, and the implication of it is almost insulting. As I mentioned above, the client is more or less just a graphical terminal; it doesn't even use bounding box information.

I didn't think you were all that likely to do that, since you seemed pretty damn smart, but considering the UO developers managed to do it... Of course, they were the first ones to build an MMO and they really had nobody to look at as a guide for what not to do. But you have done some things that we considered absolutely forbidden in UO server emulators, most specifically not pausing the game and saving all the data for everything all at once to ensure a complete and clean save.

Also, the people who build the sphere UO emulator made some pretty odd decisions in their coding leading to performance problems, too. For example, whenever a player or NPC took a step in that multi (a building stored in a data file for the client so it didn't have to be sent to it, like your log cabin), instead of checking for collisions only with the pieces of that multi on the particular tile they were trying to walk to, it checked for collisions with EVERY TILE IN THE ENTIRE MULTI. You could make some very large multis with many pieces in them, and get noticeable lag as a result. Even smaller multis eventually resulted in sever-side lag from monsters running around in them (I was at one point working on a random dungeon generator in UO using multis of dungeon room tiles, and this lagged up the server until I fixed this because of this problem). Whoever wrote it was feeling lazy and made sphere store all the pieces in one big array... I fixed it, but if we hadn't had the source I wouldn't have been able to. Any other sphere shard would have been screwed, because sphere isn't open-source.

And every time sphere wanted information about a particular terrain tile's flags, or an item's flags, etc, it read them from the hard drive, instead of loading them all once and then reading them from memory. Cue grinding the hard drive, because it reads this stuff all the time.

It did the same with the map (although the map was sizable, it could fit into memory)

It did the same with all the scripts.