joebarnin

Yes I do. I just deleted it, and now it works fine. Thanks! My apologies, I should have thought of that.

Looks great. I can create a very simple test case the works in beta04 but not in beta05 (at least, on my machine).

Attached. qconsole.log

Intel(R) Core(TM) i9-10900K CPU @ 3.70GHz 3.70 GHz 32.0 GB RAM GeForce RTX 3070

Sorry, I keep going back and forth between beta04 and beta05. So this last time I ended up with the default cfg (r_shadows "1"). That's the file I attached first. I realized this mistake and set Shadow Maps ( r_shadows "2"), and it still doesn't work (current attached file).

I increased dust to 0.2 and all the way to 1.0 - still not visible. Here's my darkmode.cfg: Here's the correct darkmod.cfg, with r_shadows "2". Dust is still not visible Darkmod.cfg

Yep, on the light I have: volumetric_light=1 volumetric_dust=.002 volumetric_noshadows=-1 Worked fine in beta04, but not in beta05.

Looks like something has happened to volumetric lighting in beta05. It was working fine in beta04 but after I upgraded to 05, it stopped working. I went back to 04 just to verify it was working, and it was. I verified I'm using Map shadows (r_shadows "2") and my r_volumetricSamples is "8". Did something break in beta05? Anybody else seeing this?

I'm using the new Secrets mechanism for my WIP. It works fine for frobbing objects with "secrets" "1" spawnarg. But I have a button that targets a atdm:secret. Every time I click the button it increments the secret count. The wiki says "By default, each of these atdm:secret entities can only be triggered once" but that doesn't seem to be the case. Unless I'm doing something wrong?

In my current work-in-progress I use a fog light for a cellar/basement type room. If I position the light correctly I can avoid the seam - I think I had to make the light extend into the walls a little bit.

@JackFarmerI've used this call to calm down AIs: $guard_1.setAlertLevel(0);

Nice mission! Good work - looking forward to the next one!

Excellent mission! Lot's of fun exploring the mansion and figuring things out. Good use of conversations. City area was good; yeah it was there to get you from A -> B, but felt right. Twist at the end was unexpected yet it fit right in. Thank you for an enjoyable mission!

Count me in for the beta test.

I've got an FM under development (actually it's in Beta test). There's something I've noticed over the course of developing and testing the mission. One large room contains several security cameras. Most of the cameras are configured to rotate. Usually, when I test the mission, they work fine. But occasionally, one of the camera's rotations will be off by 90 degrees. For example, a camera that is pointing "north" (up in the XY view), with a sweepAngle of 90, will typically rotate between 0 and 90 degrees (i.e., from 12 to 3 if you think of it as a clock). But, once in a while, I'll be testing the FM and when I get to this room, the camera is sweeping from 270 to 360 (9 to 12 on a clock). It happens very infrequently, but I have noticed it several times over the past few months of testing. I guess my first question for the developers is, is this a known issue in 2.09? I know that security cameras have undergone significant changes in 2.10; my hope is that perhaps these changes include a fix for this? This bug is maddingly difficult to recreate. I'll test the mission a dozen times and all works fine, and then the next time I start a mission one of the cameras is pointing the wrong way. I've noticed it with a couple of cameras. The problem is that if it does happen, it can make the mission impossible to finish. One option is to switch to 2.10 and hope the problem goes away. But it happens so infrequently that it might be weeks of testing before I'd see it again, or convince myself that it isn't going to happen on 2.10 (and even then that's no guarantee). Any ideas or suggestions? Thanks in advance.

@plotzzz Glad you like the mission!

Just a quick note, the method for determining if something is locked is IsLocked(). So your getDoorStatus method should be calling door.IsLocked(), not door.getBoolKey("locked").

This looks promising: "editor_var phase" "the 0.0 to 1.0 offset in the cycle to start at."

Yep, another one! My mission is also ready for Beta testing (when it rains, it pours, right?). I realize that @Bienie just started his beta, but if there is anyone left willing to test mine (or people willing to test both), please check in at my thread over in the beta testing forum.

I tried that, it did nothing (no crash, no error in the log, and the blackjack was still available).

Unfortunately that didn't work. It can't find the inventory item, no matter what name I use for it. I think the engine does some special processing when you pick up melee weapons. I also tried code to delete the blackjack weapon: $player1.selectWeapon("blackjack") entity weap = $player1.getWeaponEntity(); weap.remove(); but that crashed the game. Is there any way to temporarily override the key bindings, so that '1' and '2' are inactive?

Why not add the counter increment as a spawn arg on the button? So each button has ”counterIncrement” “13” or whatever. Then your script gets the value of the “counterIncrement” spawn arg from the button passed into the script function, and uses that to increment the counter. No need for if/then ugliness.

In my mission, I want to "take away" the melee weapons (blackjack, sword) from the player, and then later give them back. So the game progression is: Player starts with blackjack/sword/arrows (typical situation) Some event takes away the blackjack and sword. He still has his bow, and can shoot arrows. Later, another event gives him a blackjack and sword. Preferably, he would just pick them up and that would re-enable them. I read this thread but I can't figure out if it has any suggestions for my situation: I tried $player1.disableWeapon(), but this disables ALL weapons - I want the bow/arrows to still be available. I messed around with cloning and modifying the tdm_weapon_blackjack.script and tdm_weapon_shortsword.script files, and I got it to mostly work. The player can still hit the "1" and "2" keys - my modifications to those two scripts prevent the weapons from getting raised. But, the lightgem changes (for the sword at least). It would be best of those two keys were totally inactive, but I can't figure out how to do that. I also am playing with some scripting that @Geep kindly gave me. But, that involves redefining the 'player' object (from tdm_player.script), which I would rather not do. Does anyone have other ideas?

In my map under development, I see the following message in the DM console log: DepthStage: missing vertex or index cache What does this mean? Should I be concerned? I found the code that generates it (DepthStage::ShouldDrawSurf), but I'm not smart enough to know what it means. Thanks.

My personal experience matches what @AluminumHaste said. Eight years ago I tried to make my first mission a large one, got frustrated and gave up. Three years ago I tried again, but this time started small. I finished it, and have done a couple more since, with another in the works.