Forum | Thinking With Portals

#1 · April 29, 2011, 5:39 pm

Does VHE manage to extract prefabs from a current title?

I'm wondering where everyone gets their prefabs from, otherwise. I see them posted on an individual basis at the resources sites mentioned. Is there a basic Portal 2 prefab library that can be loaded into VHE?

Yes, I'm completely new to this, but I need to a pointer in the right direction so I can educate myself. :wink:

#2 · April 29, 2011, 5:50 pm

Generally there are a set of prefabs that come with the released SDK. Right now I am pretty sure that everyone is still figuring out how to use the game elements and building them by hand. Which, by the way, is a preferable method for someone new to Hammer so that you can actually learn how things work.

[Important Threads] Forum Rules | Welcome to the new Thinking With Portals
Please do not Private Message me for assistance. Post a thread if you have questions or concerns.
If you need to contact the staff privately, contact the Global Moderators via Discord.

#3 · April 29, 2011, 5:56 pm

Yeah I've already put together a few prefabs for recessed lighting and chamber doors

#4 · April 29, 2011, 6:18 pm

The new Portal 2 Source SDK isn't due out until this summer, or so I've read, which means that folks have been building these Portal 2 custom maps with the previous Source SDK, I presume

#5 · April 29, 2011, 6:22 pm

There has been no official statement on the SDK's exact release. People have been using the Alien Swarm SDK. There are a few threads around, take a look and it will get you started.

[Important Threads] Forum Rules | Welcome to the new Thinking With Portals
Please do not Private Message me for assistance. Post a thread if you have questions or concerns.
If you need to contact the staff privately, contact the Global Moderators via Discord.

#6 · April 29, 2011, 6:52 pm

zanthal wrote:

The new Portal 2 Source SDK isn't due out until this summer,

We should probably edit that thread title to remove the

"Games are made out of smaller games ? turtles all the way down, until you hit the game that is so trivial and stupid it isn?t deserving of the name." --Raph Koster

#7 · April 29, 2011, 7:04 pm

Yeah good idea. Also I added that as a real emote here.

[Important Threads] Forum Rules | Welcome to the new Thinking With Portals
Please do not Private Message me for assistance. Post a thread if you have questions or concerns.
If you need to contact the staff privately, contact the Global Moderators via Discord.

#8 · April 29, 2011, 8:22 pm

Quote from Dewin on April 29, 2011, 8:22 pm
In many cases, the new instancing system based on func_instance, func_instance_io_proxy and func_instance_param is a superior alternative to prefabs. In fact, it's used extensively in the official Portal 2 maps.

func_instance basically is an editor-only entity that basically says "Insert this VMF here during compilation and apply a couple modifications". You can even have multiple people working on separate parts of the map at the same time using instancing. func_instance_param and func_instance_io_proxy are used in the child VMF to set parameters you can change.

Say you make a box dropper. You've put a couple in your map(s) and then someone finds some sort of logic error. With prefabs, you'd have to go find every place you've inserted it and fix the logic error. With instances, you just open Boxdropper.vmf, fix the error, and all of your maps will get the fixed version next time they're opened/recompiled.

There are a few drawbacks to instances however:
* They aren't as customizable as prefabs. You can't, for instance, retexture one copy of an instance to be different from other copies. (That said, you can have individual control over just about any entity property using func_instance_param)
* There's some Hammer-level weirdness with nesting instances, particularly in regards to func_instance_param. I expect this will be fixed soon enough however, and it may be something that you can work around. Additionally, the path to the inner instance is evaluated from the map's perspective on compilation, but from the instance's perspective in the editor. This is worked around by keeping all your instances in the same directory as your maps.

You can get around the first problem by splitting your instance into two parts. For instance, I have two instances for chamber exit doors: One is the actual door, logic and entities to open and close the door. The second is the door frame. If for some reason I want a new texture on the door frame, I just copy+modify the frame instance.

In many cases, the new instancing system based on func_instance, func_instance_io_proxy and func_instance_param is a superior alternative to prefabs. In fact, it's used extensively in the official Portal 2 maps.

func_instance basically is an editor-only entity that basically says "Insert this VMF here during compilation and apply a couple modifications". You can even have multiple people working on separate parts of the map at the same time using instancing. func_instance_param and func_instance_io_proxy are used in the child VMF to set parameters you can change.

Say you make a box dropper. You've put a couple in your map(s) and then someone finds some sort of logic error. With prefabs, you'd have to go find every place you've inserted it and fix the logic error. With instances, you just open Boxdropper.vmf, fix the error, and all of your maps will get the fixed version next time they're opened/recompiled.

There are a few drawbacks to instances however:
* They aren't as customizable as prefabs. You can't, for instance, retexture one copy of an instance to be different from other copies. (That said, you can have individual control over just about any entity property using func_instance_param)
* There's some Hammer-level weirdness with nesting instances, particularly in regards to func_instance_param. I expect this will be fixed soon enough however, and it may be something that you can work around. Additionally, the path to the inner instance is evaluated from the map's perspective on compilation, but from the instance's perspective in the editor. This is worked around by keeping all your instances in the same directory as your maps.

You can get around the first problem by splitting your instance into two parts. For instance, I have two instances for chamber exit doors: One is the actual door, logic and entities to open and close the door. The second is the door frame. If for some reason I want a new texture on the door frame, I just copy+modify the frame instance.

#9 · April 29, 2011, 9:33 pm

Thanks for the helpful tips. :-)

I'm still scratching my head, trying to understand that if you can edit maps for Portal 2 with Alien Swarm's Source SDK, then what other Source SDK's can you use that are compatible?

#10 · April 30, 2011, 1:17 am

I'm almost thinking they used Alien Swarm to run this on because not many people use it, therefore most people wont mind modifying it to make it work with Portal 2. If they used a more popular one, say CS;S, many people wouldn't like it because it would interfere with them making CS:S maps.

But this is just :baselessspeculation: so feel free to ignore.

Prefabs