Enemy blocks while fallen bug

dantedevil

Well-known member
I found a new bug with the OpenBOR.v3.0.Build.6315.

In my mod I use the system to hit the enemies falle in the ground.

Here the enemy animations:
Code:
#-----------------------Hit in ground--------------------#


anim pain15
	loop	0
        delay	10
        offset  82 177
	bbox	38 159 98 19
	frame	data/chars/gang3/chainman/pain8.png

anim fall15
	loop	0
      delay	9
        offset  82 177
	bbox	38 159 98 19
        @cmd    stop
	frame	data/chars/gang3/chainman/pain8.png
         @cmd    degravity 0
	frame	data/chars/gang3/chainman/fall4.png


anim follow15

	loop	0
        delay   80
        offset  82 177
	bbox	38 159 98 19
	frame	data/chars/gang3/chainman/fall4.png

Everything worked fine while using the OpenBOR_v3.0_Build_4432.
But now using OpenBOR.v3.0.Build.6315, the enemy is able to block while on the ground.
This looks very bad, because it happens to lie on the floor to block, without going through the rise animation.
 
Ugh, that's a huge skip. I shouldn't need everything, but I do need whatever script file has the functions you used in your block and knife animations.
 
Damon Caskey said:
Ugh, that's a huge skip. I shouldn't need everything, but I do need whatever script file has the functions you used in your block and knife animations.

If you see the txt of the Knife2 that I passed before, you will see that the scripts that really make the conterknife work are these:

ani0020
Code:
#include "data/scripts/library/ani0009.h"



int ani0020(int iAni, int iTAni){
    
	/*
	ani0020
	Damon Vaughn Caskey
	Perform alternate animation if target is within range and in specified animation.

	iAni:	Alternate attack.
	iTAni:	Target animation.
	*/

    void vSelf      = getlocalvar("self");					//Caller.                                                         
    void vOpp       = findtarget(vSelf, iAni);				//Nearest target in range of alternate attack.
	
	if (vOpp)												//Found a target?
	{
		if(getentityproperty(vOpp, "animationID") == iTAni)	//Animation match?
		{
			ani0009(vSelf, iAni, 0);						//Perform alternate attack.
			return 1;										//Return 1.
		}
	}

	return 0;												//Return 0.
}



ani0009
Code:
int ani0009(void vTarget, int iAni, int iType)
{
    //Set animation and return 1 if valid.

	if (!vTarget) vTarget = getlocalvar("self");

    if (getentityproperty(vTarget, "animvalid", iAni))          //Animation valid?
    {
        if (iType == -1)                                        //Type -1?
        {
            changeentityproperty(vTarget, "animation", iAni);   //Set animation with entity property.
        }
        else
        {
            performattack(vTarget, iAni, iType);                //Set animation with perform attack command.
        }
        return 1;                                               //Return 1.        
    }
    return 0;
}
 
After doing several tests with the OpenBOR.v3.0.Build.6315, I have found several new problems, generated by this bug. In order to be better understood, I decided to share a video to make it clearer:


In this video you can clearly see how the enemy appears standing blocking the attack, without going through the anim rise.
But other new bugs come later, if you pay attention, after the enemy blocks an attack while it was down, now it can not touch the player, its attacks do not take effect, not even when it executes in grab, the attacks do not work.
Also the other bug that also appears after the enemy blocks an attack is on the floor, is that the player can not grab the enemy and clarified that this enemy does not have paingrab 1.
Another curious thing is that although the player can hit the enemy (after the blocks while they failed bug), with a simple common punch the enemy is knocked down, as seen in the video at time 0:38, which is rare since that attack does not knock down the enemy and the enemy is not in the air.
Just after knocking down the enemy, everything is normalized, until it blocks again while it is on the ground.
 
Last edited:
I'm reworking the entire block logic already. It's currently in a test phase. Homework and the gym took priority, but it should be done in next few days.
 
I was testing each build in descending order, from the last one backwards and finally I can confirm that the bug started with OpenBOR v3.0 Build 5134.

Until the OpenBOR v3.0 Build 4905 which is the previous one, everything works fine.
It should be noted that in this build I also work the Ilusionista Script for branch in holes.
http://www.chronocrash.com/forum/index.php?topic=3910.msg54840#msg54840

Only the Game Over bug remains in this Build.
 
Back
Top Bottom