joebarnin

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.

@DragoferThanks. I just tried your suggestion, and it looks like clearing immobilization is necessary, but not sufficient. Without a way to set m_bOnClimb=false (or m_bOnRope = false in the case of climbing a rope), the game still thinks the user is climbing on the ladder/rope. There doesn't appear to be a way to call ClimbDetach() or RopeDetach() from a script. The only way I can find to cause RopeDetach() to get called indirectly is to remove the rope, which I'd rather not do. I'll submit a ticket.

Not sure if this counts as a newbie question. I'm using a func_teleporter. The teleporter fires at an unpredictable time; as an example, presume that I've got a script that invokes the teleporter every 5 minutes (that's not exactly what I'm doing, but it works as an example). It works fine normally, but if the player happens to be climbing a rope (from a rope arrow) when the teleporter fires, the teleporting doesn't work as I expect. The player is teleported to an incorrect location, and the physics engine seems to think that he is still climbing a rope (i.e., the player can still climb up and down as if they were on a rope, but there is no rope at the new location). It looks like the teleport code doesn't cause the user to "let go" of the rope, or something? Is this a bug, or ...? In scripting, is there a way to force the player to let go of a rope? I've experimented with removing the deployed rope, and that does cause the player to let go and the teleport works as expected, but that's suboptimal (now the rope is missing).

I think there's probably a way to make this happen with a custom s/r and some scripting. I'll think about it. Edit: here's how. Set up a custom stim near the light, with an appropriate stim radius. The stim fires every 200 ms. Add a corresponding response to the player object. Custom responses call a script. That script looks like this: if (!light_already_on) { $mylight.On(); light_already_on = true; lightTime = sys.getTime(); thread checkLight(); } lightTime = sys.getTime(); light_ready_on is a global boolean, lightTime is a global float. Basically, the response script stores the latest systime that player was near the stim. The checkLight thread is this: void checkLight() { if (sys.getTime() - lightTime > 0.5) { $mylight.Off(); light_already_on = off; } sys.wait(.1); } Once the light is on, the checkLight thread wakes every 100 ms and compares the current time with the "last time the stim was fired". If it's more than a certain value, the user has moved away and the light is turned off. Completely untested. Also, the various timing parameters might have to be changed. But it's an idea.

In general, I feel it's best practice to extend an existing definition, rather than copying it and modifying it. Say, for example, in a future release of DM, the developers make a change to the tdm_player_thief.def file. With my original technique, anyone playing my mission won't see that change (because my mission is using a cloned version of the old tdm_player_thief.def file). With my preferred technique, that change will be maintained, because I'm just extending the existing definition.

@JackFarmer For this mission I have a unique projectile (something like a fireball) that doesn't actually damage the player when it hits them, it has some other effect. I decided to implement this using stim/response. So my fireball has a stim attached to it (more accurately, the stim is attached to the "def_result" associated with the fireball). When the fireball 'hits' the player, I want a certain effect - this is implemented by a response. So the response has to be defined on the player object. The technique I describe above enables you to add responses to the player object. (It also enables you to change other player parameters, like walking speed or starting health, by the way). Maybe there's a better way to do this, but the technique I describe seems to work. Hope this makes sense.

Never mind, I figured out a better way. In a .def file, define a custom 'player' that inherits from the default and includes the custom responses. Something like: entityDef my_player_thief { "inherit" "atdm:player_thief" // add custom responses "sr_class_5" "R" "sr_type_5" "1000" ... Then, on any worldspawn, define a spawnarg, "player_classname", with a value of your custom player entity (in this case, "my_player_thief"). When TDM starts it looks for that spawnarg on the worldspawn, and spawns that entity instead of the default one. Since my_player_thief inherits from atdm:player_thief, it behaves just like the default player, except for the changes you add/override.

I have some user-defined stims (sr_type >= 1000), and I want the response to be attached to the player object. How is this done? The only way I could figure out is to clone the default tdm_player_thief.def file into my mission folder, and modify it by adding my responses to the atdm:player_base object. This works, but it seems suboptimal (and maybe risky?). Is there a better way?

ai_type of "human" wont work. I think it's looking for a number, and it looks like humans are 0 (zero). So try "0" instead of "human" for both of those. Hmm, I just noticed that later in that wiki entry, it says "ai_type Type of AI: human, beast, undead, steambot, etc. (reads m_AIType in the SDK, which is set by the "type" spawnarg on idActors. Not sure if this is implemented yet)." Hopefully, 0 will work for humans.

Is there a script call that will tell me if an entity is in the player's inventory? Or, a call that enumerates all of the items in the inventory? getNextInvItem() isn't appropriate, as it actually modifies which inventory item is active to the player.

@GeepMy loot objectives look the same, except I don't set the Irreversible flag (both places). Try unchecking those and see if it works.

My trigger_hurt can be toggled. I've got a brazier post that you can climb up on. The flame starts out lit, so the trigger_hurt is on. If you douse the flame, the trigger_hurt turns off, and if you relight it, it turns off (this is accomplished by adding "target=trigger_hurt_1" spawn arg to the flame). I can douse and light the flame back and forth several times, and it works. What are the details of what you are trying to do? How do you activate the trigger_hurt?

Clever idea. How does it attach on the player's side? I can see how it sticks into the other side, just like a regular rope arrow. But what happens to the 'end' of the rope near the player? Does it magically attach to something? Maybe you have to be standing next to some sort of attachment object, and then the end of the rope attaches to it once the arrow is shot. Or maybe after you shoot the Tight Rope arrow, the end is 'attached' to you, and you have to walk over to the attachment object and interact with it to make it stick. Also, I think the rope will have to sag a bit or it may look cheesy?

What sad news. RIP greyman. Condolences to his family and friends. He was an important contributor to TDM, and the William Steele series will live on.