Jump to content
The Dark Mod Forums


  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by joebarnin

  1. This is very strange. The room shouldnt be locked and there shouldnt be voices coming from inside. Would it be possible for you to record some gameplay to show me this behavior? Or at least some screen grabs? Thanks.
  2. Hmm. Don't know about your room 6, but my room 6 is unlocked . Could be a bug, I suppose? Could you possibly be thinking of Room 4?
  3. Question about patch vertices. I'm looking at OPMs (Other People's Missions) and I found this patch mesh: As far as I can tell this has 3 columns and 4 rows of vertices. But the Create Simple Patch Mesh command only allows odd numbers of rows and columns (3, 5, 7, etc). How do you get a patch like this one, with an even number of rows or columns?
  4. Jack, The script file is called mapname.script (assuming your map is called 'mapname.map'). It is a text file, and it needs to be in fms\mission folder\maps (same location as the .map file). Its contents are just these few lines: void closeBar(entity ent) {} As an example, attached is the script file from my recent map. Although, I had to rename it to warehouse.script.txt in order to attach it to this message, because this message board won't let me attach files with a .script extension. warehouse.script.txt
  5. Sounds like the same issue I ran into here. My work-around was to do the following: create a dummy entity somewhere in the name, named "safe_bar" (or rename an existing entity)create a script called "closeBar". In \maps\<your map name>.script (same name as the .map file), add the following (I had to create the script file):// dummy script because tdm_numberwheel_lock.script expects one (http://forums.thedarkmod.com/topic/19639-crash-to-desktop-using-combination-lock/?p=427297) void closeBar(entity ent){}
  6. Brilliant mission. You got the Thieves Highway just right - multiple paths, a variety of path types, directionally disorienting (which is good). Then, the city watch station was nicely complicated. Multiple interesting stories. Leaves me wanting for more - on to WS3!
  7. Thanks for the comments. I saw that issue once before, Ill try to track it down.
  8. 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
  9. Ah, I didn't realize you can override core files like that. Thanks!
  10. 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).
  11. 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?
  12. 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
  13. 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.
  14. 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.
  15. 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.
  16. 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
  17. 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!
  • Create New...