Talk:Func instance

From Valve Developer Community
Revision as of 05:42, 13 February 2011 by MossyBucket (talk | contribs)
Jump to navigation Jump to search

Removed L4D2 template because it works fine in other games (as it is processed and removed by the compile tools) --Omnicoder 23:51, 22 May 2010 (UTC)

Thanks, Omni. I'll change it to all Source games. --ThaiGrocer 00:26, 23 May 2010 (UTC)
It doesn't work in-game for me (using the Half-Life 2: Episode 1 engine). (See Talk:L4D2_Level_Design/VMF_Instances for original post.) --MossyBucket (formerly Andreasen) 20:12, 12 February 2011 (UTC)
I would say instancing support in Source 2009 is simply broken. The file selection dialog in Hammer doesn't work and vbsp writes any instance entities unmodified into the BSP instead of replacing it with the actual map data. The L4D2 authoring tools had similar issues when released, but they were fixed quite fast afterwards. --Barracuda 04:17, 13 February 2011 (UTC)
The file selection dialog can be circumvented through typing the file name directly into the box, and it references the map just fine inside the editor, but once you start up the game, the engine can't find the func_instance entity (and won't import any instances), and also it sometimes breaks how visleaves are displayed. (That probably has something to do with that thing you said about vbsp.) I even tried compiling and inserting a working previously compiled "level" (a small box with a player spawn and a light inside), and got the same result. (Before I got the compile to work, I also had to restart Hammer because suddenly Hammer couldn't understand what game the instanced map was for, so I guess the func_instance I fiddled with in the previous map somehow threw my settings off. I have a feeling that that could have ended badly (with a permanently broken Episode 1 engine).) I read that Source 2009 is a beta, so if one wants to be optimistic, this entity might be fixed and fully working soon enough (in about a year or so). --MossyBucket (formerly Andreasen) 12:41, 13 February 2011 (UTC)


Alien Swarm - Rotation bug for embedded func_ in func_instance

Started using this with Alien Swarm and noticed some weird behaviour.


1. Create an instance-vmf with a func_wall entity at the origin (0,0,0) and an arbitrary size (e.g. 128,16,8)

2. Create a parent-vmf and import the instance-vmf via func_instance

3. Rotate the func_instance by 90 degrees, so that the new apparent size is (16,128,8)

4. Compile the map

5. You'll notice that func_wall inside the func_instance will have its "original" rotation with apparent size (128,16,8) instead of (16,128,8).


Changing func_wall to func_illusionary will lead to the same result after compiling.

However, if using func_brush, it'll be rotated correctly BUT you can see lighting artifacts which suggests,

that it has been rotated before lighting (which is correct) but the light-map applied is NOT ROTATED,

leading to shadows on the resulting func_brush which shouldn't be there.


Any ideas, am I using it wrong or is it bugged? --Esdeekay 16:16, 28 July 2010 (UTC)

func_wall and func_illusionary are obsolete entities and shouldn't be used. func_brush has the functionality of both func_wall and func_illusionary and should always be used instead. GiGaBiTe 08:31, 10 February 2011 (UTC)
Yes, well, that doesn't insure that func_brush won't have bugs that the older entities doesn't have. If the older entities are somehow less buggy, there are yet practical uses for them. --MossyBucket (formerly Andreasen) 12:29, 10 February 2011 (UTC)