Leaderboard

skill.c add a new function. void DOTASWAPfu (struct block_list *src, struct block_list *bl) { int x=0, y=0; x=src->x; y=src->y; unit_movepos(src, bl->x, bl->y, 1, 1); clif_slide(src,bl->x,bl->y); unit_movepos(bl, x, y, 1, 1); clif_slide(bl,x,y); clif_specialeffect(bl,34,AREA); clif_specialeffect(src,34,AREA); return; } add int skill_castend_nodamage_id (struct block_list *src, struct bl... { ... case MER_BLESSING: if (dstsd != NULL && tsc->data[sC_CHANGEUNDEAD]) { skill_attack(BF_MISC,src,src,bl,skillid,skilllv,tick,flag); break; } case DOTASWAP: //add DOTASWAPfu(src,bl); //add clif_skill_nodamage(src,bl,skillid,skilllv,0); //add break; //add case PR_SLOWPOISON: case PR_IMPOSITIO: case PR_LEXAETERNA: case PR_SUFFRAGIUM: ... skill.h add enum e_skill { DOTASWAP = 996, //add NV_BASIC = 1, Client http://goo.gl/BJ0uB db\skill_db,txt 996,9,6,1,0,0x1,0,1,0,yes,0,0,0,magic,0, DOTASWAP,DOTASWAP db\skill_require_db.txt 996,0,0,10,0,0,0,99,0,0,none,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0 //DOTASWAP data\lua files\skillinfoz\skillid.lua DOTASWAP = 996, data\lua files\skillinfoz\skillinfolist.lua [sKID.DOTASWAP] = { "DOTASWAP"; SkillName = "DOTASWAP", },

New GM, Commands & Permissions system has been added in r15572. Unfortunately, this update is not backwards compatible with previous revisions and requires reconfiguration of existing rAthena installations. This new approach is designed for easy maintenance, increased flexibility and readability. Hopefully it will make up for migration difficulties. General description The whole concept of GMs and non-GMs as well as GM levels has been abondoned in favor of more role- and privilege-oriented player groups. Each account belongs to exactly one group. Player groups are independent of each other, so unless you decide to do so, they don't have to share any privileges like it was with top-down GM level hierarchy. There is, however, a way to say which group is higher, and which is lower: it's group level. Each group has following atributes: ID — unique number name level — it can be interpereted as (GM) level of all group members commands settings — what commands can group members use permissions settings — what other permissions group members have inherited groups — permissions and commands from which groups are inherited log commands — should commands issued by this group be logged or not Groups are configured in conf/groups.conf file. The file itself is fully documented and contains default configuration that should be adjusted to your needs. Details Column `login`.`gmlevel` has been renamed to `group_id`. It now stores ID of the group player belongs to, so you need update your database accordingly. Atcommand configuration file conf/atcommand_athena.conf no longer defines GM levels required to use the command. Permissions to use commands are now defined for each player group separately in group configuration file conf/groups.conf. Command aliases are still being defined in conf/atcommand_athena.conf. File syntax has changed. Import is no longer supported for this file. File is fully documented and contains default aliases that were present in previous revisions. GM configuration file conf/battle/gm.conf no longer defines GM levels required to get some privileges (like trading or partying). See full list of removed settings:These permissions are now defined for each player group separately in group configuration file conf/groups.conf. Player titles defined by conf/battle/gm.conf settings title_lvl1 to title_lvl8 and conf/msg_athena.conf (335~342) are replaced with group names. Removed @adjcmdlvl command. Replaced @adjgmlvl command with @adjgroup, which allows to temporarily (until relog) move player to another group. In login-server configuration file conf/login_athena.conf min_level_to_connect setting has been replaced with group_id_to_connect setting, which allows you to define account group id that is required to connect to server. In char-server configuration file conf/char_athena.conf gm_allow_level setting has been replaced with gm_allow_group setting, which allows you to define group id that is allowed to bypass the server limit of online users. In log configuration file conf/log_athena.conf log_gm setting has been replaced with log_commands setting, which allows you to decide whether commands should be logged or not. Even with command logging enabled, only commands issued by groups that have log_commands set to true will be logged. About group level Group level is used only: when determining if player can override trade restrictions defined in db/item_trade.txt when determining if player can use @command on another player (existing rule that low-level player can not use some commands, eg @kick on high-level player has been kept) or see another player with @who commands (if they have "hide_session" privilege). as a return value for getgmlevel() script command when determining if player can use commands in a map with nocommand mapflag set Other CMakeLists were not updated. If you know cmake and want to contribute, just send me (or other dev) a diff. There were multiple minor changes in this revision. For full list, see rAthena Trac (r15572) or SVN log.

he is asking to check the amountof cashpoint.. it should be this mes "Cashpoint = "+#CASHPOINTS+" Cash Points."; or..setup a normal simple cashshop prontera,155,181,5 cashshop 757,909:1

I'm currently working on a custom client and wanted to share some screenshots about the progress. Some of you might wonder why there is again another project like this one with the same goal as the others, and why not just join the others to speed up development? In fact, I thought about this opportunity. However, I'm still learning to work with virtual reality and I want to learn as much as possible. And that's why this projects main goal is not to be finished as fast as possible. But still, it looks like I'm at good pace. I still don't have a "good" name for this project, even though there's a proto-name. One of the other goals of this project is to provide a stable client that runs on both, unix and windows systems. It is being developed in C/C++ and Ogre3D, takes advantage of multithreading where it is appropriate, uses atlas textures to reduce batch count and some other fancy algorithms to improve performance. Even though the complete terrain is being loaded instantly, it takes some milliseconds to finish the objects. That's why I'm currently working on further algorithms, allowing caching and paging of objects. I will release a working demo in the style of RagCam as soon as the new algorithms are finished and working. Here's a list of things that are implemented so far: GND (Terrain) Lightning Shadowmaps Colormaps (with reduced colors to match the original client) Vertex diffuse color Walls Smooth Normals RSM (Objects) Smooth Normals (with smooth groups) Animations Transparency Two Sided Triangle Faces (with correct normal vectors for both sides) RSW (World) Water (with texture and wave animation) Objects Ambient and diffuse lightning Performance is always a very important part for me. A lot of things are optimized as good as possible. This project will stay closed-source providing plug-in functionality in the future. Most of the information that has been used in this project has been discovered through reverse engineering of the original client. Rendering a map is almost completely done using the same and some improved approaches done by the original client itself. The main focus after this will be the visual improvement of the maps themself, like BumpMapping, Cel Shading support, etc. blah blah. When this is done also, I will focus on implementing network functionality and a GUI. I have started in november and worked effectively 5-6 weeks on this project. I had to stop at the end of december and started to work again two days ago. Enough talked, here are some screenshots using OpenGL as renderer (the results in DirectX are the same): Vertex color mapping: Each tile can have a diffuse color. This color, however, is not being applied to all four corners of a tile, but only to the bottom left vertex and all vertices that share the same coordinate. Textures have been disabled in this image to show that diffuse colors are being applied correctly. The border of a map is also being rendered correctly when vertex diffuse colors are applied. Shadowmaps: Some devs are still wondering why their shadowmaps look a bit weird. The reason is plain simple: A lightmap consists (most of the time) of 8x8 tiles, where only the 7x7 pixels in the center are used. Nothing new. However, the tiles are combined into a large texture. If texture filtering is being applied, then the borders of the different textures interpolate into each other, fatal for colormaps when they have different colors. This is called texture bleeding. Because of this, Gravity added a padding of 1 pixel to each tile (resulting in 8x8, instead of 7x7) and filled them with colors that still look nice when they are interpolated. The image below shows the correct display of shadowmaps. Colormaps: They are the same as shadowmaps, but use RGB colors instead. When applied to the terrain, they look smooth. If you look into a dungeon, you will notice that colormaps are not smooth at all. In fact, they look like the colors were reduced. This process is also called posterization. The best result are done with 16 levels. The idea is basically to use float colors, multiply them with the amount of levels, convert the result to an integer (and so dropping the decimal part) and divide the result by the amount of levels. Done. This image displays correct colormaps. Notice the borders of the lightning. Prontera indoor: Transparency: I've used BrowEdit to compare my results and found an issue that was the same as in my project. Some models had wrong depth writing. Using the correct order, it is possible to render objects regardless of their transparency. You can try to open BrowEdit and compare dicastes01 with this image. Instancing: A lot of objects in a map reference the same model, so it makes common sense to combine them for reducing the batch count. This image shows pretty could FPS, even though all objects of yuno are rendered. Instancing in prontera: I would also like to show animations, but am too lazy to upload a video. I am not generating MipMaps yet, since this will be part 2 of this project. As you can see from the screenshots, rendering itself is almost complete. Only some minor issues that have to be done. If you want to see a screenshot of a specific map, don't hesitate to ask. I will upload one. I let you guess which of the posted screenshots are made on linux and which on windows.

so yeah..rate please..

First: I would move the addtimer 300000, strnpcinfo(3)+"::On5Minutes"; before the warp not before you check if users are already on that map. Second: To add the price add this set .@id,7720; if(countitem(.@id) < 1) { mes "You need at least 1x "+getitemname(.@id)+" to teleport."; close; } after set .@map$,"turbo_room"; and this delitem .@id,1; after warp .@map$,100,100; I hope was able to help . Regards, Chris

Try this

Thank you for your suggestion. Libconfig which is the library used to parse these new, more complex configuration files does not allow to duplicate settings. I'm going to extend it so it would be able to merge default and imported settings. I'm sorry, I don't have OSX to test. I suppose it might be xlocale.h not being detected, so please try with this configure script: http://pastebin.com/VSLLdPv5 If it works, I'll commit it to SVN.

Good changes, but may I suggest adopting the import-tmpl/import logic for this file as well, since if one file violates the concept, it's pretty much moot

its under src/map/config

To provide some compatibility, each group has a level property, so if scripts requires a GM level with getgmlevel(), it will compare it agains a level of the group player belongs to. For example, "admin" group could have level=99, and "players" group level=0.

Just wondering, how would this affect script commands that relate to GM levels exactly?