xazax

r331

Meyraw made a nice modification on how to handle packets. You can check his project there: http://code.google.com/p/eathenanext/ The main point is, the packets are no longer edited with WFIFO macros, but they are structs, with members just like in Aegis. With such system it would be easier to add support for newer clients, since we can dump those structs from Aegis leaked pdbs ( In his code as far as I remember the struct and member names does not match with aegis' ones, maybe it would worth name matching.). Adding this would be a great deal of work, breaking lot of existing patches, and probably would be better to develop it in a different branch. Opinions?

r312

Well, some of the protection needs/should be on the client side, it is hard/impossible to make a proper server side only solution to protect servers from wpe/rpe/macros. Moreover, once we implement something, since rA is open source, it will be easy for everybody to analyze the code, and search for a workaround.

Well, grouping command would not be that hard however.. There are configs like from which level can a gm trade etc. We also need those configs to be set on each group. I think it would increase the complexity of the GM system greatly, unless you have a good idea how to handle this.

To make things a bit clearer. Reason for removing TXT support of player database: There is individual char_server and char_server_sql, we needed double work for char server edits Each time a new system appears like mercenaries, we would need to implement both sql and txt saving/loading, increasing our workload The compiled code is actially different of a SQL and a TXT compiled servers, we need to maintain more project files, people asking for support need to provide additional information etc. Using SQL is far more flexible because of CP and web services, and should perform better, and be safer ( less likely to loose data ). They are frequently modified at the runtime. Maintenance of SQL databases are easier ( deleting old/unused logins, purging invalid data, and etc). There are TXT related bugs, and unimplemented TXT features such as mercenaries. Now lets look at the db folder: db folder does not need maintenance from the server owners. Supporting db folder in txt format does not increase our workload much, the format is rarely changes, we do not need more project files for that etc. It is fairly easy to convert some of the dbs to SQL in case of somebody feel more confortable with that They are not modified on the fly, moreover the server does not modifies it at all. Does not have bugs or unimplemented features. Aegis also use flat text files for the same thing. All in all, if somebody fond of SQL db's, he can use it. But dropping TXT support for db folder provides us (developers) only little (or almost none) decrease in our workload, but degrades eA compatibility, makes people harder to switch from eA, and causes additional workload for server owners too ( They now just need to update item_db.txt and they are done. But with SQL dbs, they need to update item_db.sql and import it afterwards, +1 step) . Moreover it makes it harder for those who used to the txt format, to do db work. One of your reason was, it is easier to edit some dbs in SQL. Well.. if you use a GUI maybe. BUT: There are tools available to easily edit TXT format too ( database editors ) If you feel more confortable to edit something in SQL, you are free to do it that way and export afterwards ( i.e. mass edit ). Maybe you feel that db developers would have double work if we maintain 2 dbs. Well, no. They only need to maintain sql, or txt. The one they prefer. And if we provide conversion tools, they can keep updated the other one. ( I think there are some pearl script available to convert dbs, however it would be maybe better to provide binaries, it would be easier to use for all ). That is my opinion.

r301 Lets count at least until the last revision! How to link revision: type [ rev = # ] without the spaces.

My version: http://dl.dropbox.com/u/4131903/userDefineLang.xml May not be complete though.

The title of the topic.. I think it is not a question anymore

Greetings people I'm glad, we are here eventually.

It's nice idea, based on your one I would do something like this: if X is 0, then it affect all of the monsters, otherwise the given monster. This way it would avoid using a conf option, and you can combine the 2 behavior.

First aid! It looks awesome can use it everywhere, costs low sp, can spam it for long time. Everybody can learn it. And it can save one's life.

227

219

217

209

I think it would be more flexible, if it would work this way: 2115,1 would make valkyrie shield is not effected by drop rate, so you can use the full scale (from 0,01% to 100%). The original idea would force that, every mob has to drop that item with the SAME chance. However this way the same item can be dropped with different chances from different mobs.

First of all, I do not know what happened at the beginning of the project, I wasn't there. However if LimitLine participated in both projects as you state, I wouldn't say that, his code would belong to either of the projects as it's property. The main problem is not that, you used some of 3CeAM's code uncredited (see banding). The main problem is, you usually speak about 3CeAM with less respect than it deserves. Without 3CeAM, probably, brAthena would not be that updated/complete now. Maybe the opposite is also true, 3CeAM would not be at it's current level without brAthena. Of course brAthena has now more features since it became more efforts from developers ( I mean, as Rytech points out you had both our work/fixes, and your own ). The problem is the lack of communication and respect to each others work.

I think, it is worth keeping the pre-Renewal branch, because we may find exploits, crashers, which needs to be fixed on all servers, including pre-Renewal ones.

Actually, I think it is pretty obvious what those files are for, at least it should be for those, who wants to apply for a dev position. However that is true, there is a room for improvement in the documentation of the code. So what we need there, is not a glossary, but proper documentation.

I think most of them don't even know the existence of this forum. And without the old forums there is no way to inform them