joebarnin

Another option is to leave the window slightly ajar. This shows, from a distance, that it is openable. Use the "open" spawnarg (set to '1'), along with 'start_rotate' or 'start_position' (depending on whether the window is a mover_door or mover_door_sliding). Give you total control over how open the window is.

An excellent mission! Nice layout and architecture - exploring is rewarded. Wonderful set of interlocking stories, full of politics/factions/intrigue/corruption. Lots of opportunities for thieving (of course) and for doing good. Thank you, Bienie!

Congrats! Looking forward to this one.

Thanks, that solved it - I did as you suggested, and set image_useNormalCompression back to 1, and now reflections look good. So I guess I didn't have a clean release after all. In general, are the steps you listed a good idea for getting a clean release? So, if I run into strange behavior, is it best to do those steps first to see if that resolves the issue?

Nope. It’s a clean 2.08 release, as far as I can recall.

image_useNormalCompression is set to 1 (I am running 2.08). If I change it to 2, the reflections look good.

I'm seeing some weirdness in the 2.08 final regarding reflections. I've seen it in two different missions that I'm beta testing. Here is an example in HHTLC, in 2.07 it looks like this, a nice mild reflection (the plant pot): But in 2.08 the reflection is wonky: Same graphic settings. I deleted the darkmod.cfg, just to see if that made a difference - nope. I saw this problem in another FM too. Is anyone else seeing this?

I think I found it in script files of other FMs? Or maybe, like you said, in the source code. I don't recall exactly.

AI_KNOCKEDOUT EDIT: as in ai guard = $atdm_ai_builder_guard_lesser_1; if (guard.AI_KNOCKEDOUT) { } Edit 2: One more thing, if you knock out an AI and then kill him, I think AI_KNOCKEDOUT is still true. So if you want to check that an AI is knocked out but not dead use: if (guard.AI_KNOCKEDOUT && !guard.AI_DEAD)

I gave that a try, and it didn't work. The reason: the flame already has a response to water (and fire) in its base class, and those inherited responses already do the appropriate deactivation. So adding a response of the same type doesn't work, since that type was deactivated by the existing response. However, there is a solution, and it's pretty simple. The existing (inherited) responses on flames call script functions (response_extinguish and response_ignite) in tdm_lights.script. Those methods both activate all of the targets on the flame. So all I have to do is set this spawnarg on the flame: "target" "trigger_hurt_1" (or whatever my trigger_hurt entity is called). That toggles the trigger_hurt off/on as appropriate. Easy peasy.

I've got a flame, say a campfire. I want the player to take damage if they stand in the middle of it, so I create a trigger_hurt above the flame. That works fine. But if you douse the flame with a water arrow, I want to turn off the trigger_hurt (and likewise, if it's relit with a fire arrow, turn the trigger_hurt back on). How do I do that?

Congratulations to the entire team for a fantastic achievement! I did a small amount of beta testing on this, and I have to say that it was one of the best thieving experiences I've had in years. The geometry/geography is amazing, the story and gameplay flow is excellent. Brilliant stuff.

This is how I've gotten door locking to work, using scripting. Write a script function that locks the door, something like void lockMyDoor() { $myDoor.Lock(); } where 'myDoor' is the name of your door entity. Then on your atdm:target_call_scriptfunction you need a spawnarg "call" "lockMyDoor" (I've always used lowercase "call"). Edit - fixed typo in the spawnarg

The FM that I'm creating uses the getMissionStatistic() script function, to gather info about how stealthy the player has been at a certain point in the mission. While testing, I've seen some strange results. What I think I'm seeing is that various stealth counters don't get incremented if a non-combat civilian sees you. Specifically: sys.getMissionStatistic("numberTimesPlayerSeen") sys.getMissionStatistic("sightingScore") sys.getMissionStatistic("stealthScore") do not increase if a civilian sees you and runs away. I created a simple test map (attached). When it starts, the noblewoman has her back to you. Walk around so that she can see you - she will run to the flee point at the other end of the room. Now go frob the stone pillar - that will display various mission statistics. Note that numberTimesPlayerSeen, sightingScore, and stealthScore are all zero. Run the test again, and this time sneak up behind her and bump into her before she sees you. She'll flee again, and this time numberTimesPlayerSeen is 1 (and sightingScore and steathScore are 5). That seems appropriate. Replace her with an armed guard, and he will immediately chase you, and numberTimesPlayerSeen is 1. Are these results expected? I would think that if you went around being seen by civilians and making them panic and run away, those stealth statistics shouldn't remain at 0. test2.pk4

Congratulations! This is a solid little mission - looking forward to more!

Which is exactly why I wrote "I'll sit back now and let the real TDM developers tell me why I'm wrong" after suggesting that. I was admitting that I was clueless. I also spent several hours trying to recreate the problem on two separate missions (turns out it was two separate issues). I've learned my lesson - just recreate the problem and hand it off, don't try to figure it out.

Another data point. I grabbed the save game from The Painter's Wife, and I was able to recreate the error ("Game Error. Event Overflow. Possible infinite loop in script"). I then ran my custom version of the DM exe that doubles the event limits. The error still happens. That indicates that this problem really is an infinite loop, and supports stgatilov's contention that upping the limit won't do any good. On the other hand, the crash in Hidden Hands goes away when I double MAX_EVENTS. Maybe these are two separate issues. Both errors happen in the event code, but in different places.

New thread created for any discussion of this issue. Original post from Beta Testing 2.08 thread stgatilov's reply: There is also discussion here:

[Forgive me if this is the wrong place for this discussion.] I've been beta testing two new FMs: JackFarmer's Hidden Hands: The Last Citadel, and The Painter's Wife. They are both large missions. In each mission, testers have run into a problem related to event limits. (Note: all of my testing is has been done on the most recent 2.08 beta). 1) In HH:TLC, at some point in the mission TDM crashes. There is no "The DarkMod.exe has stopped working" dialog - the process just disappears. One other beta tester reported a CTD as well. In addition, JackFarmer indicated that he had seen this error occasionally during his testing. I set logging levels and found this in qconsole.txt: "Recursive fatal error!". I tried to debug this issue further by building a debug version of the executable and setting break points in Visual Studio. Eventually I was able to get the error message to log: idEvent::Alloc : No more free events (I posted the details in this topic: https://forums.thedarkmod.com/index.php?/topic/20404-beta-testing-hidden-hands-the-lost-citadel/&do=findComment&comment=447958). From what I can tell, reading the code, this happens because we have exceeded MAX_EVENTS, which is currently 10240: #define MAX_EVENTS (10<<10) 2) In TPW, I got this error: [In case the graphic isn't readable, the dialog says this "Game Error. Event Overflow. Possible infinite loop in script."] The FM developers have also seen this issue during development and testing of the mission. The C++ code indicates that this error occurs because the number of events exceed MAX_EVENTSPERFRAME, which is also 10240. It certainly could be that there are bugs in these missions, that they are either inefficient or have a loop somewhere that is causing these problems. But I'd like to entertain the possibility that these large missions are simply pushing the boundaries of the event limits. I'm wondering if the event limit should be increased (that is, increase the value of constants MAX_EVENTS and MAX_EVENTSPERFRAME). I understand that there may be consequences of doing this - at a minimum, presumably, the DM exe might consume more memory. I just did a test: I had a save file from HH:TLC that always crashed on 2.08 - after loading the save, if I just waited for a couple of minutes, the CTD happens every time. I downloaded the source code matching the current 2.08 beta 5 (SVN 8735). I built the release version and tried again - again, the same CTD happened within a few minutes. I then modified the code to double MAX_EVENTS and MAX_EVENTSPERFRAME, to 20480. Those are the only two changes I made. I rebuilt the Release version of the executable, ran it, and loaded that same save. This time, TDM did not crash. I acknowledge that this is a rather brute force fix. I'm not suggesting that 20480 is the best size to use. But, to me, it looks like there are a couple of large missions that are pushing up against the event limit. Perhaps it is time to consider bumping up this limit, as part of 2.08? I'll sit back now and let the real TDM developers tell me why I'm wrong

Sorry, I was wrong about remove(); I don't think it works for inventory items? But I have had success with $player1.replaceInvItem($bienie_custom_item_part1, $null_entity); In my Heart of St. Mattis mission, you collect 3 key fragments and then they magically get combined into a special key. My script used replaceInvItem to remove the fragments from inventory. I know this didn't work for you. One thing I noticed, the inventory items I'm getting rid of are non-droppable. Spawnarg "inv_droppable" = 0. Maybe that's a requirement? Anyway, try setting that on your bienie_custom_item_partN objects, see if that helps.

Try $bienie_custom_item_part1.remove(); That removes the object completely (including from inventory). I've used this technique for getting rid of inventory items.

I don't have 2.06 installed - how does one install an older version? Here is a test map: test.zip

I'm running into an issue with projected lights. The behavior is different from 2.07 to 2.08, and to my (non-expert) eye it seems to be a regression. I have a light that projects on a wall (for lighting paintings in a museum). I created a simple test case. As you can see in DR, the light does not reach the floor: In the XY side view (bottom right) you can see that the light boundary doesn't reach the floor. In DM 2.07, it looks like this: The light cuts off on the wall, before it reaches the floor. But the exact same map in DM 2.08, the light reaches the floor: The only mention of projected lights that I can find is this. I can't tell if this is related to what I'm seeing: Is this a new bug?

I'm missing it too, and I'm on 2.07 hot fix 1.

I will test on 2.08