Talk:Func instance: Difference between revisions

From Valve Developer Community
Jump to navigation Jump to search
(Apparently all I've written may be false. Who knows? Who cares? I don't.)
(redid the experiments. Sorry for the tantrum. Func_instance doesn't work, but at leat I got some detailed errors out of it.)
Line 3: Line 3:
::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.) --[[User:MossyBucket|MossyBucket (formerly Andreasen)]] 20:12, 12 February 2011 (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.) --[[User:MossyBucket|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. --[[User:Barracuda|Barracuda]] 04:17, 13 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. --[[User:Barracuda|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). --[[User:MossyBucket|MossyBucket (formerly Andreasen)]] 12:41, 13 February 2011 (UTC)
::::After some exhausting testing, I've arrived at this conclusion:
::::Here's an update: Apparently the game ''continued'' to display the error about not knowing which game it was, until I restarted Hammer once more, but it still executed an ''old'' map in-game, so I didn't notice it for awhile, so all my compiles since this error occured (somewhere after [[func_instance]] broke my VIS), have been lost.
::::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:
::::What this means is that all compiles since my first instance experiments, and all my conclusions from them (like whether or not simple compiled worldbrushes can be instanced, or whether or not a simple previous compiled brush level works) ''are not valid''. ...so it's theoretically possible that instances ''still'' work outside of L4D2 and Alien Swarm, but at this point I don't care. I'm done with having these experiments breaking my engine whether they work at some basic level or not. --[[User:MossyBucket|MossyBucket (formerly Andreasen)]] 19:29, 13 February 2011 (UTC)
::::If it's just an ''empty'' [[func_instance]], the map will compile, but you'll get the in-game console red error:
::::<code>Attempted to create unknown entity type func_instance!</code>
::::<code>Can't init func_instance</code>
::::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, you'll get a bunch of early compile error like these:
::::<code>material "brick/brickfloor001a" not found.</code>
::::<code>Material not found!: BRICK/BRICKFLOOR001A</code>
::::<code>ConVarRef mat_reduceparticles doesn't point to an existing ConVar</code>
::::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).
::::--[[User:MossyBucket|MossyBucket (formerly Andreasen)]] 21:01, 13 February 2011 (UTC)
 





Revision as of 14:01, 13 February 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, you'll get a bunch of early compile error 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)


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)