Hookshiot Through Solid Combos

Oh, I already made a thread about this one on this forum. I posted this bug on both forums 😃

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

It's called the downward hookshot bug, and some old quest rely upon it,
Not a bug... Good bye now.

Tamamo wrote: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.

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.

Saffith wrote: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.

Was this patched at any point?