Felix Griffin's Editor Mod (FGEMOD)
If you send me a Steam message I'll receive it before I check here. 
Check the log again.
Thanks for making this mod.
A few questions and comments:
Can we please have the source code of your .exe file? It is rather a pain to use the somewhat buggy interface that renders a character by character very slowly, and seeing that it's made in g++ and using ncurses (or pdcurses), I know I can get a much better mileage if I recompile it under cygwin and/or possibly rewrite the interface alltogether.
It would also be nice if it could automatically [when requested to] combine some components under a single palette item, such as the different light panels.
It should not offer for palette-selection those items that make no sense in the palette. I did not check whether it increments the palette slot counter if you select those items, but obviously it shouldn't.
Also, for those items that are already grouped into a single palette entry, allow separation [when requested] into multiple palette items (such as buttons or paint blobs)-- this is done by including a Palette{} structure in the different SubType{} elements of the same item.
Also, give a report and indication of how much room there is remaining in the palette, and how it is laid out. A possibility to reorder the elements would be useful.
The vacuum tubes appear rather buggy, and frankly, unusable. In comparison, Ben's vacuum type, which is a clunky fixed shape and not extensible, appears to work very nicely. And it also identifies the objects, but does not judge them. Could you not cooperate to combine the best features of both implementations?
Let me illustrate what I mean by the means of this short YouTube video: http://youtu.be/aV4GrCpXUdw
It appears that your tube's sucking power is directly proportional to the mass of the item, when it should be inversely proportional. E.g. massive objects, like a cube or the player, are easily sucked up, but light objects like the turrets, just cannot quite be taken.
Even then, the cubes tend to sort of hover and bounce around the entrance for quite a while before they, if ever, find the tube entrance.
Also, can you make the security cameras so that their position can be changed within the cube, like with the laser receivers and emitters?
Hello, Bisqwit!
1) Sure, I'll post it. The character-by-character thing is intentional, since on the old aperturescience.com site (before VALVe took it down) they mentioned that Aperture had never upgraded from monochrome dumb terminals. And you're right, it's compiled with MinGW g++ with PDCurses. NCurses should work fine too.
Here's the source: http://pastebin.com/YnbQig0M
This is actually more current than the compiled binary here, it includes a feature to remember your last palette so you don't need to start from scratch, and a simple way to support styles ($S is replaced by a folder prefix, so instances/$S/instance.vmf would become instances/p2editor/instance.vmf, instances/p2editor_old/instance.vmf, etc.)
2) I tried to combine the light strips, but for some reason it crashed the game. I have no idea why. Those should be combined, you're right.
3) It doesn't, the way the program works is something like this: when the user hits F1, add every item in the list to the editoritems.txt file (so that you can load maps containing items not in your current palette). For each item the user selected, if the string $P is found in the file, assign it a palette position and replace $P with that number. If either of those conditions are not met, put it in the first slot, behind the first selected item. This is why pressing F1 with nothing selected will put a turret in the first slot, it's the last one alphabetically in the list. If you select something without a $P, like the primary observation room, it will be the same as if you didn't select it at all.
4) That's a good idea, and it will be included in the BEE2.
5) Unfortunately that's not possible with the way I wrote the code, but it will be in the redesigned BEE2 as well.
6) Yes, I'm working to fix that. They are pretty much unusable right now, and you seem to have found the bug where a player can't enter a vertical vactube one voxel above the ground.
7) Sure, that would make sense. Do you want to reorient them or just move them around?
Right now I'm working with Ben, August, Carl, and Mevious on the BEE2, which should combine the best features of the Stylechanger, BEEMOD, and FGEMOD. You'll be able to select items for the palette with a GUI, as well as combining and separating items. Unfortunately it seems that it will be Windows-only since it uses C#.
Thanks. Combining the light strip items works without a crash when you do it like this.
1. Include the definition of ITEM_LIGHT_PANEL_WARM, but without the Palette{} structure. This ensures that existing ITEM_LIGHT_PANEL_WARM definitions continue to work in your puzzles.
2. Make the following changes into the definition of ITEM_LIGHT_PANEL:
- ItemClass becomes ItemButtonFloor
- a SubTypeProperty of ButtonType is added into Editor{}
- The SubType{}, without the Palette{}, from ITEM_LIGHT_PANEL_WARM is copied after the existing SubType{} within ITEM_LIGHT_PANEL
- Add a Properties{} structure after the Editor{} structure: ButtonType{ DefaultValue=0, Index=0 }
- In Exporting{}, duplicate the first instance ("0" becomes "0" and "1")
- In Exporting{}, copy the equivalent section from ITEM_LIGHT_PANEL_WARM as "2" and "3".
Done. Now your regular light strips have a "cube type" selection. The first option is a regular light strip, the second option is a warm light strip, and the third one is a dummy-don't-use one.
This worked for me.
It would be lovely if the third option could be the square warm light from HMW's set, but unfortunately it seems that the square warm light has different properties from the lightstrip (such as requiring one backing voxel in the wall) and cannot be combined to that.
For the cameras, just moving them around probably is enough. I don't see a reason to reorient them.
Nice to hear about your progress! I really, really, hope it does not depend on the multi-hundred-megabyte beast that is the .NET framework, which I do not have diskspace for. ... Well, at least if I eventually get the source code, I can port it to C++.
I know how to combine them, but for some reason it didn't quite work. I used the same structure that worked fine for the vactubes, but when I subbed in the instances and models it crashes as soon as I changed the type. You can experiment with the light_strip.test file, if you get it working I'll add it to the BEE2. 
And I think C# always requires .NET, but I've never used it so I don't know. I'll ask Ben.
I did, and that's what I was posting about, and I tested it once more now to confirm it works, and here it is. This replaces lightstrip.test and bee_warmlight.test .
http://bisqwit.iki.fi/kala/combinedlight.test
Thanks! I'm actually kind of surprised it works without even having the third type in there.
Will you make console version or will it work under wine?..
Is there any manual how to make your own items?
It should work under WINE, but I'll also update the FGEMOD to use the new item format since it's portable C++.
I don't think there's any sort of manual, but HMW has a description of what all the parts of the editoritems.txt blocks do, and building the item is the same as building an instance.
I used FGEMod twice, selecting the items that I want to appear; both of these times, it saved, and the editoritems.txt does show the changes. However, once in the PTI, it still shows the old BEEMod item palette, including items that I had definitely /not/ selected. 