User:SirYodaJedi/Porting IdTech 3 maps to Source/Entities

Common KVs

Some KVs that are common across several entities

• angle (integer) - Yaw rotation. For example, a misc_model angle of "180" is equivalent to a prop_static's angles of "0 180 0".
• target (target_destination) - send an input to the specified entity (whatever that entity's "do" input is)
• scriptname (string) - name of block in script file that the entity is associated with
• targetShaderName (material) + targetShaderNewName (material) - When this entity is triggered, the specified material is replaced with with a new specified material. Note that targetShaderName 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 env_texturetoggle or material_modify_control on brushes, but on prop_dynamic, you can just send the skin input.
• model2 (model path) - 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 prop_dynamic where the origin is, and parent it to this entity.
• 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 $scale.
• modelscale_vec (X Y Z vectors) - 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.
• skin (skinfile path) - A .skin file to use for the models skin. See #Skin files.
• _castShadows, _cs (boolean) - Whether entity casts lightmap shadows. See vrad_brush_cast_shadows for brush entities, or disableshadows for prop_static.
• _lightmapsamplesize, _samplesize, _ss (integer) - Explicit luxel scale.
• _lightmapscale, lightmapscale, _ls (float) - Adjusts luxel scale relative to the material's q3map_lightmapSampleSize, or, if not present, the -samplesize 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 static prop lightmaps if possible.
• _remap* (string "original_material;new_material") - The first material is replaced with the second material in the compiled map (usually used for misc_model). Use skins.
• _shadeangle, _smoothnormals, _sn, _sa, _smooth (degrees) - 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 -smooth n VRAD parameter, wherein n = 180 - q, with q being the q3map2 shade angle.

Q3Map2 entities

Quake 3 entities

These can be found in most games

Raven Software entities

A few entities in IdTech 3 have analogous entities in Source 1.

id Tech 3 entity	Source entity	Notes
func_group	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.
_skybox misc_skyportal props_skyportal	sky_camera
misc_model	prop_static	Unlike prop_static in Source 1, misc_model in IdTech 3 can be lightmapped in the same way as brushes. This is done sparingly, via spawnflag 2 "force meta" or material command q3map_forceMeta, as it basically converts the model into trisoup brushes. Most small or medium-sized misc_models are lit about the same as prop_static (with Q3Map2 doing bounced lighting on them like CSGO). 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 $lod 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 $lod 50 mesh (potentially using loop cuts, so that the short sides are subdivided evenly). (in and ) - Make all of the model's UVs fit onto one material with no overlap or tiling, then use a 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 $detailblendmode 8 or Modulate 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- versions of VRAD.
misc_model_static	prop_static	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.
misc_model_ghoul	prop_dynamic	In Jedi Outcast and Jedi Academy. Arbitrary animated GLM model; destroyable.
misc_model_*	prop_dynamic	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.
misc_gamemodel	prop_dynamic	In RtCW and WolfET. Source 2013 doesn't completely support arbitrary vertex animation, so animated MD3s 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 misc_model_static, described above.
script_model_med	generic_actor monster_generic	In RtCW and WolfET. A model which has its animations and movement defined in an external script file.
dlight	light_dynamic	Flickering light. Only affects dynamically lit models; set the "Do not light world" flag to be accurate.
lightJunior	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.
info_null	info_null	This is usually the same thing. The exception is in WolfET, where the entity is kept around for a tick longer than usual. This is done to allow game entities to target the point; to mimic this behavior, killtarget the entity with a logic_auto 0.1 seconds after map spawn.
info_camp	info_null	Basically the same thing.
info_notnull	info_target	Works the same way; Valve decided to rename the entity in GoldSrc.
target_position	info_target	Same as info_notnull.
target_relay target_delay	logic_relay	Only difference between relay and delay is whether the target is triggered immediately or after a delay. The delay can have a random variance to it, in which case some complicated logic_timer shenanigans may be necessary, probably in conjunction with a logic_case.
func_timer	logic_timer	Despite the func_ prefix, this is a point entity.
trigger_always	logic_auto	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 [Todo]
target_speaker	ambient_generic
target_location	dod_location
info_player_intermission	point_viewcontrol	Controls camera in between rounds. Todo: 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?
misc_portal_surface	func_monitor (if has target) func_reflective_glass (if no target) linked_portal_door (if navigable)	Point entity which affects the nearest portal surface, which will need to be turned in to the appropriate brush entity.
misc_portal_camera	point_camera	Target for the misc_portal_surface.
team_CTF_redplayer team_CTF_redspawn	info_player_combine info_player_axis info_player_terrorist info_player_scientist info_player_teamspawn (RED)	In Quake III (and maybe RtCW?), the team_CTF_*player are initial spawn points, whereas team_CTF_*spawn are respawn points. WolfET always uses the latter; toggling them based upon conditionals. In RtCW and WolfET, red is Axis (German), and blue is Allied (American).
team_CTF_blueplayer team_CTF_bluespawn	info_player_combine info_player_allies info_player_counterterrorist info_player_marine info_player_teamspawn (BLU)
team_WOLF_checkpoint	dod_control_point	In WolfET. A checkpoint, flag, command post, or control point; whatever you want to call it. Displays models/multiplayer/flagpole/flagpole.md3 if no model is defined, and plays sound/movers/doors/door6_open.wav during capture animation. Any spawnpoints that are targeted (target 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 $surfaceprop.
corona	env_lightglow	In RtCW and WolfET. Scale is loosely relative to r_flaresize, which defaults to 40. Multiplying scale by 40 should yield VerticalGlowSize/HorizontalGlowSize.