Jump to content

Jonne

Members
  • Posts

    149
  • Joined

  • Last visited

Everything posted by Jonne

  1. Your patch has nothing to do with your error.
  2. Since we don't know where you put your for loop, we can't really help you. I can tell you this much though: You will not want to iterate over a for loop in a skill usage that checks for md movement. You much rather want to implement a structure within the md that keeps track of this debuff (using a SC for example) and do all the checking in the default unit movement procedure.
  3. I changed the @who commands to accomodate your wishes. Basically I added @who4/@whomap4 which work exactly like the current @who und @who works as you wished it to diff --git a/src/map/atcommand.c b/src/map/atcommand.c index d8d52b9..ffd2d78 100644 --- a/src/map/atcommand.c +++ b/src/map/atcommand.c @@ -621,15 +621,16 @@ ACMD_FUNC(who) { int level = 0; StringBuf buf; /** - * 1 = @who : Player name, [Title], [Party name], [Guild name] + * 1 = @who : Count * 2 = @who2 : Player name, [Title], BLvl, JLvl, Job * 3 = @who3 : [CID/AID] Player name [Title], Map, X, Y + * 4 = @who4 : Player name, [Title], [Party name], [Guild name] */ int display_type = 1; int map_id = -1; nullpo_retr(-1, sd); - + if (strstr(command, "map") != NULL) { char map_name[MAP_NAME_LENGTH_EXT] = ""; if (sscanf(message, "%15s %23s", map_name, player_name) < 1 || (map_id = map_mapname2mapid(map_name)) < 0) @@ -637,12 +638,14 @@ ACMD_FUNC(who) { } else { sscanf(message, "%23s", player_name); } - + if (strstr(command, "2") != NULL) display_type = 2; else if (strstr(command, "3") != NULL) display_type = 3; - + else if (strstr(command, "4") != NULL) + display_type = 4; + level = pc_get_group_level(sd); StringBuf_Init(&buf); @@ -670,7 +673,7 @@ ACMD_FUNC(who) { StringBuf_Printf(&buf, msg_txt(sd,348), mapindex_id2name(pl_sd->mapindex), pl_sd->bl.x, pl_sd->bl.y); // "| Location: %s %d %d" break; } - default: { + case 4: { struct party_data *p = party_search(pl_sd->status.party_id); struct guild *g = pl_sd->guild; @@ -683,6 +686,10 @@ ACMD_FUNC(who) { StringBuf_Printf(&buf, msg_txt(sd,346), g->name); // " | Guild: '%s'" break; } + default: { + count++; // Just count + continue; // and don't list player infos + } } clif_displaymessage(fd, StringBuf_Value(&buf)); StringBuf_Clear(&buf); @@ -9996,9 +10003,11 @@ void atcommand_basecommands(void) { ACMD_DEF(who), ACMD_DEF2("who2", who), ACMD_DEF2("who3", who), + ACMD_DEF2("who4", who), ACMD_DEF2("whomap", who), ACMD_DEF2("whomap2", who), ACMD_DEF2("whomap3", who), + ACMD_DEF2("whomap4", who), ACMD_DEF(whogm), ACMD_DEF(save), ACMD_DEF(load),
  4. Hey, Permissions don't work that way anymore, since GM Levels have been changed to groups. I made something that works around for this, but it is definetly not the intended usage of groups! diff --git a/src/map/mob.c b/src/map/mob.c index 04b76e7..c725c96 100644 --- a/src/map/mob.c +++ b/src/map/mob.c @@ -2431,6 +2431,10 @@ int mob_dead(struct mob_data *md, struct block_list *src, int type) if(src && src->type == BL_MOB) mob_unlocktarget((struct mob_data *)src,tick); + if ((mvp_sd && pc_has_permission(mvp_sd, PC_PERM_DENY_MONSTERDROP)) < battle_config.gm_monsterdrop_lv || (sd && pc_has_permission(sd, PC_PERM_DENY_MONSTERDROP) < battle_config.gm_monsterdrop_lv)) { + type |= 1; + } + // filter out entries not eligible for exp distribution memset(tmpsd,0,sizeof(tmpsd)); for(i = 0, count = 0, mvp_damage = 0; i < DAMAGELOG_SIZE && md->dmglog[i].id; i++) { diff --git a/src/map/pc_groups.h b/src/map/pc_groups.h index 45e8b55..220d3af 100644 --- a/src/map/pc_groups.h +++ b/src/map/pc_groups.h @@ -50,6 +50,7 @@ enum e_pc_permission { PC_PERM_BYPASS_STAT_ONCLONE = 0x02000000, PC_PERM_BYPASS_MAX_STAT = 0x04000000, PC_PERM_CASHSHOP_SALE = 0x08000000, + PC_PERM_DENY_MONSTERDROP = 0x10000000, //.. add other here PC_PERM_ALLPERMISSION = 0xFFFFFFFF, }; @@ -86,6 +87,7 @@ static const struct { { "bypass_stat_onclone",PC_PERM_BYPASS_STAT_ONCLONE }, { "bypass_max_stat",PC_PERM_BYPASS_MAX_STAT }, { "cashshop_sale", PC_PERM_CASHSHOP_SALE }, + { "deny_monster_drops", PC_PERM_DENY_MONSTERDROP }, { "all_permission", PC_PERM_ALLPERMISSION }, }; This adds a permission to the group system which if true denies monster drops. So by default nobody has it (except GM Group 99 [Admin], which means Admins won't receive any loot whatsoever. That's what I mean by uninteded usage). The question is: Why do you actually need it? To your second question: That's entirely possible, but you need to split VIP and non-VIP storage backend in some way or another. And what to do about people who loose VIP status? Deny access to those items? How do they know which are which?
  5. While I do endorse optimizing in that sort of thing I think we should discuss this. I'm not that deep into Linux Kernel programming, but let me give my 2 cents on this. (Please correct me if I misunderstand anything) AFAIK the biggest cost in SELECT comes from checking sockets which have had no activity. This is when epoll exceeds, since it directly connects the wait list to the sockets and only checks sockets with activities. This gains performance for most server applications. As rAthena is a gaming server, I'm not sure how big the benefit would be. Even idle clients so send/receive ping pongs every 10 seconds. The question is the ratio: How many clients are idle on a typical server, how many clients are active players? My take on this is the following: I guess epoll will still perform very well since we are talking about ms time intervalls and even busy players won't have more than I'm assuming around 5 packets per second peak. So please go ahead and change to epoll and please share your code, but let's keep this discussion open if we can.
  6. Me and @Andre are also working on the RoBrowser, but we do most stuff provisionally and also with lots of custom edits, so it doesn't help the compatibility with rAthena. Although I'm currently overhauling the whole PacketVersion thing and we added some fixes which we will create Pull Requests for from time to time.
  7. Are you sure the ER model is correct? For example a char does not need a cart_inventory entry, but it says 1..*. It should be 0..* or just *, imho. Apart from that, omega good job
  8. I wish I could further test, but I'm on a business trip until May :/ I will definetly check it out then again, if nobody has fixxed it until then. I know what you mean about that code, as it could add something like episodes of story to the NPCs. Sorry about the bummer for now
  9. Some files seems corrupted and/or you need to convert the LF CR to standardize it for your OS.
  10. Yea, my bad. I just realized this line is wrong: if (((TBL_NPC*)bl)->visibility != 0 && ((TBL_NPC*)bl)->visibility == pc_readglobalreg(sd, "npcvisibility")) It should be: if (((TBL_NPC*)bl)->visibility != 0 && ((TBL_NPC*)bl)->visibility != pc_readglobalreg(sd, "npcvisibility"))
  11. There are a few ways to tackle this: You either do it fully with C, which means you set up a mail service on your game server and then implement a mail service to your C code.Then integrate it into a new script command. There are some wiki articles for reference, or just check script.c. The other (maybe more simple) way would be to just place all mails or mail send-requests into a DB and then set up a php (or similiar) script on your webserver which accesses the DB and sends them out periodically. The thing about conf, just check the *.c files which sound like the conf files, this is mostly where they are read. But there are also some bundles functions for that. THis can be done after functionality works, though.
  12. Though it may be a cool mod, and actually I'm interested in it. I don't think you actually have to do anything client-side. It should only involve clif.c/h mostly. I am of course just speculating. But since you said you can change the colors server-side, it means the colors are read through a db (or perhaps directly on source). These colors aren't the default client-side colors when slotting an un-slottable item, is it? Anyway, you can PM me so we can discuss further, I have several ways to possibly make use of that mod. It's still client side, but the client adds the color automatically when conditions are met. I think this isn't the right topic to discuss this (esp. since somebody offered a payed mod but nobody a soultion), except for some hints.
  13. Started a new server project with huge mods that should be really fun to play. Hope it works out & stay tuned~

  14. I see. That's a cool mod, but what if you want the color to appear for special condition items, not for refinelevel? Well, nvm, none of my business.
  15. Correct me if I'm wrong, but don't you just add cards into slots that are non-existant and the client turns the color? So you just create stub cards that do whatever and add the Card Prefixes for Legendary etc?
  16. Can't give you a diff because I work on a project and don't want to create a new branch, but here is what you do: In ./src/map/mob.c look for the mob_dead function if (map[m].flag.nobaseexp || !md->db->base_exp) base_exp = 0; And change it to the following: if (map[m].flag.nobaseexp || !md->db->base_exp || tmpsd[i]->status.base_level >= 90) base_exp = 0;
  17. src/map/battle.c static struct Damage battle_calc_weapon_attack(struct block_list *src, struct block_list *target, uint16 skill_id, uint16 skill_lv, int wflag) Und static struct Damage battle_calc_element_damage(struct Damage wd, struct block_list *src, struct block_list *target, uint16 skill_id, uint16 skill_lv) Je nachdem ob Waffe oder allgemein.
  18. Hi. I tried to set up a testserver and I once I reach the char select it gives me the following error: My clientinfo: <?xml version="1.0" encoding="euc-kr" ?> <clientinfo> <servicetype>korea</servicetype> <servertype>primary</servertype> <connection> <display>TestRO</display> <balloon>255/120 Pre-Renewal PvP/WoE/PvE </balloon> <desc>Welcome</desc> <address>127.0.0.1</address> <port>6900</port> <version>38</version> <langtype>0</langtype> <registrationweb></registrationweb> <aid> <admin>2000000</admin> </aid> <loading> <image>loading00.jpg</image> <image>loading01.jpg</image> <image>loading02.jpg</image> <image>loading03.jpg</image> <image>loading04.jpg</image> </loading> </connection> </clientinfo> And here is my mmo.h: // server->client protocol version // 0 - pre-? // 1 - ? - 0x196 // 2 - ? - 0x78, 0x79 // 3 - ? - 0x1c8, 0x1c9, 0x1de // 4 - ? - 0x1d7, 0x1d8, 0x1d9, 0x1da // 5 - 2003-12-18aSakexe+ - 0x1ee, 0x1ef, 0x1f0, ?0x1c4, 0x1c5? // 6 - 2004-03-02aSakexe+ - 0x1f4, 0x1f5 // 7 - 2005-04-11aSakexe+ - 0x229, 0x22a, 0x22b, 0x22c // see conf/battle/client.conf for other version #ifndef PACKETVER #define PACKETVER 20130605 //#define PACKETVER 20120410 #endif I also changed the packet_db for version 38 to the packets given by you. Fixxed, Disable Paket encryption needs to be patched in
  19. Look through doc/script_commands.txt or whats it called
  20. Var to String should be tought. Other way around, check for SetD and GetD
  21. Just an idea (sorry for doublepost): Could you add another entry in the inventory after 30.000? Like the item appears like a weapon twice? Or will the client block that? Just playing around with ideas.
  22. Maybe. There is 4 Bytes in the packet for the item amount as far as I see, or does the server append anything of 2 Byte at the end of a packet? Then it would only be two bytes. I checked for ZC_ITEM_FALL_ENTRY, which is 19 Bytes and the amount (as the last entry) starts at offset 15.
  23. Please state what exactly you want. I can't tell by just reading the title
  24. Here you go: http://rathena.org/board/pastebin/p6v4bmirpzc/ Limits the namelength to NAME_LENGTH - 5 (only on creation!)
  25. I think it means, that every update shall be parsed in a defaulted format and if you are unhappy with a certain update noch yet being supported by rA you can try to fork your revision and work it out yourself, then provide it for everybody. Right?
×
×
  • Create New...