Slothbot behaving weird

[paulocf]

So I'm making a script to spawn 'bosses' in specific locations in the map, I'm still testing my reset function that resets the bot whenever he goes too far from spawn point while recovering his HP on the way back.

So far so good, BUT something weird is happening when a bot goes out of sight: I've put and outputChatBox to show the distance from his spawn point when he's going back to his spawn position (done through setBotGuard), when he is going back and goes out of my sight distance message doesn't change, it outputs like: "Distance: 43.48467", "Distance: 43.48467" and keeps repeating; same happens when he's coming my way to attack me, if I leave the area where he should be limited from leaving while being out of the his sight, he keeps coming and ignores the script, when I move within the area he appears back to his spawnning position and behave accordingly.

It seems there is a lack of sync between client and server for slothbot, or I'm missing something, I've searched about stream-in and out but got no luck and I feel that's the reason... can someone help me?

[paulocf]

Anyone?

[denny199]

What code are you using for calculating the position

[paulocf]

I'm using this script server-side:

-- Constants table 
MYPVEMOD = { 
    ["BossMaxDistance"] = 50 
} 
createTeam ( "MyPvE-Bosses", 255, 230, 0 ) 
local BTeam = getTeamFromName ( "MyPvE-Bosses" ) 
  
-- Find Z rotation between two 2d vectors (enemy and his target) 
function findRotation(x1,y1,x2,y2) 
    local t = -math.deg(math.atan2(x2-x1,y2-y1)) 
    if t < 0 then t = t + 360 end; 
    return t; 
end 
  
  
addCommandHandler( "test1",  
function( plr, cmd) 
    local x, y, z = getElementPosition( plr ); 
    local skinz = math.random ( 300, 310 ) 
    outputChatBox("Spawnning bot near you with skin #"..skinz..".") 
     
    local ped = exports [ "slothBot" ]:spawnBot ( x+10, y+10, z, 270,  skinz, 0, 0, BTeam, math.random ( 4, 9 ), "waiting")--, true ); 
    if ped then 
        local px, py, pz = getElementPosition(ped) 
        setElementData(ped, "mypvemod.boss", true) 
        setElementData(ped, "mypvemod.boss_resetPosX", px) 
        setElementData(ped, "mypvemod.boss_resetPosY", py) 
        setElementData(ped, "mypvemod.boss_resetPosZ", pz) 
        setElementData(ped, "mybooname", "Ped"..tostring(math.random(20,300))) 
         
        -- Start boss position tracking to keep him within spawn point radius (BossMaxDistance value) 
        setTimer(bossTrackPosition, 500, 1, ped) 
    else 
        outputChatBox("Ped could not be created!") 
    end 
end 
) 
  
function onBotWastedCheck(theKiller, theWeapon, theBodypart) 
    outputChatBox("Ped "..getElementData(source, "mybooname").." killed.") 
end 
addEvent("onBotWasted", true) 
addEventHandler("onBotWasted", getRootElement(), onBotWastedCheck) 
  
-- Tracks boss position 
function bossTrackPosition(boss) 
    if (isElement(boss)) then 
        local x, y, z = getElementPosition(boss) 
        local rx, ry, rz = getElementData(boss, "mypvemod.boss_resetPosX"), getElementData(boss, "mypvemod.boss_resetPosY"), getElementData(boss, "mypvemod.boss_resetPosZ") 
         
        -- Trigger reset when boss goes too far from spawn position (distance defined in BossMaxDistance constant) 
        if (getDistanceBetweenPoints3D(x, y, z, rx, ry, rz) > MYPVEMOD["BossMaxDistance"]) then 
            local tx, ty, tz = getElementPosition(getElementData(boss, "target")) 
            local rotX, rotY, rotZ = getElementRotation(boss) 
            rotZ = findRotation(x, y, tx, ty) 
            setElementRotation(boss, rotX, rotY, rotZ) 
            exports [ "slothBot" ]:setBotGuard(boss, rx, ry, rz, true) 
            setElementData(boss, "mypvemod.boss_invulnerable", true) 
            setTimer(bossReturnToSpawnPoint, 500, 1, boss) -- Break tracking position, boss is returning to spawn point from now on (resetting) 
        else 
            setTimer(bossTrackPosition, 500, 1, boss) 
        end 
    end 
end 
  
-- Returns boss to his spawn point 
function bossReturnToSpawnPoint(boss) 
    local x, y, z = getElementPosition(boss) 
    local rx, ry, rz = getElementData(boss, "mypvemod.boss_resetPosX"), getElementData(boss, "mypvemod.boss_resetPosY"), getElementData(boss, "mypvemod.boss_resetPosZ") 
    outputChatBox("Distance: "..getDistanceBetweenPoints3D(x, y, z, rx, ry, rz)) -- Outputs distance from spawn point 
    if (getDistanceBetweenPoints3D(x, y, z, rx, ry, rz) < 10) then -- Back in place 
        setElementData(boss, "mypvemod.boss_invulnerable", false) 
        exports [ "slothBot" ]:setBotWait(boss) -- Becomes aggressive again 
        setTimer(bossTrackPosition, 1000, 1, boss) -- Track boss's position again once it's in place 
    else 
        --outputChatBox("Recovering HP.") 
        setElementHealth(boss, getElementHealth(boss)+10) -- Returning and recovering 10%HP/sec. 
        setTimer(bossReturnToSpawnPoint, 1000, 1, boss) 
    end 
end 

Timer layout was inspired by slothbot, it works beautifully by the way.

[paulocf]

BUMP!

Script goal: Have a boss aggro on someone and chase that person (default slothbot behavior), and head back to spawn point if the boss goes 50meters away from spawn point while recovering HP.

Issue: Script works while the bots are in someone's sight, when they go out of sight bots behave weirdly and stop doing what they were told to do, as if they weren't client-independent.

[paulocf]

So, I decided to put an image here that hopefully will explain better my issue.

Blue = Maximum distance de boss can go from his spawn point, if he goes out of bounds he resets, this causes him to go back to his spawnning position while recovering 10%HP/sec.

Orange = It seems to be field of view in MTA (140meters it seems), when someone goes out of an object/ped's field of view they are not shown, they disappear due to distance.

Now, the script WORKS while the player is within the monster's field of view, however, when they leave their field of view (black arrows in the image) the script breaks.

Example 1: The monster is coming my way, I run a ton faster than him and get out of his sight, because he disappears to me the script breaks and no longer detects when he goes out of bounds, so he keeps chasing me forever (i.e. beyond maximum distance from spawn point). When I return close to his spawn point or where he was lastly, he returns back to that point and behaves accordingly.

Example 2: The monster is returning to his spawn point, I run a ton faster than him and get out of his sight, because he disappears to me the script breaks and he doesn't move at all, when I return and he comes into sight he proceeds to move back to his spawn point.

The script DOES work because I put several outputChatBox's to check if the timers are running, and indeed they are, it seems that being in sight/out of sight causes the ped not to respond to the script, or simply stops working as if slothbot would depend on someone being close to the bot for their action to be reported back to the server. Of course this is not intended, bot should be independent of anything and should move/exist on their own. Could someone please help me?

[DiSaMe]

Of course this is not "intended", it's simply what physical elements are limited to. They cannot just move "on their own", they must have a syncer, because MTA server, being completely separate from GTA engine, does not have physics. It has to rely on the client it sets as the syncer to sync the information about the element, such as position. Since the objects far away from the player are not loaded, physics don't work properly there, so if there are no players near the element, it won't have anyone to sync it, resulting in element staying in the same position, no matter what the players see. The easiest approach to the solution for this problem is using setElementPosition server-side to simulate the movement of the ped. That's how I made it in NPC HLC to keep the peds synced when they go out of client-side sync range.

[paulocf]

Of course this is not "intended", it's simply what physical elements are limited to. They cannot just move "on their own", they must have a syncer, because MTA server, being completely separate from GTA engine, does not have physics. It has to rely on the client it sets as the syncer to sync the information about the element, such as position. Since the objects far away from the player are not loaded, physics don't work properly there, so if there are no players near the element, it won't have anyone to sync it, resulting in element staying in the same position, no matter what the players see. The easiest approach to the solution for this problem is using setElementPosition server-side to simulate the movement of the ped. That's how I made it in NPC HLC to keep the peds synced when they go out of client-side sync range.

Thanks so much, I see... I was doing that but wanted a more realistic approach, guess I'll revert current script.

[rain_gloom]

Of course this is not "intended", it's simply what physical elements are limited to. They cannot just move "on their own", they must have a syncer, because MTA server, being completely separate from GTA engine, does not have physics. It has to rely on the client it sets as the syncer to sync the information about the element, such as position. Since the objects far away from the player are not loaded, physics don't work properly there, so if there are no players near the element, it won't have anyone to sync it, resulting in element staying in the same position, no matter what the players see. The easiest approach to the solution for this problem is using setElementPosition server-side to simulate the movement of the ped. That's how I made it in NPC HLC to keep the peds synced when they go out of client-side sync range.

Thanks so much, I see... I was doing that but wanted a more realistic approach, guess I'll revert current script.

if people won't see what's happening with the boss, they won't care whether it walks or teleports behind their back

never make things too complex by simulating background things

[paulocf]

Thing is I didn't see MTA as separate from GTA, it was a foggy concept until now and yeah I was being stupid. In normal MMORPGs things happen independent of anyone because everything relies on the server, the opposite happens with MTA and that was a core concept I was missing. Now it's more clear though, I'll make the bosses more "moment-based" than permanent.