10.5c and the Party Graceperiod exploit and why it must be removed.
" You can't deal damage while immortal. Any action taken currently ends the grace period. Those who deal damage don't need to be immortal, only the ones tanking. Last edited by Alhoon#2008 on Apr 22, 2013, 8:55:03 AM
|
|
" Ah.. I see. That also explains my total confusion because I knew any actions would remove the immortality effect. would it be possible to code the game such that, while immortal, you are effectively "invisible" to the mobs - removing the ability to tank? "the premier Action RPG for hardcore gamers."
-GGG Happy hunting/fishing |
|
" This is my point. Sorry if it lead to confusion but English isn't my native language. Sadly the twitch video "Turbo Brutus easily" isn't available anymore but I am sure you find others streamers exploiting this bug for example in BLAMT party races. Best attempt would be Kripparian who likes to copy other players and claims credit for himself(such as the WED Cleave build first used by snoddgrass1283 in CB who reached WF cruel in CB) " I posted a pseudocode on page 3 that fixes it if you add it into the find target AI. for(int j=0;j<Arraysize(Players);j++) if(player[j].getstate == GracePeriod) continue; This pseudocode loops through possible targets. Actually players is wrong it should be "HostileUnit" because Summons are also affected. GracePeriod is a state given to the player so it can be detected and if it's detected it goes to the next unit. It's a dirty trick but decoy totem is used in the same way if you see that it only triggers if you are out of range. This is how an advanted AI function of mobs could look like I even changed it into lists GGG devs like to use so much in POE ;D UNIT FindNearestUnit(point Location, int DamageType, BOOL CollisionCheck) { UNIT Target = NULL; int Distance = 500; //rather max range of an attack but this is pseudocode anyway WORD SkillID = GetRolledSkill(); /*a randomfunction decides which attack will be used only local here*/ Attack Spelleffect = GetSkillInfo(SkillID); // checks the effects of the skill std::list<Unit*> UnitList; for(std::list<CUnit*>::iterator entry = UnitList.begin(); entry != UnitList.end(); entry++) { if(GetDistance(Location.X, Location.Y, (*entry)->GetPosX(), (*entry)->GetPosY()) > NearestUnit) continue; //Distancecheck if there is already a possible target if((*entry)->GetResistance(DamageType) > 99) continue; /*Resistance Check if you add that for Vaal will aim his lasers at weaker targets you can also change it in a way so he uses the mace attack more often. 99 could be replaced by 50 for example. This is an example so archers won't use PA on CI users* if(CollisionCheck && Collision(Spelleffect, (*entry)->GetPosX(), (*entry)->GetPosY())) continue; /*checks for collisions which is missing for example voidbearers cast Incinerate on stairs not hitting the target. Some skills like FP don't have a collision and they fly over walls for example*/ if(*entry)->UnitId == Decoytotem) { Target = (*entry)->GetId(); delete (*entry); return Target; } //attacks decoy totem if there is no collision and in range. if((*entry)->GetState() == GracePeriod) continue; //ignores players with Graceperiod Unit = (*entry)->GetId(); NearestUnit = GetDistance(Unit.X, Unit.Y, (*entry)->GetPosX(), (*entry)->GetPosY()); delete (*entry); //creates a temporary target; } return Unit; //returns the current target which will be attacked on an attackfunction } It's not hard to implement with dirty methods but I remembered that the decoy totem already uses such a dirty method frombehavior. A proper method use a different way to get the target anyway but PoE pretty much uses code similar to this one. But it looks like such a small fix is low priority :( |
|
" It's not impossible to unload your character from the universe entirely, before going into the loading cycle. And then spawn your character at the destination only after the client is fully synced. I can't think of any problems this behavior would introduce, but they may exist. @hilbert: really now. *smh* -- I don't have alpha access, that was a LONG time ago. Last edited by Zakaluka#1191 on Apr 23, 2013, 3:45:34 PM
|
|
I suspect if they had the ability to put your character in limbo they would have done it long ago. As someone who has had a loading screen death with a fairly high level character the increased timer was a welcome change to me, despite the abuse possibilities.
|
|