*instance_check_party

[Ziu]

@korean servers for example:

rathena\doc\scripts_comands.txt

This Command will also check if every Player inside the Party of the invoking Character is online. So if 2 Players are inside a Party

but one of them is offline, the other Player won't be able to join the Memorial Dungeon.

why?????!!!!

thanks..

[Napster]

quick fix i think

for( i = 0; i < MAX_PARTY && p->party.member[i].online; i++ )
 if( (pl_sd = p->data[i].sd) )
  if(map_id2bl(pl_sd->bl.id)){
   if(pl_sd->status.base_level < min){
 script_pushint(st, 0);
 return 0;
   }else if(pl_sd->status.base_level > max){
 script_pushint(st, 0);
 return 0;
   }
 c++;
  }

Edited May 22, 2012 by Napster

[malufett]

This code checks if the character is online..

if(map_id2bl(pl_sd->bl.id))

@Ziu

it is because the minimum number of party member is already satisfied...

so if it is done this way

instance_check_party(getcharid(1),2,2,149)

it means minimum of 2 members, minimum base level of 2 and maximum of 149...

so the counting is based on online players....

and Masao means of 'So if 2 Players are inside a Party

but one of them is offline, the other Player won't be able to join the Memorial Dungeon.'

is shown in this example

if(instance_check_party(getcharid(1),2,2,149)){
   mes "Ok, your party is complete and meets the Memorial Dungeons requirement.",
   mes	 "Members have a Baselevel between 1 and 150 and there are at least 2 Players inside the Party.";
   close;
}else{
   mes "Sorry, but it seems like your Party does not meet the Memorial Dungeon requirements.";
   close;
} 

so it means at least and the offline character can't join the instance and the other two only will be part of it..

but I think this is applied in some instances but in GH memorial maybe this can be done alone with a party created...

I hope this explain it all...^^

[mrjnumber1]

having to use the char's party id as the first argument is extremely tacky.. it should automatically know based on the rid, then you can add an optional party id arg.

[Ziu]

malufett to create GH memorial need party 2 o more... but it isn't necessary that are connected...once created even if I add other people can access.... other example is a the labyrinth forest fog ( bifrost).

[Lemongrass]

malufett to create GH memorial need party 2 o more... but it isn't necessary that are connected...once created even if I add other people can access.... other example is a the labyrinth forest fog ( bifrost).

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/

[Ziu]

@lemongrass.

When create memorial the .sc check only partyleader (if you are not partyleader you can't create)

partyleader== need be in party (2 or more... )

Other members of the party only check (var. ex-> base level, pre-quest, items, etc etc) except cash instance only party leader need the cash item.

if you meet the requirements and you join a group that created the memorial. You can access without problems.

for example in the memorial nyd. It is necessary complete pre-quest.

In the instance of orc village check your level base ... (although the memorial was created by a pj level < 80) you can't access, if you level base > 80

tomorrow I will make a small test to check on Sakray

Edited May 22, 2012 by Ziu

[MarkZD]

...

But well, if you don't like the way it works now...

...

I don't think it is just "if you don't like it, change it your way".

Since we're following kRO official, no more has to be said, it's official, right?

Maybe it's a bug as it was said or maybe it's not, I think it needs more info as it makes things easier to players if it's not a bug it must be in rA.

[Lemongrass]

Well i'll try to explain this a little...

As you all already said, on official Servers the instances / memorial dungeons do not check for each and every pleayer inside the party if they're online or meet the required minimum level to join the Party.

This is either way intended by Gravity or a bug they couldn't fix themselves yet. As for me, i believe gravity probably is just unable to fix that issue, cause it makes no sense to me why someone should be able to enter an instance / memorial dungeon were 2 players are needed in a party but one can be offline, or one of them does not have to meet the required minimum level to join.

And as for me as an Script / DB Develeoper who always gets a shit load amount of bug reports about that the instances are not checking for player or base level and such, i decided to ask malufett if he could add an new script command for me to check those needed requirements to join a memorioal dungeon, even tho it's not like that on official servers.

But well, if you don't like the way it works now, you can always use the instance scripts from eAthena which behave the old way, or you just make an SVN revision revert before i applied the change, then you copy paste those old instance files, update your svn again to the latest rev. and paste the old files in there.

Please don't get me wrong, I only wanted it that way, that it checks if the online players meet the requirements and if there are enough of them online. I do get your point that the player count and don't checking offline characters is nonesense, but those shouldn't be able to enter the instance once they come online afterwards anyway. That also fits for those that are online and don't meet the requirements...

I'll try to explain it with a short example:

Party with 4 players:

1st player lvl 99 online

2nd player lvl 70 online

3rd player lvl 99 online

4th player lvl 10 offline

Instance requirements:

2 players at lvl 80

The current check will act as follows:

The check loops the players according to the given order above.

It checks player 1 who meets all the requirements and increases the count.

It checks player 2 who doesnt meet the requirements and cancels the loop.

Output:

The two players(1,3) of the party that wanted to do the instance aren't allowed to enter.

I think it should be that way, that the loop isn't canceled by a player that doesn't meet the requirement. Instead the script of the instance warper should check, whether a player that is part of the party instance meets the requirements and if he does it warps him into the instance and if not he has to stay outside.

Using the example above the loop should act as follows:

It checks player 1 who meets all the requirements and increases the count.

It checks player 2 who doesnt meet the requirements and continues to the next player.

It checks player 3 who meets all the requirements and increases the count.

It checks player 4 sees that he is offline and continues.

No next player, loop cancelled.

Output:

Playercount of those that meet the requirements and are online: 2

Instance will be created and the players that meet the requirements can enter.

...

But well, if you don't like the way it works now...

...

I don't think it is just "if you don't like it, change it your way".

Since we're following kRO official, no more has to be said, it's official, right?

Maybe it's a bug as it was said or maybe it's not, I think it needs more info as it makes things easier to players if it's not a bug it must be in rA.

I would definitly say that this is true, but I would give the users the possibility to change the behavior as they like, for example in form of a setting in the "conf" folder.

I've prepared a small diff, that adds a conf file for instances that consists of a on/off setting for official behavior and the cooldown times if they are set within a script and if they are to be set in the quest database the quest id is stated. Whether you would like to add it or not is up to you.

Since I can't post any attachment in here, feel free to drop me a PM if you would like to have the .patch file.

Index: conf/battle/instance.conf
===================================================================
--- conf/battle/instance.conf    (revision 0)
+++ conf/battle/instance.conf    (working copy)
@@ -0,0 +1,35 @@
+//--------------------------------------------------------------
+// rAthena Battle Configuration File
+// Originally Translated by Peter Kieser <[email protected]>
+// Made in to plainer English by Ancyker
+//--------------------------------------------------------------
+// Note 1: Value is a config switch (on/off, yes/no or 1/0)
+// Note 2: Value is in percents (100 means 100%)
+// Note 3: Value is a bit field. If no description is given,
+//		 assume unit types (1: Pc, 2: Mob, 4: Pet, 8: Homun)
+//--------------------------------------------------------------
+
+// Should the instance system act like the official version on KRO? (Note 1)
+// KRO:
+//     Players that don't meet the requirements,
+//     prohibit a party from creating an instance.
+// rA:
+//     Online the players that meet the requirements are counted,
+//    for the required party member count.
+instance_official: yes
+
+//--------------------------------------------------------------
+// Cooldown times in seconds
+//--------------------------------------------------------------
+
+// Endless tower (default: 1 week)
+instance_etower: 604800
+
+// Nidhoggur's Nest
+// Edit /db/quest_db.txt 3135 and 3136
+
+// Orc's Memory
+// Edit /db/quest_db.txt 12059
+
+// Sealed Shrine
+// Edit /db/quest_db.txt 3040
\ No newline at end of file
Index: npc/instances/EndlessTower.txt
===================================================================
--- npc/instances/EndlessTower.txt    (revision 16162)
+++ npc/instances/EndlessTower.txt    (working copy)
@@ -214,7 +214,7 @@
    set .@etower_timer,checkquest(60200,PLAYTIME); // 1 week
    set .@etower_timer2,checkquest(60201,PLAYTIME); // 4 hours

-    set .@dun_lim_time,etower_timer+604800; // 1 week
+    set .@dun_lim_time,etower_timer+getBattleFlag("instance_etower"); // 1 week
    set .@dun_lim_time2,etower_timer+14400; // 4 hours
    set .@dun_cur_time,gettimetick(2);
    set .@dun_ent_t,(.@dun_lim_time - .@dun_cur_time);
Index: src/map/battle.c
===================================================================
--- src/map/battle.c    (revision 16162)
+++ src/map/battle.c    (working copy)
@@ -5307,6 +5307,9 @@
    { "cashshop_show_points",			   &battle_config.cashshop_show_points,		    0,	  0,	  1,			  },
    { "mail_show_status",				   &battle_config.mail_show_status,			    0,	  0,	  2,			  },
    { "client_limit_unit_lv",			   &battle_config.client_limit_unit_lv,		    0,	  0,	  BL_ALL,		 },
+// Instance System
+    { "instance_official",                    &battle_config.instance_official,                1,        0,        1,                },
+    { "instance_etower",                    &battle_config.instance_etower,                604800,        0,        INT_MAX,        },
// BattleGround Settings
    { "bg_update_interval",				 &battle_config.bg_update_interval,			  1000,   100,    INT_MAX,	    },
    { "bg_short_attack_damage_rate",	    &battle_config.bg_short_damage_rate,		    80,	 0,	  INT_MAX,	    },
Index: src/map/battle.h
===================================================================
--- src/map/battle.h    (revision 16162)
+++ src/map/battle.h    (working copy)
@@ -456,6 +456,10 @@
    int mail_show_status;
    int client_limit_unit_lv;

+    // Instance System
+    int instance_official;
+    int instance_etower;
+
    // [battleGround Settings]
    int bg_update_interval;
    int bg_short_damage_rate;
Index: src/map/script.c
===================================================================
--- src/map/script.c    (revision 16162)
+++ src/map/script.c    (working copy)
@@ -15859,23 +15859,26 @@
        return 0;
    }

-    for( i = 0; i < MAX_PARTY; i++ )
-        if( (pl_sd = p->data[i].sd) )
-            if(map_id2bl(pl_sd->bl.id)){
-                if(pl_sd->status.base_level < min){
+    for( i = 0; i < MAX_PARTY; i++ ){
+        if( (pl_sd = p->data[i].sd ) && map_id2bl( pl_sd->bl.id ) ){
+            if( pl_sd->status.base_level < min || pl_sd->status.base_level > max ){
+                if( battle_config.instance_official ){
+                    continue;
+                }else{
                    script_pushint(st, 0);
-                    return 0;
-                }else if(pl_sd->status.base_level > max){
-                    script_pushint(st, 0);
                    return 0;
                }
-                    c++;
+            }else{
+                c++;
            }
+        }
+    }

    if(c < amount){
        script_pushint(st, 0); // Not enough Members in the Party to join Instance.
-    }else    
+    }else{
        script_pushint(st, 1);
+    }

    return 0;
}

[Ziu]

Create memorial/Instance (Party 2 pj's)

now join new pj's (does not meet the requirements)

the memorial/instance continuously created and can be accessed. The dancer can't access (low level)...

Edited May 28, 2012 by Ziu

[Lemongrass]

I understand your point Lemongrass, but why make it that complicated? if it says the party does not meet the req. just kick the player out of the party in order to enter it, it's as simple as that instead of just keeping the loop / count going and in the end let the users stay outside anyway who aren't allowed to enter xD

That's easier said than done, since the players maybe don't know what are the requirements... And also in 90% of the cases they also don't know that they have to kick the players that don't fit in.

I'll talk to the devs. about your config switch, since i'm not allowed to make such decisions by myself

Thank you, as I said, if you need a .patch file just drop me a PM.

[Lighta]

Actually I would prefere a script argument to switch between the 2 mode presented instead a battleflag :

instance_check_party <party_id>{,<menbers needed>,<min lvl>,<max lvl>.<behaviour flag>}

This will allow to use it in both way for different script, like for instance x we need to kick player that doesn't have the good requirement while in instaqnce y ok doesn't matter...

Also few notes :

dunno why it's name instance_* as this is more generally for all party matters.

dunno why you checking if party_id exist, you said it was required in comment and either way you didn't had a fallback like player attach to script if not..

finally as Lemongrass pointed out many time they don't know that they need to kick that people or nor who doesn't fit the requirement so perhaps adding some clif_message may be interesting.