Lemongrass

Personally I would say that creating custom lua files would be the best and cleanest solution, since there are some features that gravity's lua files don't include. For me it would be the best to stay at a single sort of text data structured files and not to mix up all of those. I would create some kind of interface that gives you some kind of needed methods like: String getJobname( int id ); String getItemname( int id ); String getItemdescription( int id ); String getItemiconpath( int id ); String getItemspritepath( int id ); ... Then I would implement it in the "official" way and the way, that you decide to go. Personally I would like to see no XML and LUA files in the client, but something like a SQLite database behind the settings and/or the client informations. I would also include some kind of inititialization functionality for this interface so that the possibility to check whether the required data is existing and like that you could even provide the server owners the possibility to store the latest item infos on their server and the client downloads it at startup. What do you think of that?

I wondered about that part. Ziu do you also know, if all the (online) players in the party have to meet the requirements? Because as I experienced on fRO, they mustn't. I've posted a bug report yesterday, you can read it here: http://rathena.org/board/tracker/issue-5780-instance-check-party/

I dont know why, but somehow I cant read your post in here. Seems like the boards has some issues since the update, so I read it on your profile page. I like that idea of the register function. It would come in handy for customizations, but all in all that shouldnt be the first target of your project. I know that my version will result in redundant code, but I am a friend of clean code and I hate using preprocessors multiple times within a single function, like in network part of the eA/rA source. It becomes quite messy for me. After all I would suggest you to keep it as modular as possible and to only implement the latest packet version to start with, because right now we need an up to date client and the support of the latest packet version. This would also give the rA developers an incentive to support the latest packet version and implement it. Since I know your good with reverse engineering too I think that would not be that much of a problem for you I guess. Because of your idea with the register function I would change my idea to only create an interface with a function like: public void register( Networkmanager manager ); So that each packet version class itself registers only the packets and function it needs itself. But after all my idea is something you can like or not, its just my opinion of clean code but I know that the opinions on these kind coding style differ. Anyway I like your work so far and hope you keep it up and get it through, so there can finally be a custom ragnarok client. Edit: Trololol. The board is trolling me, right after I wrote this post I got to see the 5th page and with it your post.

Seems pretty ok. You seem to have a nice way of coding all in all, for example using design patterns. It is my mistake that you got me wrong. I do not think that the sending packets are a problem. But for receiving it could get troublesome with those structures. How do you plan on reading incoming packets? Read the packet ID and a switch/ifelse for working with the incoming packet? But all in all, I personally like the idea better, that the network manager consists of a method called for example "login" which gets some parameters like username as string and all others that are needed and the packet is created within this method not somewhere in the GUI code. Do you get what I mean? Because of my post above, I just thought over it again and came up with the idea of using a single interface for packet version and use the newest functionality for all elder packet versions too and simply drop calls to methods that arent supported by the packet version. You could therefore even provide a debug option to log such calls. All in all it will end in a call of a Singleton send call after all for sending a packet, but the code itself would be a lot cleaner, dont you think?

At last another update on your topic. I think that the preprocessor directives fit in well, but there is one problem. How do you intend to deal with packets that have variable packet length? Since you use a modular system, why dont you write an interface for each packetversion and let it handle the work. Why a interface for each packetversion? Since there are different functionalities for nearly all packetversions I think that is needed. That would also provide you and the users with the posibilty to change packets for different packet versions on their own and not only this but you would not have to think about any packet structures, since it would all be handled by the module itself.

if this is really your clientinfo.xml then that is the cause: <readfolde</readfolde

selfrip wtf? oder was meinst du jetzt gomen?

change: if( map[sd->bl.m].flag.autotrade == battle_config.autotrade_mapflag ) to: if( map[sd->bl.m].flag.autotrade == battle_config.autotrade_mapflag || map[sd->bl.m].flag.gvg_castle || map[sd->bl.m].flag.gvg_noparty )

and now please run a small script to replace the code within the npc folder, that would be awesome!

just to be correct, you can switch with strings since the latest java release aka jdk 1.7^^ i would like to see string switches in here, but first there should be a working direct variable assignment like introduced in revision 15982(havent tested it though) and things like var++ and ++var for the loops etc. but as i saw in the diff of that revision they seem to intend to implement those too

also ich weiß ja nicht welchen patcher du verwenden willst, aber falls du ne professional version von windows 7 hast, hast du zb die sogenannten IIS die du freischalten kannst, da is alles dabei web und ftp server, das management ist für windows benutzer mit halbwegs ausreichenden administrationskenntnissen auch nicht all zu schwer. sonst würd ich dir generell mal zu XAMPP raten, ich persönlich hab sonst noch mit keinen FTP-server programmen gearbeitet außer den standard paketen von linux. guides für beides solltest du eigentlich massenweise auf google finden. IIS: http://technet.microsoft.com/de-de/library/cc782498%28WS.10%29.aspx IIS-Guide: http://msdn.microsoft.com/de-de/library/6ws081sa%28v=vs.80%29.aspx XAMPP: http://www.apachefriends.org/de/xampp-windows.html XAMPP Guide: http://www.seospot.de/technik/mit-xampp-und-filezilla-einen-ftp-server-einrichten/

klar geht das auch, musst nur auf deinem pc nen ftp/web server installieren und die ip von hamachi und den port in den patcher eintragen. das hamachi netzwerk sollte dann im normalfall den rest erledigen.

wie kommts das wir nun doch wieder eine internationales forum bekommen haben?

do you intent to rename/restructure the tables or do you only want to structure the .sql files to insert them? i would appreciate the second thing and i believe a lot of people will share my opinion, since everyone would have to rewrite everything that is "custom" like control panels etc without any real purpose behind the change.

will the SQL part also get this kind of structure or will it be left as it is?

hmm seems like you don't know our TXT users... TXT users are usually the starters that don't know much of anything related to servers/commandshells/etc... so I don't think it will be fitting replacement, since they won't be able to handle this. but that's just my opinion. off topic: so if we are allready at removing features and getting the users to the "better way" to do things, wouldn't it be a nice idea to drop the GRF reading support? I didn't really look into it, but does anything use this functionality since the mapcache came up?

I think it looks beautiful, but if you don't mind please change the viewed topics source at the top, because some stupid or badly written posts are displayed as for example right now http://rathena.org/board/topic/56802-rathena-security/ ... I don't have problems with my iPhone though, on it the free space at the right top looks great.

So I'll also give my two cents to this topic: I am totally in favor of dropping TXT support, but as Gepard tries to say, it is really a difficult thing to work with SQL scripts during development. So my suggestion to this is, leave the /db/ and /conf/ folder as it is, but put a shellscript in the root folder that converts these folders to a single or maybe multiple SQL scripts. That would be a lot easier for the developers and also for all users. As for storing nearly everything into the database like the configs and the static content inside the database folder, I would say it would be no problem, because this data is only requested at server startup. Again I would be in favor of this idea, but not for development only for runtime, because its easier. For those who claim that the descriptions would be lost, it is possible to add a comment field in this configuration database! xD But all in all I would like to suggest that you maybe also implement SQLite( http://www.sqlite.org/ ), I just looked through the repository's changelog and found an entry for that 7 years ago. It is a local database which would be a perfect replacement for TXT as it can be run locally and also stops the need for TXT support, since it is also an SQL database which uses the same commands as MySQL. What do you all think of this?

do you think the system would be secure if the code would be available to public?

shit, im glad that the badword filter isnt applied to my password. otherwise i could not login anymore XD

my fail

oh lol. i've never worked with the newer ipb versions yet. didn't know that there is a user setting for this now

I also think their should be some kind of mod for it, havent looked into it yet though. btw could you decrease the post per side count to 10 or something? this topic is getting a whole load of scrolling

i didnt mean, if i could change it. what i meant was if you could change a setting for that this really sucks because then the intention behind the differentiation between user and displayname becomes useless! :/

I am also in favor of staying up to date, because in most cases ipb updates are because of security or bug fixes. And nowadays this is something that shouldnt be left aside.