Jump to content
The Dark Mod Forums


Development Role
  • Posts

  • Joined

  • Last visited

  • Days Won


demagogue last won the day on April 25

demagogue had the most liked content!


1345 Deity

About demagogue

  • Birthday 09/22/1976

Profile Information

  • Gender
  • Location
  • Interests
    international law, cognitive science, piano/guitar

Recent Profile Visitors

15596 profile views
  1. Edit: I wrote a lot trying to speculate about what your root problem was. I think I've boiled it down to the solution that's just written at the bottom in Edit3, if you want to cut to the chase. --- Replacing a spawnarg does the same thing as changing the inheritance. Okay, to literally answer your question, you could make a duplicate of the class entity from which it's inheriting "snd_closed", and then delete or replace that "snd_closed" with "nosound", "0", or "-", then have the inheritance call that modified duplicate version. But then it's just going to cut off again after snd_move ends like you just said you don't want. So that doesn't really solve your problem. So don't do that. It appears that the problem isn't snd_closed per se. It's that you don't have a transition sound from snd_move to silence. What I think you should do is use a sound editor like Audacity, take the end of the snd_move file, and then make a new & clean cut off sound at the end, like a quick fade off or play with the manipulations until it sounds like a drawer stopping would actually sound. Be sure to crop it so your fade off sound seamlessly fits the end of the snd_move. Then package your new sound in the sound folder for your mission and make a new sound shader for it, and then fill "snd_close" with the address to that sound. Read the wiki page on custom sounds for the details. Edit: Unless I don't understand your situation. ------ Edit2: It sounds like a timing issue, like snd_close is happening (and cutting off snd_move) before you want it to. In fact, you don't want snd_close at all. Is that right? Okay, here's the issue. The way the system is designed is to allow for closing sounds of any arbitrary length. So it plays snd_move as long as its moving, sometimes long, sometimes short, then snd_close plays at the moment it's finished. So you'd want to always break up your sound into two parts, one for the "still moving part" that can play on repeat for any length of time, and one for the bang of the closed part that plays only at the end it, that would fit just as well if snd_move only played 1/2 way through or if it played 3 times. So then you always get a seamless move and close sequence for any arbitrary duration from half a second to 5 seconds or whatever. Would that fix your issue? It kind of looks like you want a combined move & closed part in one sound file. But the system is not really designed for that. It's designed to play while_moving -> snd_move, at_end -> snd_closed in sequence, so you make your sounds fit that template. If you want to change that template itself, so it only plays snd_move to its end every time no matter what, now (I think) you're talking sourcecode changes, which is not something you can just fix for your FM. (But I'm not 100% sure about that. There may be a way to do that, but I don't know about it.) ------ Edit3: Oh, well if it's that last part that you want, then there's another really simple thing you can do, which is completely cut out the snd_move and snd_close altogether, use "nosound" for both, but when somebody frobs the drawer, have it like a button that calls a speaker attached to the drawer that just plays your close sound as a one-shot independent sound. It will get rid of your cut-off problem. But the catch is, you'll need to set up a script or trigger system so it only plays every other time (when closing, not when opening; unless you want it when it's opening too, in which case just trigger it every time).
  2. Right. I was talking off the cuff and should probably have said something like "at least" 2 scripts (edit: I almost edited my last post to add "at least" too; but then I guess I forgot to) or 2 relevant to the discussion at hand. I think there probably are other algorithms--I haven't looked at it in such a very long time--but they didn't occur to me. I remember the rat one of course because if you spend any time with DR, when you run a map after changing the geometry without dmapping it, you'll I think always get an error that the rat pathfinding is broken. So it's easy to recall
  3. Looks cool. I always thought DR was a great editor to build with. I mean I was originally coming from Dromed, which is a nightmare to build in in every way. So I was never sure if I liked DR just because it was so much better than that (a low bar) or if it was legit an objectively good editor. But then I see other people from other backgrounds liking it, and that lets me know it's not just me.
  4. There are actually two pathfinding scripts, one for human-sized AI and one for rats. So rat sized AI are okay.
  5. T2X did that trick I think. It's a bit non-diegetic for my taste, although people have different opinions on it. (I wouldn't like it if there were only a few keys, but when there are more than 6 or so it starts sounding better.) I think it's another good example of an alt mechanic people should be able to add in themselves. Someone may have done it somewhere already as a mod, if you search the forum for it, because I know we've talked about it before. You can at least press "k" to cycle through keys very quickly, click, click, click...
  6. I think the design is established now for the core game just as a matter of legacy. But I think it would be a good idea to make ones with the other design and make them available for individual FMs to use if a mapper wants. Any asset can be changed for an FM, so the answer to your first question is yes. I say go ahead and make them and let's see how they look in game. We're an open source game. Make what you want to see. That's always been the TDM way!
  7. The editor is a tool in the service of a mapper getting their vision into the map. I think having brushes more accurately reflecting their final state, or what's most useful for the mapper to have it reflected as, can be fairly seen as contributing to that task. At the end of the day, mapping has as much to do with the attention and motivation of the mapper than the technical aspects by themselves. And the benchmark is what mappers find useful. I'd think of it as in the neighborhood of grouping; it's a mapper added tweak for mapping purposes. So I think it's a worthwhile feature to have. That said, it'd call for a feature request, and I don't know how high the relative priority would be for it, which is another issue.
  8. Isn't rewinding time just another way to say perpetual autosave? Or do you mean the world actually animates backwards so you can pick your pick-up point? Anyway, just knowing what save does, the processing burden would have to be too high. If I were doing it, honestly I'd just hack it with an updating screen record, autosave, and play the recording backwards to the autosave point. Aside from the tech burden, I think it's a bit too gimmicky for my taste. Just my aesthetic opinion. A couple of us have thought about a scifi/cyberpunk version of TDM. I would love to see that! The issue with porting it back to Doom3 is that it's locked to Doom3, and there isn't too much to Doom3 beyond just the vanilla game. (It doesn't have so many fan maps or a mod scene anymore.) But if it were a Doom3-like scifi shooter that was friendly to fan maps & released for free, that'd be cool. That said, I would be happy to see the improvements ported back into the Doom3 engine if somebody had the initiative to do it. Lord knows it could use it, and it'd be a path of least resistance if someone were that motivated to update the game's engine.
  9. It's like the Diablo 2 version of Thief. Pretty cool if someone is in the mood for an isometric action RPG to have a Thief-inspired stealth-version to play. I like the idea looking at it from that perspective. I remember when we first got the TDM engine up and running moving the camera to follow the player isometrically, and I was thinking about making an FM in this kind of style, making the game more action and platform oriented. I still might do it sometime. (Our player animations, bare as they are, are not really up to the task though.) But it's cool to see someone really take that idea and make a full game of it. Good luck with it!
  10. Cool. For my campaign I scripted, one mission took place in the Inventor HQ for Bridgeport, called Secrets of the Inventors. I was thinking a lot about how to represent them and their areas, and I'll be really interested to see how other people portray them, because there hasn't been that much representation of them in FMs.
  11. Haha, wow, I don't think I'll ever tire of hearing how awesome we are. I've always thought we're awesome. But sometimes I wonder if it's just our little bubble, and maybe a few people at PC Gamer, where we think that. It's really cool when people from outside our bubble come in and let us know that it's not just us.
  12. Gothic 2 is generally considered to be the peak of the series. Or there's more consensus about how good G2 is, whereas Gothic 3 has more mixed opinions. I used to think about it as similar to Bard's Tale 1-3, but that's a pretty ancient example now.
  13. I think a more general statement would be better, since UI shouldn't presume your intention, something like "X surfaces are selected for retexture.", which will have more utility than just a notice, but it's also a notice.
  14. So a priority rule? Makes sense to me to some extent. The thing is when you're texturing a lot of surfaces with the same texture at the same time, some brushes you may want to texture the whole brush (select) and some you want to texture only one surface. How about that situation? (...if I understand your proposal and what DR is doing correctly.) I don't remember this being a problem for me because I instinctively clear all selections in situations like this.
  15. The gameplay appeal of restricted saves is the same type of appeal of permadeath in rogue-likes. The stakes are ramped up much higher between save rooms, and you just feel the flow of a game differently when the stakes are high.... There's a much bigger adrenaline rush taking on a challenge, and a much bigger wave of relief when you pass a part. And if you want to think about it from the other direction, compared to permadeath, save rooms are pretty forgiving. You don't have to start completely over. Where it looks like there is general agreement is that there's definite player types. Some players get off on high stakes & big adrenaline rushes, and restricted saves gives them that. Other people get off on the pure flow of making steady and sure progress, and restricted saves are like a punch to the gut because it takes away the one thing of value they get out of a game, the progress they've already achieved and now are asked to do again. And I think a lot of people can be in one or another state depending on their mood. It's really easy to see how different types like that are going to have polar opposite feelings about this mechanic. It's not really rocket science, and it's kind of funny to even "argue" about it, when it's a pretty transparent matter of taste.
  • Create New...