PDA

View Full Version : Hookshiot Through Solid Combos



ZoriaRPG
07-11-2017, 05:47 PM
Reported by Avataro, Unconfirmed


It's possible to use the hookshot through a 1 tile tall solid wall upwards if you stand exactly 4 pixels (i believe) away from the wall.

Don't even know if this has always been the case.

Avataro
07-11-2017, 08:15 PM
Oh, I already made a thread about this one on this forum. I posted this bug on both forums :D

http://www.armageddongames.net/showthread.php?97916-2-50-2-Hookshotting-upwards-through-a-wall

Tamamo
07-12-2017, 06:49 AM
It's called the downward hookshot bug, and some old quest rely upon it,
Not a bug... Good bye now.

ZoriaRPG
07-12-2017, 07:34 AM
It's called the downward hookshot bug, and some old quest rely upon it,
Not a bug... Good bye now.

That is set by a QR, under Compatiblity, and this appears to be different. (?)

Some quests may rely on it, and it can still be a bug. Stuff like this, if it exists, can and should be fixed, and a rule enabled for it.

Is this the same thing, so that I can mark it dead?

I'm trying to determine which, if any, of these have been fixed, as they are not in the logs.

Saffith
07-12-2017, 11:25 AM
I can confirm it. It's not the same as the other one. This is only with the small hitbox; Link has to be overlapping the combo by a few pixels.

link.cpp:

if(dir==up)
{
if((combobuf[MAPCOMBO2(i,x,y-7)].type==cHSGRAB)||
(_walkflag(x+2,y+4,1) && !ishookshottable(int(x),int(y+4))))
{
use_hookshot=false;
}
}


if(dir==up)
{
hookshot_used=true;
Lwpns.add(new weapon((fix)wx,(fix)wy,(fix)wz,wHSHandle,hookitem,
hookpower*DAMAGE_MULTIPLIER,dir,itemid,getUID()));
Lwpns.add(new weapon((fix)wx,(fix)wy-4,(fix)wz,wHookshot,hookitem,
hookpower*DAMAGE_MULTIPLIER,dir,itemid,getUID()));
hs_startx=wx;
hs_starty=wy-4;
}

weapons.cpp:

if(dir==up)
{
if((combobuf[MAPCOMBO(x+2,y+7)].type==cHSGRAB))
{
hooked=true;
}

if(get_bit(quest_rules, qr_HOOKSHOTLAYERFIX))
hooked = hooked || (combobuf[MAPCOMBO2(0,x+2,y+7)].type==cHSGRAB) || (combobuf[MAPCOMBO2(1,x+2,y+7)].type==cHSGRAB);

if(!hooked && _walkflag(x+2,y+7,1) && !ishookshottable((int)x+2,(int)y+7))
{
dead=1;
}
}

Link checks solidity at y+4 and puts the hookshot head at y-20 (wy is y-16), then the hookshot checks for solidity at y+7. This leaves a gap of 16 pixels - just enough to miss the combo completely.

I don't think this one warrants a quest rule. It's a lot harder to notice and take advantage of, so it's less likely anyone's depending on it. Maybe just wait and see if anyone complains.

ZoriaRPG
07-13-2017, 06:14 AM
I can confirm it. It's not the same as the other one. This is only with the small hitbox; Link has to be overlapping the combo by a few pixels.

link.cpp:

if(dir==up)
{
if((combobuf[MAPCOMBO2(i,x,y-7)].type==cHSGRAB)||
(_walkflag(x+2,y+4,1) && !ishookshottable(int(x),int(y+4))))
{
use_hookshot=false;
}
}


if(dir==up)
{
hookshot_used=true;
Lwpns.add(new weapon((fix)wx,(fix)wy,(fix)wz,wHSHandle,hookitem,
hookpower*DAMAGE_MULTIPLIER,dir,itemid,getUID()));
Lwpns.add(new weapon((fix)wx,(fix)wy-4,(fix)wz,wHookshot,hookitem,
hookpower*DAMAGE_MULTIPLIER,dir,itemid,getUID()));
hs_startx=wx;
hs_starty=wy-4;
}

weapons.cpp:

if(dir==up)
{
if((combobuf[MAPCOMBO(x+2,y+7)].type==cHSGRAB))
{
hooked=true;
}

if(get_bit(quest_rules, qr_HOOKSHOTLAYERFIX))
hooked = hooked || (combobuf[MAPCOMBO2(0,x+2,y+7)].type==cHSGRAB) || (combobuf[MAPCOMBO2(1,x+2,y+7)].type==cHSGRAB);

if(!hooked && _walkflag(x+2,y+7,1) && !ishookshottable((int)x+2,(int)y+7))
{
dead=1;
}
}

Link checks solidity at y+4 and puts the hookshot head at y-20 (wy is y-16), then the hookshot checks for solidity at y+7. This leaves a gap of 16 pixels - just enough to miss the combo completely.

I don't think this one warrants a quest rule. It's a lot harder to notice and take advantage of, so it's less likely anyone's depending on it. Maybe just wait and see if anyone complains.

Thank you for the confirmation. I thought it was a separate issue, but I was not sure if you fixed it and didn't log it. There are a few other tickets that I forwarded from Pure that I missed earlier. if you fixed any of those, lease let me know, as otherwise I may as well try to fix what I can fix before this goes Gamma.

QRs: Better safe by adding one, than needing another update in the future. We will not have the same issue with QR space in 2.60, or even in 2.54/2.55 or whatever happens between ow and then, so adding a rule that is on by default for quests made in 2.53, and off for older quests, should be safer. I will address this, but more critical is the ag.cfg issue that I can not seem to figure out. I could use some help on that, from ...anyone.

ZoriaRPG
09-25-2018, 08:43 AM
Was this patched at any point?