Spheres are still very inaccurate.

[Danix]

Hello, I saw that the new update was announced so I immediatly went to test it, although it still does not work properly.
Please, test it yourself and try enterning/exiting the sphere more than once, not just try it once and tell yourself it works.
Spheres are still not working properly, I don't know about checkpoints since I did not test them.

[DizzasTeR]

Same goes with the CheckPoints.

[.]

What do you expect people You probably need continuous collision checking to be able to catch them. My suggestion is to simply use a specialized physics engine like Bullet. They're much more optimized than a manual implementation and they usually group objects into buckets to only test collisions for nearby objects instead of all objects.

[Stormeus]

The problem is that the server does its own validation checks to make sure that the player really did enter or exit a checkpoint or sphere. These haven't been updated accordingly so it incorrectly believes a player hasn't entered or exited. Once I can get a Linux build server up, this should be resolved.

[Danix]

Bump...this is still not fixed :/

[EK.IceFlake]

What do you expect people You probably need continuous collision checking to be able to catch them. My suggestion is to simply use a specialized physics engine like Bullet. They're much more optimized than a manual implementation and they usually group objects into buckets to only test collisions for nearby objects instead of all objects.

Here is a continuous collision detector featuring threading to less affect the performance
An untested version of this:

Code Select Expand

function onScriptLoad()
{
    newthread(CheckSphere);
    centerposofsphere <- Vector(0, 0, 1); //suppose a sphere is at 0, 0, 1
    sphrad <- 2; //suppose radius of sphere is 2
}
function CheckSphere()
{
    while (!null) //just trying to be fancy here, you can use while(true)
    {
        for (local i = 0; i <= 100; i++)
        {
            local player = FindPlayer (i);
            if (player != null)
            {
                if (player.DistanceTo(centerpossphere) <= sphrad) onSphereEntered(player, 0);
            }
        }
    }
}
function CPlayer::DistanceTo(vect)
{
    local dist = 0;
    if (vect.x < Pos.x) dist += (Pos.x - vect.x);
    else dist += (vect.x - Pos.x);
    if (vect.y < Pos.y) dist += (Pos.y - vect.y);
    else dist += (vect.y - Pos.y);
    if (vect.z < Pos.z) dist += (Pos.z - vect.z);
    else dist += (vect.z - Pos.z);
}Just use some variables and modification for onSphereExitted

[.]

...
Here is a continuous collision detector featuring threading ...

Just to be clear. Threading in Squirrel is not the same as real threading. It's more like co-routines. Where one portion of code yields/suspends and another resumes. All of this in a single actual thread. In fact, AFAIK the Squirrel VM isn't even thread safe. Co-routines are great for some situations but using them inappropriately can lead to other issues.

Oh, and btw this is what I meant by Continuous Collision Detection.

[DizzasTeR]

Did you know a race gamemode can not be scripted because of checkpoints not tracking the entrance/exiting correctly, this IS a bug and it needs to be fixed so that it always responds when a player enters/exits a sphere/checkpoint

[EK.IceFlake]

...
Here is a continuous collision detector featuring threading ...

Just to be clear. Threading in Squirrel is not the same as real threading. It's more like co-routines. Where one portion of code yields/suspends and another resumes. All of this in a single actual thread. In fact, AFAIK the Squirrel VM isn't even thread safe. Co-routines are great for some situations but using them inappropriately can lead to other issues.

Oh, and btw this is what I meant by Continuous Collision Detection.

Maybe custom threads by VCMP developers would help? But its not an easy task creating threads in a dynamic language

[.]

Maybe custom threads by VCMP developers would help? But its not an easy task creating threads in a dynamic language

Using threads in a non thread-safe environment is not the best idea. Besides, Squirrel wasn't designed to be multi-threaded from the start. Adding threads would do nothing but complicate things.

Imagine this, 2 threads running in parallel and trying to move an object. One tries to move it in the +y direction and the other in the -y. You'd get a mess out of this and worse, a crash.

VCMP scripters barely know any programming for that mater, not to mention introducing them to the world of true parallelism.

[Stormeus]

We're not adding real system threading to Squirrel or the server. The server only runs on one thread and trying to multithread would kill the server pretty quickly.