joebarnin

Thanks everyone for your ideas. I decided to avoid the problem, so I adjusted the lights at the front of the building so that they no longer cast onto the front wall. Works like a charm, shadowcast counts inside are down to reasonable numbers. “Problem avoided” rather than “problem solved”, but it was time to move on. I’ve save a copy of the map from before these changes, so I can always go back and try “one more” fix, if something comes to mind. Thanks again.

Good idea, but I just checked for this situation, and no luck. It was worth a shot.

I gave this a quick test, and I'm seeing strange behavior. I created a light_torchflame, and offset the light_center, similar to your diagram above. First, the particle emitter is at the origin, not the light_center. I suspect I can figure out how to fix that. Second, the light that is cast has a few issues. There is light at the light_center, broadcast to the 'left'. But it uses the 'biground_torchflicker' texture, so it doesn't quite look right. The wall doesn't get any light, and I guess that's what is intended, but that looks incorrect too. Finally, there appears to be light coming from the location of the emitter. Not just the flames, but cast light. Here's what it looks like. Light from the light_center shouldn't reach that wall.

Nope, Jedi, you are innocent ?. This problem has been there all along.

Shoot, forgot to try that. I'll give it a go now.

I spend a lot of time this weekend trying to do this, without success. I probably wasn't as systematic as I needed to be. It's a fairly complex area to redo. One thing I forgot to mention in my previous post: I did have some success in one interior room. The boundary between inside and outside consists of two walls, worldspawn brushes, each 8 units thick, adjacent to each other. As a test, I expanded one of the walls by two units, so that the two walls overlapped. E.g.: In one interior room, that effectively 'blocked' the outdoor light - the shadowcast count dropped, and the r_showlightcount dropped by one as well. So, partial success. But this 'fix' did not work for other interior rooms.

Springheel & peter_spy - Good idea. Today I checked to see if there were any internal leaks, and I didn't find any. I followed the technique described by Springheel in one of his videos. There were no obvious leaks. I've spent a lot of time trying to isolate the problem, but every time I think I get close, it gets more complicated. Here's what I can say for sure: The outdoor light contributes to the shadowcasting calls (and to the light count) of nearby interior rooms. Dousing the light brings the shadowcasting/lightcount down. As far as I can tell, there are no leaks in visportals (or anywhere else). If I isolate the interior room, so that there are no other light sources, then the problem goes away. That is, even when the outdoor light is lit, it doesn't contribute to shadowcasting/lightcount, but only if the indoor room blocks all other light sources. I tried setting the outdoor light to noshadows, and that reduced the shadowcasting counts, but you could see the light through the walls (in the interior), which I guess is expected? I've spent a lot of time trying to figure this out. I'm ready to release the mission - it is playable, but there may be performance issues in this room for certain hardware. It would be nice to resolve this, but unless someone has a brainstorm...

I'm about to release a new mission, but I've got a performance issue that I'd like to resolve. I've got a building with a torch light on the outside wall. The light is causing performance issues inside the building, even though the wall blocks the light from getting inside. On the interior surfaces, the shadowcasting calls ('shdw' when doing r_showprimitives) are high. If I extinguish the outdoor light, the shdw count drops way down, and "r_showlightcount 1" drops by one too (on the interior surfaces). Any ideas on how the light is getting through? It doesn't show as light - the walls (brushes) are blocking the light. But somehow the engine thinks the light is there. There's another building with the same kind of light on the outside wall, and it all works fine. I keep experimenting with the walls, but so far I can't figure out what the issue is. Does anyone have any suggestions?

Thanks! I'm working on version 2 of the beta. I'll include you on the distribution of that.

Wow that was quick! Thanks everyone; I should have the mission ready tomorrow, Wednesday at the latest.

I'm looking for a small number (3?) of beta testers for my new mission "The Heart of Saint Mattis". It'll be ready for testing in the next day or two. Sign up here, and once we get a quorum I'll create a topic in the Beta Test section. Regards, joebarnin

Here's what I did. I took all of the .pk4 files from my \darkmod install, and unzipped them to a different directory, in this case c:\dm_all. (I use 7-zip, and it will extract multiple zips all in one go). So all of the pk4s are unzipped to a single folder hierarchy. If I'm looking for a file by name, I just use Windows search on c:\dm_all. But, if I want to search within those files, I use Textpad Find in Files functionality. I search the entire c:\dm_all folder hierarchy, limiting it to the following file types: *.vfp *.skin *.map *.pfb *.mtr *.def *.script *.sndshd *.prt *.xd *.lang *.gui*. It takes a minute, but that way I can find descriptive text, and also objects that are defined in text files. For example, let's say you are interested in atdm:ai_builder_priest_combatant. You won't find a file with that name, but if you search within text files you'll find that entity defined in the file 'tdm_ai_builder_priest.def'. It's important to limit the file types because otherwise it searches through all of the graphics files which is a waste of time. Anyway that's what I do. Maybe there's a better way.

Thank you, taaaki!

hint 1a hint 1b hint 2

Congratulations Jack! I had a great time with this mission (beta testing).

Jack - I'd be happy to beta test. To be honest, I probably shouldn't be your first choice; I wouldn't count myself as an expert DM player. But I'm here if you need me.

Good ideas, thanks. I was trying to stop the patrol as a work-around for a glitch (bug?) that I am seeing. Here's the scenario: I have an AI on patrol that I want to temporarily 'hide', then eventually return. The hide() method doesn't seem to work - he's still there, you just don't see him. So (at Event A) I use setOrigin() to move him to a blue room. At a certain point (Event B), I call setOrigin() again to return him to the world. This works fine, if the AI was not on a patrol. But, if the AI was on a path/patrol, sometimes he'll hang out in the blue room for a short time (20 seconds?), and then he'll suddenly disappear and show up somewhere else in the map (usually with falling damage). This problem doesn't always happen, but it only happens when the AI is on a path. So my assumption is that the path code gets confused after the setOrigin, and sometimes tries to move the dude incorrectly. I was just trying to avoid this problem by cancelling the patrol just before moving him. I'm actually rethinking this entire scenario, to destroy() the AI instead of moving him (at Event A), and then recreating a duplicate AI at Event B.

How do you get an AI to stop patrolling? I'm writing some script code, and one of the things I want to do is stop a patrol. I just can't see how to do it. I tried removing all of the path_ entities, but that just crashed DM. What am I missing?

Yes, that would work. The problem is, what if the player extinguished the candle before the script moved it? Spawning a new one will relight it. I can't tell if there are script calls to determine if a light is extinguished (in which case I could spawn it either lit or extinguished).

(the previous post was me too). I'm trying to move a light using a script call (e.g., $myLight.setOrigin(newLocation)). Works fine for most lights, but for candles in holders (for example, atdm:moveable_holder_round_plus_candle) it moves the holder, but not the candle itself. Probably something to do with the fact that atdm:moveable_holder_round_plus_candle entity has a "def_attach" of the candle itself (atdm:moveable_candle_default) - the def_attach'ed candle is what isn't getting moved by the setOrigin call. Has anyone run into this before? Any ideas?

Oh wait, "0" in lock_pins actually means "10", which is the maximum. Try using "1" - that's the real minimum (1+5). It's a lot faster than "0"

I'm not an expert, but looking at the code, I think 0 is the best you can do. As you mentioned, +5 gets added. There is a setting to override the +5, in darkmod.cfg seta tdm_lp_base_count "5" But in the code, if this value is less than 5, it looks like it gets set to 5. So, at least by my reading of the code, setting it less than 5 doesn't do anything. But you can try it and see if it works.

I'm trying to make an Objective of having the player put an object in a certain location. I've been banging my head against the wall for 3 hours on this, I just can't get it to work. I followed these instructions, and I also looked at several other FMs. For the life of me I can't figure out what I'm not doing right. I've got an entity with "objective_ent" "1", and a nice big info_tdm_objective_location, and the Objectives set up just the way the documentation says. But when I put the object in the location, nothing happens (the objective is not met). Has anybody run into any 'gotchas' trying to get this to work?

Thanks for the reminder. Done: http://bugs.thedarkmod.com/view.php?id=5037

Not sure where to best to post this, but here's a recent experience with dmap causing a crash. I was working on a map, and all of a sudden, dmap started crashing (TDM vaporized, no error dialog or anything). I turned on qconsole.log (seta logFile "2" in darkmod.cfg), and the last entry in the qconsole.log was: [store AAS] This made me think it had something to do with pathfinding/AAS. Luckily I had a backup version of my map from a few hours earlier. I compared the two, and one of the big changes in the 'bad' map was that I added a bunch of Monster Clips (which of course affects AAS). Though a tedious process of elimination, I determined that one specific Monster Clip was causing the crash. I have no idea why; it was more-or-less identical to several others in the same area (each surrounding a bench in row of benches). I remembered reading something about this, so I made the brush one unit larger in each direction, and the crash went away. Go figure. Anyway, just thought I put this out there for future searching.