Jump to content

xazax

Members
 View Profile  See their activity

  • Posts

    427

  • Joined

  • Last visited

  • Days Won

    3

 Content Type 

Posts posted by xazax

    Packets cleanup

    in Source Discussion

    Posted

    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?

    • Upvote 2

    rAthena security

    in Source Discussion

    Posted

    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.

    • Upvote 2

    New GM System

    in Implemented

    Posted

    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.

    Removal of TXT DBs

    in Implemented

    Posted

    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.

    • Upvote 7

    Editor Release: rAthena Database Editor

    in Server Manager/Editors Downloads

    Posted

    C++ intended to be fast, although it is easy to implement inefficient code with it.

    First I want to implement most of the features, I did not make any kind of caching or other kinds of performance improvements. Once the core functionalities are finished, I'll look into it.

    The program for me was very responsible and performend quite good. Qt is very decent for casual applications like this one. Although I did not try it yet on older machines.

    Try it, if you feel one of the features to be sluggish, feel free to post it, and I'll look into it, and hopefolly eliminate that bottleneck.

    In sort: resonably used Qt with reasonably written C++ code can be quite fast.

    Special Item Drop System

    in Implemented

    Posted · Edited by xazax

    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.

    • Upvote 1
×
×
  • Create New...