Jump to content


  • Posts

  • Joined

  • Last visited


About Jonne

  • Birthday 03/15/1994

Profile Information

  • Gender
  • Location
  • Interests

Recent Profile Visitors

4,093 profile views

Jonne's Achievements


Poring (1/15)




Community Answers

  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. 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.
  14. 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?
  15. 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;
  • Create New...

Important Information

By using this site, you agree to our Terms of Use and Privacy Policy.