Beim Austesten fremder aber auch eigener Maps fallen mir desöfteren konstruktive Ungenauigkeiten auf. Da liegen dann z.B die Brushes zweier benachbarten Wände nicht exakt aufeinander oder man kann bei komplexeren Konstruktionen oder Prefabs durch hauchdünne Ritzen gucken. Oder 3D Karten malen sonderbare Schatten, wo eigentlich keine sein dürften. Das sieht dann nicht gerade professionell aus.

Ich gehe davon aus, daß doch wohl alle mit Fang und Grid konstruieren und deshalb so etwas gar nicht auftreten dürfte und ging der Sache mal durch einige Versuchsreihen auf den Grund:

a Ich baute ein Stück Wand in den leeren Raum und ließ von QBSP eine .map Datei erzeugen. In dieser konnte ich so die exakten Raumkoordinaten der Mauer ablesen. Wie erwartet waren dann auch glatte Integerwerte enthalten.

b Mehrmaliges Verschieben der Mauer an beliebige Positionen im Editor und am Ende wieder an die ursprünglichen Koordinaten:
Ergebnis: exakt dieselben wie bei (a), "Verschiebefunktion" also OK.

c Durch copy erzeugte ich eine zweite Mauer und plazierte sie in einigem Abstand parallel zur ersten.
Test der .map: alle Koordinaten sind Ganzzahlen, "copy/paste" also OK.

d Ich drehe die erste Mauer mit sechs Mausklicks exakt um 90°
Ergebnis: Mist! aus einigen der glatten Integerwerte sind gebrochene 5-stellige Fließpunktzahlen geworden.

e Ich drehe diese Mauer mit der gleichen Methode wieder zurück auf ihre ursprüngliche Lage.
Ergebnis: Bockmist! noch krummere Werte in der .map Datei.

f Ich lösche die erste Mauer, ändere die Schrittweite der Drehfunktion im Editor von 15° auf 90° und wiederhole Schritte (d+e) mit einer "sauberen" Mauer.
Ergebnis: Die Drehung erfolgt exakt, saubere Ganzzahlen. Was nicht verwundert, weil bei 90° Drehungen keine Berechnung stattfindet, sondern nur die Koordinaten vertauscht werden müssen.

Also ist 6x15 eben doch nicht 90, weil sich die Rundungsfehler der arithmetischen Routinen im Editor addieren.

Das Dumme an der Geschichte ist, daß die durch "falsche" Drehung erzeugten Brushes im Editor nicht auffallen und exakt aufs Grid gezeichnet werden. So schleichen sich nach und nach immense Ungenauigkeiten ein, die dann schon mal ein gefürchtetes Leak erzeugen können, welches nur schwer aufzuspüren und auf den ersten Blick auch schwer zu erklären ist.

Diese Rundungsfehler treten natürlich bei allen arithmetischen Funktionen des Editors auf und sollten nicht außer Acht gelassen werden, wenn man das nächstemal in die Trickkiste greift.

Sig as a brick ┴┬┴┬┴┬┴┬┴┬┴┬┴
WW

gut zu wissen

t@sk-force mod
Bombs don't kill people, explosions kill people.

erstmal ist das ja sehr interresant, freut mich das du dich engagierst und ergebnisse eigener nachforschungen hier publiziers um einen lob auszusprechen. meine frage ist ob du diese informationen aus der .map datei herbeigezogen hast oder ob du obrige informationen aus dem wc internen rmf format bezogen hast. denn das map format automatisiert sich quasi sobald man speichert, es werden fehler von wc gefixt was zb. ausser-grid liegende brushes angeht. wenn auch willkürlich, map legt vertex knoten auf den nächst gelegenen grid-knoten. ich werde mir das selbst nochmal anschauen, habe bisher selbst nie davon gewusst.

erstmal zur erklärung, der thread ist im allgemein weil das beiträge gelöscht wurde ich fande den thread aber wertvoll, habe ihn noch schnell kopiert.

zum thema:

Ich baute ein Stück Wand in den leeren Raum und ließ von QBSP eine .map Datei erzeugen.
warum mit qbsp eine .map erzeugen? wenn ich dich korrekt verstehe hast du eine .rmf gemacht und dann mit qbsp zu map konvertiert? ich habe deine schritte mit export to map wiederholt, bei mir war sowohl mit 90*1 als auch mit 15*6 keine einzige zahl krumm.

ich werde weiterhin ausprobieren in der richtung..

map kann keine daten hinter 2 stellen nach dem komma speichern das heisst 1,6 grad drehung sind möglich, 1,63 ändern zwar wc intern etwas doch gespeichert wird dies nicht. in diese falle würde abgerudnet auf 1,60. auch texturinformationen können nicht mit 2 stellen nach dem komma gespeichert werden. 6x15 sind also 90, deine informationen können unmöglich aus einem gewöhnlichen map stammen zumal die engine nicht mit koordianten die über die 3 stelligen angaben hinnausgehen arbeiten kann. gerade weil die engine dies nicht kann werden krumme koordinaten beim speichern immer auf 2 stellen nach dem komma gereundet, dp's test: wc33 bietet texture lock der auch wärend einer brush-rotation wirkt, mit srtg+m könnte man nun den brush um 0,000234 grad drehen was aber geometrisch am brush nichts ändern würde. die textur dreht sich erstmal mit doch diese information wird auf 0,00 grad gerundet, wird nicht gespeichert. diese ganzen lücken die dann auch leaks erzeugen können also nur die ursache haben das der mapper geschlampt hat, vertex knoten nicht auf dem crid liegen und somit von map willkürlich auf den nächstgelegenen grid-knoten geschoben werden. doch wie man solch krasse fehler wie in de_aztec (heisst sie so?) als mapper erstellen kann ist mir ein rätsel, die map ist grauenhaft.
wenn man ein objekt erstellt hat welches nicht überall auf dem grid liegen könnte und zu faul ist tief reinzuscrollen und es zu kontrollieren kann man das einfach testen indem man das objekt auf der stelle kopiert. beim kopieren werden knoten auch aufs grid gezogen und im verlgeich sieht man dann den unterschied.

@linga: Ich habe gerade Deine Zeilen gelesen und den gestrigen Versuch mit einem einfachen Würfel wiederholt. Und ob in der Map-Datei gebrochene Werte stehen !! Übringens habe ich nun mit der aktuellen Zoner hlbsp.exe gearbeitet und die erzeugte, abgespeicherte .map geladen und ausgewertet. Das Ergebnis ist hier auch nicht anders:

Kopien des Inhalts "t1.map":
(Würfel original auf Grid gebaut)
[c=005000]
// This map has been written by QuArK - Quake Army Knife, Release 6.1
// It is a map for the game Half-Life.

{
"classname" "worldspawn"
"skyname" "2desert"
"wad" "../valve/halflife.wad"
{
( 0 64 -64 ) ( 0 -64 -64 ) ( 128 64 -64 ) LAB1_C4A001 0 -64 0 1 -1 //TX1
( 0 0 0 ) ( 0 128 0 ) ( 128 0 0 ) LAB1_C4A001 0 0 0 1 1 //TX1
( 0 0 -64 ) ( 0 0 64 ) ( 128 0 -64 ) LAB1_C4A001 0 -64 0 1 1 //TX1
( 64 64 -64 ) ( 64 64 64 ) ( -64 64 -64 ) LAB1_C4A001 64 -64 0 -1 1 //TX1
( 0 64 -64 ) ( 0 64 64 ) ( 0 -64 -64 ) LAB1_C4A001 64 -64 0 -1 1 //TX1
( 64 0 -64 ) ( 64 0 64 ) ( 64 128 -64 ) LAB1_C4A001 0 -64 0 1 1 //TX1
}
[/c]
Kopien des Inhalts "t2.map":
(Würfel mehrmals 15° vor-und zurückgedreht)
[c=0000ff]
{
( 0 64 -64 ) ( 0 -63.99999 -64 ) ( 128.00002 64.00002 -64 ) LAB1_C4A001 0 -64 0 1 -1 //TX1
( 0.00001 0 0 ) ( -0.00001 128 0 ) ( 128 0 0 ) LAB1_C4A001 0 0 0 1 1 //TX1
( 0.00001 0 -64 ) ( 0.00001 0 64 ) ( 128 0 -64 ) LAB1_C4A001 0 -64 0 1 1 //TX1
( 64 64 -64 ) ( 64 64 64 ) ( -64.00002 64.00002 -64 ) LAB1_C4A001 64 -64 0 -1 1 //TX1
( 0 64 -64 ) ( 0 64 64 ) ( 0 -63.99999 -64 ) LAB1_C4A001 64 -64 0 -1 1 //TX1
( 64 0 -64 ) ( 64 0 64 ) ( 64 128.00003 -64 ) LAB1_C4A001 0 -64 0 1 1 //TX1
}

}
[/c]

glaubst Du mir jetzt ??

Sig as a brick ┴┬┴┬┴┬┴┬┴┬┴┬┴
WW

êhm, mal eine kurze zwischenfrage: ich exportiere meine wc maps immer in wc selbst über file ---> export to *.map
wie machtn ihr das????

@warewolf: sag doch gleich das du quark nimmst. ich habe deine schritte mit wc 3.3 ausprobiert und export to map.

aber nochmal die frage:
"mit der aktuellen Zoner hlbsp.exe gearbeitet und die erzeugte, abgespeicherte .map"
kann quark nicht als .map speichern?

Quark arbeitet doch auch intern mit map oder? das was ich über die koordinaten und wie die engine damit arbeitet stimmt das erlebe ich jeden tag, wie deine koordinaten zustadne kommen kann ich mir nicht erklären jedenfalls wäre das eine wahnsinnige schlamperei von Quark und diese koordinaten werden niemals im bsp gespeichert da kommt es zwangsweise zu komplikationen

@DP: OK, ich hab nur den Umweg über qbsp genommen, um eine .map zu erhalten, ich dachte die .map Erzeugung ist ein Teilschritt von qbsp. Irrtum meinerseits, aber die Ungenauigkeiten entstehen so oder so.
@Linga: Wenn Du recht hast, dann liegt der Fehler an Quark, denn erwiesenermaßen werden dann nicht diese Rundungsfehler des Editors beim Erstellen des .map Files gefixt (wie bei WC)
SHIT, muß ich doch den Editor wechseln ?!

Sig as a brick ┴┬┴┬┴┬┴┬┴┬┴┬┴
WW

Ich kenne Warewolfs Problem. Er redet von der *.map Datei, die im Half_Life\valve\maps\ Ordner erzeugt wird, wenn man aus WC heraus alle vier Compilierprogramme laufen läßt. (Ihr wißt schon, eigentlich is ja die *.bsp Datei die entscheidende, aber *.map *.prt usw. werden "mitgeliefert") Und in dieser Map kann es noch viel schlimmer kommen! Hier ein Auszug aus einer meiner Maps:

{
"classname" "func_healthcharger"
"rendercolor" "0 0 0"
{
( 17 -2712 -182 ) ( 17 -2712 -230 ) ( 17 -2680 -230 ) BLACK [ 0 1 0 23 ] [ 0 0 -1 -19 ] 0 1 1
( 25 -2680 -182 ) ( 17 -2680 -182 ) ( 17 -2680 -230 ) MEDKITEDGE1 [ 6.12303e-017 0 1 51 ] [ 1 0 -6.12303e-017 10 ] -90 1 -1
( 25 -2712 -182 ) ( 25 -2712 -230 ) ( 17 -2712 -230 ) MEDKITEDGE1 [ 6.12303e-017 0 1 51 ] [ 1 0 -6.12303e-017 10 ] -90 1 -1
( 25 -2712 -182 ) ( 17 -2712 -182 ) ( 17 -2680 -182 ) MEDKITEDGE1 [ 6.12303e-017 1 0 23 ] [ 1 -6.12303e-017 0 10 ] -90 1 -1
( 25 -2712 -230 ) ( 25 -2680 -230 ) ( 17 -2680 -230 ) MEDKITEDGE1 [ 6.12303e-017 1 0 23 ] [ 1 -6.12303e-017 0 10 ] -90 1 -1
( 25 -2680 -182 ) ( 25 -2680 -230 ) ( 25 -2712 -230 ) +0MEDKIT [ 0 1 0 48 ] [ 0 0 -1 -76 ] 0 0.5 0.5
}
}

Na, sind das jetzt Werte oder was? Wie ihr sehen könnt, liegt hier das Problem ein klein wenig anders. Hier habe ich einen healthcharger aus einem Prefab eingefügt und anscheinend legt WC da keinen Wert auf Gridgenauigkeit beim Einfügen!

So long,
Geordy

Geordy

Ja watt denn nu?

Ist WC 3.3 scheiße oder Quark? Oder wie oder was?

K:R-I)Z++
"CSS ist cascading style sheets. Und nicht so'n Ranzspiel." - dp
In memory of Voice († 2005/03/30)

Oops anscheinend dann wohl beides! Also meine e-017 sind waschechte WC - Produkte. Und bei Warewolf waren es dann doch anscheinend Quark-Resultate...
Hmmm,
Geordy

Geordy

Wie sagt der Hesse da:

Wos lei meir donn dro?

Für Nicht-Hessen: Was liegt mir dann dran?

Solange alles funzt, funzt es eben... Verfunzt nochmal! *gg*

Cu

K:R-I)Z++
"CSS ist cascading style sheets. Und nicht so'n Ranzspiel." - dp
In memory of Voice († 2005/03/30)

interessant, interessant....
@geordy : da sieht man mal wieder : man solltemöglichst keine prefabs benutzen, da sie meist schlecht gemacht sind, da passiert sowas ein leafd portal saw into leaf u.a fehler !

Doomhammer
Obwohl wir nicht mehr die Stärke besitzen durch die in früheren Zeiten Himmel und Erde Bewegt werden konnten, sind wir doch immernoch eine Gruppe fest entschlossen Menschen, zwar geschwächt durch die Zeit und die Schläge des Schicksals, aber weiterhin durch den starken Willen beseelt stets zu suchen, stets zu finden und niemals aufzugeben
"Ulysses", Alfred Lord Tennyson || Your Truth Is Fiction, Your Reality Is Fake || Hinterfragt alles und glaubt nichts

Tritt dieses "Zeugs" auch auf, wenn man nach dem Drehen jede einzelne Ecke wieder
genau auf den Gitterpunkt verschiebt (D.h. auch wenns so aussieht als würde es schon
passen nach dem Drehen noch einmal Korrigiert. Wenn ihr versteht was ich damit
sagen will) ?