Query an Gameserver

[Flodding]

Also ist meine Angehensweise total falsch.

Ich muss Die Reihenfolge der Empfangenen Daten beachten um dann gezielt die Bytes auszulesen.

Ich habe ehrlich gesagt die ganze Zeit nicht die Längenangaben hintendran beachtet und somit bin ich von völlig falschen längen ausgegangen.

Theoretisch müsste ich in etwa so interpretieren:

Header: Lese 1tes Byte und wandele um,
Protocol: Lese 2tes Byte und wandele um,
Name: Fang an zu lesen nach 2tem Byte und stoppe bei erstem "00" , merke dir wo du aufgehört hast zu lesen!!!
Map: Lese weiter wo du vorher aufgehört hast und weiter bis zum nächsten "00"; merk dir wieder die Endposition.
Folder: weiter "00" bis "00" lesen, merken,
Game: weiter "00" bis "00" lesen, merken,
ID: Lese von der LETZTEN Position 2 Bytes weiter und wandele um, merk dir neue Position,
Players: Lese 1 weiteres Byte, wandele um und merk dir Position,
Max. Players: ....... und so weiter.

Korrekt?

EDIT:

Die ID : 8A84 sollte umgewandelt 33930 ergeben. Tut es aber nicht egal in was ich umwandel. HextoStr gibt Kryptisches, HextoInt gibt eine falsche Zahl: 35460.

[BadenPower]

Zitat von Flodding:

Die ID : 8A84 sollte umgewandelt 33930 ergeben. Tut es aber nicht egal in was ich umwandel. HextoStr gibt Kryptisches, HextoInt gibt eine falsche Zahl: 35460.

Das sagt mir, dass Du nie versucht hast 33930 in ein Hex umzuwandeln, denn dann hättest Du gesehen , dass 33930 ToHex-> 848A ist.

Na, fällt Dir etwas auf?

[Flodding]

ja das habe ich natürlich probiert...

von SIGNED INT to HEX funktionierts ja auch.

aber von HEX to SIGNED INT häng ich. ich bekomms nur in INT gewandelt und das gibt dann den falschen wert.

[Sir Rufo]

Es ist erheblich einfacher als du denkst, aber du musst eben etwas umdenken

Zunächst einmal schaust du dir die Datentypen an, die Valve da vorgibt und suchst dir die passenden Delphi-Typen dazu heraus
http://docwiki.embarcadero.com/RADSt...Der_Typ_Single

Dann könnte man das hier bauen

Delphi-Quellcode:

type
  TValveByte     = Byte;     {8 bit character or unsigned integer}
  TValveShort    = SmallInt; {16 bit signed integer}
  TValveLong     = Integer;  {32 bit signed integer}
  TValveFloat    = Single;   {32 bit floating point}
  TValveLongLong = Cardinal; {64 bit unsigned integer}

Jetzt gibt es in Delphi auch so nette Sachen wie TStream und der kann TStream.WriteData und (viel Spanier hier) TStream.ReadData.

Du bekommst ja eine Handvoll Bytes und die kann man in einen TBytesStream packen und dann liest man ganz gemütlich die Daten heraus.

Hier mal ein kleines Beispiel zum Starten:

Delphi-Quellcode:

const
  SIMPLE_RESPONSE_HEADER : TValveLong = $FFFFFFFF;
  MULTIPACKET_RESPONSE_HEADER : TValveLong = $FFFFFFFE;

procedure Foo( AResponse : TBytes );
var
  LResponseStream : TStream;
  LHeader : TValveLong;  
begin
  LResponseStream := TBytesStream.Create( AResponse );
  try
    LResponseStream.ReadData( LHeader ); // Wir lesen den 4-Byte Header
    case LHeader of
      SIMPLE_RESPONSE_HEADER : 
        WorkOnSimpleResponse( LResponseStream );
      MULTIPACKET_RESPONSE_HEADER : 
        WorkOnMultiPacketResponse( LResponseStream );
    else
      raise Exception.CreateFmt( 'Unknown Header Value %8.8x', [LHeader] );
    end;  
  finally
    LResponseStream.Free;
  end;
end;

Wie du sehen kannst, vermeide ich auf Teufel komm raus, irgendwo im Quelltext mit Magic Values zu arbeiten.

Wenn irgendein Wert eine bestimmte Bedeutung hat, dann definiert man sich einen Konstante und verwendet diese Konstante im Quelltext. Dann bleibt das auch immer schön lesbar.

[Sir Rufo]

Bist du dir auch sicher, dass [$8A, $84] auch wirklich $8A84 bedeuten oder evtl. eher $848A ?

In der Valve-Dokumentation wird ganz eindeutig von All types are little endian gesprochen, was wiederum bedeutet, dass du dir diese Seite anschauen solltest
http://de.wikipedia.org/wiki/Byte-Re...-Endian-Format

und dann bedeutet diese Bytefolge [$8A, $84] eben genau $848A entspricht was dezimal dann tatsächlich 33930 entspricht. Nur im Speicher sind die Bytes eben in umgekehrter Reihenfolge abgelegt.

Darauf achten musst du nicht, wenn du diese Werte (wie in meinem Beitrag zuvor gezeigt) direkt aus dem Stream liest (lese einfach eine SmallInt , bzw. Int16 )

[BadenPower]

Zitat von BadenPower:

Zitat von Flodding:

Die ID : 8A84 sollte umgewandelt 33930 ergeben. Tut es aber nicht egal in was ich umwandel. HextoStr gibt Kryptisches, HextoInt gibt eine falsche Zahl: 35460.

Das sagt mir, dass Du nie versucht hast 33930 in ein Hex umzuwandeln, denn dann hättest Du gesehen , dass 33930 ToHex-> 848A ist.

Na, fällt Dir etwas auf?

Zitat von Sir Rufo:

und dann bedeutet diese Bytefolge [$8A, $84] eben genau $848A entspricht was dezimal dann tatsächlich 33930 entspricht. Nur im Speicher sind die Bytes eben in umgekehrter Reihenfolge abgelegt.

Vielleicht fällt es ihm jetzt auf, wenn er das 2. mal mit der Nase darauf gestoßen wird.

[Flodding]

Zitat von BadenPower:

Vielleicht fällt es ihm jetzt auf, wenn er das 2. mal mit der Nase darauf gestoßen wird.

Ja ist es jetzt.
Aber ich muss dazu sagen, dass es kaum möglich ist, diskreter darauf hinzuweisen.

Man schaue sich "8A84" und "848A" nur mal an.
Ich möchte nicht unhöflich klingen, aber man hätte mich einfach direkt drauf hinweisen können OHNE zu warten und sich dann lustig drüber zu machen.
Ich bin sehr dankbar für die Hilfe die mir hier angeboten wird und interpretiere sie auch nicht als lästiges Rumgedruckse oder Ähnliches. Indirekt / eloquent jemanden zu beleidigen ist trotzdem nicht die feine Art und ich bitte dies in Zukunft zu unterlassen. Sicher hätte ich dem preventieren können wenn ich wie der Fuchs aufgepasst hätte. Wir stempeln das als meinen Fehler ab

Soviel zum Offtopic!

Delphi kennt TBytes bei mir nicht.
procedure Foo( AResponse : TBytes ); Des Weiteren verstehe ich am Beispiel noch nicht so ganz, wie ich unbekannten Inhalt erkennen soll. Das mit dem Header war ja nun leicht weil er bekannt ist.