joebarnin

Okay, try this: I get Objective Failed and then the mission ends. I think "Ongoing" and "Satisfied at start" are the keys.

Try unchecking the "Boolean NOT" box, but adding "Failure Logic: 1" (see my screengrab). That way the objective fails if the AI is killed, and since it is a Mandatory objective, the mission fails.

Something like this, I think:

A fun mission - great atmosphere and design. Good idea - sort of a "Ponte Vecchio" feeling for the bridge. Lots of entry points, good use of rope arrows (I love missions with rope arrows), nice physical relationship between rooms & levels. I don't have the patience to ghost, but it looks ghost-able. I just knocked out most everyone, which was fine. I did accidently kill one guard who was sitting, but that's a known bug with TDM. Nice work, and thanks! Like others, I ran into performance issues. Outside my FPS was low, and TDM froze once for about 10-15 seconds. Also, some minor things:

Stunning!

See this comment:

I created a simple test with 3 objects. A stackable arrowhead: "classname" "atdm:moveable_loot_ancient_arrowhead" "name" "atdm_moveable_loot_ancient_arrowhead_1" "origin" "64 104 -40" "rotation" "1 0 0 0 1 0 0 0 1" "inv_category" "Special" "inv_loot_type" "0" "inv_loot_value" "0" "inv_stackable" "1" A frobable bowl: "classname" "atdm:frobable_base" "name" "func_static_1" "origin" "112 104 -61.9901" "model" "models/darkmod/kitchen/bowl01.lwo" "rotation" "1 0 0 0 1 0 0 0 1" "target" "atdm_target_itemremove_1" And an itemremove target: "classname" "atdm:target_itemremove" "name" "atdm_target_itemremove_1" "origin" "120 104 -16" "ammo_count" "0" "ammo_type" "-" "drop_in_world" "0" "stackable_class" "Arrowhead" "stackable_count" "1" "unique_item" "-" When you frob the bowl, the arrowhead count in your inventory drops by 1. If you want to do additional processing when the bowl is frobbed, have it target a atdm:target_callscriptfunction, which can do whatever you like (including activating the atdm:target_itemremove).

I found this object in the TDM files (tdm_target.def) entityDef atdm:target_itemremove { // Added in #3784 "inherit" "atdm:target_base" "editor_color" "1 0.5 0" "editor_mins" "-5 -5 -5" "editor_maxs" "5 5 5" "noclipmodel" "1" "wait_for_trigger" "1" "spawnclass" "CTarget_ItemRemove" // DR documentation "editor_usage" "Removes items from the player's inventory. Each target_itemremove can remove up to 1 unique entity, one stack of stackables, and one type of ammo. Melee weapons cannot be removed." "editor_var unique_item" "The name of a unique entity to remove. Must match the entity's 'name' spawnarg." "editor_var stackable_class" "Specify a type of stackable. Must match the entity's 'inv_name' spawnarg." "editor_int stackable_count" "The number of stackables to remove. 0 means all." "editor_var ammo_type" "The weapon whose ammo is to be removed. Standard ammo names are: broadhead, firearrow, gasarrow, mossarrow, noisemaker, ropearrow, vinearrow, waterarrow" "editor_int ammo_count" "The amount of ammo to remove. 0 means all." "editor_bool drop_in_world" "If set, the item will be dropped at the player's feet instead of being removed from the world." // DR default keys "editor_setKeyValue unique_item" "-" "editor_setKeyValue stackable_class" "-" "editor_setKeyValue stackable_count" "0" "editor_setKeyValue ammo_type" "-" "editor_setKeyValue ammo_count" "0" "editor_setKeyValue drop_in_world" "0" // Defaults for subclasses "stackable_count" "0" "ammo_count" "0" "drop_in_world" "0" } Note this: "editor_int stackable_count" "The number of stackables to remove. 0 means all." The default is 0, which is the behavior you are seeing. I'm not sure how to use this, but maybe you can somehow, and set stackable_count to 1?

Thanks. I was hoping to create the trigger in an arbitrary location. I guess I could create a brush trigger in a "blue room" (in DR), then have some script code that moves it to the arbitrary location (using setOrigin). Anyway, I found a different workaround for this, so it's not an issue anymore.

I want to dynamically create a trigger_hurt via a script. The following creates one, but it has no size: sys.setSpawnArg("origin", <some point>); entity trigger = sys.spawn("trigger_hurt"); How can I specify a size and shape (e.g., a rectangle) for this entity?

I've been using DR for years. I just reinstalled on a new computer and I'm seeing behavior that isn't familiar. When I deselect objects with the Escape key, the Camera view doesn't update (the objects still show as selected). The objects are deselected in the Orth views, but not the Camera view. If I click in the camera view or move the camera at all, the view is updated correctly. Same thing happens if I Hide an object (H key) - the hide happens, but the camera view isn't updated until I do something (Shift-LMB in the window, move the camera, etc). I know on my old system that the Escape or Hide actions would immediately show up in the Camera view. Is there a setting that effects this behavior? Edit: Never mind, now it's working. I don't know what the problem was, but now it's working as expected.

I dunno. Ignorance? Laziness? I'll go with laziness . I really don't remember why.

Which specific Dark Radiant features are involved with that screengrab?

I spent some time in the Visual Studio debugging this issue and I think I found the problem. Looks like the following line in Bounds.cpp (line 163) is incorrect: if ( idMath::Fabs( cross.z ) > extents.x * ld.y + extents.y * ld.z ) { it should read if ( idMath::Fabs( cross.z ) > extents.x * ld.y + extents.y * ld.x ) { The only change is the final variable, it should be ld.x, not ld.z. This problem was introduced in SVN 9993 (July 14, 2022). The code was refactored to make it more readable and faster, but it looks like a simple error was introduced. I made the fix on my machine and it resolves the problem. I don't want to check in the fix (and I suspect I don't have access to do so), so I'll leave it to others to verify this change. But I do think this is a serious bug fix that needs to go into the next release. In fact I think it should be put out as a patch to DM 2.11, since other others have reported this, and I've seen it playing other DMs. Basically, any projectile fired on the East/West axis will not hit an AI target (it will go right though them). I'll update the Bug Report with this info.

I had a look at the C++ code, here's what I found (I'm no expert). There is code that attempts to deal with AI being blocked when on a path. Specifically, MovementSubsystem::CheckBlocked has this line: if (traveledPrev < 0.1) // movement is very close to zero traveledPrev is the distance travelled during the previous cycle. If this check is true, the system thinks that the AI might be blocked, and it starts processing movement a bit differently. With most AI, their walking speed is such that this check only happens when they bump into something. But the spider_child walks so slowly that sometimes this check happens even when isn't blocked. I think that's what is happening here - normal walking by the spider results in the movement subsystem thinking that the spider is blocked, so it has the spider back up and try a different path. So the spider looks like it is doing an animal patrol. The walking speed of an AI is determined by its walking animation. To test my theory, I made a custom spider_child that uses the ai_spider's animation, and sure enough, it followed the corner paths correctly (because it is walking faster). The downside is, the spider_child looked weird as heck, because the animation is made for a larger spider. So this really isn't a solution. Maybe the spider_child animation needs to be modified (sped up)? Or the code needs to handle slower creatures? I don't know. This explains why your timescale change allowed the spider to follow the paths - by speeding it up, it was moving fast enough to avoid that check in the C++ code. Edit: If you set "anim_rate_walk" to 1.6 or greater on the spider_child, it seems to work fine. Give it a try.

I want some guards to react to an alarm. Specifically, I want them to go to the room where the alarm is going off. I tried using the alarm technique, but that just alerts the guards where ever they are - they just look around in place, they don't head to the source of the alarm. I tried using path nodes - specifically, I set alert_idle_only on a path_corner, hoping the guard would head there when he was alerted. But, it turns out alert_idle_only is based on HasEvidence, and this flag is not set when the AI is alerted by noise. (it is based on the following: return memory.enemiesHaveBeenSeen || memory.hasBeenAttackedByEnemy || memory.itemsHaveBeenStolen || memory.itemsHaveBeenBroken || memory.unconsciousPeopleHaveBeenFound || memory.deadPeopleHaveBeenFound || spawnArgs.GetBool("alert_idle", "0") ) Anyone know of a technique for getting guards to converge on the source of an alarm? EDIT: I found this: https://wiki.thedarkmod.com/index.php?title=Path_Nodes#Switching_Immediately_(TDM_2.08+) It works by itself - the guard will be alerted and run to the room. But, in combination with the alarm bell, it confuses him, and he stops and searches. So I think I'll use that technique to switch his path, and then make the alarm not audible by AIs (since it doesn't do what I want). EDIT #2: I'm still struggling with this, so if anyone has any ideas or techniques, please let me know.

Look into the script call setLightgemModifier. It's used in the lantern (see tdm_playertools.script). You could make your light kind of like another lantern, but this one with no or little effect on the light gem.

I tried my test case at 60fps: no change, still goes right though me.

Brilliant, this worked like a charm.

In a TDM script (in real time) I want to calculate the angle between two points ('vectors' in the scripting language). It's basically arctan - but there is no 'arctan' function in the TDM script language. Is there any way to call an external script or function? Like, jython? Worst case, I can hard-code a table of values, but that is kludge-a-rific.

@tapewolf That sure sounds like the same thing. It seems to happen when the projectile an angle close to 0 or 180 (i.e., east/west). It's easy to recreate the problem with a func_shooter, because they are lined up at a specific angle. But I saw it in gameplay too, when testing my mission. I fired a gas arrow and it went right through the guard. Sure enough, I was shooting pretty much along the X-axis (angle 0).

Clever idea, I’ll do that

I've got a window (func_static made of textures/darkmod/glass/clear_warp). Just on the other side of it is a frobable object. The player can see it and frob it. I want to prevent frobing through the glass window. Other than lowering the frob distance, is there a way to stop frobing through the window? I tried adding a tdm_nodrawsolid_glass func_static 'over' the window, and made it frobable (to catch the frob first), but that didn't work, I could still frob the object on the other side.

@JavaGodI'm glad you enjoyed the mission. As for your questions

I just submitted a new bug report: https://bugs.thedarkmod.com/view.php?id=6292. In certain specific cases, projectiles don't collide with the player. I've got a test case where a atdm:func_shooter shoots an arrow right at the player, and it goes 'right through' them without damage. It seems to be related to the angle of the projectile (and whether the player is moving or not). This is new to TDM 2.11. It's the cause of the problem that @JavaGod reported playing my mission: