Wolfenstein City - Community

Dago-xy hat geschrieben:Habe jetzt öfter auf schmerzliche weise bemerkt das manche auf den axis ausgang hüpfen können - auch dieser trickjump oder auch anders erreichbar?

Und wenn nicht: schnell selfkill und hinten spawnen.

Xenier hat geschrieben:...Wie wechselt man den Spawnpunkt eigentlich?

Cris-D50 hat geschrieben:

Dago-xy hat geschrieben:Habe jetzt öfter auf schmerzliche weise bemerkt das manche auf den axis ausgang hüpfen können - auch dieser trickjump oder auch anders erreichbar?

Klar, ist trickjump.
Aber Schmerzen brauchst du keine haben, ist ja nur ein Spiel.
Obwohl......., mir würde das auch stinken.
In diesem Fall wäre es nicht übel, wenn ein Engie gleich mal am Anfang hinten die Barrieren aufbaut, obwohl der dann vorne fehlt.
Kommt in diesem Fall auf die Spieleranzahl an. Bei viel Spielern kann man einen Engie hinten ev. verkraften.
Der sieht oder hört den Eindringling vielleicht.
Und wenn nicht: schnell selfkill und hinten spawnen.

bexx hat geschrieben:[
also am besten erst gar nicht fueldump spielen ist besser für alle

mfg

bexx =)

andreasposer hat geschrieben:alle einstellungen der q3engine sind nur zu einem zweck gemacht worden !

damit auch leute mit schwachen rechnern freude an dem spiel haben können.

alles was über die menü's im spiel einstellbar ist finde ich legitim.
alles andere, was nur in einer configurationsdatei gemacht werden kann ist genauso cheaten...

seht es meinetwegen anders, ich finde aber eine orginalinstallation super,
geile grafik und so weiter, leider funzt dann kein trickjump, ob das wohl so gewollt war ?

übrigens ist die fps-rate nach einer installation 90 und nicht 46,76, 125, ...
wer mit 90 fps in den fueldump hüpfen kann, unglaublich

WoodSTokk hat geschrieben:Das Menü bietet nur die wichtigsten Sachen zum einstellen für die Schnelleinsteiger und Gelegenheitsspieler. Du findest im Menü zB nirgens Proxy-Einstellungen obwohl das Spiel problemlos mit Proxy's zusammen arbeitet.

Die überall propagierten FPS-Raten finden nur unter ETmain und ETpub (früher shrubET) Verwendung. Unter ETpro ist die Physik schon seit langem von der Grafik entbunden und du schaffst jeden Trickjump mit jeder FPS-Rate. Für einen Trickjump musst du also üben und nicht an der Config schrauben.

mfG WoodSTokk

Danke, Danke, auch an Bexx für's Festmachen des Threads; wie gesagt, der erste Post ist aber alles andere als vollständig. Ich habe selbst lange herumorakelt, was genau hinter den ganzen Variablen, die zur Berechung der Spielphysik benutzt (und ausgenutzt ) werden, steckt und möchte jetzt versuchen, auch anderen Spielern zu helfen. Freut mich natürlich, wenn sich Leute dafür interessieren und ich mir die Finder nicht umsonst wundgeschrieben habe.
@<3CHRISTINA: Pmove_fixed ist eine Variable, die sowohl server- als auch clientseitig anwendbar ist; pmove_msec ist eine rein serverseitige Variable und gibt vor, wie lang im Falle von "pmove_fixed 1" das Berechungsintervall für Frames sein soll (Standard: 8 Millisekunden), diese Variable ist also in einer Spieler-Config nutzlos. 'pmove_fixed 1' kannst Du bei Dir jederzeit einstellen, den erwünschten Effekt wird das aber nur haben, wenn der Server auch "pmove_fixed 1" aktiviert hat, also ein festes Frame-Berechnungsintervall von pmove_msec <Millisekunden> für alle Spieler erzwingt.

Die von bexx und Butcher genannten Variablen b_fixedphysics, b_fixedphysicsfps (beides serverseitige Variablen) und b_optimizedprediction (Client-Variable) sind im Gegensatz zu den pmove-Variablen ETPro-spezifisch können daher natürlich nur auf solchen Servern verwendet werden; Jumpserver sind ja i.d.R. ETPro-Server.
(Anmerkung: Variablen, die mit "b" anfangen wie "b_fixedphysics" sind allesamt ETPro-Variablen. "b" steht für "bani", einen der Mod-Coder von ETPro. Man kann ETPro-Variablen natürlich in seiner Spieler-config lassen, wenn man auf einem Nicht-ETPro Server spielt, sie haben dort aber natürlich keinen Effekt.)
Zitat:
Zitat von bexx
pmove hat bei etpro auch keinen einfluss mehr da es b_fixedphysics gibt die standardmäßig bei allen eine fps zahl von 125 simulieren

Ich fürchte, b_fixedphysics alleine macht genau das Gegenteil; es bricht Trickjumpern geradezu das Genick. Aaaaaber:

b_fixedphysics, b_fixedphysicsfps und b_optimizedprediction haben eine ähnliche Wirkung wie pmove_fixed, dieser und dieser post im bani-Forum beschreiben sie.
In Kürze: es gibt bei pmove_fixed einige bugs (Rukkeln bei extrem hohen FPS-Raten > 300 fps , Rukkeln bei Bedienung eines festen MGs oder eines Mörsers). Die drei ETPro Variablen haben eine pmove-ähnliche Funktion, sollen aber die Bugs (die FPS-abhängig auftreten) verhindern.

b_fixedphysics 1 oder 2 und b_fixedphysicsfps
Dies sind, wie oben geschrieben, Servervariablen mit ähnlichen Ziel wie pmove_fixed. "b_fixedphysics 1" verhindert das Auf- oder Abrunden nicht ganzzahliger Werte bei der Spielphysik-Berechung, damit auch deren Aufaddieren und damit die extreme Abhängigkeit der Spielerphysik von der verwendeten FPS. Bei dieser Servereinstellung macht es also keinen Sinn eine FPS größer als die Bildwiederholungsrate des Monitors zu nutzen, da man sich unabhängig von der Client-FPS IMMER gleich bewegen wird. Damit wir Trickjumper aber nicht Amok laufen weil uns die Basis für alle Trickjumps und damit der Sinn des Lebens entzogen wird, gibt es noch b_fixedphysicsfps <Wert>; damit kann ohne "pmove_fixed 1" und "pmovemsec 8" eine FPS von <Wert> emuliert und das altgewohnte, FPS-abhängige Verhalten beim Springen erzeugt werden. "b_fixedphysics 2" ist eine Art Mittelweg: alle FPS-Raten bis 166 FPS haben die von uns 'erwünschten' Rundungsfeher bei der Berechung und lassen uns weiter springen, bei allen FPS darüber (z.B. 333) wird die Rundung wie bei "b_fixedphysics 1" unterbunden (= kein Trickjumpeffekt mehr)

b_optimizedprediction
... ist eine Clientvariable, die Rechenleistung einsparen und so insbesondere Spielern mit hohem Ping einen Leistungsschub bringen soll. Sie funktioniert so: Normalerweise berechnet ET (und RTCW/Q3) bis zu 64 der letzten frames im Hintergrund erneut um abschätzen zu können, wo der betreffende Spieler für das im Augenblick zu berechnende Bild sein sollte. "b_ompimizedprediction 1" führt nun dazu, dass diese letzten Berechungen gespeichert und ohne sie erneut zu berechnen wiederverwertet werden, wenn deren Ergebnis im Vergleich zu den jetzt vom Server empfangenen Daten akzeptabel erscheint. Das sollte, zumindest theoretisch, einiges an Rechenzeit einsparen, hab's aber noch nie selbst getestet.

Ich werde die oben genannten Dinge der Vollständigkeit halber heute Abend in den ersten Post integrieren, dann haben neue Leser alle Infos auf einen Blick.