Ich versuche clientside zu prüfen, ob ein Entity "tot" ist, dazu hab ich
den EntIndex vom Server rübergeschickt. Durch den Index habe ich dann per
GetEntityByIndex( ... ) eine cl_entity_s* Variable gekriegt. Da das besagte
Entity eigentlich eine Granate ist - bei Granaten wird, wenn sie explodieren, das EF_NODRAW - Flag gesetzt , habe ich abgefragt, ob ent->currentstate.effects & EF_NODRAW . Dieser Ausdruck ist komischer immer false. Ich habe auch prevstate und baseline ausprobiert.

Kennt ihr das Problem oder habe ich was falsch gemacht ?

Ich denke mal, das Problem ist folgendes: Entities, die EF_NODRAW gesetzt haben, werden auf Serverseite ausgefiltert und nicht an die Clients geschickt. Um halt Netzwerktraffic einzusparen von Entities, die sowieso nicht sichtbar sind.
Was willste denn überhaupt machen?
Zur Not könnteste den Test serverside rausnehmen. Ist glaub ich in der AddToFullPack() oder jedenfalls dort in der Nähe, client.cpp.

TheTinySteini
Coder Poke646
"Don't Panic" - Hitchhiker's Guide to the Galaxy

Es geht um folgendes :

Ich will einen Feuerball mit einem Partikelsystem machen. Der Ball ist serverside, der Schweif ist clientside. Jetzt muss der Manager wissen, wann er aufhören muss den Schweif zu "drawen".

also, du könntest das so machen:

beim Spawn des Feuerballs sendest du doch an die clients den index des entities.. warum schickst du dann nicht beim "tod" des feuerballs eine message an die clients, wo du nur den entindex mitsendest ?

Mar 01 01:10:13 <voice> jo
Mar 01 01:10:40 <voice> bis dann ^^
Mar 01 01:11:20 <Archangel> jo
**** ENDING LOGGING AT Tue Mar 1 01:58:13 2005

jep, eine zum anmachen, eine zum ausmachen, den traffic wird er ja wohl noch verkraften

Another1

...relaxing..atm =)
... und Schweiz suckt!

Ok anmachen hab ich mit dem Event geschickt und ausmachen per Msg.
Die einfachsten Lösungen sind halt meistens die besten =).

Wobei du aber vielleicht auch den Ball selber clientside machen könntest?

TheTinySteini
Coder Poke646
"Don't Panic" - Hitchhiker's Guide to the Galaxy

das wird zu ungenau, es sei denn er schickt ab und zu 'korrektions'-events womit die clientside position und rotation und velocity gesynct wird, das kann aber zu hässlichem springen des cl_entities führen, von daher kann er's ruhig so lassen

Another1

...relaxing..atm =)
... und Schweiz suckt!

hmm jetzt hab ich ein weiteres prob bez. dem Partikelsys ...

Und zwar :

Am Anfang werden natürlich die Partikel auf einmal createt. Jetzt
werden aber alle Partikel auf einmal gedrawt, da die Partikel zur selben Zeit
starten und nicht wie danach je nach Zufallswert von age.

Hier die Update-Routine vom Manager :

Quellcode:
void CParticleManager::Update()
{
    CParticleJob *job,*nextjob,*prevjob;

    job = m_pIndex;
    prevjob = NULL;

    while(job)
    {
        nextjob = job->next;

        if(job->m_iParticleCount == 0 && job->stop)
        {
            DeleteJob(job,nextjob,prevjob);
        }
        else
        {
            prevjob = job;

            job->Draw();
            
            if (!job->stop && (job->m_iBurnedOut > 0))
            {
                
                for(;job->m_iBurnedOut;)
                {
                
                    job->CreateParticle();
                }
            }
            
        }

        job = nextjob;
    }
}



Bei dem ursprünglichen Partikelsys von TTT erkenne ich kein "Lösung" dafür.

Hm, doch, mit meinem Particle-System ist es eigentlich so, dass nur eine bestimmte Anzahl pro Sekunde gespawnt wird. Jedenfalls bei mir... oder hab ich das im Tutorial anders geschrieben? Ich denke nein.
Wenn du allerdings z.B. am Anfang 500 Particles erstellst und dann die ausgebrannten sofort neustarten lässt, dann sieht das bisschen blöde aus, da hast du recht. Aber wie gesagt, bei meinem Tut sollte das eigentlich nicht so sein.

TheTinySteini
Coder Poke646
"Don't Panic" - Hitchhiker's Guide to the Galaxy

Ich hab dein Tut ja nicht 1:1 kopiert , ausserdem wollte ich ein bischen selber rumprobieren.

Quellcode:

void Draw_Particles()
{
    static vec3_t origin;
    cl_entity_t *player;
    particles_t *p;

    if( !gParticleRenderer.m_fInitialized )
    {
        gParticleRenderer.Init();
        // Load it up with some bogus data
        player = gEngfuncs.GetLocalPlayer();
        if ( !player )
            return;
        origin = player->origin;
    }
    
    int iCount = gParticleRenderer.m_flFrametime * 450.0f;
    for( int i = 0; i < iCount; i++ )
    {
        if( p = gParticleRenderer.Create() )
        {
            p->life = RANDOM_FLOAT(0.8, 1.5);
            p->vel.x = RANDOM_FLOAT(-20.0, 20.0);
            p->vel.y = RANDOM_FLOAT(100.0, 200.0);
            p->vel.z = RANDOM_FLOAT(5.0, 10.0);
            p->origin = origin;
            p->vel = p->vel;
            p->color[0] = 0.0;
            p->color[1] = 0.0;
            p->color[2] = 0.5;
            p->color[3] = 0.7;
            p->color_end[0] = 1.0;
            p->color_end[1] = 0.5;
            p->color_end[2] = 0.0;
            p->color_end[3] = 0.0;
            p->fadein_time = 0.1;
            p->size[0] = 3.0;
            p->size[1] = 3.0;
            p->size_end[0] = 40.0;
            p->size_end[1] = 40.0;
            p->gravity = -0.1;
            p->flags = (PARTICLE_FLAG_FADEIN|PARTICLE_FLAG_COLORFADE|PARTICLE_FLAG_SIZE);
            gParticleRenderer.CalcDeltas( p );
        }
    }
    
    gParticleRenderer.Update();
}


Sorry , wo ist hier die "Lösung" ?

Da:
Quellcode:int iCount = gParticleRenderer.m_flFrametime * 450.0f;
Dadurch werden immer nur ein paar Particles pro Frame erstellt.

Ich denke mal, du setzt bei dir, wenn du ein neues System startest, automatisch m_iBurnedOut auf die Anzahl der Particles, oder so? Dann werden natürlich auch gleich am Anfang so viele Particles gespawnt. Vielleicht ist es besser, auf das m_iBurnedOut zu verzichten, und einfach pro Frame eine Anzahl an Particles zu erzeugen. Muss man nur aufpassen, dass man nicht mehr erzeugt als vernichtet werden. Sonst gibt's nen Overflow, aber dazu hat man ja sowas wie nen MAX_PARTICLES-Check (vorrausgesetzt, du hast den übernommen).

[edit]
Btw: wenn dein System gut funktioniert, könnteste ja mal mein Tutorial erweitern ;-) Würde mich jedenfalls interessieren, wie du das mit den Jobs machst.
[/edit]

TheTinySteini
Coder Poke646
"Don't Panic" - Hitchhiker's Guide to the Galaxy

ok , ich änders erstmal und schicks dir dann nochmal , nicht das
ich da nur performancefressendes Zeug geschrieben hab :\

Warum eigentlich m_flFrametime * x?

Soll ich eine Frametime für jeden Job einzeln nehmen oder für alle
in der ParticleManager-Loop ?

( Vielleicht hab ich dir schon ne msg geschickt, aber die erschien
nicht in meinem Postausgang, also kann sein, dass sie nicht angekommen ist :\ )

Hmm diese Aufgabe gestaltet sich schwieriger als ich gedacht habe ...

Der Schweif hat "nur" 10 Particles. D.h., dass nach dieser Änderung ( nicht alle auf einmal drawen) zwar am Anfang nicht alle particles auf einmal gedrawt werden, aber das Intervall zwischen den Partikeln ist immer noch zu klein .. Oder hab ich was falsch gemacht ?

-quote - warum m_flFrametime * x? -/quote -
darum: weil die anzahl der gespawnten partikel davon abhängig sein soll, wie lang der letzte frame 'gedauert' hat, d.h.: wenn er genau 1 sekunde gedauert hat is m_flFrametime genau eins und es werden 1*x also x partikel gespawnt. Hat er hingegen nur 1/10sec gedauert werden auch nur 1/10 partikel gespawnt. Das is genau wie mit allen physikalischen berechnungen die von der zeit abhängen, z.b. is bei beschleunigten bewegungen die geschwindigkeit = altegeschwindigkeit + beschleunigung * frametime; damit nich bei 1/10sec langen frames genauso beschleunigt wird wie bei 2sec langen, das wär ja blödsinn (was dabei rauskommt wenn man das mit der zeit nich so genau nimmt, siehst du wenn du wing commander 1/2 mal auf nem neuen PC spielst, da läuft das alles viel zu schnell, da der PC heute das, wofür alte PC's vorher 1sec gebraucht haben, in 1/20 sec oder schneller schafft, und die frametime einfach nich berücksichtigt wurde. )
Das Problem der frametime bei partikeln is, das es, wenn HL ruckelt, dann zu merkwürdig gespawnten partikelhäufchen kommen kann, was durch interpolieren der nichtgezeichneten frames wieder auszugleichen ist, aber die sache etwas komplizierter und rechenaufwendiger macht.

Another1

...relaxing..atm =)
... und Schweiz suckt!

Zitat:

Der Schweif hat "nur" 10 Particles. D.h., dass nach dieser Änderung ( nicht alle auf einmal drawen) zwar am Anfang nicht alle particles auf einmal gedrawt werden, aber das Intervall zwischen den Partikeln ist immer noch zu klein .. Oder hab ich was falsch gemacht ?

Ich hab auf deine Message geantwortet, aber bei 10 Particles solltest du vielleicht wirklich ein Speichern der Bruchteile überlegen. Sowas hier:
Quellcode:
float flFraction = m_flFrametime * ParticlesPerSecond;
flFraction += m_flRest;
int ParticleCount = abs(flFraction);
m_flRest = flFraction - ParticleCount;


Müsste gehen, ich hab das grad so zwischen Tür und Amsel, äh, Angel geschrieben.

TheTinySteini
Coder Poke646
"Don't Panic" - Hitchhiker's Guide to the Galaxy