Difference between revisions of "Talk:Func instance"

From Valve Developer Community
Jump to: navigation, search
m
m
Line 57: Line 57:
  
 
(Portal 2) I have 2 doors, each into 2 identical instances. With one door and one button, everything works correct, but when using two it does not work. One button suddenly controls both doors. The buttons should send an output to each door inside the instances. All names in my main map are different from each other (1 and 2), except the names inside the instance. Is this the problem? If so, how to fix this? Thanks in advance! --[[User:StephenB|StephenB]] 19:58, 19 May 2011 (UTC)
 
(Portal 2) I have 2 doors, each into 2 identical instances. With one door and one button, everything works correct, but when using two it does not work. One button suddenly controls both doors. The buttons should send an output to each door inside the instances. All names in my main map are different from each other (1 and 2), except the names inside the instance. Is this the problem? If so, how to fix this? Thanks in advance! --[[User:StephenB|StephenB]] 19:58, 19 May 2011 (UTC)
:Nevermind, I have studied the trust_fling map: I have to trigger a proxy_relay inside the instance which triggers the door instead of immediately trigger the door through the instance. Also, outside the instance, I have to use proxy_relays in between the button and the instance. I believe this is a bug, but I'm not sure as I'm not too familiar yet with instances.
+
:Nevermind, I have studied the trust_fling map: I have to trigger a proxy_relay inside the instance which triggers the door instead of immediately trigger the door through the instance. Also, outside the instance, I have to use proxy_relays in between the button and the instance. I believe this is a bug, but I'm not sure as I'm not too familiar yet with instances. --[[User:StephenB|StephenB]] 12:23, 21 May 2011 (UTC)

Revision as of 12:23, 21 May 2011

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)
After some exhausting testing, I've arrived at this conclusion:
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 the trouble starts when you compile your map:
If it's just an empty func_instance, the map will compile, but you'll get the in-game console red error:
Attempted to create unknown entity type func_instance!
Can't init func_instance
Also it sometimes breaks how visleaves are displayed at this point for some odd reason. (That probably has something to do with that thing you said about vbsp.)
However, if you actually provide an instance, the compiler will not be able to find any materials (and possibly other things) in your main map, and you'll get a bunch of early compile errors like these:
material "brick/brickfloor001a" not found.
Material not found!: BRICK/BRICKFLOOR001A
ConVarRef mat_reduceparticles doesn't point to an existing ConVar
VIS will then fail, but even though Hammer fails to compile a map, it will still load an older version of it (if available), so whether or not the actual instancing would work, is both unknown and irrelevant: It won't show up in-game.
I've tried to instance both simple worldbrushes to precompiled levels, so this is pretty conclusive: It doesn't work (at least for the Half-Life 2: Episode 1 engine).
What's worse, is that even though you remove the func_instance from your map, Hammer still won't be able to find the materials of your main map, refusing to compile any maps until you restart Hammer.
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) 21:01, 13 February 2011 (UTC)
My guess is that instancing support exist in Hammer only at present and not in the compiling tools (at least it doesn't work, even though there are some strings in the vbsp.exe that let assume that Valve tried to add support for it). Since the recent engine update, all HL2+episode games are using Source 2009, so this problem is not just limited to EP1.
A func_instance entity shouldn't exist in the compiled BSP at all, even L4D2 and AS would display this error message if the compiler fails to compile instances properly. And yes, I know you can manually enter the path to an instance without using the dialog window, but it's really painful (heh, Gabe's words :D) and should be fixed, of course. --Barracuda 12:47, 14 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)

(Portal 2) I have 2 doors, each into 2 identical instances. With one door and one button, everything works correct, but when using two it does not work. One button suddenly controls both doors. The buttons should send an output to each door inside the instances. All names in my main map are different from each other (1 and 2), except the names inside the instance. Is this the problem? If so, how to fix this? Thanks in advance! --StephenB 19:58, 19 May 2011 (UTC)

Nevermind, I have studied the trust_fling map: I have to trigger a proxy_relay inside the instance which triggers the door instead of immediately trigger the door through the instance. Also, outside the instance, I have to use proxy_relays in between the button and the instance. I believe this is a bug, but I'm not sure as I'm not too familiar yet with instances. --StephenB 12:23, 21 May 2011 (UTC)