hiho

und zwar werkel ich an ner mod die das problem aufweist, das sie praktisch nicht spielbar ist. warum? nungut, eröffnen man einen listenserver, dann geht alles 1a für alle spieler auf dem server
eröffnet man aber einen dedicated server, dann is schluss mit lustig, denn es kommt so gut wie nichts mehr bei den clients an.
weder schussgeräusche noch animationen noch sonstwas

hat jmd ne ahnung oder idee was das hervorruefn könnte oder wie man dies beheben könnte?

ps: es handelt sich um ein windows-compile, und nein es ist nicht windows ._.

mfg

"selbermachen rockt am meisten :D" - -LeJean-

Das erste, was mir bei deiner Fehlerbeschreibung durch den Kopf geschossen ist, ist: delta.lst

Hast du in client.cpp bei AddToFullPack(), GetWeaponData(), UpdateClientData() (so die Kante) etwas geändert und die delta.lst nicht entsprechend angepasst? Liegen auf dem Server und bei den Clients die gleiche Version der delta.lst?

Der Horizont vieler Menschen ist ein Kreis mit Radius Null - und das nennen sie ihren Standpunkt.

mh, das ist wirklich ne 1a idee
da hab ich nämlich was geänder, nur hab ich zZ gar kein plan (nagut,is ja fast selbsterklärend) was in der delta.lst abgeht
kannst du mir das mal erklären,oso?

i würde jetzt in der clientdata_

Quellcode:DEFINE_DELTA( vuser3[0], DT_SIGNED | DT_INTEGER, 10, 1.0 ),
    DEFINE_DELTA( vuser3[1], DT_SIGNED | DT_INTEGER, 10, 1.0 ),
    DEFINE_DELTA( vuser3[2], DT_SIGNED | DT_INTEGER, 10, 1.0 ), adden, da ich mit dem vector die ammo-info mit schicke (vector hat sich bei 3typen gerade angeboten)

"selbermachen rockt am meisten :D" - -LeJean-

Im SDK gibt's ein Word-Dokument namens 'NetworkEntity.doc' in dem die Kommunikation zwischen Client und Server (incl. delta.lst) ausführlich beschrieben wird. "Ausführlich" heißt in diesem Zusammenhang aber nicht unbedingt "verständlich" *g*

Grob kann man sagen, das die delta.lst bestimmt, welche Daten vom Server zu den Clients fließen soll und mit welchem Format. Der Bereich 'clientdata_t' umfasst dabei die Playerdaten des eigenen Spielers, 'entity_state_player_t' die Playerdaten der anderen Spieler und 'entity_state_t' die ganzen restlichen Entities.

Ganz spontan sag ich mal, das das da oben gut aussieht. vuser[] wird dabei als vorzeichenbehaftetes Integer mit 10 Bits (9 für den Wert und 1 für das Vorzeichen) gesendet. Die letzte Angabe (1.0) ist nur für float-Werte interessant. Float-Werte werden nämlich ebenfalls als Integers gesendet. Hierzu wird einfach der Wert mit der letzten Angabe bei DEFINE_DELTA multipliziert und am Client wieder dividiert.

Was mich ein klein wenig stört ist, das vuser bereits standardmäßig übertragen wird (zwar als float, aber das sollte deiner Mod eigentlich egal sein) und es demzufolge nicht zu Problemen bei dir führen sollte.
Das vuser[3] bereits misbraucht wird (als SecondaryAmmoType), hast du gesehen und entsprechend umgeschrieben?

Der Horizont vieler Menschen ist ein Kreis mit Radius Null - und das nennen sie ihren Standpunkt.

jo das vuser[3] hab ich schon rauskommentiert
du hast mir auf jeden fall schonmal sehr geholfen, jetzt muss ich das nurnoch aufm dedi server testen
ich geb dann nochmal statusreport

mfg

*e*
ok,durch diese eintragungen da oben bekomm nur der server alles mit,was auf den clients abgeht
der client bekommt nach wie vor nichts/kaum was mit
aber da das vorher nicht so war liegt es mit großer wahrscheinlichkeit auch an der delta.lst
jetzt muss ich das teil nurnoch richtig konfigurieren und das sdk säubern ._.

danke so weit :)

"selbermachen rockt am meisten :D" - -LeJean-

soo, ich hab mir das ganze nochmal zu gemüte gefühtr und bin zu dem entschluss gekommen, das es nicht an der delta.lst liegt
ich hab mal alle custom messages auskommentiert und das prob bleibt bestehen

meine nächste befürchtung: die events kommen am client/server nicht richtig an, was aber eigendlich nich sein dürfte :\
ich bin mittlerweile schon recht verzweifelt, weil es nich sein kann das es nich geht arghs

Quellcode:int flags;
#if defined( CLIENT_WEAPONS )
    flags = FEV_NOTHOST;
#else
    flags = 0;
#endif
PLAYBACK_EVENT_FULL( flags, m_pPlayer->edict(), m_usFire, 0.0, (float *)&g_vecZero, (float *)&g_vecZero, vecDir.x, vecDir.y, iFireMode, m_iId, 0, 0 ); FireMode ist ein parameter der an die fkt Fire übergeben wird, in der das event aufgerufen wird

so,und dann auf dem client werden dann die animationen und sound,etc (also alles was zum event gehört) nur sehr vereinzelt/falsch abgespielt
Quellcode:if ( EV_IsLocal( idx ) )
    {
        if(args->iparam1 == PRIMARY)
        {
            //gEngfuncs.pEventAPI->EV_WeaponAnimation( BASE_SHOOT1, 1 );
            gEngfuncs.pEventAPI->EV_WeaponAnimation( pData->AnimNormShoot, 1 );
        }
        else if(args->iparam1 == IRONSIGHT)
        {
            //gEngfuncs.pEventAPI->EV_WeaponAnimation( BASE_SHOOT2, 1 );
            gEngfuncs.pEventAPI->EV_WeaponAnimation( pData->AnimISShoot, 1 );
        }

        V_PunchAxis( 0, gEngfuncs.pfnRandomFloat( -2, 2 ) );
    } so z.B. die animationen, aber es werden sehr oft, auch wenn man im iron-sight mdus ist, als normale anims abgespielt und das gleiche auch mit den sounds/muzzleflashs/etc

iparam1 ist in diesem fall ja iFiremode und es müsste alles ordendlich gehen :\

danke

"selbermachen rockt am meisten :D" - -LeJean-

so, ich bekomms einfach nich gebacken :\
hab schonmal mit dem coder gesprochen, der den code vorgearbeitet hat und er findet auch keine lösung

also ich hab die events mal entmüllt(also nur das nötigste rein,den rest alles raus) und bin zu dem ergebnis gekommen, das es auch nicht daran liegt
die evenst werden bei schneller folge (z.b. mg's) von aufrufen einfach nicht aufgerufen
schiesst man nun langsam schuss für schuss geht alles 1a

kennt jmd das prob? weil eigendlich darf das ja nicht sein :\

danke

"selbermachen rockt am meisten :D" - -LeJean-

Zitat:

Exec postete
die evenst werden bei schneller folge (z.b. mg's) von aufrufen einfach nicht aufgerufen
schiesst man nun langsam schuss für schuss geht alles 1a

kennt jmd das prob? weil eigendlich darf das ja nicht sein :\

Das ist auch schon so bei der MP5 wenn man vom SDK nichts verändert. Ich nehme mal an Valve hat das reingebaut um den Netzwerk Traffic zu reduzieren.

Nun ist deine Zeit gekommen sprach der Tod, stolperte und brach sich das Genick. :o

was? das hab ich aber noch _nie_ bemerkt
weil so extrem ... das ist unnormal, wenn nur 18 von 30 schuss vom client gerendert werden

"selbermachen rockt am meisten :D" - -LeJean-

Also ich muss mich da Agamemnon anschließen. Ich würde sogar sagen, dass bei Dauerfeuer nur jeder 2. Schuss gerendert wird, oder so etwas in der Größenordnung.

wtf? ich war vorhin nochmal im hldm auf meinem eigenen lan-dedi (so,wie ich die mod auch immer getestet hab) und da hab ich nichts dergleichen bemerkt o_O

"selbermachen rockt am meisten :D" - -LeJean-

"Low Ping Server Physics"
...gibt bei HL so einen Menupunkt beim Lan Game erstellen. Ka wie es unter Steam ist. Aber ich denke das diese Option den Unterschied macht.

/edit
Ka Stuss gelabert, aber habe grade nochmal HLDM kurz getestet, mit der MP5.
Jedenfalls, hinterlässt nur jeder 2. Schuss einen Fleck an der Wand z.B. die Animation/Muzzle wird richtig dargestellt, aber das ist ja eh irrelevant für den Traffic.
Exec, lauf an einer Wand schießend lang und Zähl nachher die Einschüsslöcher.

/edit2
Wegen Ani/Muzzle, bin mir nicht sicher, aber auch todmüde und keine Lust heute mehr was zu machen, evtl. in 10 min. :>

Nun ist deine Zeit gekommen sprach der Tod, stolperte und brach sich das Genick. :o

brauch doch nich die einschusslöscher zählen
wozu gibts den consoleprint(), damit kann man sich doch fein anzeigen lassen, wenn das event aufgerufen wird und das sind nunmal nur so 17 von 30 aufrufen :\

das es bei der mp5 nur alle 2 schuss decals gibt liegt an der tracerfrequenz

*e*
komisch ist halt, das alles perfekt geht, wenn man selber server ist
joint man aber nen server is die ganze client-server sache komplett fürn arsch

"selbermachen rockt am meisten :D" - -LeJean-