joebarnin

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:

I can recreate this problem on DM 2.11. It doesn't happen on 2.10, so something changed in the core that surfaced this issue. Whether it's a bug in DM or a bug in my mission, I don't know (I would assume the later). It's going to take a while to track this down, especially as I'm going to be out of town for the next few days. I'll work on trying to isolate the problem when I get back. If you can't wait, one option is to play the game with DM 2.10. You can install it separately from 2.11, and use it just for this mission.

So, is this where you throw the Steampunk emperor at the end of the last mission?

Thanks. Now, allow yourself to get hit by the blue (or orange) elemental, so you are transported, and send me that log. Actually, you could store out a save file and let me try to debug it on my machine. Go to <darkmod install>/fms/byanyothername/savegames and send me the <savename>.* files. Pick the save just before you get into the elemental section. That might be a more efficient way of debugging this. (You are using Version 2 of this mission, correct?)

Weird - like you said, there was no additional logging. Do you have a save from earlier, like at the start of the elemental section? It would be great to have a console dump from that point, then playing to where the elementals don't work. Also, along the way, get hit by the working elementals (blue, orange) - that should log something too. Thanks.

This is very strange. It may take a few iterations to figure out what is happening. Do you have logging turned on? I'd like to get a console dump (https://wiki.thedarkmod.com/index.php?title=Reporting_Problem#condump). If you have a save point at the start of the fireball section, that would be best - start there, and when you get to the point where the green balls fail, grab a console dump and send it to me. Thanks!

Hmm, this is weird. What's supposed to happen, is that when you get hit by the green elemental you are transported to the nearby room with the green mushroom. Inside that room is a button that opens the gate to let you out of the green-mushroom room, and also opens the gate that lets you out of the big room (sounds like you figured that out when by noclipping). As for the next room, you have to get the keys in order (green, orange, white, blue), so since you can't get the green one, you're stuck. Something must be messed up in the script? Question: when you get hit by the green/white ball, does anything happen at all? Any fading on the screen? Any sounds? If I can't figure this out, you can just noclip beneath the cube in the middle (with the keys). Un-noclip near the metal rods (you'll see), because there's a Trigger that you need to activate to make things work further on. I'm sorry this is giving you trouble. (Also, how cool that you run an escape room IRL! )

Thanks! Mission difficulty is always a struggle to get right - it's a delicate balance. As for loot and secrets, here's the deal: I'm not a completionist when I play other missions. I don't have to find every last loot item or secret. So when I build a mission, I'm happy making a few loot items and/or secrets really hard to find, to reward those who work hard (unlike me). I suppose that might be frustrating to those who are completionists - but since those goals are optional, I don't too feel bad I am making another mission, should be ready for beta this summer.

Official support within DM would be great, but I suspect it could be done now using something like this: Create "go to location x" as the last objective in the mission. This is a "controlled by external script" objective.(assuming the last step in the mission is to go to a location) At location x, create a triggle_multiple that calls a script The script checks that all other objectives have been met. If so, display the GUI debrief page(s). Then, when the player finishes reading, set final objective to Complete. Mission will end. This assumes it is possible to display an arbitrary GUI in the middle of a mission. For my WIP, I want a debrief, so I'll experiment with this.

Take a look at this, see if it helps: https://wiki.thedarkmod.com/index.php?title=Cutscenes_Part_5:_Somewhere_Above_the_City

There is a script function to set the loot count, by type: changeLootAmount.

mainmenu_briefing.gui has a windowDef called 'scrollDown'. It contains the following line: visible ("gui::ScrollDownVisible" == 1) ScrollDownVisible is set in C++ code, based on whether the briefing has more pages. Maybe you need to change this logic to be TRUE only if the briefing text is also visible. Something like: visible ("gui::ScrollDownVisible" == 1 && "BriefingText::visible" == 1) That way when your start location page is up, the arrow won't display.

I'm happy to help!

I converted the brush to a func_static, that seems to resolve the problem. I thought I had already tried that, but I guess not. I'll keep experimenting, but it looks like it might be as simple as that.

I've got two brushes that are perpendicular, and they are "joined" with a curved patch (bevel) to create a smooth transition. This is what it looks like in a small test map: However, if I copy these objects into my big WIP map, I see lines along the patch: Here's a close-up: Reiterating, these are the exact same objects, just copied from one map to another. Does anyone have idea as to why this is happening? In general, what causes these types of lines on a patch?