View source for User:SirYodaJedi/Porting IdTech 3 maps to Source/Entities

== Common KVs ==
Some KVs that are common across several entities. If I mention a KV, but it isn't listed here or in the per-entity lists below, assume it works the same as in Source and can be kept as-is.
{{kv|Yaw angle|intn=angle|angle|Yaw rotation. For example, a misc_model <tt>angle</tt> of "180" is equivalent to a prop_static's <tt>angles</tt> of "0 180 0".}}
{{kv|Target|intn=target|target_destination|send an input to the specified entity (whatever that entity's "do" input is)}}
{{kv|Script block name|intn=scriptname|string|only=RtCW, WolfET|name of block in script file that the entity is associated with}}
{{kv|TargetShaderName|intn=targetShaderName|material}}
{{kv|TargetShaderNewName|intn=targetShaderNewName|material|When this entity is triggered, the specified material is replaced with a new specified material. Note that <tt>targetShaderName</tt> will always be the original material name, even if the material being displayed has been changed at runtime. This will require some complicated material proxy stuff <tt>[[env_texturetoggle]]</tt> or <tt>[[material_modify_control]]</tt> on brushes, but on prop_dynamic, you can just send the <tt>skin</tt> input.}}
{{kv|Model2|intn=model2|studio|The first frame of a dynamically-lit model is displayed at runtime wherever this brush entity's origin is (which will move if the entity moves). Put a <tt>[[prop_dynamic]]</tt> where the origin is, and parent it to this entity.}}
{{kv|Model2 Pitch Yaw Roll (Y Z X)|intn=modelAngles|angles|only=Jedi Academy|Rotational offset of Model2 compared to the rotation of the bmodel. This should be ''added'' to the brush entity's <tt>angles</tt> KV when put in the prop_dynamic.}}
{{kv|Uniform model scale|intn=modelscale|float|Uniform scale of the model (or for brush ents, model2) in all directions. Depending upon the engine branch and entity, you might be able to do this in the entity's properties, but otherwise you can use <tt>[[$scale]]</tt>.}}
{{kv|Model scale vectors|intn=modelscale_vec|vec3|Per-axis scale of the model (or for brush ents, model2). This can't be done with entity KVs or $scale, so it will need to be done in Blender.}}
{{kv|Skin|intn=skin|file|A <tt>.skin</tt> file to use for the models [[skin]]. See [[User:SirYodaJedi/Porting IdTech 3 maps to Source#Skin files|#Skin files]].}}
{{kv|Cast Shadows|intn=_castShadows, _cs|boolean|Whether entity casts lightmap shadows. See <tt>vrad_brush_cast_shadows</tt> for brush entities, or <tt>disableshadows</tt> for prop_static.}}
{{kv|Lightmap sample size|intn=_lightmapsamplesize, _samplesize, _ss|integer|Explicit <tt>[[luxel]]</tt> scale.}}
{{kv|Lightmap scale|intn=_lightmapscale, lightmapscale, _ls|float|Adjusts luxel scale relative to the material's <tt>q3map_lightmapSampleSize</tt>, or, if not present, the <tt>-samplesize</tt> Q3Map2 parameter). If neither are present, assume a default luxel scale of 16. Do note that brush/disp lightmaps in Source are much lower resolution than lightmaps in Quake 3 (32px vs 128px+), so to avoid excessive subdivision on really low luxel scales, consider using [[$lightmap|static prop lightmaps]] if possible.}}
{{kv|Smoothing angle|intn=_shadeangle, _smoothnormals, _sn, _sa, _smooth|angle|any angles equal to or more obtuse than this value are phonged together. Use [[smoothing groups]] as deemed suitable. If this is on worldspawn, use the <tt>-smooth n</tt> VRAD parameter, wherein {{code|1= n = 180 - q}}, with q being the q3map2 shade angle.}}
{{kv|Constant light color|intn=color|color1|rendercolor.}}

== World brushes ==
=== <tt>worldspawn</tt> ===
<tt>[[worldspawn]]</tt>

=== <tt>func_group</tt> ===
N/A

Func_group brushes should be untied from entities and returned to worldspawn, as [[VBSP]] lacks func_group support. If the brush had the detail flag, tie to func_detail instead.

I added func_group support to my {{src13mp}} VBSP fork, [[User:SirYodaJedi/YBSP|YBSP]].

== Q3Map2 entities ==
=== <tt>misc_model</tt> ===
Usually <tt>[[prop_static]]</tt>, unless there is a <tt>target</tt> KV, in which case it should be a prop_dynamic parented to the specified entity.

Most small or medium-sized misc_models are lit about the same as prop_static (with Q3Map2 doing bounced lighting on them like CSGO), but misc_models with forcemeta can be lightmapped the same way as brushes, unlike Source; see notes below for spawnflag 4.

Collisions are usually done via clip brushes; use [[Propper++]] if you want to convert them to [[$collisionmodel]]. Oftentimes it may be preferable to create a new collision mesh for the prop instead.

<br>
:; Keyvalues
{{kv|Tie to bmodel|intn=target, _target|target_destination |Ties the model to the named brush entity instead of being part of worldspawn. Instead of using [[prop_static]], use [[prop_dynamic]] and [[parent]] to the specified entity.}}
{{kv|Remap material|intn=_remap*|string|Format {{code|"original_material;new_material"}}.<br>The first material is replaced with the second material in the compiled map (usually used for misc_model). Use [[skin]]s.}}
<br>
:;Spawnflags
{{fl|2, 8, 16, 128, 256, 512, 1024, 2048, 4096|Auto-clip model|If ''any'' combination of these are enabled, they have collision automatically generated collision, so make sure the ported prop has a <tt>[[$collisionmodel]]</tt>. You can decompile the map to get the autoclipped geometry, but you probably only want to do that for large terrain meshes.}}
{{fl|4|Force meta|Decompose to "metasurfaces", allowing it to be lightmapped.}}
{{workaround|There are ways of improving lighting, depending upon the engine branch. These are more [[expensive]], however, and should only be done if the default vertex lighting is unsatisfactory.
* {{in|any branch}} - Subdivide each convex face of the mesh, being careful not to change the overall topology (don't add verts to "curved" edges). Lighting is done per-vertex, so increasing the number of vertices results in more accurate lighting, and a dense enough mesh can be more accurate when vertex lit than when lightmapped.
:: If <tt>[[$lod]]</tt> is available for the engine branch, consider having two versions of the subdivided mesh: one with heavy subdivision for the default close-up mesh, and one with much less subdivision for further away. For example, a simple rectangular prism (ex: fence post) could be subdivided on the long sides with 12x3 faces for the close up mesh, and 7x2 faces for the {{code|$lod 50}} mesh (potentially using loop cuts, so that the short sides are subdivided evenly).
* {{in|{{src13mp}} and {{gmod}} }} - Make all of the model's UVs fit onto one material with no overlap or tiling, then use a [[$lightmap|static prop lightmap]].
* {{in|any branch}} - Do the same UV edits as above, but pre-bake the lighting in Blender (possibly onto a detail texture with <tt>[[$detailblendmode]]</tt> 8</tt> or <tt>[[Modulate]]</tt> mesh). Use UnlitGeneric instead of VertexLitGeneric to prevent VRAD lighting from conflicting with the Blender lighting. Note that this will cause the model to be unaffected by most dynamic lights except for flashlights and CSM.
* {{in|any branch}} - Use OBJ2MAP or similar to convert the model to brushwork (only if the model is simple enough!). This can work around the lack of bounced static prop lighting on pre-{{CSGO}} versions of VRAD.
}}
{{fl|32|Color to Alpha|The RGB vertex colors in the source model represent vertex alpha instead of vertex color. If you can, remake the geometry as displacements; otherwise, bake the blending into a [[megatexture]].}}

=== <tt>_decal</tt> ===
<tt>[[info_projecteddecal]]</tt>… sort of.

_decal is a brush entity (patch mesh entity, rather), but it works similarly.

:; Keyvalues 
{{kv|target|intn=target|target_destination|Entity to project towards the origin of. Use some math to determine the <tt>angles</tt> and <tt>Distance</tt> KVs.}}

=== <tt>_skybox</tt> ===
<tt>[[sky_camera]]</tt>

:; Keyvalues 
{{kv|Scale|intn=_scale|float|<tt>scale</tt> of sky_camera.}}

=== <tt>light</tt> ===
If no target: <tt>[[light]]</tt>
If target: <tt>[[light_spot]]</tt>

:; Keyvalues
{{kv|Color|intn=_color|color1|Light color; convert from [[Color1]] to [[Color255]] and make part of <tt>_light</tt>.}}
{{kv|Brightness|intn=light|int|Light intensity; make part of <tt>_light</tt>.}}

:; Spawnflags
{{fl|1|Linear attenuation|Uses linear attenuation instead of inverse square… except if compiled in <tt>-wolf</tt> mode, in which case it uses inverse square instead of linear.}}

=== <tt>lightJunior</tt> ===
N/A

Only affects dynamically lit models, and does not use an edict. Source 1 and its BSP format technically supports this, but the compilers lack a way to set it, so you'd have to manually edit/replace the WORLDLIGHTS and WORLDLIGHTS_HDR lumps.

== Quake 3 entities ==
These can be found in most games

=== <tt>info_null</tt> ===
<tt>[[info_null]]</tt>

This is ''usually'' the same thing. 
The exception is in WolfET, where the entity is kept around for a <tt>[[tick]]</tt> longer than usual. This is done to allow game entities to target the point; to mimic this behavior, use an <tt>[[info_target]]</tt>, and [[killtarget]] the it with a <tt>[[logic_auto]]</tt> 0.1 seconds after map spawn.

=== <tt>info_notnull</tt> ===
<tt>[[info_target]]</tt>

Works the same way; Valve decided to rename the entity in GoldSrc.

=== <tt>target_kill</tt> ===
N/A

If no targets, deals 100000 hit points to the [[!activator|activator]].
<br>
:; Keyvalues 
{{kv|Target to kill|intn=target|target_destination|only=RtCW, WolfET|[[killtarget]] the specified entity instead of hurting the player.}}
<br>
:; Spawnflags
{{fl|1|Kill user too|only=RtCW, WolfET|Still damage player even if a target is present.}}


=== <tt>target_position</tt> ===
<tt>[[info_target]]</tt>

Same as info_notnull

=== <tt>target_relay</tt> ===
<tt>[[logic_relay]]</tt>

:; Spawnflags 
{{fl|1|Red only|Use a [[filter]] to prevent the blue team from using this relay.}}
{{fl|2|Blue only|Use a [[filter]] to prevent the red team from using this relay.}}
{{fl|4|Random target|Only triggers one of the targets (they'll all have the same name).<br>Change the targets to all have different names, and have this relay send a PickRandom input to a [[logic_case]] which then uses the OnCase## outputs to trigger the appropriate target.<br>Since target_relay supports up to 32 targets compared to logic_case's 16, you may need to use three logic_cases, with the first one deciding which of the other two to use.}}

=== <tt>target_delay</tt> ===
<tt>[[logic_relay]]</tt>

The delay can have a random variance to it, in which case some complicated <tt>[[logic_timer]]</tt> shenanigans may be necessary, probably in conjunction with a <tt>[[logic_case]]</tt>.

=== <tt>target_speaker</tt> ===
<tt>[[ambient_generic]]</tt>

=== <tt>target_location</tt> ===
{{dods}} <tt>[[dod_location]]</tt>

=== <tt>trigger_always</tt> ===
<tt>[[logic_auto]]</tt>

IdTech version is poorly named. It is only fired on map spawn, but does ''not'' fire if a map is entered from a level change without starting a new unit. As such, it might be necessary to put a trigger_once around the player spawn if using in singleplayer.

=== <tt>func_static</tt> ===
<tt>[[func_brush]]</tt>, <tt>[[func_wall]]</tt>, or <tt>[[func_wall_toggle]]</tt>

<br>
:; Keyvalues
{{kv|Name|intn=targetname|target_source|{{in|RtCW and WolfET}} If this entity is triggered, it toggles visibility and collision. Send the <tt>Toggle</tt> input to this entity to replicate this.}}
<br>
:; Flags
{{fl|1|Starts Invisible|only=RtCW and WolfET|Starts in the off state. This is the same as <tt>[[func_wall_toggle]]'s</tt> spawnflag 1; for <tt>[[func_brush]]</tt>, enable <tt>StartDisabled</tt>.}}

=== <tt>func_rotating</tt> ===
<tt>[[func_rotating]]</tt>
<br>
:; Keyvalues 
{{kv|Rotation speed|intn=speed|integer|Change to <tt>maxspeed</tt>.}}

=== <tt>func_timer</tt> ===
<tt>[[logic_timer]]</tt>

Despite the func_ prefix, this is a point entity.

=== <tt>misc_portal_surface</tt> ===
<tt>[[func_monitor]]</tt> (if has target)<br><tt>[[func_reflective_glass]]</tt> (if no target)<br>{{portal2}}{{strata}}<tt>[[linked_portal_door]]</tt> (if navigable)

Point entity which affects the nearest portal surface, which will need to be turned in to the appropriate brush entity.

=== <tt>misc_portal_camera</tt> ===
<tt>[[point_camera]]</tt>

Target for the misc_portal_surface.

=== <tt>info_player_intermission</tt> ===
<tt>[[info_intermission]]</tt><br>
{{css}}{{dods}}<tt>[[point_viewcontrol]]</tt>

Controls camera in between rounds.
{{todo|nocat=1|In at least WolfET, the is also a flag to set whether this is used after which team wins; is there an equivalent way to handle this in CS:S/DoD:S?}}

=== <tt>team_CTF_redplayer</tt>, <tt>team_CTF_redspawn</tt> ===
{{hl2dm}}<tt>[[info_player_combine]]</tt><br>{{dods}}<tt>[[info_player_axis]]</tt><br>{{css}}<tt>[[info_player_terrorist]]</tt><br>{{bms}}<tt>[[info_player_scientist]]</tt><br>{{tf2}}<tt>[[info_player_teamspawn]]</tt> (RED)

In Quake III (and maybe RtCW?), the <tt>team_CTF_*player</tt> are initial spawn points, whereas <tt>team_CTF_*spawn</tt> are respawn points. WolfET always uses the latter; toggling them based upon conditionals.<br>In RtCW and WolfET, red is Axis (German), and blue is Allied (American).

=== <tt>team_CTF_blueplayer</tt>,<tt>team_CTF_bluespawn</tt> ===
{{hl2dm}}<tt>[[info_player_combine]]</tt><br>{{dods}}<tt>[[info_player_allies]]</tt><br>{{css}}<tt>[[info_player_counterterrorist]]</tt><br>{{bms}}<tt>[[info_player_marine]]</tt><br>{{tf2}}<tt>[[info_player_teamspawn]]</tt> (BLU)

See above

== Wolfenstein entities ==
=== <tt>corona</tt> ===
<tt>[[env_lightglow]]</tt>

In RtCW and WolfET. Scale is loosely relative to <tt>r_flaresize</tt>, which defaults to 40. Multiplying <tt>scale</tt> by 40 should yield <tt>VerticalGlowSize</tt>/<tt>HorizontalGlowSize</tt>.

=== <tt>dlight</tt> ===
<tt>[[light_dynamic]]</tt> (if possible)
<tt>[[light]]</tt> (otherwise)

Flickering light. Unlike light_dynamic, custom lightstyles are supported, so it may be necessary to use a real light instead.

Also, there are some additional preset lightstyles (19 instead of 13), so yeah.

; Keyvalues 
{{kv|Preset lightstyle|intn=style|integer choices|Various preset lightstyles. Some of them are in Source, but not all.}}
{| class="wikitable"
|-
! Wolf !! Style string !! Source || notes
|-
| 1 || <code>mmnmmommommnonmmonqnmmo</code> || 1 || 
|-
| 2 || <code>abcdefghijklmnopqrstuvwxyzyxwvutsrqponmlkjihgfedcba</code> || 2 || 
|-
| 3 || <code>mmmmmaaaaammmmmaaaaaabcdefgabcdefg</code> || 3 || 
|-
| 4 || <code>ma</code> || 4 || Source version is longer, but repeats itself, so result is identical
|-
| 5 || <code>jklmnopqrstuvwxyzyxwvutsrqponmlkj</code> || 5 || 
|-
| 6 || <code>nmonqnmomnmomomono</code> || 6 || 
|-
| 7 || <code>mmmaaaabcdefgmmmmaaaammmaamm</code> || 7 || 
|-
| 8 || <code>aaaaaaaazzzzzzzz</code> || 9 || 
|-
| 9 || <code>mmamammmmammamamaaamammma</code> || 10 || 
|-
| 10 || <code>abcdefghijklmnopqrrqponmlkjihgfedcba</code> || 11 || 
|-
| 11 || <code>mmnommomhkmmomnonmmonqnmmo</code> || N/A || 
|-
| 12 || <code>kmamaamakmmmaakmamakmakmmmma</code> || N/A || 
|-
| 13 || <code>kmmmakakmmaaamammamkmamakmmmma</code> || N/A || 
|-
| 14 || <code>mmnnoonnmmmmmmmmmnmmmmnonmmmmmmm</code> || N/A || 
|-
| 15 || <code>mmmmnonmmmmnmmmmmnonmmmmmnmmmmmmm</code> || N/A || 
|-
| 16 || <code>zzzzzzzzaaaaaaaa</code> || N/A || close enough to style 9, if you want to use that
|-
| 17 || <code>zzzzzzzzaaaaaaaaaaaaaaaa</code> || N/A || 
|-
| 18 || <code>aaaaaaaazzzzzzzzaaaaaaaa</code> || N/A || 
|-
| 19 || <code>aaaaaaaaaaaaaaaazzzzzzzz</code> || N/A || 
|-
|}
{{kv|Custom lightstyle|intn=stylestring|string|A custom lightstyle (like {{ent|light}}'s {{mono|pattern}})}}
{{kv|String offset|intn=offset|int|Offset the starting point of the lightstyle. Move one minus this number to the end of the string.}}
{{kv|Attenuation|intn=atten|int|Add or subtract this value from each character in the string. stylestring of "ddeeffzz" with an atten of -1 would result in "ccddeeyy".}}

=== <tt>func_explosive</tt> ===
<tt>[[func_breakable]]</tt>

:; Flags
{{fl|4|Use shader|Uses the materials found on the original brush entity's geometry for debris instead of basing on the type of debris. You'll need to make custom gib models. Since func_breakable doesn't support custom gibs, you can use [[env_shooter]], but it might be easier to make an invisible [[prop_dynamic]] that gets destroyed when the func_breakable does.}}

=== <tt>misc_gamemodel</tt> ===
If animated and/or has targetname/scriptname: <tt>[[prop_dynamic]]</tt>
If single-frame and lacks targetname/scriptname: <tt>[[prop_static]]</tt>, with per-vertex lighting disabled

In RtCW and WolfET. {{src13|4}} doesn't completely support arbitrary [[vertex animation]], so animated [[MD3]]s or MDCs will need to be re-animated with a skeleton. If unnamed and not animated, it is only an edict for as long as info_null entities are, becoming effectively the same as <tt>[[#misc_model_static|misc_model_static]]</tt>, described below.

=== <tt>script_model_med</tt> ===
<tt>[[monster_generic]]</tt> or <tt>[[generic_actor]]</tt>

In RtCW and WolfET. A model which has its animations and movement defined in an external script file. 

=== <tt>team_WOLF_checkpoint</tt> ===
{{dods}}<tt>[[dod_control_point]]</tt>

In WolfET. A checkpoint, flag, command post, or control point; whatever you want to call it.
* Displays <tt>models/multiplayer/flagpole/flagpole.md3</tt> if no model is defined, and plays <tt>sound/movers/doors/door6_open.wav</tt> during capture animation.
* Any spawnpoints that are targeted (<tt>target</tt> KV) by this entity are only active while the point is in the respective team's control.
* Unlike the DoD:S equivalent, this model is solid, so cover the pole with a small rectangular func_detail using a nodraw material with a metal <tt>[[$surfaceprop]]</tt>.

=== <tt>props_chair</tt> ===
<tt>[[prop_physics]]</tt> with ported version of <tt>models/furniture/chair/chair_office3.mdc</tt>, including gibs via <tt>[[$collisiontext]]</tt>

:; Keyvalues
{{KV|Health|intn=health|integer|Default 10}}

=== <tt>props_chair_hiback</tt> ===
<tt>[[prop_physics]]</tt> with ported version of <tt>models/furniture/chair/hiback5.mdc</tt>, including gibs via <tt>[[$collisiontext]]</tt>

:; Keyvalues
{{KV|Health|intn=health|integer|Default 10}}

=== <tt>props_chair_hiback</tt> ===
<tt>[[prop_physics]]</tt> with ported version of <tt>models/furniture/chair/sidechair3.mdc</tt>, including gibs via <tt>[[$collisiontext]]</tt>

:; Keyvalues
{{KV|Health|intn=health|integer|Default 10}}

=== <tt>props_skyportal</tt> ===
<tt>[[sky_camera]]</tt>

== Raven Software entities ==
=== <tt>misc_model_static</tt> ===
<tt>[[prop_static]]</tt>, with per-vertex lighting disabled.

In Jedi Academy. Like misc_model, but the model is rendered as a runtime entity, instead of baked into the map geometry. If you want to be accurate to how this affects lighting, you could disable per-vertex lighting.

=== <tt>misc_model_ghoul</tt> ===
<tt>[[prop_dynamic]]</tt>

In Jedi Outcast and Jedi Academy. Arbitrary animated GLM model; destroyable.

=== <tt>misc_model_*</tt> ===
<tt>[[prop_dynamic]]</tt>

In Raven Software games. Specific MD3 model to display at runtime, sometimes animated; see DEF or ENT entity description file for model path and usage specifics.

=== <tt>misc_skyportal</tt> ===
<tt>[[sky_camera]]</tt>