geegee

@cabalistic Yes. I haven't played around with cvars. At any rate, I now know something about how to go about tweaking an effect along these lines. p.s. I mentioned how enabling bloom effected all my lights, so the general look - said something negative. In fact I went through my entire WIP checking out bloom=on/off and the difference seems small, and tends to look better with bloom on.

quit trolling me.

Look at the pic of the array, above. It shows the spectrum (a bit off. ... but hey, who's nitpicking??? hmm), in a fairly equally lighted room with shadows at rgb=8. Yes, there's a different effect with different colors. That's what my post was about.

rgb 2: off, default, highest; rgb 4: off, default, highest; copy/paste from pic above

gradations rgb factor: 2, 4, 8, 16, 32, 64, 128, 256, 1024

Well, I always toggle 64-bit on in the advanced screen. Is there something else?

Here's another example of this blend/add shader. The lamp on the wall is done with translucent, alpha, emitter, light. The weird globe has a translucent 19 frame animated plasma shader, and there's a smaller translucent globe inside it with the same plasma shader bumped with a blend/add stage rgb 4. There's a grayscale-75 light at center size 50x50x50. This helps when bloom is off. The first 2 pics are with everything maxed but bloom off. The next 2 pics are the same but with bloom on, slider med-high. It's hard or impossible to see in the low rez still pics, but with bloom off the inner globe is transparent, and the anim effect bounces along with the outer, but the two globes are sharply distinguished. With bloom on the translucencies of the two globes merge quite well and the in game effect is quite nice. Note how the bloom on/off effects the lamp on the wall. It effects every lamp I put in my WIP the same way. I prefer the lamp with bloom off. ... (I didn't see any difference between blend/add 1 and 20 - all seem to produce the same effect. Am I going crazy???)

@cabalistic Yes, there's some room to move re. shader transparency, color, rgb factor and the bloom slider. I do these tests to try to learn these different things. Perhaps I shouldn't have delivered a judgement "visually ...." or artistically, since at root I just wanted to show my test setup, the numbers (now corrected), and bit of what I found so far about how rgb turboboost hdr works with the spectrum, as on the array pic showing colors rgb 8 and all the same bloom factor. Thanks again for helping me correct the numbers, and get more accurate info. Strangely enough, this diversion has heightened my focus on learning more about how to control the particle system.

Thanks. I need a minder... I left noshadows=1 on the original panels with the lights and emitters, then forgot about that when setting up the panels as grouped worldspawn so I could easily change colors on the light shaders. The new numbers are (I didn't turn on ambient occlusion): e_noss_bloom_on 57 e_ss_bloom_on 15 hdr_noss_bloom_on 54 hdr_ss_bloom_on 25 So with soft shadows disabled the panel setup with 48-lights + 48-emitters is 57fps, the hdr setup is 54, only causing a slight hit. But with soft shadows enabled the lights and emitters cause a huge hit, the hdr setup much less so. Visually, I find using mixing translucent and alpha shaders with lights and emitters gives a huge range of subtlety, conformable to every mapping situation, whereas the hdr bloom shaders seem flat and overpowering. In the time allotted I couldn't make a hdr-bloom shader that gave both a nice amber glow as well as showing a translucent (or opaque) amber diffuse. eta: the particles are a slightly altered ea001_bloom_focused

So there's an inverted fps finding: with NO soft shadows or ambient occlusion 48xlight&emitter 71fps bloom shader 59fps with YES soft shadows and ambient occlusion 48xlight&emitter 16fps bloom shader 22fps (Ambient occlusion doesn't seem to have much of a fps impact - esp compared to soft shadows. Soft shadows in TDM brings my pc to its knees.) Note that the hdr bloom shaders at the yellow end of the spectrum look different in photoshop and DR than they do in game. At the top end of the spectrum, red-magenta-blue-cyan-green are more true to photoshop. The soft yellow bloom most resembling my light/emitter panel is actually a yellow-green, rgb=43,78,9 and emits a greenish glow, which isn't too bad. FYI the colors in the panel array are: yellow-green 43,78,9 orange 94,30,0 yellow 255,242,0 red 255.0.0 magenta 236,0,140 blue 0,0,255 cyan 0,255,255 green 0,255,0 dark-yellow 100,94,0

and finally setup_hdr_8_ss_bloom_on.jpg 22fps

Likewise with the hdr texture that most resembles this (yellow_green) setup_hdr_8_noss_bloom_on.jpg 59fps

then with ss and ao setup_e_8_ss_bloom_on.jpg 16fps

At top of the pic is a testbed where, by cloning and substitution I can set up a scene with 48xlights, 48xemitters, and test non-hdr framerates: without soft shadows and ambient occlusion setup_e_8_noss_bloom_on.jpg 71fps

At bottom of the pic is an array of panels with (hdr) bloom lit corners, set up to mimic the RGB/CMYK color wheel (except orange and yellow should be transposed). At centre set off from the array is a non-hdr-bloom panel done with 4xlight and 4xemitter entities. The panels in the array are: yellow-green, orange, yellow, red, magenta, blue, cyan, green, and a darkened yellow. In game the array looks like this: array_hdr_on_translucent.jpg With the translucent property there's enough contrast to see a flame, for instance, inside the enclosure. Otherwise there doesn't seem to be much difference between translucent and opaque, since the hdr add/blend 8 bump is overwhelming.

I set up a scheme in DR to test this property. DR_setup.jpg (It appears that I have to attach the next pics to follow up posts)

Thanks! It's good to know that there isn't a problem still lurking in the brushwork of that area. I'd never build an area like that nowadays, using clip to cover bumps in func_statics, etc. - nor would I make clumsy intersected brushes like that. A problem with reworking old badly made areas is the nostalgia, the deep-set attitude "but I don't want to delete and rebuild that whole area, it took so much time to make and ... crying real tears here!" Yet in truth it's much easier, faster and gives far superior results to just do it, delete it all and rebuild with a better plan.

@stgatilov Yes. However the original map is 54MB, 7038 entities. Which is why I moved on to TDM v2.10. It has 200+ new textures with many covering sealing brushes so without those it won't dmap without a box around it. But since it's the error you're interested in, I erased all I could while still leaving the error. Which left me with error.map, attached, 85KB. It has one horse (horses are .... finicky) and 4 clip brushes, either of which I delete removes the error. In this map, at any rate. Removing the horse from the 54MB original doesn't work, but removing the clip brushes does. By the way, when deleting entities I noticed blue lines left behind by deleted triggers. The entity inspector listed all the entities supposedly deleted. When I selected all entities a hundred or so origin vertices highlighted. I saved to a new map and deleted them, which reduced the size of the map from 107K to 85K. That's in DR 2.13 Opre2 x64. eta: yes, that horse is blatantly ripped off from bikerdude's caduceus, along with the walls. I used it in an inaccessible outdoor scene to peek at thru' thin slit windows - the horse in the stable with the walls, the cart and path. And I took envshots for cubemaps, so it's also vaguely reflected in opaque windows. error.map

With dev build TDM 2.10/64 #9406 I get the warning: during compiling AAS... WARNING:brush 0 on entity 1114636288 is unbounded. That warning makes no sense to me. The brushes and entities near the coordinate location haven't been touched in ages. Of course there is no such entity and I've had different entity numbers 1.1 billion, 1.2 billion, ... I don't get that warning with stable build TDM 2.09/64 #9108 eta: After only vaguely isolating the problem area, I reverted to 2.09 and problem solved, or at least the appearance of a solution. However with thinking cap on I doubt that this is a problem with the dev build. Much more likely it's my map, which is a disgraceful clutter of stuff dating from too long ago, when I didn't have a clue, up to today when I'm getting the hang of it. I've decided to rebuild the map geometry, streamline it and set up portals properly. Use the 2.10 build. eta2: Had to delete the sealing brushes, sky and floor, plus the static floor meshes, over the entire affected area. Then slice up the replacement brushes to rid the WIP of neverending "chopwinding bla bla bla" errors. But it's done, v 2.10 dmap gives no errors. I fear I breached a protocol by posting this topic here, for which I apologize.

I hadn't looked at dev builds until yesterday. First thing I noted, of course, was the new frob highlight. I like it. A lot. Several frobables that didn't show up before are now clearly shown. An irongate.ase frobable that was difficult to see or even find thru' all the fence gaps is now clearly shown. A quick check through my whole map found nothing but improved visuals and gameplay. It makes it easier to select and pick up entities, esp. when some are close together.

Thanks, joebarnin. Yes, your fire-hurt setup works like a charm and I'll be using it in several places now. The setup I was having a problem with required directly targeting the trigger_hurt on/off from a trigger_multiple, and also from a func_static set frobable. The triggers also set other actions, doors, removed entities. In my recent test map it seems that a trigger_once works to toggle it, a second trigger_once will toggle it back, and I suppose that a third would do the same. However, a trigger_multiple doesn't work at all (in my test setup at any rate), not even once. My in-game setup was using a func_static set frobable. This worked to trigger other related events but didn't work on the trigger_hurt. Likewise when I reproduced a simplified version in my test map it didn't work, just like the trigger_multiple. By changing the frobable func_static to a mover_button the trigger_hurt toggling properly, on/off/on/off, as with the fire-hurt. This is enough info for me to get a good in-game setup working, so thanks again.

As per title. trigger_hurt has a spawnarg "on" with values 1 or 0, so at map start will be on or off, and in game it may be triggered off or on, respectively. But only once. I've found no way to allow the thing to be toggled again. It goes "off->on", but won't go "off->on->off". This, although to my untutored eyes it seems like everything's there for the usual toggleable entity, just like a switchable light. But that the original coder for trigger_hurt went the extra distance and "fixed" this by disabling the toggle after a single use. Is there a way to get around this.

A footnote to my posts re. difficulties with teleporting AI and pathing. My aim is to teleport in reinforcements to both sides of an ongoing battle, with the reinforcements teleported to areas well away from the battle and ordered to take paths toward it, only then to react and join the fight. I did tests to ensure that those areas are distant enough so visual and sound alerts can't reach. The paths are taken if the AI isn't teleported in - and the AI join the battle. But AI teleported in are pre-alerted to everything happening in the location provided by the info_location, even if the teleport area is blocked by info_portalsettings with sound_loss spawnarg. Since they're alerted they won't take the paths and since they can't see or hear the battle they run around in circles, cursing almost as loud as I am. To keep the AI unaware on teleporting in it's required that the teleport area be in a distinct location provided by an info_location - and then they'll be obedient and follow the damn paths!!

No, I've never used a trigger_random. So far, all my changetargets have been from loop to loop to terminate, the several AI being separately triggered to pace around their own distinct paths. I haven't incorporated RIT yet.