Re: CVS update: freexp/Homepage/forum/language/lang_ukrainian
Joachim Merkel <[EMAIL PROTECTED]> wrote on 05.10.04: > Michael Heydekamp ([EMAIL PROTECTED]) schreibt: >>> Welchen Modulnamen? >>> Mein Vorschlag: >>> freexp-http >> Oder "freexp-web". > freexp-site Ist ja nicht nur die Web"site", sondern alles, was web-basierend ist (Forum halt). Na gut, ist vielleicht doch die "site", weiß nicht. "web" schien mir klarer. Aber wurscht -- Martin, nimm, was Dir gefällt. :) Michael FreeXP Entwickler-Mailingliste [EMAIL PROTECTED] http://www.freexp.de/cgi-bin/mailman/listinfo/dev-list
Re: heise online: DFN-CERT warnt vor Angriffen auf Webserver mit unsicheren PHP-Skripten
<[EMAIL PROTECTED]> wrote on 05.10.04: > Diese Meldung aus dem heise Security-Newsticker wurde Ihnen von > "[EMAIL PROTECTED]" gesandt. [...] Ich dachte, die würden wir inzwischen nuken? Michael FreeXP Entwickler-Mailingliste [EMAIL PROTECTED] http://www.freexp.de/cgi-bin/mailman/listinfo/dev-list
Re: CVS update: freexp/Homepage/forum/language/lang_ukrainian
Michael Heydekamp <[EMAIL PROTECTED]> wrote:, >> Aktuell ist die Homepage halt ein Unterverzeichnis des >> CVS-Moduls freexp. > >Was auch nicht so glücklich ist, wenn jemand nur "mal eben" den Code >auschecken will. Ich hoffe, Jochen macht nicht gerade heute ein "cvs >up". ;-) Eben. Bei OpenXP haben wir dafür ein eigenes Repository, so das man neben dem Code nicht gleich die Homepage (und umgekehrt) auschecken muß. Aber für die Homepage arbeiten wir sowieso an einer Lösung, die kein CVS mehr erfordert. -- Happy Arts Software pgpRPNeqQ8p2L.pgp Description: PGP signature FreeXP Entwickler-Mailingliste [EMAIL PROTECTED] http://www.freexp.de/cgi-bin/mailman/listinfo/dev-list
Re: CVS update: freexp/Homepage/forum/language/lang_ukrainian
Markus Kaemmerer <[EMAIL PROTECTED]> wrote on 06.10.04: > Michael Heydekamp <[EMAIL PROTECTED]> wrote:, >>> Aktuell ist die Homepage halt ein Unterverzeichnis des >>> CVS-Moduls freexp. >> >> Was auch nicht so glücklich ist, wenn jemand nur "mal eben" den Code >> auschecken will. Ich hoffe, Jochen macht nicht gerade heute ein >> "cvs up". ;-) > Eben. Bei OpenXP haben wir dafür ein eigenes Repository, dito (seit eben). Aber das war ja auch bei OpenXP nicht immer so, jedenfalls finde ich hier lokal noch ein Unterverzeichnis "Internet". Michael FreeXP Entwickler-Mailingliste [EMAIL PROTECTED] http://www.freexp.de/cgi-bin/mailman/listinfo/dev-list
Golem-News: Spieletest: Star Wars Battlefront - Gefechte mit Darth Vader
Hinweis: Die untenstehende News der Golem.de-Redaktion wurde Ihnen ([EMAIL PROTECTED]) auf Wunsch von [EMAIL PROTECTED] mit Hilfe der Funktion "Artikel-per-E-Mail senden" geschickt. Sollten derartige Zusendungen unerwuenscht sein, informieren Sie uns bitte per E-Mail an [EMAIL PROTECTED] . --- Uebermittelte Golem.de-News vom 06.10.2004: Spieletest: Star Wars Battlefront - Gefechte mit Darth Vader Action-Spiel fuer PC, Xbox und PlayStation 2 Lucas Arts hat die Star-Wars-Lizenz in den letzten Jahren nahezu unendlich ausgereizt und immer neue Spiele zum Thema veroeffentlicht, wobei die Qualitaet der Programme oft zu wuenschen uebrig ließ und Ankuendigungen neuer Titel somit auch bei absoluten Krieg-der-Sterne-Fans kaum noch zu großen Erwartungen fuehrten. Bei Star Wars Battlefront hatte man allerdings schon im Vorfeld das Gefuehl, dass hier nach "Knights of the Old Republic" ein weiterer großartiger Titel entstehen koennte - und die Vorahnungen haben sich ueber weite Strecken als richtig erwiesen. Waehrend der Entwicklung von Star Wars Battlefront gab sich Lucas Arts nur wenig Muehe, darueber hinwegzutaeuschen, dass sich das Spiel inhaltlich sehr deutlich am Multiplayer-Hit Battlefield 1942 orientiert. Aehnlich dem von Battlefield bekannten Conquest-Modus geht es auch in Battlefront meist darum, mit dem eigenen Team alle Stuetzpunkte auf einer Karte einzunehmen. Alternativ kann allerdings auch einfach das komplette feindliche Team eliminiert werden, was sich oft als einfachere Option entpuppt. Insgesamt stehen vier verschiedene Parteien zur Auswahl, wobei sich aufden jeweiligen Maps aber immer nur zwei von ihnen begegnen. Neben den Rebellen kann man sich auch auf Seiten des Imperiums schlagen, fuer die Republik antreten oder die Droiden steuern. Jede Partei hat darueber hinaus fuenf unterschiedliche Kaempfertypen - neben dem gut ausgebildeten Allrounder gibt es in jeder Partei Scharfschuetzen und Piloten, zudem ist auch immer ein recht einmaliger Charakter wie etwa der Wookie-Schmuggler bei den Rebellen anwaehlbar. Einen besonderen Reiz machen in Battlefront die Fahrzeuge aus - hier wird praktisch alles geboten, was aus den Star-Wars-Filmen bekannt ist, unter anderem natuerlich X-Wings, Tie Fighter und At-Ats. Betreten der Fahrzeuge ist per simplen Knopfdruck moeglich, auch die Steuerung ist von Beginn an denkbar einfach; allerdings gestatten leider nicht alle Maps den Einsatz der Raumgleiter. Star Wars Battlefront muss nicht zwangslaeufig im Multiplayer (fuer bis zu 32 Spieler) gespielt werden, die Entwickler spendierten dem Titel auch eine recht umfangreiche Solo-Kampagne. Hierbei waehlt man entweder ein kurzes und schnelles Gefecht, stuerzt sich in die historische Kampagne oder wendet sich in der Galaxis-Eroberung nach und nach einem neuen Planeten zu, der in die eigene Gewalt gebracht werden muss. Trotz unterschiedlicher Rahmenbedingungen spielen sich all diese Modi aber sehr aehnlich. Da die Intelligenz der Computer-Kontrahenten recht gut ist und auch an die eigenen Bots im gewissen Rahmen Befehle erteilt werden koennen, wirkt das Ganze laengst nicht nur wie ein einfaches Extra, sondern wie ein eigenstaendiges Spiel. Optisch und akustisch zieht Battlefront alle Register - die vielen Schauplaetze wie Naboo oder Hoth sehen, dem jeweiligen Filmvorbild entsprechend, extrem unterschiedlich, aber immer aeußerst detailliert aus; die bekannte Musik sorgt fuer zusaetzliche Atmosphaere. Neben der hier getesteten PC-Version ist Star Wars Battlefront auch fuer Xbox und PlayStation 2 verfuegbar. Diese Versionen lagen uns allerdings nicht vor. Fazit: Ob man Star Wars Battlefront mag, haengt vor allem davon ab, wie sehr man die Star-Wars-Reihe schaetzt; denn prinzipiell bietet der Titel nicht mehr als andere gute Multiplayer-Shooter wie eben Battlefield 1942. Wer aber strahlende Augen bei Saetzen wie "Darth Vader hat das Spielfeld betreten" bekommt, oder gluecklich ist, wenn er einen X-Wing fliegen kann, wird die naechsten Monate nichts anderes mehr spielen wollen. Battlefront bietet eben keine Innovationen, dafuer aber eine der schoensten Science-Fiction-Erfahrungen, die es am PC bisher zu erleben gab. Quelle: http://www.golem.de/0410/33989.html Verwandte Artikel: Star Wars Battlefront - Krieg-der-Sterne-Shooter ist fertig (03.09.2004, http://www.golem.de/0409/33383.html) Star Wars Trilogy als Spiel fuer den Game Boy Advance (14.07.2004, http://www.golem.de/0407/32343.html) Star-Wars-Shooter Republic Commando verschiebt sich auf 2005 (15.06.2004, http://www.golem.de/0406/31747.html) Lucas Arts: Weniger Angestellte, weniger Spiele (16.08.2004, http://www.golem.de/0408/32996.html) Entlaesst LucasArts wieder Mitarbeiter? (13.08.2004, http://www.golem.de/0408/32969.html) --- Copyright 2004 by Golem.de (http://www.golem.de) Wollen Sie in Zukunft derartige News noch schneller per Email erhalten? Dann abonnieren Sie doch einfach den taeglichen, kostenlosen
Ihre Nachricht an Support-List wartet auf Bestätigung des Moderators
Ihre eMail an 'Support-List' mit dem Betreff/Subject Golem-News: RegTP: Keine ortsfremden Rufnummern für VoIP wird zurückgehalten, bis der Moderator der Liste Ihre eMail genehmigt. Der Grund, weshalb eine Genehmigung erforderlich ist: Absender ist nicht Mitglied der Liste -- eMails an die Liste aber nur für Mitglieder erlaubt! Entweder wird Ihre Email in Kürze freigegeben und über die Liste verteilt, oder Sie erhalten eine ablehnende Mitteilung durch den Moderator. Sie können diese eMail *zurückziehen*, solange sie noch nicht verteilt worden ist. Wenn Sie NICHT mehr verteilt werden soll, besuchen Sie bitte den folgenden Link: http://www.freexp.de/cgi-bin/mailman/confirm/support-list/1d644d9520403c0933e11506226a70df21481a80 FreeXP Entwickler-Mailingliste [EMAIL PROTECTED] http://www.freexp.de/cgi-bin/mailman/listinfo/dev-list
Datum-/Zeitroutinen (was: Immer wieder erstaunlich...)
Martin Wodrich <[EMAIL PROTECTED]> wrote on 05.10.04:
> Michael Heydekamp <[EMAIL PROTECTED]> schrieb am 04.10.04 um 18:09:
>> Der Bug liegt, wenn man den Code liest, so klar vor einem wie nur
>> was. Manchmal kann man sich nur wundern, wie so etwas über 10 Jahre
>> lang unentdeckt bleiben konnte.
> Indem genau der Bug eben in der Praxis total selten auftrat. Solange
> man keinen Codereview macht, sieht man sowas einfach nicht.
> Genau soclhe Stellen sind es aber unter Umständen die eben eventuell
> doch mal echte Probleme machen. Nicht direkt diese Stelle, aber eben
> solche Stellen, die eben bei Tests übersehen werden.
Eine "Kunst" beim Programmieren liegt halt auch darin, an (möglichst)
alle Fälle zu denken.
Es ist aber auch wirklich zum K*tzen und ich scheine sowas irgendwie
anzuziehen: Eigentlich wollte ich nur dem "Date:"-Header die übliche
Angabe des Wochentags spendieren, prompt stoße ich erstmal auf den
obigen Bug. Ok, der war nicht so schwer zu fixen.
Aber *danach* bin ich im selben Bereich noch auf mehr Dinge gestoßen,
und die haben wieder dazu geführt, daß ich praktisch alles komplett neu
schreiben mußte, was mit der Erzeugung von Headern zusammenhängt, die
Angaben über Datum/Zeit/Zeitzone enthalten.
Einiges davon kann man hier vielleicht tatsächlich mal zur Diskussion
stellen, denn einige Fragen sind da durchaus noch offen.
Da ich mit der Dokumentation der bisherigen Änderungen gerade eben
fertig geworden bin, quote ich die nachfolgend einfach mal einzeln und
schreibe ein paar Kommentare und Fragen dazu:
--8<--
> 3. Die "From_"-Zeile von UUCP-Mails enthält nicht mehr Erstellungs-
>datum und -uhrzeit der Nachricht im RFC-Format (wie es im "Date:"-
>Header steht), sondern es wird eine Zeile mit dem *aktuellen*
>Datum/Uhrzeit im sog. "asctime()"-Format erzeugt:
> Jetzt : From my Wed Oct 6 19:08:33 2004 remote from freexp.de
> Bisher: From my 06 Oct 2004 19:08:33 +0200 remote from freexp.de
>Das RFC-Format ist sowohl laut der Beispiele in RFC976 als auch in
>der Praxis beim UUCP-Austausch an dieser Stelle zumindest unüblich,
>möglicherweise sogar falsch.
--8<--
Das Format habe ich tatsächlich anhand realer UUCP-Messages verifiziert,
die mir von zwei verschiedenen Seiten zugeschickt wurden.
Dabei hat sich aber nicht nur das andere Format bestätigt, sondern auch,
daß nicht wie bisher die Erstellungszeit in den Header gehört, sondern
die aktuelle Zeit (wie sie auch in den "Received:"-Header geschrieben
wird.
Ich denke, das ist soweit eindeutig, es sei denn, jemand weiß mehr
darüber als ich sehen und recherchieren konnte.
Jetzt was Umfangreicheres, es geht um die Zeitzonenangaben:
--8<--
> 4. Bei Headern, die das aktuelle Datum/Uhrzeit enthalten ("Received:",
>"From_"-Zeile bei UUCP-Mails), wird die Zeitzone nicht mehr blind
>vom Erstellungsdatum der Nachricht übernommen, da dies im Fall, daß
>Erstellungs- und Konvertierdatum in unterschiedlichen Zeitperioden
>liegen (Beispiel: Nachricht wird am Abend des letzten Tages der
>Sommerperiode erzeugt, aber erst in der Nacht oder am nächsten
>Morgen konvertiert und versandt), zu einer falsch deklarierten
>Zeitzone führen würde - bzw. in der Vergangenheit auch konkret dazu
>geführt hat.
>Stattdessen wird jetzt geprüft, ob Erstellungs- und aktuelles Datum
>in derselben Zeitperiode liegen. Ist dies nicht der Fall, wird die
>Zeitzone des aktuellen Datums aus der Zeitzone des Erstellungs-
>datums errechnet, indem je nach Konstellation 1 Stunde addiert
>(Winter => Sommer) bzw. subtrahiert (Sommer => Winter) wird. Liegen
>Erstellungs- und aktuelles Datum in derselben Zeitperiode, wird die
>Zeitzone aus dem Erstellungsdatum - wie bisher - unverändert über-
>nommen.
>Maßgebend für die Definition der Zeitperioden ist ausschließlich
>die aktuell für die EU geltende Regelung, deren Algorithmus auch
>bei der automatischen Zeitumstellung in FreeXP verwendet wird. Die
>Angabe "S" bzw. "W" im ZConnect-Header ist unzuverlässig und wird
>wie bisher ignoriert.
>Das obige Verfahren funktioniert daher in allen Fällen zuverlässig,
>in denen die Konvertierung in einem Land stattfindet, in dem a)
>eine mit der in der EU gültigen Regelung identische Winter-/Sommer-
>zeitregelung angewandt wird, und b) dessen Zeitzone identisch ist
>mit dem Land, in dem die Nachricht erstellt wurde (was nahezu immer
>der Fall sein dürfte). Mit anderen Worten: Bisher stimmte die Zeit-
>zonenangabe bei dem geschilderten Szenario praktisch nie, jetzt
>stimmt sie praktisch immer.
--8<--
Ich hoffe, das ist soweit verständlich beschrieben. Wir (wie alle
anderen UUZs auch) haben also in bestimmten Fällen schlicht eine falsche
Zeitzone deklariert. Das funktioniert jetzt alles sehr schön wie oben
beschrieben und ist IMO umfassend getestet.
Was aber evtl. noch etwas stört, ist
Re: Datum-/Zeitroutinen
Michael Heydekamp <[EMAIL PROTECTED]> wrote on 06.10.04:
[...]
> Ich hänge im Followup zu diesem Posting mal die zentralen neuen
> Routinen für das ganze Gedönse an.
Bzw. als Text geht das in diesem Falle auch:
Vor dem Schreiben des Headers jeder Nachricht Variablen mit Inhalt
füllen:
--
[...]
begin { of WriteRFCheader }
with hd do
begin
msgtime:='';
msgdate:='';
msg_TZ:='';
nowdate:=date;
nowtime:=time;
now_DST:=sommer(nowdate,nowtime);
now_TZ:=iifs(now_DST,'+0200','+0100'); { Default: MEZ/MESZ }
if (length(zdatum)>7) and (length(datum)>5) then
begin
{ my: Ggf. Jahr bei Jahrhundertwechsel korrigieren, }
{ damit bei Nachrichten, die als UTC-Datum in }
{ 'zdatum' noch den 31.12.1999, als lokales Datum }
{ in 'datum' aber bereits den 01.01.00 (zweistel- }
{ lige Jahreszahl!) ausweisen, nicht wie bisher }
{ durch das blinde Kopieren der ersten beiden }
{ Ziffern der Jahreszahl aus 'zdatum' das lokale }
{ RFC-Datum "01 Jan 1900" erzeugt wird. }
msgdate:=copy(datum,5,2)+'.'+copy(datum,3,2)+'.'+
iifs(((copy(zdatum,3,2)='99') and (left(datum,2)='00')),
strs(ival(left(zdatum,2))+1)+left(datum,2),
left(zdatum,2)+left(datum,2));
if (length(zdatum)>13) and (length(datum)>9) then
msgtime:=copy(datum,7,2)+':'+copy(datum,9,2)+':'+copy(zdatum,13,2);
if (length(zdatum)>16) and (upcase(zdatum[15]) in ['W','S']) and
(zdatum[16] in ['+','-']) and (zdatum[17] in ['0'..'9']) then
begin
msg_DST:=sommer(msgdate,msgtime);
p:=cpos(':',zdatum);
if p=0 then p:=byte(zdatum[0])+1;
msg_TZ:=zdatum[16]+formi(ival(copy(zdatum,17,p-17)),2)+
formi(ival(mid(zdatum,p+1)),2);
if right(msg_TZ,4)='' then{ bei TZ '' immer '+' }
msg_TZ[1]:='+';
p:=ival(left(msg_TZ,3))+ { 'p' für Zeitzone mißbrauchen }
iif(not msg_DST and now_DST,1,
iif(msg_DST and not now_DST,-1,0));
now_TZ:=iifs(p<0,'-','+')+formi(abs(p),2)+right(msg_TZ,2);
end;
end;
[...]
Die Routine, die aus den obigen Variablen wahlweise RFC- oder asctime()-
Format (mit Wochentag) erzeugt:
{ - }
{ asc=false: Datums-/Zeitstring in RFC-Format umwandeln }
{(für "Date:"-Header, Quelle: EDA:-Header) }
{(für "Received:"-Header, akt. Zeit)}
{"Fri, 31 Dec 1999 23:01:00 +0100" }
{ }
{ asc=true : Datums-/Zeitstring in asctime-Format umwandeln }
{(für "From_"-Zeile in UUCP-Mails, akt. Zeit) }
{"Fri Dec 31 23:01:00 1999" }
{ }
{ dateS= Datum im Format "31.12.1999" }
{ timeS= Zeit im Format "23:01:00" }
{ - }
function RFCdate(const dateS,timeS,TZ:datetimest; const asc:boolean):string;
begin
if dateS<>'' then
begin
RFCdate:=copy('MonTueWedThuFriSatSun',dow(dateS)*3-2,3)+
iifs(asc,'',', ')+
iifs(asc,'',left(dateS,2))+' '+month(copy(dateS,4,2))+
iifs(asc,iifs(dateS[1]='0',' '+copy(dateS,2,1),left(dateS,2)),
right(dateS,4))+
iifs(timeS='','',' '+timeS)+
iifs(asc,' '+right(dateS,4),iifs(TZ='','',' '+TZ));
end
else RFCdate:='';
end;
Und hier die Zeilen/Header, wo 'RFCdate' letztlich verwendet wird:
--
--8<--
if ddatum<>'' then
begin
fpar:=fpar+'modification-date="'+
RFCdate(copy(ddatum,7,2)+'.'+copy(ddatum,5,2)+'.'+
left(ddatum,4),copy(ddatum,9,2)+':'+
copy(ddatum,11,2)+':'+copy(ddatum,13,2),
'-',false)+'"';
if hd.groesse>0 then fpar:=fpar+'; size='+strs(hd.groesse);
end
--8<--
--8<--
else wrs(f,'From '+left(s,p-1)+' '+
RFCdate(nowdate,nowtime,now_TZ,true)+ { akt. Datum/Uhrzeit }
' remote from '+mid(s,p+1));
if (wab<>'') and (cpos('@',oem)>0) and not smtp { (*1) - s.u. }
then rfor:=empfaenger
else rfor:='';
wrs(f,'Received: by '+mid(s,cpos('@',s)+1)+
iifs(programm<>'',' ('+programm+')','')+
iifs(rfor<>'',#10#9'for '+rfor+';',';'));
wrs(f,#9+RFCdate(nowdate,nowtime,now_TZ,false)); { akt. Datum/Uhrzeit }
end
--8<--
--
