prop_static vs prop_dynamic vs prop_physics: farklar ve hatalar

Bir prop_static derleme sırasında BSP'ye yazılır ve oyunda artık bir entity değildir: hiç hareket etmez, input kabul etmez ve entity bütçesinde yer kaplamaz. Bir prop_dynamic ise animasyon oynatan, başka entity'lere parent'lanabilen ve input'larla kontrol edilebilen gerçek bir entity'dir. Bir prop_physics, fizik sistemi tarafından simüle edilen bir entity'dir; yani düşer, yuvarlanır ve itilebilir. Bir modelin hangi türleri desteklediği model derlenirken belirlenir ve VBSP haritandan bir prop_static sildiğinde kontrol ettiği şey de tam olarak budur.

Üç türün karşılaştırması

VBSP statik prop'ları BSP'nin kendilerine ait bir bölümüne yazar ve entity listesinden çıkarır. GMod'un VBSP'siyle yapılan bir testte, derlemeden sonra entity lump'ta hiçbir prop_static kalmadı; her prop_dynamic ve prop_physics ise yerinde duruyordu. Bir BSP'nin bölümleri BSP dosyası nedir? yazısında anlatılıyor.

Bir sunucu için en önemlisi son satırdır. Her dinamik prop ya da fizik prop'u, ağ üzerinden eşitlenen entity'ler için ayrılmış sınırlı slotlardan birini kaplar. Bu slotlar tükendiğinde ne olduğu edict limiti yazısında anlatılıyor.

Işıklandırma, çarpışma ve performans

Üç türden VRAD yalnızca prop_static türünü ışıklandırmaya dahil eder. Bu prop lightmap'lere gölge düşürür ve VRAD'ın -StaticPropLighting seçeneğiyle ışığı vertex başına hesaplanır. Dinamik prop'lar ve fizik prop'ları lightmap'leri etkilemez. Tek bir noktada aydınlatılırlar ve yalnızca dinamik gölge düşürürler. Bu yüzden prop_dynamic olarak yerleştirilmiş bir evin önceden hesaplanmış gölgesi olmaz ve örnekleme noktası karanlıkta kalırsa modelin tamamı fazla koyu görünür. Seçenekler Source Engine'de ışıklandırma yazısında anlatılıyor.

Çarpışmada Use VPhysics ayarı, modelin çarpışma modelini kullanır. Valve Developer Community'ye göre modelde çarpışma modeli yoksa motor yükleme sırasında bir uyarı yazar ve prop katı olmaktan çıkar. Çarpışma modeli olmayan bir prop_physics fizik nesnesi alamaz. Source Engine'in standart kodunda (Source SDK 2013) oyun bu durumda ERROR!: Can't create physics object for [model] mesajını verir ve prop'u hareketsiz ve katı olmayan hâlde bırakır. Garry's Mod'un server.dll dosyası da aynı mesajı içerir.

Büyüklük sırası olarak Valve Developer Community, harita başına binlerce statik prop'tan, yüzlerce dinamik prop'tan ve karmaşıklığa bağlı olarak onlarca ila yüzlerce fizik prop'undan söz eder. Statik bir prop'un ağ yükü yoktur; bir fizik prop'u ise simüle edilmek ve her oyuncuya aktarılmak zorundadır.

Model neyi belirler ve bunu Hammer'da nasıl görürsün

Hangi türlere izin verildiğini modeldeki iki veri belirler. QC komutu $staticprop iskeleti ve animasyonları kaldırır ve prop_static için şarttır. Bir prop_data bloğu fizik ve hasar değerlerini tutar ve modeli fizik prop'u olarak işaretler. Bu ayrımın gerekçesi olarak tutarlılık gösterilir: bir haritada yuvarlanan bir varil, bir sonrakinde yere cıvatalanmış olmamalıdır.

Bir modeli şöyle kontrol edersin:

1. Prop'un özelliklerinde, World model girdisinden Model Browser'ı aç.
2. Modeli seç ve Info sekmesine geç.
3. physics, dynamic ve static adlı üç onay işaretine bak. Kütle bunların altında yazar.

Varyantlar, her biri tek cümleyle

• prop_dynamic_override: prop_dynamic gibidir, ama fizik prop'u olarak tasarlanmış modelleri de kabul eder. FGD onu yalnızca prototipleme amaçlı bir entity olarak tanımlar.
• prop_physics_override: prop_physics gibidir, ama modelde kayıtlı verileri geçersiz kılar ve özel bir Health değerine izin verir. Modelin yine de bir çarpışma modeline ihtiyacı vardır.
• prop_physics_multiplayer: prop_physics gibidir; ağ üzerindeki prediction hatalarını önleyen sadeleştirilmiş çarpışmaları ve ek olarak Physics Mode özelliği vardır.
• prop_detail: prop_static gibi BSP'ye giren, çarpışması olmayan bir detail prop'tur. Elle nadiren yerleştirilir; çoğunlukla VBSP detail prop'ları materyalden üretir.
• prop_ragdoll: eklemleri olan bir fizik prop'udur. Simülasyonu pahalıdır ve çok ağ trafiği üretir.

Tipik mesajlar ve bunlara karşı ne yapmalı

Şu satırlar GMod'un VBSP'siyle yapılan bir testten alındı:

Error! prop_static using model "models/props_c17/oildrum001.mdl", which must be used on a dynamic entity (i.e. prop_physics). Deleted.
Error! To use model "models/props_c17/door01_left.mdl" with prop_static, it must be compiled with $staticprop!
Error loading studio model STATIC "models/props_does_not/exist.mdl"!
Static prop models/props_c17/fence01a.mdl outside the map (2000.00, 2000.00, 0.00)

• must be used on a dynamic entity: Modelde allowstatic olmadan prop_data var. prop_physics kullan ya da yerinde durması gerekiyorsa prop_dynamic_override kullan. Kendi modelinde allowstatic ekle ya da prop_data bloğunu hiç koyma. GMod'un VBSP'sinde ayrıca bu kontrolü kapatan -allowdynamicpropsasstatic seçeneği vardır.
• must be compiled with $staticprop: Model $staticprop olmadan derlenmiş; çoğunlukla kemikleri ya da animasyonları olduğu için. prop_dynamic kullan ya da kendi modelini $staticprop ile yeniden derle.
• Tek başına Error loading studio model: Bu satır log'da diğer ikisinden biri olmadan görünüyorsa VBSP model dosyasını bulamamıştır. Nedenleri eksik texture'ları ve ERROR modellerini düzeltme yazısında anlatılıyor.
• outside the map: Prop sızdırmaz alanın dışında duruyor ya da tamamen bir brush'ın içinde. Yerini değiştir. Testte sızdırmaz alanın dışındaki prop ayrıca bir leak'e (**** leaked ****) yol açtı, çünkü VBSP ona orada diğer her entity gibi davranır. Tamamen bir brush'a gömülü olan prop ise yalnızca bu tek satırı üretti.

VBSP dört durumda da derlemeye devam eder. Prop oyunda eksik olur, o kadar; nedenini de yalnızca log ortaya koyar. Log'u Map Scanner aracına yapıştır ya da mesajı hata veritabanında ara. Geri kalan satırlar compile log nasıl okunur yazısında ele alınıyor.

prop_dynamic ve prop_physics için VBSP hiçbir şeyi kontrol etmez. Source Engine'in standart kodunda (Source SDK 2013) kontrolü, prop'u oluştururken oyun yapar: uyumsuz bir prop'u siler ve developer 1 etkinken konsola şunu yazar: prop_physics at [x] [y] [z] uses model [model], which has no propdata which means it must be used on a prop_static. DELETED. Garry's Mod'un server.dll dosyası ne bu metni ne de prop_dynamic için olan karşılığını içerir. Yalnızca geçersiz bir prop_data türü için olan mesaj hâlâ duruyor. Bu, GMod'un bu kontrolü uygulamadığına işaret ediyor ve Sandbox'ın spawn'lanan her prop'u, model ne olursa olsun prop_physics olarak oluşturmasıyla da örtüşürdü. Çalışan oyunda test edilmedi, bu yüzden mapper olarak buna güvenme: Info sekmesine göre hareket edersen harita her Source oyununda aynı şekilde davranır.

Karar tablosu

Sık sorulan sorular

Oyuncular haritamdaki prop'ları Physics Gun ile hareket ettirebilir mi?

Bir prop_static asla hareket ettirilemez, çünkü entity değildir. Sandbox'ta haritadan gelen bir prop_dynamic ya da prop_physics varsayılan olarak tutulabilir. Allow Physics Gun özelliğini (gmod_allowphysgun) No yapmak tek bir prop'u kilitler. Diğer oyun modları ve prop protection addon'ları kendi kurallarını uygular.

Bir prop_static'i oyunda gizleyebilir ya da yok edebilir miyim?

Hayır. Adı yoktur ve input kabul etmez. Bunun için TurnOff ve TurnOn input'larına sahip bir prop_dynamic kullan. Bunları nasıl bağlayacağın Hammer'da input ve output yazısında anlatılıyor.

Bir prop_static herhangi bir limite sayılır mı?

Çalışma zamanında sayılmaz; ne entity ne de edict olarak. Ancak derleme sırasında VBSP onu, harita dosyasındaki girdiler için kendi üst sınırına dahil eder. Genel bakış için Source Engine harita limitleri yazısına bak.