Geep

If this gets implemented successfully, I see a potential follow-on project that could use some of the same architecture, but for a mapper audience. Namely, find all official FMs that use a specific resource (e.g., texture, material, model, audio file, AI character, script or script function). Essentially, there would be a similar search form, a new backend database with this information, and new indexing scripts to gather it (run whenever an FM is released/updated). Some of this scripting would be easy; some would require inference (e.g., usage of prefabs). The search results would have not just each FM hit, but a link to detail info (e.g., where the resource is defined; where it is deployed in the particular map). As it stands now, a mapper can use generic full-text-search tools on their dev box (and some manual poking around) to do this, but only over FMs they have downloaded and retained.

Related: For a WIP FM, I've been gathering additional 2D art images, and NOT seeking obscure art, but trying to restrict it to originals with either CC or public domain sources. The latter is satisfied (in the case of paintings or prints) by using only artists that were dead by 1920 (100 years ago), and images that are not high-resolution (having to do with potential copyrights on the scans or digital photos). To fit in with the TDM epoch, I prefer images painted no later than 1870... I may crop or (in special cases) retouch out more-modern anachronisms. Some preference for European (including UK) art as well, fitting with the generalized TDM locale. As opposed to, say, US or Asian art.

Maybe it just doesn't work if I erase parts of the background directly; the Save As doesn't ask about alpha channels. I guess I'll try to figure out how to do transparency with a layer mask... was trying to avoid that. Thanks

I'm trying to create a .tga with transparency, that I can use as a decal. I erased part of the image in Photoshop (old Elements 8 ) to add transparency. I can save as a .png file, and all appeared to be good. But if I try to save as .tga (32 bit, uncompressed), the transparent section comes out white (on reload into PSE, or in TDM). I gather from the Photoshop forums that you have to do backflips and blood sacrifices to get .tga with alpha channel to be emitted. A trip of the .png file through GIMP and exported out resulted in a corrupted .tga I know there are online file converters, so maybe it will come to that. But I'd like to hear your recommendations.

The use case for the ducts is probably somewhat different than for wall modules.That said, I do think that the existing single-face ducts have their uses as is, so would not propose replacing them with 2-faced ducts, just would like to have both sets available. Pluses of 1-sided ducts - - Perfect if mapper is hiding them, within existing architecture or custom shell enclosure - In which case, the enclosure can take care of blocking light from any internal lamps (similar to what Springheel indicates) - Half the draw calls of 2-sided ducts - Since walls are transparent from outside, easier to see any internal doodads like fans, and abutment with architecture in DR camera view. Pluses of 2-sided ducts - - Looks like a realistic duct from outside; no need to create one's own enclosure - Easier to see where the real openings are, when surveying the module set and assembling a run The situation with internal lights and 2-sided ducts is TBD. If this can't be solved by the modules themselves, it's not the end of the world - - Many ducts don't need internal lights -The range of an internal light can be tightly restricted - Maybe only parts of runs with external shells would have lights within

Regarding light through the 2-sided surface, in the wiki Material_Files entry... This is a bit cryptic. Maybe it's saying you should create a second not-quite-coplanar patch with nodraw surface and forceShadows?

I was able to assemble a satisfactory 1x fan unit (except for outer skin); I replaced the stock fan+motor with a separate stock motor & scaled-up fan, that better fills the duct.

On thinking about this further, the light-penetrating the current modules is probably not a real problem, given that these modules assume the mapper will provide their own shell (architectural enclosure). From my perspective, for an alternative set with external skins, an implementation with two-sided, light-blocking patches would be much preferable to shell modules, that would require additional mapper attention to matching and alignment. (Shells for some of your S-shaped could be challenge for you to make too.) As for my immediate needs, external skins for these would help: - single horizontal duct - horizontal right-angle connector - complex generator unit I've also tried the closed 3-unit fan (which as you know as a fan model at one end, a different fan texture at the other), but it is unsatisfactory. Due to the integral (non-removable) grate over the only entrance, in the side of the central duct, you can't really poke your head in to see the fans at either end... so what's the point? A variant that might be useful would be a 1x unit with fan model and light... A shelled version could have an exterior end-cap texture suggesting the fan within; or maybe spinning fan blades would cast a rotating shadow through a transparent end-cap grill. (I'll try cobbling such up with the existing assets.)

One problem I saw with the duct prefabs that contain lights, is that the light unfortunately penetrates the patches but not the brush edging... the latter cast shadows. (This would not be a problem with all-brush ductwork, but I imagine there are other solutions as well.)

@Aosys I've been using your duct modules, but still find a lot to head scratch about. Is there a video tutorial? They would be so much more helpful to me for if the outside was opaque. Is the earlier version of the modules (all brushes) still available? Or would it be easy for you to do double-faced patches? (If so, I could enumerate which ones I need at the moment.)

Thanks, will stumble forward as before.

The nice think about 2.08 is it reports all the ineffective visportals. The bad thing is that then you have to fix them. One question I've had, that's not clearly addressed in "Visportals/Multiple Joined Visportals": Can you "combine" 2 visportals at right angles (or more generally, non-coplaner)? That is, you have a vertical visportal, let's say across a corridor at a point that has an extensive hole in the floor. There's a horizontal visportal across the hole. Is it possible to make this arrangement work? If so, I imagine you have to make the vertical visportal's lower edge exactly touch the horizontal visportal active surface. Be good to know if this ever possible.

I'm updating to 2.08 today, and look forward in particular to using the new visportal dev tools this coming month. And fewer black rectangle artifacts. Thanks!

It's configured as a multi-part entity (even if only with 1 part), in which you have to navigate to the particular part you want in order to resize. So, after you select the brush overall, hit TAB. Then you can resize it. Hit TAB again to return to the normal mode. I had the same problem when first working with water.

If you don't get the PM response, maybe your mailbox is full? Thanks too for the tip. I'll be on the lookout for model problems