Moin!

Habe soeben ein Model in meine CS:S Map eingebaut.

Es ist ein ganz normales "Gitter" für einen Luftschacht, wie es ihn auch in HL2 gibt, aber für CS:S ist der ja leider (noch) nicht verfügbar.
Naja, jedenfalls klappt alles wunderbar.

Wer mag kann sich das ganze gerne runterladen und in seinen Maps benutzen.
www.adorata.de/johannes/Gitter.zip
Die beiden Verzeichnisse in der Zip gehören in den
...\steamapps\*username*\sourcesdk\cstrike_sample_content bzw. in den
...\steamapps\*username*\counter-strike source\cstrike Ordner.
Auf Credit bestehe ich nicht, hab aber auch nix dagegen :-P

Nun zu meinem Problem:
Das oben aufgeführte Model funktioniert als "Prop_static".

Eigentlich hatte ich aber vor das man auf Gitter schiessen kann und es dann runterfällt/umkippt. Kaputt gehen soll bzw darf es aber nicht.

Wenn ich nun aber ein "Prop_dynamic" daraus mache, bekomme ich, wenn ich meine Karte in CS:S starte, eine Fehlermeldung dass mein Model gelöscht wurde. Wie gesagt, das passiert nicht wenn es ein "Prop_static" ist.

Ich hatte das ganze vorher mit einer func_physbox getestet, also einem einfachen Brush-Entity, damit ging es auch. Nur möchte ich ja kein Luftgitter im Hammer bauen, das kostet viel zu viele Ressourcen.

Ich denke mal es hat etwas damit zu tun, was ich in der QC oder vielleicht der VMT Datei geschrieben habe.
Nur weiß ich nicht was ich sonst einsetzen sollte. Hat jemand eine Idee wie ich das umschreiben muss?

Hier der Inhalt der QC Datei:

// Output .MDL
$modelname cs_guerilla_tactics/Gitter.mdl
// Directory of .BMP
$cdmaterials models\Gitter
$staticprop
$surfaceprop "metal"
// Write textures into a ???T.mdl
//$externaltextures
$scale 1.0
// whole body
$body studio "./Gitter"
// sequences: all sequences are in $cd
$sequence idle "Gitter_seq" loop fps 1
$collisionmodel "Gitter_phys.smd" {
// Mass in kilograms
$Mass 5
$concave
}

und hier noch der Inhalt der VMT Datei:

"VertexLitGeneric"
{
"$baseTexture" "models/Gitter/Gitter"
"%keywords" "Gitter"
"$model" 1
"$selfillum" 1
"$envmap" "env_cubemap"
"$normalmapalphaenvmapmask" 1
"$envmapcontrast" 1
}

Ich hoffe ich finde jemanden der da eine Idee zu hat :-)

Danke & Gruß,
hamburghannes

Also ich kenn mich mit Modeln noch nicht so aus aber ich denke mal das der fehler darn liegen wird:

$staticprop

es gibt bestimmt noch einen befehl für physik bzw. dynamik.

Denk ich mir mal weis aber nich obs stimmt.

ja, den Verdacht hege ich auch - nur was sollte ich einfügen? :-)

ich werd gleich mal ein paar sachen ausprobieren die mir einfallen, mit etwas glück erwische ich das richtige

ja, den Verdacht hege ich auch - nur was sollte ich einfügen? :-)

ich werd gleich mal ein paar sachen ausprobieren die mir einfallen, mit etwas glück erwische ich das richtige

Zitat:

$staticprop

Causes all bones to be collapsed in the object; this can only be used when there’s no animation associated with the object. You want to use it wherever possible though, because it will make the models render more quickly.

Das Weglassen hat nicht funktioniert.

Aber ich habe es trotzdem hinbekommen; zwar musste ich dafür fast die gesamte Source SDK Doku auf http://www.valve-erc.com/srcsdk/
lesen, aber das schadet ja auch nicht wirklich.

Kann wegen mir geschlossen werden.

Dann könntest du doch wenigstens mal sagen, WIE du es hinbekommen hast :rolleyes:
Das sollte doch drinne sein oder :)

Achso, klaro.

Also:

Damit ein Model nicht nur als prop_static benutzt werden kann, sondern auch als prop_dynamic ( das war der Entity Typ den ich gebraucht habe )
bedarf es zusätzlicher Informationen in der QC Datei.

Diese beziehen sich auf das Kollisonsmodell, den Oberflächentyp und einiger Schlüssel werte.

Hier der Inhalt meiner QC Datei :

ANFANG
---------------------------------------------------------------------------

// Output .MDL
$modelname cs_guerilla_tactics/Gitter.mdl

// Directory of .BMP
$cdmaterials models\Gitter

$autocenter

$contents "grate"

// Write textures into a ???T.mdl
//$externaltextures

$scale 1.0

// whole body
$body studio "./Gitter"

// sequences: all sequences are in $cd
$sequence idle "Gitter_seq" loop fps 1

$surfaceprop "metal"

$collisionmodel "Gitter_phys.smd" {
// Mass in kilograms
$Mass 5
$concave
}

$keyvalues
{
"prop_data"
{
"base" "Metal.Medium" // base material defined in propdata.txt
"health" "40" // overriding material properties
"physicsmode" "0" // setting a custom physics mode
}
}

---------------------------------------------------------------------------ENDE

Die letzten 3 Einträge sind die wichtigen:

$surfaceprop
gibt den Oberflächentyp an. Hier sind zum Beispiel Holz, Glass und Metall denkbar. Man kann die vorgegebenen Typen nutzen oder auch eigene erstellen.
Wählt man Metall, gibt ein typisches Metallgeräusch wieder und ein Einschussloch Decal wird auf die Oberfläche gezaubert.
Wält man Glass hört man ein splitterndes Geräusch, und Man sie einige Risse und ein Loch auf der Oberfläche wenn man darauf schießt. ( So wie die Bilder in HL2/CS:S )
Die genaue Liste der möglichen Typen findet man in der Datei
\scripts\surfaceproperties.txt
Diese muss man aber erst mit GcfScape oder einem ähnlichen Programm entpacken.

$collisionmodel "Gitter_phys.smd"
{$Mass 5
$concave}
Gibt den Namen des Kollisionsmodels an. Dieses sollte übrigens in den wenigstens Fällen ( eigentlich nur bei einfachen Models wie Kisten und ähnlichem ) genauso aussehen wie das Originalmodel, sondern immer mit bedacht und gänzlich eigentständig gemodelt sein. Aber das ist eine andere Geschichte :-)
"Mass" gibt die Masse an und zwar in Kilogramm. Dieser Wert hat Auswirkungen auf das Verhalten in der Physik-Engine : z.B. : Ob man das Objekt schieben oder aufheben kann, oder wieviel Schaden es macht, wenn es einem zufällig auf den Kopf fällt.
"concave" sagt der Studiomdl.exe, dass das Kollisionsmodell nicht ein einfacher
konvexer Körper ist ( wie ein würfel ) sondern aus mehreren konvexen Körpern besteht. Die Begriffe konvex und konkav kannte ich zwar bisher nur in anderen Zusammenhängen, aber naja. Jedenfalls muss mein Gitter unbedingt "concave" sein, weil es ja Zwischenräume gibt, durch die man durchschießen können soll.

$keyvalues
{"prop_data"
{"base" "Metal.Medium"
"health" "40"
"physicsmode" "0" }}
Dies sind verschiedene Schlüsselwerte die gegeben sein müssen.
'base_data' gibt eine Aussage über den Objekttyp ab, mit dem unser Modell vergleichbar ist, was auch hinsichtlich der Physik von Wichtigkeit ist.
Hier hätte ich auch Metal.Large eingeben können, wenn mein Objekt von der Größe und dem Verhalten her einem typischen Autowrack aus HL/CS:S hätte entsprechen sollen.
Die verschiedenen Eingabemöglichkeiten bei prop_data findet ihr in der Datei
\scripts\propdata.txt
welche ihr wie schon oben erst entpacken müsst.
'Health' bezieht sich auf die Haltbarkeit des Objekts und überschreibt bei Angabe Sowohl die diesbezüglichen Eigenschaften die man in Hammer angeben kann, als auch die Standardeinstellung für den Objektyp.
Zuletzt noch 'physicsmode'. Hierbei kann man 4 verschiedene Einstellungen wählen inwiefern sich das Objekt hinterher verhalten soll und zwar Server und/oder Clientseitig. Ich habe '0' angegeben, da dies für den Automodus steht, welcher das Verhalten von Gewicht (Masse, siehe oben) und Größe des Models abhängig macht.

Tja, das wars im Groben.
Damit das auch wirklich jeder mal ausprobieren und nachvollziehen kann werde ich die im ersten Post oben angegebene Datei mit der neuen Version ersetzen.
Da könnt ihr euch das nochmal anschauen.

Gruß,
hamburghannes

Hmpf, da ich nix mehr reineditieren kann, hier der neue Link:

www.adorata.de/johannes/Gitter_hamburghannes.zip

Viel Spaß!