demagogue

I'm listening to this while I'm opening up this thread, so I guess I may as well as post it here. It's nostalgia incarnate.

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).

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

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.

There are actually two pathfinding scripts, one for human-sized AI and one for rats. So rat sized AI are okay.

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...

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!

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.

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.

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!

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.

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.

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.

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.

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.

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.

I like this kind of system occasionally. I think the beauty of the FM system is some system-level things can be different across FMs, so you get a different experience, and I think as with most things, the best judge is the mapper for their own map (granting that it needs to be beta-tested to make sure it works as intended). I don't like design by committee, I mean after the basics are settled. I like design by an author with a specific vision, where all the parts fit their vision. Better it having some things I don't like but part of a strong unified vision than a lot of things I like but thrown together wishy-washy. So all that said, generally I like open saving and just personally committing to dealing with the consequences of my actions and only having the save game there for if I die, or there's such insane guard frenzy after 5 minutes it breaks the game. But save restrictions do make a different experience that I can appreciate when it happens. I'm on board that it should be only one difficulty level that isn't different from "Normal' though. I think it'd be interesting for there to be a general save restriction option anybody can turn on for any FM. But we already have the stat screen record how many times you've reloaded, so if you do Ironman it, it is registered. I always thought that was sufficient for people wanting to scratch that itch before some complicated system that literally shuts off your save button.

Yes, by "we" I meant with grayman. It was really a pleasure working with him on this. Well the tasks themselves got frustrating, but it was great working through them with him. I learned a lot about coding from him, and he did so much for us under the hood. Another reason he's really missed. I believe the original code might have been set up by Greebo, then iirc Fidcal did the first version (when the score was subtractive, so almost everybody got "0" almost every time), then I edited that to make it additive, then grayman fixed up a lot of the bugs like the cascades, and I just chat with him about how a few things might best be done. It's gone through a lot of hands. But grayman could have probably followed what it does best. The way you're describing it now sounds like it's not a problem with the score per se (I don't think it's been changed in a while anyway) but the way the alert system itself works though. But I don't really know offhand what it could be.

Wow, this is a lot more ambitious than a little contest mission. Congratulations on releasing a new classic. It looks & plays great!

Yes, level 1 alerts don't count to the score.* If other people are being alerted by his barks, I don't know how attribution works. But I believe it's not going to be counted to the score even if it's attributed because we got rid of alert cascades, where 1 alert can cascade into stealth scores that go into the 100s. I haven't looked into the details recently, but if it turns out to be a trade off between these two bugs, stealth scores where a tiny alert cascades the score into the 100s vs. transmitted alerts triggered by a tiny alert only counting that tiny alert (and in the case of an level-1 alert, not counting at all), I think I still think we're on the right side of that dilemma with stopping the cascade. That's just my initial guess that that's what's happening, though. --- Re: your last question... At the bottom of the stat screen should be a down arrow. When you click it, it takes you to a new screen that shows you the exact break down of the Stealth Score. There are 5 alert levels. The first two are "suspicion", the first of which is not counted to the score (but is counted in the "Suspicions" count). So only 2nd level suspicions are counted to the score (x1). The next two are "search" (x2 and x3 I think). And the last one is a sighting (x5 I think it was?). I don't know what you mean by "the fifth number" because I don't have a screenshot of the stat screen on-hand and don't feel like playing a whole mission to completion to get one. If you post one and circle the number that you mean then I can let you know more specifically, if what I said doesn't already answer your question. * Footnote on that: A substantial number of FMs have the player putting AI on level 1 alerts even when they just spawn! Or in places it's impossible to pass without a level-1 alert. So there's a good case to drop it, at least from the stealth score, because it's ridiculously sensitive. And we still do count it in the Alert list! So it's not like you're completely "getting away with it". But we thought the score should be as fair-play as we could make it.

If I recall this issue correctly, the alert has to be attributable to the player. Of course if a separate AI puts a guard on alert, that shouldn't add to the player's score. If there's a weapon on the ground or a door open / torch unlit (with the "door shouldn't be open" / "torch should be lit" boxes checked), the guard will go on alert, but nothing is attributable to the player yet (I think), since anything can cause those events. If they find a noise arrow, then it gets more debatable as it still follows the general unattributable weapon rule, but as a game, only the player is using noise arrows. (That may have been updated though.) So the issue here may be that it's a touch stim, not a sight or hearing stim. That's what I'd look into. Does the touch stim creating an alert carry an "attributable to player" property which is properly being registered by the part of the code that counts up the score? Or something like that. It could be a completely different issue, but it sounds like something to do with the touch stim.

Yeah, good idea ... for a robot.

I'm late to the party, but that volumetric lighting looks really cool! I can imagine it adding a lot of atmosphere to levels in a lot of different ways. Good work, team!

I don't feel like reading that thread, but I think a mapper might be able to hack this on their own. The idea that comes to me is spawning in a series of simple horizontal walkable objects from destination to origin, and then just have it render as a rope-looking object. It'd probably be much easier done as a pre-set-up system (like a prearranged place where it spawns) than an open system you can do anywhere, since there are so many variables involved you'd have to control for in the latter. But never say never.

I missed it by literally 4 minutes.