@kariko: interesting, thanks for sharing, now let's see if I can get some stuff done in there

kariko wrote:
We have enough slots for four new instances (replacing companion cube, sphere, franken, and relfective).

You could also put one in the laserfield slot, seeing as you can right-click on a fizzler and change type.

If I were to use a custom element (not one used in the game), and place it into the palette, would the Puzzle Creator pack all the necessary files? I remembering Lp mentioning that to use her death fizzlers in a custom map, the textures would need to be packed in also. So the question is if the Puzzle Creator can pack extra files if needed.

Ethaksus wrote:
If I were to use a custom element (not one used in the game), and place it into the palette, would the Puzzle Creator pack all the necessary files? I remembering Lp mentioning that to use her death fizzlers in a custom map, the textures would need to be packed in also. So the question is if the Puzzle Creator can pack extra files if needed.

Pretty sure no.

Nice going here! I already have a few ideas in the works for some handy additions to the editor.

During the last few weeks, I have slowly dissected and documented a fair amount of this file. I haven't talked much about it yet, but now is probably as good a time as any to throw it out there and see what you guys can do with it.

I didn't know of that Steam forum thread and I haven't fully read it yet, so there may be a fair amount of repeating. Also the writing is a bit sloppy as this text has mainly served as notes for myself, but I reckon it's readable enough.

Incoming!
||```
Item attributes:

ItemClass: defines built-in behaviour such as catapult / target pairing,
           fizzler auto-extend etc.

Type: name of this item as referenced in p2c files

---

Editor: subsection for how it behaves in the editor
   
    sub-items:
   
    MovementHandle: how the item can be positioned inside a voxel

        possible values (example items in parentheses):

        HANDLE_NONE: position is fixed (floor button)
        HANDLE_4_DIRECTIONS: rotate 4 ways (switch, glass)
        HANDLE_36_DIRECTIONS: rotate in 10dg increments (turret)
        HANDLE_8_POSITIONS: 4 horizontal, 4 vertical (lights)
        HANDLE_6_POSITIONS: similar to 8, but item is placed in the center
                            instead of at 1/4 and 3/4 (light bridge, fizzler)

        HANDLE_5_POSITIONS: center and 4 edges (all laser props)
            (Not suitable for custom items: there need to be two paired item
             types, one for the center and one for the edges.  These pairings
             are hard-coded in the editor.)

        HANDLE_CATAPULT: catapult trajectory
            (Also obviously not suitable for custom items.)
   
   
    SubType: variations on one part (buttons, gels, ...)
        at least one SubType block is required per item type, even if it does
        not have multiple types.

        sub-items:

        Name: name of item as displayed to the user (can be any text)

        Model: appearance in the editor
               can be present more than once for certain ItemClass types
            sub-items:
            ModelName: name of model to show in the editor.  3ds extension is
                       ignored, as this must be an mdl file inside
                       models/props_map_editor.
                       There is a selection_name.3ds, which is used for
                       detecting when the user clicks on the object.
                       (It's like a vphysics mesh in the normal game.)
            TextureName: name of texture; obsolete as the mdl file already
                         refers to a texture.

        Palette: position on the parts list
                 (non-placeable items don't have this)

            sub-items:

            Position: "<x> <y> 0" (last number must be 0 or it won't show up)
                      (speculation: different tabs besides the one "items"?)
                      If multiple items specify the same position,
                      the last one takes precedence.
                      (i.e. just add you custom stuff to the end of the file
                       and it will replace built-in items)

            Tooltip: text shown at the bottom of the parts list when this item
                     is selected (Like Name, you can put any description you
                     want here.)

            Image: image in the parts list, from
                   materials/models/props_map_editor

        Sounds: various sounds that play when handling this item

        Animations: TODO: investigate
            (not needed for a part to play its "explode" animation when
             selected.  Defining the animations in the mdl is enough.)

    SubTypeProperty: property that enables selection of sub-type via rclick.
                     Value is position of SubType in list, starting from 0
                     Only works with an ItemClass that is designed to do this,
                     and the number of choices and their names are not
                     customisable AFAIK.

    InvalidSurface: indicates invalid orientations: CEILING; WALL; FLOOR
                    (multiple flags can be combined)

    CanAnchorOnBarriers: set to 1 to allow placement on glass or grating
                         (cubes, turret)

    CanAnchorOnGoo: set to 1 to allow placement above goo
                    (only the cubes, currently)

    OccupiesVoxel: set to 0 to indicate that this item does not prevent
                   placement of other stuff in the same voxel
                   (glass, catapult target)

    Copyable: set to 0 to prevent clone-dragging of this item (exits etc.)

    Deletable: set to 0 to prevent deletion of this item (exits, but also
               resizing widgets, which seem to be separate items)

    DesiredFacing: item prefers certain orientations (bridge, fizzlers)

    PseudoHandle: not sure; all resizing widgets seem to have this

    RenderColor: Unknown, as of now.  (Only the catapult target has it.)

---

Properties: item-specific properties.

    Standard properties that will work on any item regardless of class:

    TimerDelay and TimerSound: places a time selection widget on the rclick
    menu for setting time.
    (TimerSound is set to 0 if selection is "infinite"?)

    ConnectionCount: will report the number of incoming connections to
    the map instance for this item.  Used by instances to set MaxLegalValue
    on a counter inside the instance vmf, so they only work when all incoming
    signals are activated.

    StartEnabled: places a "Start Enabled" menu item on the rclick menu.
    TODO: there are similar properties named StartDeployed and StartOpen.
    I haven't checked whether these are class-specific or not.

---

Exporting: various settings for exporting an item to vmf

    sub-items:

    InstanceNames: one or more vmf files; function of each file seems
                   predefined by item class
                   generic behaviour is to put the first instance in the map
                   at the indicated position and orientation

    TargetName: base targetname for instances; gets number appended to make
                unique targetnames
                probably a good idea to keep this unique across items

    Inputs, Outputs: specifies which inputs and outputs the instance for this
                     item uses.  Specifying either of these for a standard
                     item will enable the rclick menu option for connecting
                     to other items.  Items are allowed to specify both an
                     input and an output in order to act as a relay.

                     Sub-items name the type of connection.  The only
                     connection type supported on standard items is
                     CONNECTION_STANDARD.  (You can't make up your own
                     connection types, unfortunately.)

                     Any item defining inputs or outputs must have a
                     ConnectionPoints section to specify where the antlines
                     attach.  (Failing to provide this will result in
                     a disabled "connect" menu item.)

    Offset: offset of the inserted instances from the lower-front-left corner
            of the voxel.  Everything except the entry and exit doors has this
            set to "64 64 64" i.e. the center of the voxel.

    OccupiedVoxels: defines the space taken up by the item in the map.
       
        sub-items: one or more "voxel" entries.

        voxel attributes:
            Pos:    relative position where "0 0 0" is the anchor location
                    of the item
            Surface: addresses one side of a voxel.  (See below.)

            CollideType, CollideAgainst: Distinguishes between different types
            of objects, so that certain objects only collide with certain
            other objects.  I haven't looked at this much but it seems pretty
            straightforward.

        surface attributes:
            Normal: designates one whole side of a voxel.
                    The value is the vector of the surface normal
                    pointing inwards (e.g. bottom = "0 0 1", top = "0 0 -1")
            Pos: designates a 32x32x32 cube inside the voxel at the given
                 coordinates (range 0 ~ 3)

            These two properties can be combined to designate a 32x32 square
            on one side of a voxel.  (See the pedestal button for an example.)
            I have no idea how this is different from just addressing the
            sub-cubes directly, without the normal.

    EmbeddedVoxels: Defines the space taken up behind the surface the
                    item is mounted on.  When exporting to vmf, the editor will
                    build a hollow shell around the indicated area, consisting
                    of 128x128x4 trapezoid shapes.  These serve as chamber
                    walls, floors or ceilings for any areas that border on open
                    parts of the map, instead of the regular solid blocks
                    generated elsewhere.  Any surfaces that border on voxels
                    designated as occupied by the item, will be left open.
                    (But see "EmbedFace" below.)

        sub-items:

        Voxel: coordinates of an occupied voxel, like for "OccupiedVoxels",
               except that "0 0 0" is the voxel behind the item's anchor
               location, inside the wall.

        Volume: designates the entire block between Pos1 and Pos2 as occupied.
                (See entrance and exit doors, for example.)

    EmbedFace: Used to close any openings left because the instance is smaller
               than 128x128.  (Example: lasers.)

        sub-items: one or more "Solid" entries, each of which creates one
                   rectengular tile around the base of the instance.

            Attributes:

            Center: location of the center relative to the bottom-left corner
                    of the face, in map units.
                    TODO: meaning of Z coordinate?

            Dimensions: width and length of the solid; Z seems to be ignored
                        and is always 4.

            Grid: which tile texture to use on the chamber-facing side;
                  options are 2x2 and 4x4.  (The colour will match the portal /
                  nonportal setting of the surface.)

    ConnectionPoints: defines locations where the antlines attach to the item.
       
        sub-items: one or more Point entries, with these attributes:

        Dir: incoming line direction: left to right is "1 0 0", top to bottom
             is "0 -1 0" etc.

        Pos: point on an 8x8 grid inside the voxel, where the line terminates.
             (Z coordinate is always 0.) (Each grid cell is 16x16 map units.)
             "0 0 0" is the lower-left corner.  Coordinates outside the voxel
             continue on whatever surface makes sense in that direction.

        SignageOffset: a second point in the same grid.  This point, together
                       with "Pos", must mark a 2x2 block (32x32 map units) area
                       where a checkmark or timer display will be placed.

        Priority: connections with priority 0 are used first, then 1, etc.

        GroupID: unknown at this time.
```||

@Ethaksus: No, it will not pack custom files. You will still need to do that manually.

Anybody else run into the phantom-killer bug?

For some reason, in this one room, there seems to be a set location (usually a horizontal line about 3 blocks down from the roof) that insta-kills you as you fly through it. It moves around with each compile, and I can't tie it to any one change yet.

madcat1030 - Do you have two bodies of water on separate floors, one directly above the other at any point? There's a bug with that which causes them to be linked by an invisible death field. Valve are reportedly working on a fix, but in the meantime the only solution is to move the water pools so they don't overlap or else replace one with laser fields.

Ah, that explains why it was moving with some other rooms. Alright, thanks for the info. Extra weird, because I have overlapping pools in two places, and only one of them was making the death field.

Valve just rolled out an update that fixes that bug, among others.
Also, if you export to vmf with puzzlemaker_export, it will now start correctly (i.e. in the elevator) and not loop around when you reach the exit.

Mr. Happy wrote:
The Build Process
As I mentioned above, the PeTI editor works with .p2c files (see below for file format documentations). When you click build this is what happens:
1. .p2c file is converted to a .vmf placed in steamapps/common/portal2/sdk_content/maps/ . This file is called preview.vmf
2. the preview.vmf file is compiled using vbsp, vvis, and vrad as normal with these settings:

vbsp.exe: -entity_limit 1750
vvis.exe:
vrad.exe: -final -staticproppolys -staticproplighting -textureshadows -hdr
(thanks Robdon)

Hello, good morning.

I am looking for ways to eliminate the limitation of the compiler of the "TPI" for 1750 items and it still fails.

Anyone know how to raise that amount or cancel?

• my maps need twice as minimum xDDDDDDD

Thank you.

carlymx wrote:
Mr. Happy wrote:

The Build Process
As I mentioned above, the PeTI editor works with .p2c files (see below for file format documentations). When you click build this is what happens:
1. .p2c file is converted to a .vmf placed in steamapps/common/portal2/sdk_content/maps/ . This file is called preview.vmf
2. the preview.vmf file is compiled using vbsp, vvis, and vrad as normal with these settings:

vbsp.exe: -entity_limit 1750
vvis.exe:
vrad.exe: -final -staticproppolys -staticproplighting -textureshadows -hdr
(thanks Robdon)

Hello, good morning.

I am looking for ways to eliminate the limitation of the compiler of the "TPI" for 1750 items and it still fails.

Anyone know how to raise that amount or cancel?

• my maps need twice as minimum xDDDDDDD

Thank you.

Hammer.

I've been experimenting with adding custom items to the editor, and I thought it would be worthwhile to share some of it, as an example.

Included are:
- auto-save trigger;
- portal magnet (an info_placement_helper with "force orientation" turned on, so you can flip portals sideways or upside-down);
- an alternative light source that emits a warmer light than the default panels and office windows;
- logic gates.

None of these use any custom models or textures, so you can still publish maps straight to the workshop from within the editor. (The included models and textures are just for the editor icons, they are not needed to play maps.)

Please read the included readme.txt!

HMW wrote:
Stuff

I tested it out, it seems to override current items in the palette.
and when I tested it out in the maker, it says there was an error building the puzzle.
but these are still great instances, I can use.

lpfreaky90 wrote:
carlymx wrote:

Mr. Happy wrote:

vbsp.exe: -entity_limit 1750

Hello, good morning.

I am looking for ways to eliminate the limitation of the compiler of the "TPI" for 1750 items and it still fails.

Anyone know how to raise that amount or cancel?

• my maps need twice as minimum xDDDDDDD

Thank you.

Hammer.

Thanks but we already know. xDDD
I mean in the game, a configuration file or something ...

spongylover123 wrote:
I tested it out, it seems to override current items in the palette.
and when I tested it out in the maker, it says there was an error building the puzzle.
but these are still great instances, I can use.

Yes it does replace things in the palette. It's the only way because it's not possible to increase the size of the palette.

I'm curious what caused your compile to fail. Do you know if it's one particular element? They all work ok for me so far.

Edit, @carlymx: I just searched the entire Portal 2 folder for "-entity_limit 1750" and came up with nothing useful. I'm afraid that this is hard-coded.

Edit 03/06/2012: updated!

i don't know either, I added everything that you included.
and the compile fails.

-entitylimit is a special parameter for the compiler for the puzzle maker to not add too many things.
there was a bug if you added to many things to the maker and compile...... (can't say the bug name)
then a crash engine error.

HMW wrote:
I've been experimenting with adding custom items to the editor, and I thought it would be worthwhile to share some of it, as an example.

Included are:
- auto-save trigger;
- portal magnet (an info_placement_helper with "force orientation" turned on, so you can flip portals sideways or upside-down);
- an alternative light source that emits a warmer light than the default panels and office windows;
- logic gates.

I haven't had any problems with compiling using these new elements, but I had some problems with the way they work.

If the new light is placed on a portable surface, you can portal through (behind? over?) about half the light. I don't know if you have any control over this behavior, though.

The autosave only seems to work the first time a player moves onto the autosave square. Subsequesnt visits to that square don't override the first save.

Other than that everything else worked great for me. Thank you for taking the time to make these.

HMW wrote:
I've been experimenting with adding custom items to the editor, and I thought it would be worthwhile to share some of it, as an example.

Included are:
- auto-save trigger;
- portal magnet (an info_placement_helper with "force orientation" turned on, so you can flip portals sideways or upside-down);
- an alternative light source that emits a warmer light than the default panels and office windows;
- logic gates.

Hi HMW,

download and used. Works perfectly well. Created a map with all original stuff, swapped the editoritems.txt to your version and finalized the map beautifully (posted as 'Sunbury Chambers 001').

I do believe, this concept of swapping the editoritems.txt is great for the Puzzle Maker and could be enhanced with further addon versions.

Thanks for that. Awesome hack, mate.

HMW wrote:
spongylover123 wrote:

Edit, @carlymx: I just searched the entire Portal 2 folder for "-entity_limit 1750" and came up with nothing useful. I'm afraid that this is hard-coded.

I think its hard coded into client.dll.

If you 'strings' client.dll, then search for 'entity_limit' the entry before it is 1750. So I recon its in there.

Looks like vbsp.exe also has a limit to what it can be set to. Seems to be between 32 and 2048 and generates an error if its above 2048:

VBSP: invalid value for '-entity_limit' (9999), use a value between 32 and 2048

You can also see a few bits about the limits here:

https://developer.valvesoftware.com/wiki/Entity_limit

RogerL wrote:
I haven't had any problems with compiling using these new elements, but I had some problems with the way they work.

If the new light is placed on a portable surface, you can portal through (behind? over?) about half the light. I don't know if you have any control over this behavior, though.

That is hard to prevent, unfortunately. I put a func_noportal_volume over the light to minimise the chance of this happening, but it can still happen.

RogerL wrote:
The autosave only seems to work the first time a player moves onto the autosave square. Subsequesnt visits to that square don't override the first save.

That's correct. Most autosaves in the main game work like that, so I decided to stick with this behaviour. (Remember you can always edit the instance if you want one that works multiple times. Just replace the autosave trigger with a trigger_multiple + logic_autosave.)

RogerL wrote:
Other than that everything else worked great for me. Thank you for taking the time to make these.

Thanks!

@spongylover123: Hmm... For a moment I was worried that I forgot to pack something, but for other people it works, apparently. I honestly have no idea why it won't work for you.

@BierPizzaChips: Cool! Is your map published yet? I can't find it on the workshop.