Puzzle Creator Tech Info, Hacks, and Laughs
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 
Other Portal 2 maps: Medusa Glare
Portal 1 maps: Try Anything Twice | Manic Mechanic
Thanks!
And that sounds like a very cool idea. Maybe we should add those comments into the worldspawn of each P2Editor instance.
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:
- Code: Select all
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.)
Other Portal 2 maps: Medusa Glare
Portal 1 maps: Try Anything Twice | Manic Mechanic
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:
(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.)
Other Portal 2 maps: Medusa Glare
Portal 1 maps: Try Anything Twice | Manic Mechanic
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.