Das Forum ist read-only und nur noch zu Archivzwecken vorhanden. Neue Benutzer werden nicht mehr freigeschalten.
Benutzt bitte unser aktuelles Forum: http://www.battle-planet.de/pbp/main/forum_neu.php
Aktuell ist auf Kryt ein Fehler aufgetreten. Mein Scope soll RF von einem Primerose abholen, das macht er auch. ASC zeigt aber weiterhin je 1 x RF von 3 weiteren Primerose an, die aber schon geschossen haben (mein Scope nimmt auch kein Schaden). Danach zeigt ASC an das der Scope auf Medium Air 4 x RF von den gegnerischen Comas abholt. Die machen auf Flieger natürlich keinen Schaden.
Den Spielstand habe ich an Martin geschickt. Eine Mail an die Spieler und SV von Kryt ist auch raus, weil die Comas danach kein RF mehr austeilen. Soll der SV entscheiden ob es so weiter geht oder wir auf eine Fehlerbereinigung warten sollen.
MFG Key
___________________________________________________ Save your environment. Switch off the light! (Schütze die Umwelt, bekämpfe LuX!)
Hi, hab diesen Fehler eben gestern erst in einem Duell gehabt. Die Bedingungen dafür sind mir nicht klar. Außer, daß Du vor Deinem eigentlichen Ziel, was Du anfliegst, das 1. RF fängst. VH weiß Bescheid. Es gibt einen Workaround, dafür muß aber der Angreifer ehrlich genug sein ;) Du fliegst erstmal genau zu dem Feld, wo Du das 1. RF kassierst und dann erst weiter.
Gruß, Redhorse
Gruß, Redhorse
95% aller Computerprobleme befinden sich zwischen Tastatur und Stuhl
Zitat von RedhorseHi, hab diesen Fehler eben gestern erst in einem Duell gehabt. Die Bedingungen dafür sind mir nicht klar. Außer, daß Du vor Deinem eigentlichen Ziel, was Du anfliegst, das 1. RF fängst. VH weiß Bescheid. Es gibt einen Workaround, dafür muß aber der Angreifer ehrlich genug sein ;) Du fliegst erstmal genau zu dem Feld, wo Du das 1. RF kassierst und dann erst weiter.
Gruß, Redhorse
Genau das funktioniert ja leider nicht, weil ich auf einem Feld genau diese 8x RF kassiere! Leider ist die Front auch so eng das ich das RF der Comas vorher kaum abholen kann. Bei jedem Versuch bekomme ichBoden-RF von den Primerose, die ich aber vorher abschiessen will!
Verzwickt.
___________________________________________________ Save your environment. Switch off the light! (Schütze die Umwelt, bekämpfe LuX!)
Wie man an der Versionsnummer erkennen kann ist dies die allerneuste Version, die bereits auch die neue undo-taugliche Einheiten-Produktion beinhaltet. Das ist ein gewisses Risiko an dieser Version, deshalb bitte beim Einheiten-bauen genau schauen, ob alles korrekt funktioniert. Wenn bis morgen abend keine Probleme mit dieser Version gemeldet werden, rollen wir die komplett im PBP aus.
Betroffene, die ein Problem mit dem Reactionfire haben, können diese Version auch sofort einsetzen.
Der Hintergrund des Bugs ist folgender: Das Reactionfire wurde ein zweites mal überprüft, bevor die Einheit endgültig an ihrem Zielort 'festgeschraubt' wurde. Zum Zeitpunkt des RF-Tests war die Einheit aber noch nicht auf dem Feld vermerkt, deshalb hat der Angriffstest nicht gegen die Einheit geprüft, sondern beliebige andere Ziele - und hat Objekte gefunden. Der Angriff selbst wurde dann aber wieder gegen die Einheit durchgeführt...
vielleicht kannst Du bei meinen persönlichen Problemen behilflich sein ?
Warum ist die EXE für Windows so klein und das Binary für Linux so groß ? Kann man das anpassen, so dass man unter Linux nicht immer alles neu kompilieren muss ? Auf meinen alten Kisten dauert das nämlich jedes Mal rund eine Stunde, was mit der Zeit sehr nervig ist, wenn fast täglich eine neue Version kommt.
Zitat von Tokei Ihto Warum ist die EXE für Windows so klein und das Binary für Linux so groß ? Kann man das anpassen, so dass man unter Linux nicht immer alles neu kompilieren muss ? Auf meinen alten Kisten dauert das nämlich jedes Mal rund eine Stunde, was mit der Zeit sehr nervig ist, wenn fast täglich eine neue Version kommt.
Benutzt du die update funktion von CVS? Dann dürfte das kompilieren - zumindest theoretisch - schneller gehen, weil make nicht jedes unveränderte File bauen muss.
Zitat von Garrett Benutzt du die update funktion von CVS? Dann dürfte das kompilieren - zumindest theoretisch - schneller gehen, weil make nicht jedes unveränderte File bauen muss.
Ja, ich verwende CVS, aber groß ist der Unterschied nicht.
also ich freue mich ja sehr, dass ValHaris so fleißig Updates macht. Wusste gar nicht dass man sich über sowas auch nicht freuen kann ;)
-------------------------------------------------- I´m not here to make everybody happy. Understating, yet relentless. UFP. Wir sind die Guten!(tm) http://www.ufp.de.lv/
Zitat von Prophetalso ich freue mich ja sehr, dass ValHaris so fleißig Updates macht. Wusste gar nicht dass man sich über sowas auch nicht freuen kann ;)
Ich habe nicht gesagt, ich würde mich darüber nicht freuen. Viel größer wäre die Freude nur noch, wenn es für Linux die Änderungen wie für Windows als kleine, fertige Happen gäbe *fg* ;-)
Worum geht's Dir? Den Download? Der ist mit CVS viel kleiner und schneller als mit Windows. Die Größe des Executables? Sollte, wenn Du Optimierungen (-O3) übersetzt, vergleichbar mit Windows sein. Und allgemein so klein, dass es irrelevant ist. Die Zeit zum kompilieren?
Benutz' ccache:
export CC="ccache gcc" export CXX="ccache g++" ./configure make
Beschleunigt den Übersetzungsprozess enorm, weil Änderungen in den Kommentaren nicht zum neuübersetzen des Codes führen.
Bei mir ist die typische Zeit, um die Linux Version nach einer Änderung zu kompilieren, bei ca. 1-2 min, die Windows-Version braucht 15 - 20 min zum kompilieren! Bei Multi-Core Prozessoren das -j flag beim make nicht vergesssen, mit ca. 1,5 - 2 mal Zahl der Kerne. Bei meinem Quad-Core fahre ich "make -j 6"
Zitat von ValHarisWorum geht's Dir? Den Download? Der ist mit CVS viel kleiner und schneller als mit Windows. Die Größe des Executables? Sollte, wenn Du Optimierungen (-O3) übersetzt, vergleichbar mit Windows sein. Und allgemein so klein, dass es irrelevant ist. Die Zeit zum kompilieren?
Benutz' ccache:
export CC="ccache gcc" export CXX="ccache g++" ./configure make
Beschleunigt den Übersetzungsprozess enorm, weil Änderungen in den Kommentaren nicht zum neuübersetzen des Codes führen.
Bei mir ist die typische Zeit, um die Linux Version nach einer Änderung zu kompilieren, bei ca. 1-2 min, die Windows-Version braucht 15 - 20 min zum kompilieren! Bei Multi-Core Prozessoren das -j flag beim make nicht vergesssen, mit ca. 1,5 - 2 mal Zahl der Kerne. Bei meinem Quad-Core fahre ich "make -j 6"
Mir geht es hauptsächlich um die Beschleunigung des Übersetzungsprozesses. Und dem hast Du mit Deinem Tipp bezüglich ccache beträchtlich vortrieb gegeben. Vielen Dank. Als Programmier-Dummy hab ich von diesen Parametern keine Ahnung und bin auf Tipps von Leuten wie Dir angewiesen.
Kannst Du mir noch verraten, wo und wie ich diesen Optimierungs-Parameter -O3 angeben muss ?
Sie sind vermutlich noch nicht im Forum angemeldet - Klicken Sie hier um sich kostenlos anzumelden
Offline
