So, the engine just does not seem to want to do this. Luckily, the reason I want to do this gives me an out.
Normally you get a switch texture and you're basically saying that if you will have a switch, it will take up an entire side. There is nothing that says your switch texture can't have switches shorter than 1/8th of a WU on a side. Lots of my textures are smaller than that. It didn't make sense with 128 pixel bitmaps, but with high-res textures you're okay there. If you work with 1024 pixel bitmaps, you're looking at 64 pixels at 1/16th of a WU, which is passable.
But maybe you don't want to keep switching scale in Weland each time you want to just pop a switch somewhere, maybe you don't want like 50 different height settings that involve dividing to 16ths? Maybe you want tiny dainty switches without the pain of tiny dainty mapping? What ultimately then ensues begins with the basic double-texture trick, where you overlay a transparent texture over another texture using a split poly. In the time honored methods of yore, one might often delete that extra polygon once everything looked nice. In this case, we're using the polygon... for reasons.
The switch texture involves some transparency. So, instead of a box shaped polygon, you can just make triangles (and those triangles can be 1/8th WU for simplicity's sake), and overlay a switch texture that may be smaller than 1/8th, and may also be any damn shape you please without needing to worry about the surrounding texture. In this example, I've used a rounded rectangle. Instead of four switch subtextures at 256 pixels each, I can do 16 that fit in a 128 pixel square. With some margin around each one to prevent bleed-thru with bump mapping, you can put an absolute butt-load of switches into one bitmap, depending on scale and so on. The switch I have here is 128x64 pixels in a 1024 pixel bitmap, so I could fit as many as 32 in one frame, assuming they're all the same size.
So, you have a switch texture, but you cannot push said switch when it is on a transparent side. The switch does nothing by itself here.
That is where our triangular polygon comes in. I've done similar stuff with decal textures. Circular, triangular, and other odd shaped signs overlaid upon varying textures. At the very least, you need to flatten that polygon to make it look right. Therefore, we know that each polygon with a decal in front of it should have zero area. You can iterate through each of the polygons and find the ones you want through .area, then. We then look for a transparent side on at least one of the lines, and make sure that said side's transparent part's texture index is less than 2 (since I'm still using the switch slots as is.) If we see all this to be good, we know our polygon with the switch does a thing.
![[MUp]](./images/smilies/13.png "marathon")
Polygons do lots of things normally, even terribly complicated stuff like turning platforms on or off. If I set my little triangular (flat) polygon to the "platform on" type, we will know that it has a permutation equivalent to the platform's polygon index, no? Said polygon knows what platform to activate!
So, if we did ourselves a favor, we did something during Triggers.init() whereby we made a table with all of these switch polygons. We probably added some custom fields or some such that says "Me, me, I'm a switch man!" and maybe even gave it some methods to do the needful.
If you're as hyped as I am about looking at sides when a player presses the action key, you probably already have a function that looks at :find_target for that information and more to call other functions. If in fact the player interacts with a side belonging to some such switch polygon, it should then naturally engage said functions necessary to get a platform moving.
That's easy enough, as far as I can tell. I'm there, had the soup, got the t-shirt... It works! The next trick is to add a dealie to a table of dealies that are constantly queried during Triggers.idle(), so that once said platform's state changes again, you can swap the side's texture index just like a real switch. I guess I should probably just go ahead and write a generalized script for such deferred events, watchers, promises, etc. as it seems useful in many situations.
Is this as versatile as switches in general? Maybe, maybe not. When all is said and done it's not much more complicated than switches as is. Mapping triangles instead of boxes, editing the switch's behavior in Weland, that may be even less complicated than the status quo. Specifying all of the behaviors of switches? We will see. I don't think it will ever be that good, but where some random platform/door is concerned, I think this works better for me and MPDX. Light switches are basically in the same boat, tags might be trickier.
