Gepard

Developing a server application and a game client are very different. Doing the first does not necessarily mean, one is capable of or willing to do the latter. And we have a lot of stuff to do with rAthena, so everyone is pretty busy, I guess. However, I definitely would not oppose if anybody wanted to cooperate somehow with rAthena team to create a working server+client duo. But that's only my opinion. BTW Take a look at Shinryo's client topic in Project forums.

There are some problems with porting everything to libconfig. Main issue is "import". Libconfig supports "include", but it's a bit different. Most importantly, it does not allow to include in a way that would create duplicate settings. In rAthena, duplicate setting from import file simply overwrites the previous default setting and it's intended behavior. With libconfig it would require an additional code to merge the imported settings into main settings and sadly, API does not provide such function. rAthena conf files are really simple, it's just a bunch of scalar settings, all on the same level. No nesting, no lists, arrays, groups, nothing. To take advantage of libconfig, one requires a bit complicated configuration. It also explains why "include" works the way it works. "Importing" a list (like groups list in groups.conf) is not really possible, without overwriting it as a whole (there's no way to delete a member). But if we're overwriting it anyway, there's no need for import file that's specifically intended to change only some of settings while keeping other untouched. So actually there's no point in having rA-style import in libconfig, unless you use it .ini-style.

Yeah, multiple inheritance is supported, that's why it is inherit: ( "othergroup" ) You can put more than one, so inherit: ( "othergroup", "anothergroup" ) is ok. Does not matter if () or [] are used. Both lists and arrays will work. Recursive inheritance is also supported, ie in the example, group 5 will inherit from group 1 and - through group 1 - from group 0 as well. All commands are off by default. True means enable this command for this group, false means disable (used to override inherited settings). [false, true] is for atcommand, charcommand, yup. And no, one value is for atcommand only, because most commands will be either disabled for remote use (don't wanna players running commands on other players) or just don't have a remote version (that needs a cleanup on its own, by the way). I'm also considering adding a special superuser (admin) group, that would have all commands enabled by default (so there would be no need to enable all of them one by one) or, alternatively, a setting "all_commands: true" that would do the same for any group.

Ok, I've started working on new GM system. As soon as I finish it, I'll post a diff here for other devs to review changes. Progress: libconfig - Visual Studio done, autotools & cmake - to do, groups config file format - done, reading groups config file - done, group ihneritance - 50%, allowed commands per group - done, other permissions per group - 0%, atcommand config file format & reading - 75% command aliases - done command logging - 0% replacing gmlevel with group_id - 5% Config files at the moment look like that: groups.conf groups: ( { id: 0 name: "Players" commands: { autotrade: false iteminfo: true } permissions: { can_trade: true } }, { id: 1 name: "Supporters" inherit: ( "Players" ) commands: { autotrade: true broadcast: true } permissions: { can_trade: false } }, { id: 5 name: "testgroup" inherit: ( "Supporters" ) commands: { kick: [true, false] ban: [false, true] } permissions: { can_trade: true } } ) new atcommand.conf // The symbol that will be used to recognize commands. // You can set any one character except control-characters (0x00-0x1f), // '%', '$' (party/guild chat speaking) and '/' (standard client commands). // atcommand_symbol represents @commands used locally // charcommand_symbol represents #commands used on other players. atcommand_symbol : "@" charcommand_symbol: "#" // Command aliases // <commandname> : [ "<alias>", ... ] aliases: { mobinfo: ["monsterinfo", "mi"] iteminfo: ["ii"] time: ["date", "serverdate", "servertime"] autotrade: ["at"] help: ["h"] help2: ["h2"] jumpto: ["goto", "warpto"] mount: ["mountpeco"] who: ["whois"] npctalk: ["npctalkc"] gvgon: ["gpvpon"] gvgoff: ["gpvpoff"] jobchange: ["job"] load: ["return"] mapmove: ["rura", "warp"] dye: ["ccolor"] hairstyle: ["hstyle"] haircolor: ["hcolor"] monster: ["spawn"] blvl: ["lvup", "blevel", "baselvl", "baselvup", "baselevel", "baselvlup"] jlvl: ["jlevel", "joblvl", "joblvup", "joblevel", "joblvlup"] glvl: ["glevel", "guildlvl", "guildlvup", "guildlevel", "guildlvlup"] allskill: ["allskills", "skillall", "skillsall"] allstats: ["allstat", "statall", "statsall"] block: ["charblock"] unblock: ["charunblock"] ban: ["banish", "charban", "charbanish"] unban: ["unbanish", "charunban", "charunbanish"] unjail: ["discharge"] homlevel: ["hlvl", "hlevel", "homlvl", "homlvup"] homevolution: ["homevolve"] mutearea: ["stfu"] monsterignore: ["battleignore"] }

I don't recommend XAMPP nor any similar packages. To run rAthena in Windows you only need MySQL server. Webserver or PHP is not required. For local test installations, even rAsql is sufficient.

Source edit.

Edit common/mmo.h #define MAX_QUEST_OBJECTIVES 3 //Max quest objectives for a quest I didn't check, but probably you'll have to edit all entries in db/quest_db.txt as well (to match new number of objectives) Item objectives are usually handled by script, because there is no real need to this in another fashion. if(countitem(512) >= 10) // has 10 apples { // do something (quest done) } else { // do something else (quest not done yet) }

No, plugin system is there, because it's a required thing to convince anyone to using such a closed-source client. With no measures to customize it, nobody would use it. It's not to hide anything, but to make up for all the doors that closed source would close. Probably. Time will tell. Everything depends on how well designed are interfaces Shinryo was talking about. Is that a problem really? Opensource client modifications could be included in the client binary itself, but there's nothing wrong about dynamic libraries too. How is that different from open-source? I assume source would be released on GPL license or similar, which forces everyone to provide source code too. Then it would be even easier to add or remove anything. Yup. All GRF patchers are closed source. Yet every server uses one of them. I'm by no means advocating closed source for this project. I'm all for open source. But (depending on license) it will also have some drawbacks.

Trailing semicolons are optional. Users should not have to think/guess, because config file should be properly documented, so no problem here. Multithreading is not an issue at the moment. rAthena in general is not thread-safe, so adding multithreading would be a great overhaul anyway. Proper handling of configuration, which is very rarely written to, would be the least problem.

To improve GM system, we'll need a better format for config files. I think we should choose one that is human-readable, easy to edit with text editor and provides some more functionality that simple .ini which only has sections and key-value pairs. Maybe http://www.hyperrealm.com/libconfig/ ? I also thought about YAML, but it seems too complex for our needs. XML is out of question, it's not really readable nor editable. LUA - bleeeh. Writing own parser is reinventing the wheel.

But why would you prevent that? It's actually a good thing, because project will more likely flourish with great variety of plugins/customizations (both free and paid) built around free base. More people would like to learn how to write for Shinryo's client if they're not forced to release everything for free. That is one damn good point in favor of closed source.

Please check config.log. I installed mysql-server-5.5 and libmysqlclient-dev (libmysqlclient18) from Dotdeb repo and got the same error. In my case reason was: /usr/bin/ld: cannot find -lssl Solution to this is of course apt-get install libssl-dev

537

http://packages.debian.org/stable/mysql-server

MySQL 5.5? from experimental distribution? Try 5.1 stable package.

525

514

If you make SVN update on a working copy that has modifications in it, TortoiseSVN will attempt to merge changes. If your custom src mod is not very big, most likely it will succeed, and you'll have an updated working copy with your custom changes left intact.

501

"Attack a monster" is a very wide term. Do you mean physical attacks only or any kind of attacks? What about reflected attacks? What about attacks that hit multiple monsters, like any AoE spells (eg Storm Gust) - you want only one monster ID, so which monster should be chosen in such situations? What about attacks with help of mercenary or homunculus?

Is it supposed to be an usable item or equipment?

Take a look at conf/battle/client.conf

You can count number of monsters on a map, but only if they have a "script label" attached. You can also count all (all IDs) regular monsters on a map. To run a script when player logs off, use OnPCLogout event label. To run a script when player dies, use OnPCDead event label. You don't really need to make anything special here. Most quests work like this. Please note, that there is no way to give up quest in quest window. So probably, player would have to talk to the NPC to give up the quest. Use gettimetick(2) script command. No examples, sorry. There are some in doc/script_commands.txt and doc/sample/.

@block is a permanent ban and affects whole account. Currently there is no mechanism to block only selected characters from logging in.

Edit conf/battle/gm.conf // [GM] Can use all skills? (No or mimimum GM level) gm_all_skill: no