joebarnin

Thanks! Btw, my name is actually Jeff.

Thanks for the comments. I saw that issue once before, Ill try to track it down.

Marbrien - read the book in that room

With regards to edit: uses spoiler tags now

Summary A new plague threatens Bridgeport. There are rumors of a cure - let's see if you can find it, and get it to the people who deserve it. Background This is my first released DarkMod mission. Four years ago I created an FM and got it into beta testing. Based on the feedback, I tried to expand it and clean it up at the same time, and it fell apart (I lost focus and got frustrated). So I put modding aside. This time I plan to stick with modding for several reasons, not the least of which is that I have much more free time (I'm recently retired). To ensure that I would actually finish this FM, I kept it short and straightforward. Don't expect anything ground-breaking. (How's that for a soft sell?) My next FM (already sketched out in my head) will be more ambitious. Download The mission is available here: https://www.dropbox.com/s/5xa63aysm2ucmkg/mercwarehouse.pk4?dl=1. Place the PK4 in your \fms folder. TDM will recognize it as a new mission. Build Time Six months running time. I have no idea how many actual hours I spent. I18n I have not yet done the work required for internationalization. Thanks Many thanks to the numerous beta testers, who really helped me get this mission into shape: Bikerdude, s.urfer, kingsal, Boiler's_hiss, Cambridge Spy, Abusimplea, Judith Bikerdude provided a window light projection texture, as well as instructions so that I (and others) can do it myself in the future. The video series by Springheel and Sotha were helpful and energizing. Thanks to the entire Dark Mod community for building an amazing project. Note This mission has only been tested on TDM 2.06. I have no idea if it works on older versions. Screenshots

Ah, I didn't realize you can override core files like that. Thanks!

Perhaps I'm misunderstanding, but tdm_numberwheel_lock.script is part of the standard DarkMod install, in tdm_base01.pk4. I wouldn't think it was possible to modify that file. Can it be overridden (it defines an object called numberwheel_lock)? (Anyway, my workaround works fine).

Summary: I think I figured it out. Looks like there's a bug in tdm_numberwheel_lock.script. I can work around it in my FM, but I don't know what the real fix is. Details: I have a software background, so I download the DarkMod source code, and VisualStudio, and did some debugging. Eventually I figured out that the crash is happening on line 73 of tdm_numberwheel_lock.script: callGlobalFunction("closeBar",$safe_bar); From my limited understanding of scripting, this code requires that the mod have a script called "closeBar" and an entity named "safe_bar". My mod had neither. I found an FM (Mission 1: A New Job) that uses the combination lock, and it has both. I think what this code is doing is, when you spin a combo dial away from the correct combination, it should close the "safe_bar" (slide it closed) which effectively locks the safe. My safe doesn't have a safe_bar, so the hard-coded references in tdm_numberwheel_lock.script cause the crash. I can work around it by creating a dummy "safe_bar" entity in my map, and a no-op "closeBar" script. But perhaps that script code should be more bullet-proof, so that if those objects don't exit, the app doesn't crash?

The lock does target the door. I've created a very simple test map (attached). It is just a locked door, with a combination lock bound to it (and it targets the door too). I can get the CTD to happen every time: set the combo to 111, which opens the door. Close the door, then try to change the combo in any way. Poof. Here are the two entities. You can see that the combination lock targets and binds to the door. // entity 3{"classname" "atdm:3panel_104x56""name" "door""origin" "64 64 768""rotation" "1 0 0 0 1 0 0 0 1""lock_picktype" "-""lock_pins" "0""locked" "1""rotate" "0 90 0""used_by" "-"}// entity 4{"classname" "atdm:combination_lock_small""name" "combo_lock""bind" "door""combination" "111""frob_peer" "door""frobable" "1""model" "models/darkmod/mechanical/combination_housing01_small.lwo""origin" "34.76 61.875 821.75""rotation" "1 0 0 0 1 0 0 0 1""target" "door"} test.map.txt

I've got a CTD that happens when using a atdm:combination_lock_small. The lock is bound to a safe door (atdm:mover_door). I can get it to happen every time by setting the combo correctly (which opens the door), then closing the door, then trying to spin one of the combo dials again - as soon as you do this TDM crashes. I cranked up logging. I saw one thing interesting, that didn't show up until the CTD: [game\BinaryFrobMover.cpp ( 533):DEB (FROBBING) FR: 5085] [safe_door1] FrobMover is locked This might be related to the crash because it's the last thing that is logged, just before all of the C++ destructor logging (which I assume is associated with the crash). E.g.: [game\Entity.cpp (1889):DEB (FUNCTION) FR: 5085] this: 327766FC [idEntity::~idEntity] But that's just a guess. Anyway, it was suggested that Obsttorte might be the right person to help me with this? I've got a simple test map that displays this issue. Or let me know if there's anything else I should try. Thanks. Edit - I've experimented with different spawnargs on the combination lock, trying to see if that changed behavior - no luck. Also, I found a different FM that used the same lock (and doesn't crash), and tried to see what it does differently, but so far I can't figure out why it works and mine doesn't.

Okay, now I understand why it is happening. I've got a func_static lamp on the desk (models/darkmod/lights/non-extinguishable/lamp_desk_01). I put a light near this lamp - the issue is the exact placement of the light. If I put the light 'within' the lamp (under the lamp shade), that's when the problem happens. In DarkRadiant, here's the 'bad' positioning of the light (the light is selected): With the light in that position, guard pretty much don't see an unconscious guard at all. But when I move the light so that it is just above the lamp: things work as expected (unconscious guards are spotted). To the player, it looks more-or-less the same (slightly different shadow positions). But to the AI, it's as if the light isn't there (in the former example). Maybe by putting the light entity 'within' the lamp, it was inside the model or something? Anyway, I've got a solution so I'm happy. Let me know if I'm doing something totally wrong, or if there is additional experimentation I can do.

I had completely forgotten about those settings. My AI Vision is set to Forgiving (which I think is the default?). I'll try variations of that and see what happens. I've been experimenting with different types of lights, and different brightness settings. No luck yet figuring out why this behavior is happening. One thing I noticed is that the desk light was originally a light created with the "Create Light" command (as opposed to an light entity created with "Create Entity..."). I thought that might be the issue, but I'm not sure. Even switching to a light_lamp_desk, the patrolling guard is pretty oblivious. Anyway, I'll keep experimenting.

Okay, this one's driving me crazy. s.urfer found this during beta testing. My patrolling guard won't notice an unconscious guard unless he is right in the way of the path. Here's an example of an unconscious guard being ignored, dude walks right past him: The patrolling guard only reacts if I put the unconscious guard right in his path, so he actually bumps into him. I checked the spawnargs on the guards, everything looks good. I'll keep experimenting, but if anyone knows what's going on here, I'd really appreciate it. Jeff

Just finished. This is a brilliant mission! A rich layout, full of spacial complexity. Good set of stories and characters. It looked great, too. Looking forward to the sequels. Thank you!

Looks good. I guess I gotta go play the first three...(been out of circulation for a while)

Thank you! This makes perfect sense. Just thought I'd mention, there's one issue with the video. Around 8:47, you start doing work with the .mtr file - this all happens off screen (maybe a dual monitor issue?). I can't see exactly what you did, but I can figure it out based on the .mtr file you sent (and your audio commentary). Looks like you searched lights.mtr for an existing window light texture, eg: lights/mansion01_window01{ description "projection for mansion01 window01"{forceHighQualitymap lights/mansion01_window02coloredzeroClamp}} Copied this, and then modified it to match the new .tga file name: lights/diamond_pattern01{ description "projection for diamond_pattern01"{forceHighQualitymap lights/diamond_pattern01coloredzeroClamp}} Save this in a separate file in the materials folder. Thanks again.

Just got around to this mission, and I really enjoyed it. I'm not actually done, I had completed the main objectives and then an optional one popped up, and I know there's more out there I haven't found yet. I actually like that feeling a lot, that there's stuff I haven't discovered yet (like a real city). Big and complex, nicely designed, lighting is just right. For my own FMs, I'm going to have to steal from be inspired by this mission.

I have an FM that I think is ready for Beta testing. It's a standalone mission, fairly simple. From the readme: A new plague threatens Bridgeport. There are rumors of a cure - let's see if you can find it, and get it to the people who deserve it. The mission briefing: It's been four years since I last build an FM, so this is my attempt at putting my toes in the water once again. The previous mission got though beta testing, but then I tried to expand it and clean it up at the same time, and it fell apart and I put it aside. This time I plan to stick with modding for several reasons, not the least of which is that I have much more free time (recently retired). Anyway, I would appreciate anyone who could take a look and see if I'm even in the ballpark. Once I have some volunteers I'll create a new thread in the Beta Testing forum. Thanks, Jeff

It appears that moss (from a moss arrow) has some height? I have a "tunnel" that is 40 units tall. The player can crouch down and go through it. But if I shoot a moss arrow into it, I'm blocked. It looks like I have to raise the roof to about 48 units in order to crawl through, if there's moss. Is this intentional? If so, that's pretty cool.

I'd like order to matter. I set up a frob stim/response on the first switch, the response did an Add Target (Entity: second switch, Target: secret door). Maybe not the optimal solution, but it seems to work fine - second switch doesn't open the door until you frob the first one. Thank you! Jeff

I've got a secret door that I want to open only if two separate switches are thrown. I've got it working with a single switch, but I can't figure out how to tie it to two switches. I did some searching and found this but I don't think that quite covers what I want. I also thought about using trigger_count but I couldn't figure out how to make those work in this case. Do I need to use a script? Any suggestions would be greatly appreciated. Jeff

So, here's my plan. I'm going to clean up the existing mission, based on the excellent feedback I've received. I'm leaning toward not releasing this shorter mission, but instead expanding it to the "full length" mission I had originally planned. Should be fun to do - fine tuning the existing stuff, and creating some new bits. Thanks again for all the feedback.

Thanks for the feedback - it matches with what others have said, which tells me where I need to make changes. To answer your question...

Deadlove - thanks for your comments. You've supplied lots of good ideas for improvements - I'll be busy for a while. Jeff

RJFerret - Thanks for the incredibly detailed write-up. It's going to take me a while to digest all of this. At least let me answer one question Between your comments and Airship Ballet's, I've got lots to think about and work on. Thanks again! Jeff