[Release] Common Prefabs for Portal (CP4P) version 1
UPDATE: Version 1 released
dload.php?action=file&file_id=139
[I'm a relatively novice mapper (but I'm familiar with mapping concepts -- I've "tinkered" with Quake maps once upon a time and am a quite logic-minded person), but my inner programmer wasn't entirely happy with the quality of the few good sets of prefabs for Portal that I've found, so I'm working on creating my own set for eventual release.
Well, "my own" is not 100% true. A good portion is derived from official Valve maps, or some from existing prefab packs. The major difference is that I've tried to clean things up to be consistent, usable, and with very little unneeded fluff. (There's nothing worse than inserting a prefab and then spending 10 minutes stripping it down to what you really wanted.)
So, I've been compiling and cleaning up prefabs for eventual release (including a test map). The idea is:
- They're all documented. Instructions should be clear as to exactly how to integrate the prefabs with an existing map.
- They all place nicely together.
- They all use 'sane' entity names when entity names are required, with &i to instance them properly. (A lot of prefabs use tutorial names or are lifted straight from Valve maps with names like "ball_catcher_rm7")
They aren't ready for release yet, but a snippet of the documentation is attached to give an idea of what is included. The short list:
* Self-contained room with standard one-instance-only components for a level (Aperture_AI, water_lod_control, templates for cube spawners, filters, etc.) to be placed out of the world.
* Big Button
* Round Door (wide and normal versions)
* Ball launcher and catcher. (Waiting for permission from youme to release the latter.)
* Switches/little buttons. Four versions exist: Timed, Timed Refreshable (can restart the timer by reactivating the switch), Simple, and Toggle.
* Box droppers.
* Storage/Companion Cube models with appropriate names to work with other CP4P prefabs.
Not yet documented:
* Door state sign. (Create connecting indicator overlays with the same name)
Not yet prefabbed:
* Toxic goo.
Planned:
* Working elevator.
* Non-working elevator. (For decoration at the start of a level without the overhead).
* Lifts
* Unstationary Scaffolds
* ... whatever else makes sense.
I'd like to eventually make this a community project but with some level of quality control to ensure that everything keeps the same quality as I hope the existing prefabs have. If you'd like to make any contributions I'll accept them at some point assuming you don't mind me editing them mercilessly, just let me know how to give you credit in the documentation. 
(I'm not accepting contributions yet, as I'd like to get an initial release out first so people can see the general style of the existing setup).
Apparently I can't attach a txt file for the aforementioned documentation, so here it is:
- Code: Select all
CP4P - Common Prefabs for PortalThis is a set of prefabs intended for creating common gameplay elements in Portal.
They are designed with the following in mind:
* Easy alignment to the grid (when feasible)
* No excess baggage
* Consistent naming scheme designed to not conflict with other entities not related to CP4P
* All prefabs are documented.
* Prefab origin makes sense.Most named entities use a naming scheme that is:
* Instance-able. Most named entities use &i somewhere in their name so multiple copies can coexist. Exceptions may exist for entities that should only need to exist once per map, or where multiple entities with the same name is acceptable.
* Named to not conflict with existing entities. All entity names begin with "CP4P_" (and expect similiar)
* Work with wildcards in such a way where additional components of a prefab will not inadvertently be affected as well.Prefabs try to designate a minimal set of entities for communication with 'the outside world'. For instance, a multipart door only requires a single set of inputs (one to open and one to close) to a single connection point, rather than having to instruct each side of the door to open/close individually.
About &i:
Hammer allows prefabs to use "&i" in entity names. This is a token that will be replaced by a unique number when the prefab is inserted in a map, which allows multiple copies of a prefab to coexist peacefully without stepping on each other's entity names.All CP4P prefabs use &i tokens on named entities, except for those which should only exist once per map (such as those created by the "Common CP4P Dependencies" prefab.)
=====Common CP4P Dependencies=====
Description:
This is a small set of common entities required by other CP4P prefabs (among other things). All of the entities are in a sealed nodraw room that is intended to be isolated from the rest of the world.
Included here is:
* CP4P_filtercubes - a filter_activator_name that filters for boxes. Used by big buttons to ensure the object sitting on them is, in fact, a cube (as opposed to a camera or turret or other physics object).
* CP4P_filterballs - A filter_combineball_type that filters combine energy balls. Used for proper functioning of ball catchers.
* CP4P_cube_storage and CP4P_template_cube_storage - A weighted storage cube and a template used to spawn it. Used for box droppers.
* CP4P_cube_companion and CP4P_template_cube_companion - A weighted companion cube and a template used to spawn it. Used for box droppers.
* Aperture_AI - A generic_actor used to make GLaDOS speak in your levels, as documented at http://developer.valvesoftware.com/wiki/Making_GLaDOS_speak
* An unnamed water_lod_control should you use water or slime in your level, built with default values.
Source:
Various, but mostly built from scratch by Dewin.
Usage:
* Place one (and only one) instance of this prefab in your level. There is no need for multiple instances, regardless of how many CP4P prefabs are used.
* You may delete unused components. For example, a level with no energy ball catchers does not require CP4P_filterballs.=====Ball Launcher=====
Description:
Ball Launcher, a producer of high-energy pellets.
Source:
Test Chamber 13 (decompiled with VMEX) used as a reference.
Modifications for CP4P by Dewin.
Dependencies:
none
Usage:
* Insert in map and rotate as desired.
* Make sure CP4P_launcher_&i points the correct direction... sometimes it isn't rotated when the rest of the group is.
* Adjust the other attributes of CP4P_launcher_&i as needed (respawn time, minimum lifetime, lifetime after portal transition, etc.)=====Ball Catcher=====
Description:
Ball Catcher, as seen as the ultimate destination of an high-energy pellet.
Source:
"Portal Prefab Pack" created by Youme -- http://forums.thinking.withportals.com/dload.php?action=file&file_id=19
Altered for CP4P by Dewin.
Dependencies:
* CP4P_filterballs
Usage:
* Place at desired location. You may delete or retexture the backing brushes, however, be sure to keep a 32x32x8 'hole' behind the catcher -- source: http://developer.valvesoftware.com/wiki/Creating_an_energy_ball_launcher_and_catcher#See_also
* Add desired OnTrigger outputs to the trigger brush (CP4P_catcher_&i).=====Big Button=====
Description:
A big floor button ("Aperture Science 1500-Megawatt Supercolliding Superbutton") that can be activated by a storage cube or the player.
Source:
Derived from testchmb_a_05. Modified for CP4P by Dewin.
Dependencies:
* CP4P_filtercubes
Notes:
* Regular portal maps (at least testchmb_a_05) have buttons on a platform slightly raised above the rest of the floor. This platform is included in the prefab, but may be deleted if not required. (It also serves to ease grid alignment.)
* The platform in regular portal maps has four overlays (one on each corner) for aesthetics. These overlays are not present on this prefab, as Hammer has issues inserting prefabs with overlays and maintaining proper rotation.
Usage:
* Create "OnOpen" and "OnClose" outputs of CP4P_bigbutton_button_&i connected to entities of your choice. The CP4P_bigbutton_button_&i entity is the 'nodraw' brush directly beneath the button's top.
* OnOpen fires when the button is pushed, OnClose fires when the button is no longer pushed.
Named Entities:
* CP4P_bigbutton_sndup_&i and CP4P_bigbutton_snddn_&i - ambient_generics for button activation.
* CP4P_bigbutton_button_&i - func_door brush for button activation.
* CP4P_bigbutton_triggercube_&i and CP4P_bigbutton_triggerplayer_&i - trigger_multiples to actually activate the button when a cube or player is on it.
Troubleshooting:
* If your button activates/deactivates rapidly with nothing on it, you probably forgot to include the dependencies.=====Round Door and Round Door (wide)=====
Description:
A round door.
Source:
Derived from testchmb_a_05
Usage:
* Open or close CP4P_rounddoor_&i as needed.
* CP4P_rounddoor_&i refers to the right side of the door. The left side is automatically linked to the right side via the right side's outputs.
* You may need to adjust the func_door entity angles (CP4P_rounddoor_&i and CP4P_rounddoor_&i_left) if you rotate the door.
Troubleshooting:
* If your door does not open properly, you may need to adjust the angles of the func_door entities (CP4P_rounddoor_&i and CP4P_rounddoor_&i_left)=====Switch (Timed), Switch (Timed Refreshable), Switch (Simple), Switch (Toggle)
Description:
A small switches/button (func_button).
Multiple variations exist:
Timed: Plays a ticking sound when activated for a set amount of time, and then deactivates.
Timed, Refreshable: Like Timed, only the switch can be re-activated while the countdown is going to start the countdown over.
Simple: For a non-time-related task that might need to be triggered multiple times.
Once: For a one-time-only task, such as permanently opening a door. Switch reminds in 'down' position forever once activated.
Source:
Created by Dewin from scratch from tutorial at http://developer.valvesoftware.com/wiki/Creating_a_switch and related pages
Notes:
* Hammer does not recognize the Enable/Disable inputs on ambient_generics, and will (incorrectly) report an error about bad I/O connections when these prefabs are present.
Usage:
* Insert the desired prefab at the appropriate location.
* For Timed switches (NOT Timed Refreshable):
* Adjust CP4P_switch_&i's (the invisible brush aligned with the button) "Delay before Reset" to the desired duration of the countdown.
* Add inputs to CP4P_switch_&i's OnPressed (activated) and OnOut (out of time) outputs.
* For Timed Refreshable switches:
* Adjust CP4P_switch_&i_logic's (the topmost logic_relay) "OnTrigger !Self FireUser2" output to the desired duration of the countdown.
* Add inputs to CP4P_switch_logic&i's OnUser1 (activated) and OnUser2 (out of time) outputs.
Note: The slightly wonky implementation here avoids duplicate "Open the doors", etc. commands from being sent if the timer is reset, however, the 'switch pressed' sound will play again.
* For Simple switches:
* Adjust CP4P_switch_&i's "Delay before Reset" to the desired delay between activations. Generally, all actions activating the switch begins should be completed before the switch can be reactivated.
* Add inputs to CP4P_switch_&i's OnPressed (activated) and OnOut (out of time) outputs. The OnOut outputs are optional.
* For a one-time-only switch, set "Delay before Reset" to -1.
* For Toggle switches:
* Adjust CP4P_switch_&i's "Delay before Reset" to the desired delay between activations. Generally, all actions activating the switch begins should be completed before the switch can be reactivated.
* Add OnTrue and OnFalse inputs to CP4P_switch_&i_toggle. By default, the OnTrue inputs will fire every odd time the switch is activated and the OnFalse will fire every even.=====Weighted Storage/Companion Cube=====
Description:
A weighted storage or companion cube.
Source:
Derived from testchmb_a_05. Modified for CP4P by Dewin.
Usage:
* Place storage/companion cube where desired.
* You should consider using one of the boxdroppers instead, especially if your map offers any means of destroying the cube before the player is done using it. (Common design sense suggests maps should be solvable on the first attempt and not require a restart or reload should the player make a non-fatal mistake.)
* It is recommended that you filter based on "CP4P_cube*", which will proper trigger for all storage and companion cube instances on the map.
* If you want to filter against just storage cubes (not companion cubes), filter on "CP4P_cube_storage*"
* If you want to filter against just companion cubes (not storage cubes), filter on "CP4P_cube_companion*"
Named Entities:
* CP4P_cube_storage_&i or CP4P_cube_companion_&i=====Weighted Storage/Companion Cube Dropper=====
Description:
A box dropper for spawning multiple storage/companion cubes.
Source:
Derived from testchmb_a_05. Modified for CP4P by Dewin.
Dependencies:
* CP4P_cube_storage and CP4P_template_cube_storage, or CP4P_cube_companion and CP4P_template_cube_companion, depending on type.
* CP4P_filtercubes
Notes:
* Both prefabs are identical except for the EntityTemplate of "CP4P_dropper_boxmaker_&i". You can convert between storage and companion cubes by altering its value between "CP4P_template_cube_storage" and "CP4P_template_cube_companion", provided the requisite template exists (see dependencies)
Usage:
* On map load (or before the first box is needed), trigger CP4P_dropper_boxmaker_&i's "Spawn" event to create the initial box.
* Trigger CP4P_dropper_trigger_&i's "Trigger" event no less than 4 seconds later to allow the initial box to drop to the floor.
* Trigger CP4P_dropper_trigger_&i's "Trigger" event whenever a replacement box is needed.
* Many Valve maps delay the actual release of the inital box until a player approaches the generator by using a trigger_once to draw the player's attention to the dropper.
Named Entities:
* CP4P_dropper_boxmaker_&i - env_entity_maker to spawn cubes.
* CP4P_dropper_stopper_&i - func_brush used to hold cubes in the tube until the tube is opened.
* CP4P_dropper_trigger_&i - logic_relay used to trigger the release of a cube and spawning a replacement.
* CP4P_dropper_cover_&i - prop_dynamic animated as part of the cube replacement process. This is the tube 'cover'.
* CP4P_dropper_clear_&i - Used to signal when the box is fully clear of the dropper, which triggers the dropper to close and the next box to be spawned.
I have my own prefabs, with some extra element like the vertical door ortectuletogglers, special boxdroppers, special observ.rooms of all size. I constantly reconstructing/fixing them and using in my maps. Will check your prefab pack and send you some that not exist in yours.
I try to make my elements easily-modifiable, everrything is accessed by logic relays, but its a pain in the ass renaming the different elements after I played them, like circle_door_left_1, or with the buttons the names, parentnames, and events.
I planning to make a small program hat auto-change the prefab numbers before inserting. Something like this:
The user enters 7, selects floorbutton prefab from the list, clicks, and the program replaces the end of every targetname parentname etc that ends with _ and a number with the entered one. But I havent checked yet if the brefabs are loaded from the file at Hammer startup, or only when I select and place it.
To help mappers, I've already released the full source of my 2 finished map and planning to do it with the upcoming ones too. Feel free to copy out and use anything from them. (http://heroes.hardwired.hu/-/portal/damagepy_source.zip - 3 map source included)
I just got permission from Youme, so as soon as I add some finishing touches, create a change history and make a quick level showing the all of the prefabs working together to show they really do work.
Very nice. I've been trying to put together my own set of prefabs, and it's good to see I'm not the only one who's had trouble with angles and overlays (in the round door and superbutton, respectively). I'm going to assume that's just a limitation in Hammer's prefab utility, unless anyone can suggest a solution....?
Anyway, good luck with the rest of this, though it seems simple enough that you shouldn't need luck.
gepy: From my own experience debugging prefabs, I can tell you that Hammer appears to copy the prefab file at insertion-time. But I'm not sure if that helps or hinders what you're trying to do with the naming. (I would hope it helps.)
Hammer is already capable of incrementally naming prefabs upon insertion, provided you use a naming token.
A special token "&i" can be added to the name of entities in prefab objects so the entity will have a unique name when placed in the level. When the prefab is placed, the &i token will be replaced by a unique number. The token can be included in the targetname, inputs and outputs, etc. All tokens in the prefab will be replaced with the same number. This allows entities in the prefab to reference each other, but still have a unique name so multiple prefabs won't trigger each other.
For example, a func_door entity with the name "door_sliding_&i" in the prefab would become "door_sliding_1" when placed in a level. Consecutive placements of the prefab would be called "door_sliding_2", "door_sliding_3", ...
A trigger_multiple included in the same prefab, with the name "trigger_sliding_&i", would share the same token number and be renamed "trigger_sliding_1", "trigger_sliding_2", "trigger_sliding_3", ...
That's one of the major reasons behind this
Most of the other prefabs out there do not. 
Well I'd be looking forward to the prefabs.
Can we use them in the January challenge?
== John ==