Jump to content
The Dark Mod Forums


  • Posts

  • Joined

  • Last visited

  • Days Won


Everything posted by geegee

  1. Well, I always toggle 64-bit on in the advanced screen. Is there something else?
  2. 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???)
  3. @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.
  4. 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
  5. 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
  6. Likewise with the hdr texture that most resembles this (yellow_green) setup_hdr_8_noss_bloom_on.jpg 59fps
  7. 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
  8. 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.
  9. 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)
  10. 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.
  11. @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
  12. 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.
  13. 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.
  14. 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.
  15. 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.
  16. 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!!
  17. 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.
  18. Hi destined. Yes, this is strange AI behavior, but I had nothing much to do for awhile so re dmap'ed the test area over and over trying to figure it out. Nope, the AI only targeted one path_corner. I have to go out now but I could attach the .map file later (only 280 lines) after reproducing that configuration. I experimented with giving the paths the "chance" spawnarg but there were no results relevant to what I wanted the AI to do, which is, port in and immediately start one exact path to a destination - after which all hell breaks loose. I know that "chance" works when doing what Sotha calls "RIT" random interesting things, but in those cases the AI isn't teleported in and aimed at a corner to start. The AAS_flood/elevator example is good (and interesting) to know. For elevators I use grayman's prefab almost untouched and so far have escaped the horror of trying to set that thing up - now I know a bit more about what it is I'm pasting in there. Hi JackFarmer. I cloned your crane setup from hhtlc into a testmap just to see how it was done. Not in a million years would I have figured out those rotate stoppers! Anyway, in the test setup that worked every time I didn't have the teleported AI targeting a corner, but a path_waitfortrigger. The path_waitfortrigger then targeted the corner of choice. When I triggered the teleport entity, because I wanted the AI to start the path at once I used the same trigger_once to target the AI, and the AI was triggered the same instant it popped into the test area. If I wanted the AI to pause before starting the path I'd have the trigger_once target another trigger_once with a delay on it, targeting the AI. The info on how I could use the atdm:target_changetarget is going to be put to use in another area where I have some very complex pathing. I didn't know you could target an AI to add a path_corner. I've been using the changetarget targeted at a corner, then changing the corner it's pointed at. Having it target the AI might simplify things considerably (knock on wood).
  19. @datiswous Pathing teleported AI is a legitimate topic. If you can't see the questions that I've been addressing in my test maps, leading to my post, that isn't really my problem. There's no way I can know what the experts on S/R, scripting and pathing might contribute to expand my understanding, if they should feel motivated.
  20. Is there any protocol for gabbing about what one has discovered, when experimenting with getting something to work in TDM? I guess so long as I'm polite, people aren't forced to read it... I've been trying to get some teleported AI to follow paths, so created a small test map for the purpose. One thing I hadn't seen mentioned is that the test map requires that some AI (dummyAI) already be in the test area of the map at start. It can't be in a sealed room or a room that it can't exit from - it has to be able to access the test area where the teleport and paths are. Otherwise nothing related to pathing of the teleported AI (t_AI) will work. The dummyAI needn't be pathed, and it can be removed at any time before or after the teleportation. (I guess it tells the engine that dmap has to do the area calculations...) The wiki article https://wiki.thedarkmod.com/index.php?title=Teleporting_entities is correct in explaining that it's best to target t_AI at a path_waitfortrigger, which in turn targets the first path_corner of t_AI's route. So to avoid yet another script I had a trigger_once target both the atdm:teleport and t_AI. That plan (is the only plan that) seems to work every time. One can target t_AI at a path_corner, but that only works in a half-ass way and the path_corner must target a looped path. The looped path doesn't have to loop back to the original path_corner, it can be a closed loop somewhere along the way. However, it appears to be absolutely arbitrary which path_corner in that series that t_AI will head to first, except it seems to be rare if ever that t_AI will head to the original corner it's targeted at. It changes arbitrarily with each dmap of the same setup. So that's hardly recommended. Why didn't I do it the correct way from the start? Best not ask that question, but at least now I feel confident that I can set up a more complicated in-game scenario.
  21. You mean the far wall with the tdm low_brick_wall_old tex. It's a func_static but you're right, very monotonous - just a long rectangle. I guess I just got used to it, so left it, having so much else to work on. Your observation is noted, it'll be fixed up. Here's a closeup of the grass edge. I tried following Sotha's tutorial on building an edged road, but have my difficulties following arbitrary corners and meanderings. I used the standard tdm grass_edge texture, but since there wasn't one for grass4 I swapped the grass4 diffuse for one in Fidcal's material defs. As you can see, the grass4 in the edging is a very different scale than that in the patch it joins. I don't like that either. I've only recently started work on edging and will no doubt experiment with adjusting the alpha blend so I know how to give it more teeth, while also controlling the scale of the diffuse. The edging around the straw in the barn is atrocious and definitely technique is a work in progress and I'm a slow learner.
  • Create New...