FelixGriffin wrote:
EDIT: I've been working on adding in new test elements, like the breakable glass. HMW, do you mind if I include your Sendificator? A modified copy of the script for it could also disable an entity which would otherwise display something like "You need the sendification script from (URL)".

Sure, go ahead! Keep in mind that you also need to modify the laser instances (both of them) so they can send sendificator tracers.

I do have doubts about that fallback construction though! Showing that to players when they download a map from the workshop, and ask them to download a separate package would not be acceptable IMO. If you're going to do this, then use Sicklebrick's packer thing with it. Looks like that would work fine!

@sicklebrick: I haven't tested this yet, but I can already think of a cool addition: a Python script or something, that sifts through the vmf and included instances, looking for markers in the entity comments that specify what custom stuff it needs.
It would then build a custom packing.txt list for that particular map, so it only packs assets for things you actually use. Nobody likes bloat

Thanks!

And that sounds like a very cool idea. Maybe we should add those comments into the worldspawn of each P2Editor instance.

HMW wrote:
@sicklebrick: I haven't tested this yet, but I can already think of a cool addition: a Python script or something, that sifts through the vmf and included instances, looking for markers in the entity comments that specify what custom stuff it needs.
It would then build a custom packing.txt list for that particular map, so it only packs assets for things you actually use. Nobody likes bloat

I've been considering building it right into the program itsself (I've included the C# source in the download btw), but I'm back at work this week, so it's baby steps
One thing I'm determined to change though is to make the build process and toolchain flow take place after the BSP was created (but before vrad, etc). I.e. allowing the user to load a map and edit it like pakrat or alter the pack list during a build. I think that way would be the least intrusive and most useful I've yet to decompile pakrat and figure out how it knows which files are loose and which are .gcf.pak content though. Any ideas?

My guess would be that it knows how things like textures and models look inside the bsp, builds a list of anything it finds and then matches that against some "official assets" list that is either built in or read from the game files.

I really think it would be easier to invent some sort of referencing mechanism for use in instance files. After all, you'd expect the creator of an instance to know what custom stuff they used.

You could put something like this in the comment field of any entity:

fudge_pack_assets: {
models/hmw/props/sendificator*
materials/models/hmw/props/sendificator*
scripts/vscripts/hmw/sendificator.nut
}

This would include all of the sendificator-related files.
If you make the schema unique enough, it doesn't even matter where it is in the vmf; a line-by-line scan would find it automatically. (Accounting for the fact that there may be text on the same line before "fudge_pack_assets: {", and after the closing "}".)

(I like FelixGriffin's idea of using the worldspawn for this, but it doesn't appear to remember any comments.)

Heh, that's actually a pretty cool idea - not too hard to implement either.
I can think of a few problems off the bat though...
-It's easier to drag and drop files onto the editor (already implemented this)
-You'd still have to write a fair amount of stuff out manually, and I'd have to account for all sorts
-I'd probably have to add some sort of file filtering mechanism. For example, I have stuff like mynewtexture_Copy.vmt, and all my .PSD files kicking about in the same folders. Not sure if it would be quicker to filter an ignore list, or an include list for this.

Your suggestion did give me a pretty cool idea though..
Pre-make a file list, for example.
-Open fudge packer...
-Hit new file..
-Drag stuff on.
-Save as fudge1.txt
-Switch over to hammer...
-add a comment: packer:fudge1.txt
-Reads .vmf, finds fudge1, sends the contents over to BSPZip.

Then it'll autobuild the right content - or even groups of content.
Or if it's a PeTI map, just use default.txt

Maybe even a couple of extra commands, such as
packer:auto , packer:manual
To determine whether or not the packer log window pops up during builds, or will auto-close itsself.

Sounds like quite an elegant solution, huh?
Btw, the new topic's over at:

topic6692.html

Should probably limit the geeking to there before we hijack this thread

Edit:
Implemented basically all of that. Works really well, thanks!

Question: Mainly to HMW, but to anybody else who has played with his items...

How can I make a Single-pulse state changer without using a boxdropper on a button? I want two timed buttons, that when pushed within the limit, cause a gel dispenser to come on forever. I was trying to make a simple single-bit logic circuit, but I can't get it right, in my head or in the game.

Simple:

single pulse state change.jpg

(Scroll down if you don't see the two buttons.)

The topmost two gates are connected in a loop so they keep each other activated. (You can't connect a single gate to itself.)

Hello,

I have unfortunately lost my .p2c files. I have got .vmf ones thanks to a "BSP to VMF" tutorial. Is there a way to get my .vmf files into .p2c, now? I only use Puzzle editor, not Hammer. Note that I have never opened Hammer and edited my maps with it. So, it could be possible to transform it into *.p2c files! Please, help me, I do not know how to do!

Thanck you!

K_az

K_az, no it is not possible.
Also I don't know why you changed the colour of your text. Quite annoying actually

K_az, it wouldn't be too hard to write a program to do that, but it would take some work and I'm too busy. It's probably easier just to load the vmf file in hammer, or play the map in Portal 2, and recreate it in the Puzzle Editor from observation. That should be quite fast and easy, unless you have complex logic.

People may have noticed that I'm making a Style Changer mod for Portal 2's Puzzle Maker that allows you to choose a style from: 1950s, 1960s, 1970s, 1980s, Portal 1, Destroyed, Behind The Scenes, Evil Wheatley, or Clean. Then any Puzzle Maker map you preview or publish will be completely in that style, including elevators, test elements, textures, voices, ant-lines, etc. (Textures, some signs, bottomless pits, underground fizzler particle fields and antlines will not be changed for puzzle makers using a Mac though, sorry. But I tried to make it still look good without the right textures).

The idea is not to add new testing elements, just to change all existing test elements into the equivalents for that style. That way you can take any existing map and just recompile it in the new style without changing anything, and you instantly have a map that looks like it was created in Hammer specially for that style. Or you can change your mind and compile it again in another style at any time.

Other features (PC only): removed entity limit, automatically packing files (compatible with Fudge Packer), faster lighting for previews with full lighting for published maps or if you hold Shift, and you can press Ctrl+F9 to preview the map with entrance and exit elevators rather than just the puzzle. Ctrl+F9 is also needed for exporting the puzzle to Hammer, since the console command will only export the map without the changed textures.

It consists of - 3 exe files: replaced vbsp.exe and vrad.exe, and StyleChanger.exe which just shows the list of styles for you to choose and changes which editoritems.txt file to use; an editoritems.txt file for each style, and a folder of instances for each style. StyleChanger.exe also handles installation (replacing the exe files).

HMW: If you don't mind, I'm also going to make it compatible with your extra test elements.

Just so you know, you don't actually have to edit anything to edit PTI maps in Hammer. There is a built-in command for just that purpose. Simply go to the console while in the PTI editor and type portaleditor_export [mapname here]

BierPizzaChips wrote:
Say, guys, any chance to have an Angeled Panel being active 90 degrees to block a tunnel and being turn flat by activating a trigger? I am looking for something to open and close tunnels / walk throughs. But again, i am a Newbie and may miss the point. On the other had, if such a thing could be configured by a replaced editoritems.txt that would be soooo cool.

Actually, if you know how to configure hidden logic items (aka lasers and laser relays), you can put a button on the floor which opens the panel as if the player had passed through a trigger.

HMW wrote:
Out of the logic gates? Yeah, probably, as in: a row of buttons, some of which must be pressed and others not. You could then either show the wiring to the player so they can figure it out, or hide it away in a box somewhere and show the combination on a wall somewhere in huge, awesome 128x128 "pixels"

The latest update makes hiding antlines MUCH easier. It is now possible to set the visibility of the connection between two items.

I have an extremely hard time that it isn't possible to change the dimensions/tabs on the editor. I will look into this.

portal2_dlc1/scripts/ has a file called mapautocompile.txt I don't have any way to test at the moment, but it might have to do with the compiling of maps...

Boy I love the mystery of this stuff. To clarify the part about "Voxels" on HMWs wonderful guide on editoritems.txt: Voxels appear to be attached to a specific side of the voxel, which makes sense considering that the whole editor is based on attaching stuff to the geometry of the test chamber. The "Normal" parameter appears to be the normal of the face that the voxel is attached to.

EDIT: "CollideType" is the collision group that this object is in, "CollideAgainst" is the collision groups that this object is not friends with. It is important to specify voxels, and maybe even a "CollideType" even if you don't have "CollideAgainst", just for compatibility purposes.

EDIT2: If a object should take up a whole surface, instead of a 3D space based on that surface, you can leave the "Pos" out of a "Surface" element.

Hi there!
I created a new icons for HMW PTi items: http://i.imgur.com/RplTg.jpg (on the screenshot they are in a different place (1,4; 8,2; 8,3; 8,4), I like it more)
Link: http://www.mediafire.com/download.php?c5rol98e0a9b8po (sorry, I don't know how to attach files to messages)

I like those! Other-Felix and HMW, do you mind if I use these files in my PTI mod instead of the originals?

Sure, go ahead!

Those look very close to the ones I made for the next (soon to be released) version
Only the square light seems a bit too big.

Some interesting observations I made.

• If your lightstrip is ItemButtonFloor rather than ItemLightStrip, you can position it in five different positions (center being the default) rather than four, per orientation. Previously I have used this feature intentionally in my test chamber design.
• However, if you set it as ItemButtonFloor, it will not block antlines. Antlines run through it.

• Using ItemLightStrip will also always use the first instance (VMF) rather than choose instance depending on type. This means that the ButtonType selection, if any, will do absolutely nothing.

• If you use CubeType instead of ButtonType, you can use five choices instead of three. You must then also use ItemCube for ItemClass, rather than using ItemButtonFloor. You must also provide a DropperEnabled property and set it to 0, or you will get a complimentary cube dropper.

• However, CubeType does not vary depending on whether it stands on portalable or non-portalable surface. For ButtonType, you can have effectively six different options (selected on compile time), by using a different VMF file for black and white surfaces. For example, you can extend Portal1 wall this way to provide six different textures (which I did). You can download the copy here. (Note that the different walls still appear identical in the editor, because I am hoping someone else will make the in-editor models...)

I apologize if this was all common knowledge to everyone already! But by using CubeType instead of ButtonType, you can e.g. have Choreo-boxes provide 530 distinct lines instead of 330 (unless you want to play with portalable/non-portalable surfaces and get 630).
Oh, and you can also add StartEnabled ($start_enabled), AutoRespawn ($disable_autorespawn), AutoDrop ($disable_autodrop) and StartReversed ($start_reversed) inputs, to multiply the number by 16, for a total of 530*16 (2400) options. Note that with the exception of StartReversed, you can only manipulate these inputs when the Dropper is enabled. Just enable dropper, manipulate the options, and then disable the dropper.

Note that if you change your ButtonTypes into CubeTypes (and ItemButtonFloors into ItemCubes), your existing puzzles will reset to using the default option for each element that depends on ButtonType.

To recap:
- CubeType: Five options on compile-time if you set ItemClass to ItemCube. You will need to remove the complimentary cube dropper.
- ButtonType: Six options on compile-time if you set ItemClass to ItemButtonFloor. However, you only select three options with the "button type" option. The other choice between three and three comes from whether it is standing on a portalable or non-portalable surface (also on compile-time).
- StartEnabled, StartReversed, AutoRespawn, AutoDrop, TimerDelay: All of these options are evaluated by run-time logic even though they are defined at compile-time, but you can do 480 different combinations with these options.

Oh, by the way, you can place an object that can only be placed on walls, such as an observation room, in the floor, by making sure there are no walls near the left edge of the screen when you pick the element from the palette. If you are so inclined, of course. The editor will then allow placing it on the floor.

Gotcha: No matter what your MovementHandle is, when you use CubeType, for the Reflective (third option) cubes the MovementHandle is forced as HANDLE_36_DIRECTIONS.