Read Access Violation with respawning vehicles

[Linken]

So I'm attempting to fix a bug that's been plaguing Jedi Academy. If a vehicle collides with a wall and that vehicle has an NPC_target to respawn itself, the game crashes with a read access violation. There are several points where it crashes, depending on how you hit the wall, but the error is still the same. Any ideas?

[Lancelot]

@Asgarath83, do you know a solution for Linken's problem?

[Asgarath83]

Apparently seems okay.

but the issue is caused by pmove.

two questions:

1 - name of the functions when it happens?

2 - is default ja code, or a mod code?

Never had this problem on my openjk, my personal code edits, or  vanilla original code or other mod codes (also if on my machine run only eezstreet gunslinger) .

if is a edited code, i should suppose is caused by unpredictable effects.

i means, there is some kind of entropy into a game code.

each time that you edit something, it will can have unpredictables effect or create bugs.

when you do a code edit, checks ever carefully with "find all references" all the code chunks when is called the functions and also the subfunctions that are inside it, so, if happens a bug or crash, you have a start point to fix it.

you can try to do try and error deactivating the chunks of code line that you guess to cause the crash for better identify it.

for example, try the function with the pmove line deactivated

you can use

// before the line for deactivate his code reading.

othersiwe you can put code chunk between

/* */

i never had  a good debugging on my machine, so for fix crash mostly i go with try and error with this sytem until i find the issue.

a good debugging help very much to avoid time consuming to locate the issue.

but if you have crash with unknown causes, using this method can give you an help for find the chunks or code, or the function calls that cause the issue.

 

 

 

 

 

 

[Linken]

On 3/24/2022 at 6:58 AM, Asgarath83 said:

Apparently seems okay.

but the issue is caused by pmove.

two questions:

1 - name of the functions when it happens?

2 - is default ja code, or a mod code?

Never had this problem on my openjk, my personal code edits, or  vanilla original code or other mod codes (also if on my machine run only eezstreet gunslinger) .

if is a edited code, i should suppose is caused by unpredictable effects.

i means, there is some kind of entropy into a game code.

each time that you edit something, it will can have unpredictables effect or create bugs.

 

 

I can understand what you mean, though looking back on prior commits, I'm not seeing any edits to the code that would've screwed with Pmove.

The favorite place for the code to crash is actually this if statement here (sorry I can't post a screenshot):

        if (pm->gent->client &&
            pm->gent->client->NPC_class == CLASS_VEHICLE &&
            trace.plane.normal[2]<pm->gent->m_pVehicle->m_pVehicleInfo->maxSlope
            )
        {
            pm->ps->pm_flags |= PMF_BUMPED;
        } 

 

This is located on Line 202 in code\game\bg_slidemove.cpp.

It's interesting that you mentioned regular OpenJK, because out of curiosity I attempted to replicate the bug there, drove a respawning swoop into a wall and crashed, and the game did crash. I just now attempted normal JKA and it crashed as well.

If you want to try it, I made a few edits to the Coruscant Speedway map for Galactic Legacy to stop an infinite swoop respawning bug, the link is here (will only work on OpenJK unless you can compile entity files): https://drive.google.com/file/d/11n547dbW2fgfHacW7kZQZvNubx5KBf13/view?usp=sharing

I also got pretty consistent crashing on the Battle for Hoth map when crashing a snowspeeder into a wall. Here are the links, again taken from the SWGL files and editted down to work in base JKA.

https://drive.google.com/file/d/1oX3tu7tVcQfeLPkRQHxUclOpvD1--X5R/view?usp=sharing

https://drive.google.com/file/d/1zbnWfYYPp1Cn-1utqxL2wRCmZusGguOK/view?usp=sharing

 

 

 

[Asgarath83]

1 hour ago, Linken said:

I can understand what you mean, though looking back on prior commits, I'm not seeing any edits to the code that would've screwed with Pmove.

The favorite place for the code to crash is actually this if statement here (sorry I can't post a screenshot):

        if (pm->gent->client &&
            pm->gent->client->NPC_class == CLASS_VEHICLE &&
            trace.plane.normal[2]<pm->gent->m_pVehicle->m_pVehicleInfo->maxSlope
            )
        {
            pm->ps->pm_flags |= PMF_BUMPED;
        } 

 

This is located on Line 202 in code\game\bg_slidemove.cpp.

It's interesting that you mentioned regular OpenJK, because out of curiosity I attempted to replicate the bug there, drove a respawning swoop into a wall and crashed, and the game did crash. I just now attempted normal JKA and it crashed as well.

If you want to try it, I made a few edits to the Coruscant Speedway map for Galactic Legacy to stop an infinite swoop respawning bug, the link is here (will only work on OpenJK unless you can compile entity files): https://drive.google.com/file/d/11n547dbW2fgfHacW7kZQZvNubx5KBf13/view?usp=sharing

I also got pretty consistent crashing on the Battle for Hoth map when crashing a snowspeeder into a wall. Here are the links, again taken from the SWGL files and editted down to work in base JKA.

https://drive.google.com/file/d/1oX3tu7tVcQfeLPkRQHxUclOpvD1--X5R/view?usp=sharing

https://drive.google.com/file/d/1zbnWfYYPp1Cn-1utqxL2wRCmZusGguOK/view?usp=sharing

 

 

 

Damn, that's is pretty nasty. it means that you have found a rare glitch and bug of original game engine!

so, infinite swoop spawns are instables when they hit a wall and slide on wall.. that's is very interesting and incredible glitch.

Congratulations for your sharp eye sight.

you should talk about this to openjk developeers team stuff and segnalate the incredibile issue and pull a request on git about some way to fix the bug.

I will try this stuff when i have a lot of time. i need to repay your for bypass 32 bit limit field of weapons, remember?

but i not know if i am so skilled to fix this stupid crash. it will require a lot of time for manage it.

thanks however for pointed me the lines that are responsable of this silly behavour of engine.

HINT:

try to check ALL the code parts whre is called the flag PMF_BUMPED. maybe there is some strange connections with spawners entities. 

the issues should be mostly that, or the "if statement itself" i can't be sure without testing it. it will require times. :3

i'll let you know if i 'll do some progress.

pm->ps->pm_flags |= PMF_BUMPED;

 

Into the way, signal this to openjk stuff. is a really interesting bug that need to be investigated.

 

[Linken]

8 minutes ago, Asgarath83 said:

Damn, that's is pretty nasty. it means that you have found a rare glitch and bug of original game engine!

so, infinite swoop spawns are instables when they hit a wall and slide on wall.. that's is very interesting and incredible glitch.

Congratulations for your sharp eye sight.

you should talk about this to openjk developeers team stuff and segnalate the incredibile issue and pull a request on git about some way to fix the bug.

I will try this stuff when i have a lot of time. i need to repay your for bypass 32 bit limit field of weapons, remember?

but i not know if i am so skilled to fix this stupid crash. it will require a lot of time for manage it.

thanks however for pointed me the lines that are responsable of this silly behavour of engine.

HINT:

try to check ALL the code parts whre is called the flag PMF_BUMPED. maybe there is some strange connections with spawners entities. 

the issues should be mostly that, or the "if statement itself" i can't be sure without testing it. it will require times. :3

i'll let you know if i 'll do some progress.

pm->ps->pm_flags |= PMF_BUMPED;

 

Into the way, signal this to openjk stuff. is a really interesting bug that need to be investigated.

 

Sorry I should've been more specific, the specific point where it crashes is at "pm->gent->client->NPC_class == CLASS_VEHICLE"

[Asgarath83]

39 minutes ago, Linken said:

Sorry I should've been more specific, the specific point where it crashes is at "pm->gent->client->NPC_class == CLASS_VEHICLE"

thanks, is a start point.

but i told you that i never worked much with vehicles code, so i not guarantee that i can fix the bug. also cause is a very strange and foolish bug.

openjk is born with purpouse to clean bugs from original engine. if you find a new bug, really, you should ask to openjk stuff to fix it asap.

i see what how can i do, but i am not doing promises.

 

 

[Asgarath83]

Okay, i examinated the code and i found something very interesting about how this things works into engine:

basically there is a flag, like EF_BOUNCE, EF_BOUNCE_SHRAPNEL, EF_BOUNCE_HALF etc, that when is enabled create some special movements features with game vectors.

the bounce and bounce shrapnel are related to the bouncing physic used by bouncing projectiles, flechette shrapnel main fire and flechette alt fire / thermal detonator.

when on my code i tried to edit stuff with these things i EVER add crashes and exceptions. and they going me mad and crazy for YEARS until i understand . i never really fixed it, i just bypassed the problemes editing the code. i rewrote avoiding the flag on / off feature (basically act like a boolean : on \ off true \ false, so instead of do a silly round of functions with some weird cycle it execute directly the instruction for edit the vectors without use Flags.

flags code of the engine is very sensitive and unstable for my experience.

 

about this case:

bg_public.h

#define PMF_BUMPED            (1<<17)//131072    // Bumped into something

this is the flag. his marked to the 17th bit field (each flag can contain 32 bit values)

//////////////////////////////////////////////////////////////////////////
// pmove->pm_flags
#define    PMF_DUCKED            (1<<0)//1
#define    PMF_JUMP_HELD        (1<<1)//2
#define    PMF_JUMPING            (1<<2)//4        // yes, I really am in a jump -- Mike, you may want to come up with something better here since this is really a temp fix.
#define    PMF_BACKWARDS_JUMP    (1<<3)//8        // go into backwards land
#define    PMF_BACKWARDS_RUN    (1<<4)//16        // coast down to backwards run
#define    PMF_TIME_LAND        (1<<5)//32        // pm_time is time before rejump
#define    PMF_TIME_KNOCKBACK    (1<<6)//64        // pm_time is an air-accelerate only time
#define    PMF_TIME_NOFRICTION    (1<<7)//128        // pm_time is a no-friction time
#define    PMF_TIME_WATERJUMP    (1<<8)//256        // pm_time is waterjump
#define    PMF_RESPAWNED        (1<<9)//512        // clear after attack and jump buttons come up
#define    PMF_USEFORCE_HELD    (1<<10)//1024    // for debouncing the button
#define PMF_JUMP_DUCKED        (1<<11)//2048    // viewheight changes in mid-air
#define PMF_TRIGGER_PUSHED    (1<<12)//4096    // pushed by a trigger_push or other such thing - cannot force jump and will not take impact damage
#define PMF_STUCK_TO_WALL    (1<<13)//8192    // grabbing a wall
#define PMF_SLOW_MO_FALL    (1<<14)//16384    // Fall slower until hit ground
#define    PMF_ATTACK_HELD        (1<<15)//32768    // Holding down the attack button
#define    PMF_ALT_ATTACK_HELD    (1<<16)//65536    // Holding down the alt-attack button
#define PMF_BUMPED            (1<<17)//131072    // Bumped into something
#define PMF_FORCE_FOCUS_HELD    (1<<18)//262144    // Holding down the saberthrow/kick button
#define PMF_FIX_MINS        (1<<19)//524288    // Mins raised for dual forward jump, fix them
#define    PMF_ALL_TIMES    (PMF_TIME_WATERJUMP|PMF_TIME_LAND|PMF_TIME_KNOCKBACK|PMF_TIME_NOFRICTION)

////////////////////////////////////////////////////////////////////////////

 

THEN here is how it works:

BG_Slidermove.cpp

function:

/////////////////////////////////////////////////////////////////////////////////

qboolean    PM_SlideMove( float gravMod ) {
    int            bumpcount, numbumps;
    vec3_t        dir;
    float        d;
    int            numplanes;
    vec3_t        normal, planes[MAX_CLIP_PLANES];
    vec3_t        primal_velocity;
    vec3_t        clipVelocity;
    int            i, j, k;
    trace_t    trace;
    vec3_t        end;
    float        time_left;
    float        into;
    vec3_t        endVelocity;
    vec3_t        endClipVelocity;
    qboolean    damageSelf = qtrue;
    int            slideMoveContents = pm->tracemask;

////////////////////////////////////////////////////////////////////////

This function bumps the vehicles when slide against a wall. obvious.

when this happens, it enabled the flag here:

if (pm->gent->client &&
            pm->gent->client->NPC_class == CLASS_VEHICLE &&
            trace.plane.normal[2]<pm->gent->m_pVehicle->m_pVehicleInfo->maxSlope
            )
        {
            pm->ps->pm_flags |= PMF_BUMPED; // <- FLAG ENABLED.
        }

//////////////////////////////////////////////////////////////////////////////////////

now, into the code, there are 2 other points of interest

1: - when flags is turned off (so is edit is deactivated)

2 - when flags is executed, so what happens when PMF_BUMPED is active.

case 1: flag is deactivated when into Pmove main function (player movevement, the LARGE and BIG function that code ALL player movements! swim, fly, run, etc! )

every time pmove run, flag is turned out.

////////////////////////////////

// Clear the blocked flag
    //pm->ps->pm_flags &= ~PMF_BLOCKED;
    pm->ps->pm_flags &= ~PMF_BUMPED;

/////////////////////////////

 

NOW the chunk of code about when PMF_BUMPED is used:

is used into

bg_pmove

static void PM_airmove (void)

so, the function that control the movement of entities into air. (so flight, hovering i guess?)

 

and this is what happen when is executed:

///////////////////////////////////////////////////////////////////

if (pVeh && pm->ps->pm_flags&PMF_BUMPED)
    {

/*
        // Turn Vehicle In Direction Of Collision
        //----------------------------------------
        vec3_t    nAngles;
         vectoangles(pm->ps->velocity, nAngles);
        nAngles[0] = pVeh->m_pParentEntity->client->ps.viewangles[0];
        nAngles[2] = pVeh->m_pParentEntity->client->ps.viewangles[2];

        // toggle the teleport bit so the client knows to not lerp
        player->client->ps.eFlags ^= EF_TELEPORT_BIT;

        // set angles
        SetClientViewAngle( pVeh->m_pParentEntity, nAngles );
        if (pVeh->m_pPilot)
        {
            SetClientViewAngle( pVeh->m_pPilot, nAngles );
         }

        VectorCopy(nAngles, pVeh->m_vPrevOrientation);
        VectorCopy(nAngles, pVeh->m_vOrientation);
        pVeh->m_vAngularVelocity = 0.0f;
*/

        // Reduce "Bounce Up Wall" Velocity
        //----------------------------------
         if (pm->ps->velocity[2]>0)
        {
            pm->ps->velocity[2] *= 0.1f;
        }
    }
}

 

 

///////////////////////////////////////////////////////////////////////

 

as you can Most part of this chunk is Deactivated by /*  */

one of the thousand of code parts when developers wrote "foxil code" that deactivated and in game is not running, ever is still present.

so is executed ONLY this line:

 // Reduce "Bounce Up Wall" Velocity
        //----------------------------------
         if (pm->ps->velocity[2]>0)
        {
            pm->ps->velocity[2] *= 0.1f;
        }

 

So, basically, what it create the crash, should be the reduction of velocity of entity when bounce a wall into some circustances.

so the solution i suggest should be to

1 - deactivate this:

/*

 // Reduce "Bounce Up Wall" Velocity
        //----------------------------------
         if (pm->ps->velocity[2]>0)
        {
            pm->ps->velocity[2] *= 0.1f;
        }

*/

and see what happens and if crash again.

if this is the reason of crash, it should be possible to fix running

this feature when is played on  qboolean    PM_SlideMove

so something like:

////////////////////////////////////////////////////////////////

if (pm->gent->client &&
            pm->gent->client->NPC_class == CLASS_VEHICLE &&
            trace.plane.normal[2]<pm->gent->m_pVehicle->m_pVehicleInfo->maxSlope
            )
        {
            // pm->ps->pm_flags |= PMF_BUMPED;

                 if (pm->ps->velocity[2]>0)
              {
                  pm->ps->velocity[2] *= 0.1f;
              }

        }

 

//////////////////////////////

So it avoid and bypass to call dangerous flags like PMF_BUMPED and to silly workaround with ping-pong between functions.

I hope this work, but i not know. can you try or i need to do by myself? :)

 

(i fixed EF_BOUNCE BOUNCE_HALF crashes using this method into weapon code recently, working for doing a lib like .SAB file for free customize the guns. i added a tons of variables for customize the ballistic of projectiles. it was very hard but they works without crashes )

 

 

 

 

 

 

 

 

 

[Linken]

5 hours ago, Asgarath83 said:

Okay, i examinated the code and i found something very interesting about how this things works into engine:

basically there is a flag, like EF_BOUNCE, EF_BOUNCE_SHRAPNEL, EF_BOUNCE_HALF etc, that when is enabled create some special movements features with game vectors.

the bounce and bounce shrapnel are related to the bouncing physic used by bouncing projectiles, flechette shrapnel main fire and flechette alt fire / thermal detonator.

when on my code i tried to edit stuff with these things i EVER add crashes and exceptions. and they going me mad and crazy for YEARS until i understand . i never really fixed it, i just bypassed the problemes editing the code. i rewrote avoiding the flag on / off feature (basically act like a boolean : on \ off true \ false, so instead of do a silly round of functions with some weird cycle it execute directly the instruction for edit the vectors without use Flags.

flags code of the engine is very sensitive and unstable for my experience.

 

about this case:

bg_public.h

#define PMF_BUMPED            (1<<17)//131072    // Bumped into something

this is the flag. his marked to the 17th bit field (each flag can contain 32 bit values)

//////////////////////////////////////////////////////////////////////////
// pmove->pm_flags
#define    PMF_DUCKED            (1<<0)//1
#define    PMF_JUMP_HELD        (1<<1)//2
#define    PMF_JUMPING            (1<<2)//4        // yes, I really am in a jump -- Mike, you may want to come up with something better here since this is really a temp fix.
#define    PMF_BACKWARDS_JUMP    (1<<3)//8        // go into backwards land
#define    PMF_BACKWARDS_RUN    (1<<4)//16        // coast down to backwards run
#define    PMF_TIME_LAND        (1<<5)//32        // pm_time is time before rejump
#define    PMF_TIME_KNOCKBACK    (1<<6)//64        // pm_time is an air-accelerate only time
#define    PMF_TIME_NOFRICTION    (1<<7)//128        // pm_time is a no-friction time
#define    PMF_TIME_WATERJUMP    (1<<8)//256        // pm_time is waterjump
#define    PMF_RESPAWNED        (1<<9)//512        // clear after attack and jump buttons come up
#define    PMF_USEFORCE_HELD    (1<<10)//1024    // for debouncing the button
#define PMF_JUMP_DUCKED        (1<<11)//2048    // viewheight changes in mid-air
#define PMF_TRIGGER_PUSHED    (1<<12)//4096    // pushed by a trigger_push or other such thing - cannot force jump and will not take impact damage
#define PMF_STUCK_TO_WALL    (1<<13)//8192    // grabbing a wall
#define PMF_SLOW_MO_FALL    (1<<14)//16384    // Fall slower until hit ground
#define    PMF_ATTACK_HELD        (1<<15)//32768    // Holding down the attack button
#define    PMF_ALT_ATTACK_HELD    (1<<16)//65536    // Holding down the alt-attack button
#define PMF_BUMPED            (1<<17)//131072    // Bumped into something
#define PMF_FORCE_FOCUS_HELD    (1<<18)//262144    // Holding down the saberthrow/kick button
#define PMF_FIX_MINS        (1<<19)//524288    // Mins raised for dual forward jump, fix them
#define    PMF_ALL_TIMES    (PMF_TIME_WATERJUMP|PMF_TIME_LAND|PMF_TIME_KNOCKBACK|PMF_TIME_NOFRICTION)

////////////////////////////////////////////////////////////////////////////

 

THEN here is how it works:

BG_Slidermove.cpp

function:

/////////////////////////////////////////////////////////////////////////////////

qboolean    PM_SlideMove( float gravMod ) {
    int            bumpcount, numbumps;
    vec3_t        dir;
    float        d;
    int            numplanes;
    vec3_t        normal, planes[MAX_CLIP_PLANES];
    vec3_t        primal_velocity;
    vec3_t        clipVelocity;
    int            i, j, k;
    trace_t    trace;
    vec3_t        end;
    float        time_left;
    float        into;
    vec3_t        endVelocity;
    vec3_t        endClipVelocity;
    qboolean    damageSelf = qtrue;
    int            slideMoveContents = pm->tracemask;

////////////////////////////////////////////////////////////////////////

This function bumps the vehicles when slide against a wall. obvious.

when this happens, it enabled the flag here:

if (pm->gent->client &&
            pm->gent->client->NPC_class == CLASS_VEHICLE &&
            trace.plane.normal[2]<pm->gent->m_pVehicle->m_pVehicleInfo->maxSlope
            )
        {
            pm->ps->pm_flags |= PMF_BUMPED; // <- FLAG ENABLED.
        }

//////////////////////////////////////////////////////////////////////////////////////

now, into the code, there are 2 other points of interest

1: - when flags is turned off (so is edit is deactivated)

2 - when flags is executed, so what happens when PMF_BUMPED is active.

case 1: flag is deactivated when into Pmove main function (player movevement, the LARGE and BIG function that code ALL player movements! swim, fly, run, etc! )

every time pmove run, flag is turned out.

////////////////////////////////

// Clear the blocked flag
    //pm->ps->pm_flags &= ~PMF_BLOCKED;
    pm->ps->pm_flags &= ~PMF_BUMPED;

/////////////////////////////

 

NOW the chunk of code about when PMF_BUMPED is used:

is used into

bg_pmove

static void PM_airmove (void)

so, the function that control the movement of entities into air. (so flight, hovering i guess?)

 

and this is what happen when is executed:

///////////////////////////////////////////////////////////////////

if (pVeh && pm->ps->pm_flags&PMF_BUMPED)
    {

/*
        // Turn Vehicle In Direction Of Collision
        //----------------------------------------
        vec3_t    nAngles;
         vectoangles(pm->ps->velocity, nAngles);
        nAngles[0] = pVeh->m_pParentEntity->client->ps.viewangles[0];
        nAngles[2] = pVeh->m_pParentEntity->client->ps.viewangles[2];

        // toggle the teleport bit so the client knows to not lerp
        player->client->ps.eFlags ^= EF_TELEPORT_BIT;

        // set angles
        SetClientViewAngle( pVeh->m_pParentEntity, nAngles );
        if (pVeh->m_pPilot)
        {
            SetClientViewAngle( pVeh->m_pPilot, nAngles );
         }

        VectorCopy(nAngles, pVeh->m_vPrevOrientation);
        VectorCopy(nAngles, pVeh->m_vOrientation);
        pVeh->m_vAngularVelocity = 0.0f;
*/

        // Reduce "Bounce Up Wall" Velocity
        //----------------------------------
         if (pm->ps->velocity[2]>0)
        {
            pm->ps->velocity[2] *= 0.1f;
        }
    }
}

 

 

///////////////////////////////////////////////////////////////////////

 

as you can Most part of this chunk is Deactivated by /*  */

one of the thousand of code parts when developers wrote "foxil code" that deactivated and in game is not running, ever is still present.

so is executed ONLY this line:

 // Reduce "Bounce Up Wall" Velocity
        //----------------------------------
         if (pm->ps->velocity[2]>0)
        {
            pm->ps->velocity[2] *= 0.1f;
        }

 

So, basically, what it create the crash, should be the reduction of velocity of entity when bounce a wall into some circustances.

so the solution i suggest should be to

1 - deactivate this:

/*

 // Reduce "Bounce Up Wall" Velocity
        //----------------------------------
         if (pm->ps->velocity[2]>0)
        {
            pm->ps->velocity[2] *= 0.1f;
        }

*/

and see what happens and if crash again.

if this is the reason of crash, it should be possible to fix running

this feature when is played on  qboolean    PM_SlideMove

so something like:

////////////////////////////////////////////////////////////////

if (pm->gent->client &&
            pm->gent->client->NPC_class == CLASS_VEHICLE &&
            trace.plane.normal[2]<pm->gent->m_pVehicle->m_pVehicleInfo->maxSlope
            )
        {
            // pm->ps->pm_flags |= PMF_BUMPED;

                 if (pm->ps->velocity[2]>0)
              {
                  pm->ps->velocity[2] *= 0.1f;
              }

        }

 

//////////////////////////////

So it avoid and bypass to call dangerous flags like PMF_BUMPED and to silly workaround with ping-pong between functions.

I hope this work, but i not know. can you try or i need to do by myself?

 

(i fixed EF_BOUNCE BOUNCE_HALF crashes using this method into weapon code recently, working for doing a lib like .SAB file for free customize the guns. i added a tons of variables for customize the ballistic of projectiles. it was very hard but they works without crashes )

 

 

 

 

 

 

 

 

 

I'll be able to try this on Monday since I'm busy all weekend. I'll let you know how it goes

[Asgarath83]

5 hours ago, Linken said:

I'll be able to try this on Monday since I'm busy all weekend. I'll let you know how it goes

Okay, i will wait.

 

[Linken]

@Asgarath83 So I attempted your fix and unfortunately it did not work. The error is from the game attempting to access the destroyed vehicle which has already been destroyed and freed from memory. In the if statement:

if (pm->gent->client &&
            pm->gent->client->NPC_class == CLASS_VEHICLE &&
            trace.plane.normal[2]<pm->gent->m_pVehicle->m_pVehicleInfo->maxSlope
            )
        {
            pm->ps->pm_flags |= PMF_BUMPED; // <- FLAG ENABLED.
        }

The exception is thrown when attempting to read "pm->gent->client->NPC_class == CLASS_VEHICLE" since the vehicle has already been removed from memory. A Read Access Violation.

[Asgarath83]

1 hour ago, Linken said:

@Asgarath83 So I attempted your fix and unfortunately it did not work. The error is from the game attempting to access the destroyed vehicle which has already been destroyed and freed from memory. In the if statement:

if (pm->gent->client &&
            pm->gent->client->NPC_class == CLASS_VEHICLE &&
            trace.plane.normal[2]<pm->gent->m_pVehicle->m_pVehicleInfo->maxSlope
            )
        {
            pm->ps->pm_flags |= PMF_BUMPED; // <- FLAG ENABLED.
        }

The exception is thrown when attempting to read "pm->gent->client->NPC_class == CLASS_VEHICLE" since the vehicle has already been removed from memory. A Read Access Violation.

So, is not the flag that create the damage, but the fact that there is some worst that happened with target counter set to -1.

so basically it ask to engine "spawn again the vehicle" but the vehicle is removed from memory, so engine try to spawn but not find ...  nothing!

i need to check when i can do how work the target_counter code related to vehicle spawning at this point. it's clear that if is not related to the flag BUMPED, the problem is into the code of target_counter, target_scriptrunner, Usescript, whatever is used by engine for spawn the vehicle!

So need to be checked the icarus code, i guess and the gtk radiant code.

icarus is set into Q3_Interface.cpp and Q3_interface.h.

Is there is a script that is runned by the spawner of snowspeeders?

HOW they are spawned and respawned into these maps? how this works into the map structure? you need to analyze that and do a reverse engeneering job for find the issue.

consider however that VH_FIGHTER code are VERY messy and incomplete (the reason cause i tried to create a new code working with AI npc and player vector movement, instead of use Vehicle code) probably the problem is about the VH_FIGHTER, try first off to edit the snowspeeder entity into a VH_SWOOP into VEH files of map and see if this cause again the crash.

VH_FIGHTER code is buggy, incomplete and very messy. so i not surprise it crash for every stupid run access violation of memory bias etc.

 

 

 

 

 

[Linken]

19 hours ago, Asgarath83 said:

So, is not the flag that create the damage, but the fact that there is some worst that happened with target counter set to -1.

so basically it ask to engine "spawn again the vehicle" but the vehicle is removed from memory, so engine try to spawn but not find ...  nothing!

i need to check when i can do how work the target_counter code related to vehicle spawning at this point. it's clear that if is not related to the flag BUMPED, the problem is into the code of target_counter, target_scriptrunner, Usescript, whatever is used by engine for spawn the vehicle!

So need to be checked the icarus code, i guess and the gtk radiant code.

icarus is set into Q3_Interface.cpp and Q3_interface.h.

Is there is a script that is runned by the spawner of snowspeeders?

HOW they are spawned and respawned into these maps? how this works into the map structure? you need to analyze that and do a reverse engeneering job for find the issue.

consider however that VH_FIGHTER code are VERY messy and incomplete (the reason cause i tried to create a new code working with AI npc and player vector movement, instead of use Vehicle code) probably the problem is about the VH_FIGHTER, try first off to edit the snowspeeder entity into a VH_SWOOP into VEH files of map and see if this cause again the crash.

VH_FIGHTER code is buggy, incomplete and very messy. so i not surprise it crash for every stupid run access violation of memory bias etc.

 

 

 

 

 

Basically the map entity is given an NPC_target and targetname value which are set to the exact same value. When the NPC (or in this case Vehicle) is killed, the NPC_target is fired and looks for the entity with the same targetname (in this case itself). Since the NPC_target and targetname are the same, the vehicle will respawn itself after being destroyed. Since vehicles tend to delay a little bit before being destroyed and freed from memory, there is no issue when a vehicle or NPC is killed by a weapon rather than the environment.

[Asgarath83]

12 minutes ago, Linken said:

Basically the map entity is given an NPC_target and targetname value which are set to the exact same value. When the NPC (or in this case Vehicle) is killed, the NPC_target is fired and looks for the entity with the same targetname (in this case itself). Since the NPC_target and targetname are the same, the vehicle will respawn itself after being destroyed. Since vehicles tend to delay a little bit before being destroyed and freed from memory, there is no issue when a vehicle or NPC is killed by a weapon rather than the environment.

so is a problem of missing delay...

i wondering if that could be fixed with entity modding adding a lot of delay to the target_counter or whatever entity is used for respawn infinite vehicles. 

 

 

I guess i need to decompile the Map and to check directly how entities works. i need specific informations.

[Linken]

1 hour ago, Asgarath83 said:

so is a problem of missing delay...

i wondering if that could be fixed with entity modding adding a lot of delay to the target_counter or whatever entity is used for respawn infinite vehicles. 

 

 

I guess i need to decompile the Map and to check directly how entities works. i need specific informations.

There is no target_counter entity, the entity is:

{
"npc_target" "swoop1"
"targetname" "swoop1"
"count" "-1"
"delay" "5"
"alliedTeam" "2"
"classname" "NPC_Vehicle"
"origin" "432 -1039 -206"
"NPC_type" "snow-speeder-tfp"
"angle" "45"
"teamowner" "2"
}

The NPC_target is targetting its own spawner so whenever the vehicle is destroyed it respawns. There is a "delay" key in the entity, but as far as I can tell, this means nothing, at least in Single Player.

[Asgarath83]

2 hours ago, Linken said:

There is no target_counter entity, the entity is:

{
"npc_target" "swoop1"
"targetname" "swoop1"
"count" "-1"
"delay" "5"
"alliedTeam" "2"
"classname" "NPC_Vehicle"
"origin" "432 -1039 -206"
"NPC_type" "snow-speeder-tfp"
"angle" "45"
"teamowner" "2"
}

The NPC_target is targetting its own spawner so whenever the vehicle is destroyed it respawns. There is a "delay" key in the entity, but as far as I can tell, this means nothing, at least in Single Player.

What the hell!!! a... a NPC entity spawner that bounce into itself! O.o

sure a very fast and direct way but it can be the motivation for crash, the easy way to fix that should be to edit the map for use a target_counter -> target_scriptrunner that lead to a script with

wait 1000

"use Swoop"

 

commands and see what it happens, there is sufficente debounce time for avoid a CRC error and for allow engine to free entity.

also if is added delay 1000 to target_counter or to scriptrunner for increase the debounce time.

but it require or entity modding, or original MAP file.

if it crash again, should be very hard to fix with code hacking.

or at least i am not sure exactly of how do it.

 

 

 

 

[Linken]

So just in case if anybody cares. The solution to the problem I implemented is add a target_delay for the vehicle to NPC_target to when the vehicle is automatically destroyed when crashing into a piece of map geometry. You need that small delay. Trying to fix it through the code would be a daunting task.