Jump to content
The Dark Mod Forums

grayman

Active Developer
  • Content Count

    13130
  • Joined

  • Last visited

  • Days Won

    191

Everything posted by grayman

  1. Biker asked that I post this: “Evening, as some of you may know I have been working on a large city based mission for TDM. I am very close to rolling out the first beta so have set up a Discord server to do the beta testing on. For anyone that has previous beta testing exp and would like to help, head on over to - https://discord.gg/myX2pJV" I've seen this map, and it looks really good. Help Biker get this long-awaited puppy out the door! Thanks!
  2. No idea at all. A quick glance through the player camera code indicates that the screen is simply taken over by the camera's viewport. No GUI involved. My suggestion is invalid if the camera doesn't use a GUI to paint the screen. Looks like this is a dead end. I can't think of another way to do it.
  3. IIRC, If your cam view is an overlay, as part of the request to create the overlay, you can give the overlay a layer number. Perhaps you can look at the def of the message overlay to see if you can give it a higher layer number than the cam view?
  4. The fault is in the "2" map, and is not a general "the player will move...". What happens in the "1" map: 1. The player falls into the trigger, and gets teleported to a spot just below mover1. 2. The player falling into the trigger also calls the script routine "cs_cam1". 3. This routine runs AFTER the player has been teleported. 4. The player is bound to the mover, and stays with the mover until it's finished its movement. 5. When the player's view is restored, he's at the end of the mover's path, so when he's unbound from the mover, he drops down to the floor in the 'end' area. What happens in the "2" map: 1. The player falls into the trigger, and DOES NOT teleport, because the teleport entity doesn't exist. 2. The player falling into the trigger also calls the script routine "cs_cam1". 3. The player is bound to the mover, and stays with the mover until it's finished its movement. Since the player never teleported, he ends up a large offset from the mover, at (4623.88 2948.38 204.64), which is in the void. 5. When the player's view is restored, he's unbound from the mover, and since he's in the void, he begins to fall forever.
  5. It appears in several places: on the piece of paper that the drunk drops at mission start in a note on the engineer's desk in a note in Ales' fireplace (You don't read the readables? )
  6. No video I know of. Create a nodraw moss patch to cover the walking surface of the rock. Give the patch lots of triangles: Select the patch and switch to vertex mode. Select the individual vertices and pull them down to a couple units above the rock surface below. See if you and the AI can walk across the patch.
  7. Perhaps gift-wrapping the walking surface of the rock with a single moss patch snugged to fit?
  8. Are there any existing examples of working drawbridges, where AI are blocked when the bridge is up, and can walk across when the bridge is down? Thanks. Edit: FIgured it out.
  9. The areas mentioned in the warnings aren't created until dmap runs, so DR knows nothing about them. Look for these situations: 1. You're missing one or more location separators between the basement and the ground floor. Check visportals where the basement is on one side and the ground floor is on the other. Add separators where needed. 2. You have all the separators in place, but one or more of them aren't touching their visportals. Adjust them so they are. dmap posts warnings about separators not touching portals. 3. The separators are fine, but you're missing one or more visportals at the separators. Again, dmap posts warnings.
  10. Nope. Add a path_wait after the path_sleep.
  11. Fair enough. For whatever unknown reason, whoever created it decided not to have it show up in the Targets folder. Here's a picture of one I used in Somewhere Above the City, showing spawnargs. This one, when triggered every frame or so, resets the "target" spawnarg in VaultCamera4 so that it points to the entity target_null_7, which is moving around. This lets the camera resync its view in real time.
  12. And you don't want to use the existing "target_setkeyval"? Keep in mind that some spawnargs are read and initialized only at spawn time, and changing them later will have no effect.
  13. Yes. The timeline should help, especially since Witchers and Mages don’t age, which adds to the confusion, since the season covers a span of 65 years w/o telling you.
  14. Jack: Give me a simple test map with the AI, the path corners, the switches, the doors and their visportal, all monsterclip in the area, and I'll try to see what's going on. When a mission is loaded, if a door has a switch targeting it, the door makes a list with all switches in it. When the AI approaches the door, and he's told by pathfinding that it's closed, the presence of a switch list should send him to the closest switch to open the door. Once he's through the open door, he'll go to the other switch and close the door behind him.
  15. Working on several missions that will rely on 2.08. Yay! Getting treatment for my cancer that has decided to attack after 11 years of remission. Boo! Enjoying my 2-month-old grandson. Yay!
  16. Ok, when I include the dmapped files of the "moonlight" version, it now fails. (???????) Anyway, do the following: 1. Download "Braeden Church" using the in-game downloader, then install it. 2. Go to fms/braeden_church and unzip this file there. You should now have fms/braeden_church/maps/*. 3. Start the mission. The failure is that the only part of the map that gets painted with moonlight is the "section" (visportal-bound) containing the moonlight light entity. (The light is named "Moonlight" if you open the map in DR.) ======================================================= Stretch task: You can try the "it works when you don't include the dmapped files" issue (??????) by deleting everything in fms/braeden_church/maps except the *.map file. You can try this and see if the light suddenly starts working.
  17. Well, that didn't go well. I added a bright parallel moonlight light to Braeden Church, and my initial test runs showed that it fails with 2.08 (before your changes), only lighting up the visportaled section where the light lives. So I wrote up instructions to include the new map for testing, but when I ran through the instructions to make sure I had it right, the moonlight decided to start working. The changed map works correctly in 2.06, 2.07, and 2.08. Go figure. So I'll have to rethink this. The only thing I can think of is that my failed tests included a new dmapping of the moonlight version, and my instructions only included adding the map file but not the proc, cm, or aas files. I can think of no reason why this would matter, but I'm going to have to revisit this. Back later.
×
×
  • Create New...