mrjnumber1

drama whore staff (shows immaturity) incompetent staff (both technically and game-knowledge wise) stupid donations/customs (anything from big and ugly gears to stupid gears that give crap like stats+20) low population (usually a sign of bad economy and woe; plus, i don't want to play alone) inactive staff (no updates) harmony (because i can't play from my uni) bad woe (tends to follow everything else i posted, but mostly it means our investment into the server is meaningless)

I should note that the grey floors are just a custom GRF.

Outside of the obvious problems of extensibility being subpar. No matter how amazing your plugin system is, it will ALWAYS be inferior to what it'd be as open source. 1) Let's say there's a huge bug. Everyone will have to either rely on you (instead of Gravity) to fix it or try to find it in ida (or anything similar for disassembly debugging, I'll just say ida) instead of something much more sane like visual studio or c::b where you can see the original code/data structures/etc, on top of being much MUCH more accessible for most people. Considering Gravity's client is much much older software, any bugs are much more likely to have been found and fixed (or ignored, sadly). With your client, you won't be able to catch up to that status for years. Or worse, with your plugin thing people are going to have to ship 10 hojillion plugins to fix bugs that aren't fixed yet. Then maybe they're fixed but users still have those plugins and the client becomes unstable. Oh no! 2) Let's say there's an exploit of some sort. Everyone will have to rely on you to fix it........ or try to find a solution in ida instead of something more sane like visual studio! With Gravity's client this is the same case, but people at least have had years of work put into modifying it and will have at least some familiarity with what they should be doing. With yours, none of those people know anything about your client. So they're going to stick to fixing bugs with Gravity's client. Easier that way when you've got years of experience there. 3) let's say there's bad code somewhere. who knows where, but something clogs up too much memory or cpu time. there's an issue somewhere, and someone wants to improve it. well, unfortunately they would have to do so via ida. Or that "amazing" plugin system where they have no idea if what they're doing will be stable or not.. 4) let's say you die in a horrific accident (though let's hope not, be safe!) while the client is closed source. that's it. game over. client development stops there. we are then back to where we are now, with no custom ro client worth a damn. y in general all of these problems just come down to the project dying with you alone. And infinitely easier and more expandable in an open-source implementation. You wouldn't have to worry about creating this system (for this project at least) and you would actually have people who can help you with development. Not really sure where you're coming from here... you're worried that people won't follow, say, the GPL? yep You have the chance to release one of the most important projects for private server development (one that is at its best if open source, and at its worst if not) but you're going to give us nothing but an alternative to Gravity's. Maybe it gets slightly better performance, who knows. In my experience at this point in time it's really only relevant for huge GvGs, which don't exist on most servers anymore (and the performance issues are gone upon an @refresh anyways, heh).

This project isn't much better than Gravity's client if it stays closed-source IMO.

You aren't providing anything useful, and I'm assuming that the black square is the contents of image/no_emblema.bmp. You probably don't have GD installed.

1 billion scary things going on 1) you didn't actually show us the contents of emblem.php that would in fact help 2) you're linking to emblem.php?data=id.png which is most likely not proper 3) you're an evil man using <> instead of != 4) you're echoing html 5) you're using mysql_ functions 6) you might not be sending the header in emblem.php

make sure you've updated your atcommand conf and check that you have no space between command_symbol: and @/!. cause that seems to be bugged atm.

hi i too am a girl add me on irc my name is mistah_j

Should this be agreed on, all new scripts created should use the new extension, with legacy scripts remaining in .txt imo. I'm not sure how the versioning screws up upon renaming in subversion so hopefully that all goes well in the event old scripts are updated and renamed.

It should be expected for txt builds to not find sql commands. So either use #ifndefs or entirely remove the txt builds from your project.

hi xazax you are cool in irc tia

hi newbie :P

This would also need a way to apply to drops added to items. For example, Orc Archer Bow adds a Steel Arrow drop, so it'd be useful to limit that drop rate separate of the drop rate from the mob Orc Archer. I've implemented a system like this for my own source but I haven't done enough testing so far, and it feels kind of hackish (essentially I just added 2 new entries to struct item_data and a separate db to add those). Another thing that would be good (something I have been working on) is limiting mobs to specific rates; that is, instead of forcing every drop from shining plant to be lowered in the item_db, just add a new db to adjust its drop rates. Additionally, it could work to adjust their EXP on top of their drop rates.

avatar owns fyi