Geep

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

Thanks. Responding to your test PM.

@Fieldmedic I tried to send you a PM, but you're not able to accept those currently, so here it is in public - Subject: Request for Use of your ANTR Billiard Table I'm leading an effort to create a new FM (working title "Away0"), which will be a prequel to my "Away1: Air Pocket" FM. This extends and re-images Atti's 2007 "Setting the Scene" mission. A beta-release might be expected in Q1 2021. The map includes a large 4-story building, which is being recast as a casino and entertainment complex. In one of the rooms, we'd like to include your billiard table, balls, cues, and cue rack from A Night to Remember. Most likely this would be in the "Map Room", a members-only lounge. Might we do so? You would of course be given credit... and let me know if anyone else should be credited for these billiard-related assets. Thanks for considering this. Geep

@HMart, thanks. Don't know how I overlooked (1). It will help a lot, even though it's only relative rotations. (Still wouldn't mind an absolute tool, along these lines: Select a flat surface In a dialog, see the 3 angles of that surface WRT to the world X, Y, Z planes You can also set/step the angles; Before you change angles, you can toggle checkboxes: rotate entire entity; rotate entire group) 2) No, talking about TDM itself, main GUI menus.

OK, here's 2 stupid questions -- 1) In DR, I'd like to rotate an object (prefab, model, brush) so that it is EXACTLY 45 degrees in the XY plane with respect to world coordinates. If I use the DR rotate tool (with coordinates & size info turned off so they don't interfere with seeing the angle) and drag the mouse far from the rotation center to get finer control, and fiddle around and fiddle around, I usually still can't get EXACTLY 45 degrees. And once I release the mouse, info about the angle WRT world is seemingly irretrievably lost to me. Really, what I ideally want is to just go somewhere, type in "45", and be done with it. 2) I occasionally switch the mouse to the left side to give my right hand a break. In Windows, I reverse the mouse buttons. This doesn't affect TDM, so I use the game control settings to interchange the mouse buttons for frob and action events. BUT doing that doesn't make the main menu use the right mouse button for selections! I think that's a UI bug, but is there a workaround, some console command I can make sticky?

Also worth thinking about using the cutscene tech, moving the player's view by moving a camera, then at the end teleporting the player to the new location.

I don't think the disable-weapons approach is so applicable here. The invisible brush method sounds reasonable. Speculatively, a variant would be to have the player stand on the brush, possibly in the form of an elevator with horizontal motion. But you'd have to keep him from stepping off the platform. Could perhaps be done passively (playerclip box) or actively (run a script that frequently forces the player back to the elevator platform's XY origin).

BTW, for anyone wondering about how tall the elevator is, here's a DR shot of the elevator-only test map. You can see the silhouette of the guard on the upper level.

With 2 second decel_time, speed of 120 is no problem for AI. That's brisk enough for me.

@Dragofer, although there's no inherited spawnarg starting with "accel", there is "decel_time". I changed the default value from 0.2 to 2 seconds, and sure enough, I can use a speed of 60 without AI damage. Let's crank this baby up and see what she can do!

I can try that. Didn't see them among the inherited spawnargs, but that's not so unusual.

SOLVED! @Springheel, thanks for the tip. As you said, the AI's damage was causing the elevator reversal. But the source of that pain turned out to lay elsewhere than worldspawn collision. Because this is a tall express elevator, I had doubled its speed from the default 30 to 60. Evidently the abrupt stop when going upward (but not downward... odd) inflicts the pain. If I reduce it to 55, the AI handles it fine, and everything works. It is possible that this max speed of 55 is the same for all AI. It is also possible that it varies, e.g., based on mass. I'll leave that for someone else. IRL an express elevator has a gradual acceleration/deceleration cycle. Too much to ask for here, methinks.

This all encouraged me to try again with the elevator-only map. Made various changes, but burying the aas_obstacle fully within the aas_solid broke the log jam. The good news: the AI guard can fetch the elevator from both levels. The bad news: using the elevator leaves him KO'd or dead! Specifically, he fetches the elevator from the top floor, rides it down, makes his rounds on the ground floor, fetches it again and rides it up. All good. But when it reaches the top, the platform immediately reverses and heads down again, inflicting pain in the process! When it gets to the bottom, the AI pushes the top-floor button, and the cycle repeats... more pain. And after yet one more cycle, he's flat and twitching. Morale: be careful what you wish for? Silver lining: possible new way to disable guards? So the mystery continues