demagogue

I was just reading a post over on TTLG about Thirith's experience playing Sable when he realized the game played significantly more smoothly, and the movement control was less wonky, at 30 fps than 60 fps, and then I see your post explaining just that. Edit: I should have double checked the date. I didn't realize when I clicked the thread that it didn't take me to the latest page but evidently to the last point I had read up to, which was more than 2 months ago. Sorry about that. Well it's still an interesting thing to point out anyway.

I don't recall a system for noise masking. It sounds like it'd be a good idea, but when you get into the details you realize it'd be complicated to implement. It's not only noise that that goes into it, I think. E.g., a high register can cut through even a loud but low register rumble. And it's not like the .wav file even has data on the register of what it's playing. So either you have to add meta-data (which is insane), or you have to have a system to literally check pitch on the .wav data and paramaterize it in time to know when it's going to cut through what other parameters from other sounds. For that matter, it doesn't even have the data on the loudness either, so you'd have to get that off the file too and time the peaks with the "simultaneous" moment at arbitrary places in every other sound file correctly. And then position is going to matter independently for each AI. So it's not like you can have one computation that works the same for all AI. You'd have to compute the masking level for each one, and then you get into the expense you're mentioning. I know there was a long discussion about it in the internal forums, and probably on the public subforums too, but it's been so long ago now I can't even remember the gist of them. Anyway the main issue is I don't know if you'll find a champion that wants to work on it. But if you're really curious to see how it might work, you could always try your hand at coding & implementing it. Nothing beats a good demo to test an idea in action. And there's no better way to learn how to code than a little project like that. I always encourage people to try to implement an idea they have, whether or not it may be a good idea, just because it shows the power of an open source game. We fans can try anything we want and see if it works!

I was about to say, follow the tracker and you can see exactly what's being worked on, and often the entries come with comments talking about all the issues involved with it, so you know why this or that is being done and not that or this. Then you can even give comments to the comments here, and you're on your way. The point is, it's important to follow the tracker because otherwise you don't really have any idea what's going on behind the scenes. It happens so often, something you think should be a really trivial thing is actually mindbendingly complicated because of how the game deals with that system, and other things you think could never be done, once you actually look into it, turn out to be really easy, or something you think you see is really a kind of illusion once you dig into it. You just never really know until you get into the details of it. But if you do get into the details, once you starting understanding your way around the code, suddenly your comments can be really helpful. Oh, sorry, I didn't even mention the main point of following the tracker. That's where you can see if the issue you're worried about has already been tracked and its status, or you can track a new issue if you don't see it already there, and then follow its status from there.

I think it has to occur before the "go to exit" objective is triggered. That may just mean moving its place in the objective list, but another idea is to change the "go to exit" objective from that specific objective into triggering two arbitrary objectives in a row or triggering a script that triggers two arbitrary objectives, "objective1" (which checks the "don't kill" box) then "objective2" (which checks to "go to exit" box if all others are fulfilled). ... This question has probably come up before, so run a search for it. I feel like somebody would have thought about this in designing the objective properties.

I think it's probably right that the game doesn't presume when to check objectives or not, but it's really up to the mapper to design it. I think the simplest way to do this IIRC is to have the objective logic just fulfill the objective when all of the other objectives are fulfilled, but of course still irreversibly fail if the player kills. That should do the job.

I mentioned this in a similar thread on TTLG. If there's going to be a new Thief game, my vote is for a remake of the original Dark Project.

Yes, and speaking of memory, yours is better than mine. But in fairness, the whole point of the contest is that we're coming up on the 20th anniversary of the game!

You can probably find the postmortem about it. They were using the Unreal engine whichever version, the same used for DX:IW, which was already kind of cramped with memory as you can see in that game, although still worlds better than Dromed! But one guy on the team implemented real time shadows IIRC on his own initiative. So they moved to that new version and got sunk into it before realizing it came with some heavy costs, like the memory use was so tight they had to chop the levels into parts with load zones, performance was a constant problem, and a lot of features had to be cut for related technical reasons like rope arrows, swimmable water, etc. And by then the original guy had left the company and I think know one knew the inner workings well enough to know how to fix it. Something like that. Then all of those problems just got compounded with the editor version for people making FMs. It wasn't even out that long before a group of editors and fans started looking for an alternative engine they could make a total conversion just for making FMs the way the game was meant to be, and the Doom3 engine fell right at that time... And that ultimately led to Darkmod.

I don't think a material pack would be judged as part of the contest, but I'm sure it'd be appreciated and in the spirit of the thing. I think it's a great way to be part of the action. I also don't think you'd need to make a full FM. Just a demo of the material pack and/or a nice T3 inspired environment would probably be cool too. Well do what you like. We're talking about being fans of a video game at the end of the day.

In a weird way TDM can thank TDS for its existence, being so mod-unfriendly. That's reason enough for us to be part of this contest. Then you should be happy to know you can make an FM in TDM for the contest.

Higher-level alerts cost more to the score. It's not exactly rocket science. An extra point per level except the highest is even worse, and you can't count level-1 because half the FMs have the player spawn with level-1 alerts. Well more importantly it's not counted in the original rules for ghosting, which is what it's originally for. But to your point, not knowing where the Stealth Score comes from makes it even more arbitrary to the player. It has to come from something, and it's going to be arbitrary no matter how you spin it, so may as well explain how it's made if it's going to be there at all. Anyway it's well out of the way.

I saw that featured on Steam's homepage today and was intrigued. I liked the aesthetic. I didn't really understand the gameplay, but maybe I'll watch a few videos, since it sounds interesting. The concept of a procedural murder/crime & investigation sim sounds pretty fresh; it's a wonder we haven't seen something like it before.

Here's a good video of a demo for talking to a ChatGPT NPC in-game. There are bugs to iron out, but I think we've basically arrived, at least at a level functional enough for NPCs.

I don't think it's entirely off-base that there's a link between the game being conceived and made largely by map editors and the main antagonists being Builders preaching about good design as a religious sacrament all the time.

The current working title is just The Dark Campaign. If you want a little backstory, the idea of this campaign was to introduce all of the major districts and factions of Bridgeport, and give a lot of lore about what's happening in the city and the world. So in that sense it's meant as a kind of ... not official campaign, but the kind of campaign laying down a lot of lore, faction, and setting information on which people can build FMs. But then the story started taking on a life of its own. The concept is the Empire is at war with their neighbors Menoa. In this world, Menoa is an Islamic or Ottoman-like empire counterpart, the Ghazis, to the Catholic-like Builders. (I understand the more official concept of Menoa is different, but either my concept is just different or I'd pick some other empire to do the job.) At the start, the Menoans have Bridgeport surrounded in siege, with constant flaming boulders periodically raining down. So our protagonist Khursand is Pakdamani, which is a counterpart to Persian Zoroasters, with his homeland now fully occupied & harassed by the Menoan Ghazis, although his family has already lived in Bridgeport for several generations, also harassed by Builders but at least not killed or forced to convert (yet). So he's kind of a natural opportunist, no friend of either side, but he speaks both languages of the Empire and Menoans and is willing to work with whoever pays. So the first mission, Shadow of Opportunity, opens with the Menoan district of Bridgeport, where Khursand lives, being walled up into a kind of ghetto to contain them. You've got Menoan friends that want you to help their resistance from the inside, starting with you getting some city plans to the army outside. But as you're getting out, one of the guards they paid off double-crosses you and turns you into the Bridgeport forces. But rather than just executing you, the general gives you the alternative option to work as a double agent on their behalf to bring back intelligence on the Menoan army and do some sabotage on their behalf, which you don't have much choice but to accept. (They're also holding his uncle that raised him hostage.) The next mission has you making contact with the Menoan army and already trying to please both sides in a dangerous tightrope walk, and the story goes on from there.

I'd make the campaign I scripted out for Dark Mod. I also think it'd be good to just make a medieval stealth game with a new protagonist, and just call it a spiritual successor.

I like the Gershwin tune. I'll have to see about the game.

That'd be a great idea. To dynamically change EFX, we have to know that it's a dynamic feature and not one permanently set during dmap or spawn time.

I really knew that & shouldn't have said it, but thank you for correcting that. Oh wow, how did I not hear about EV_GetLocation() before? That's great! As for the performance part, stgatilov makes a good point. If you want to keep running track of the AI's location, you have to keep the script running in a loop, which can really eat up up cycles. (Performance was one of our big concerns with the Location script itself because of that.) One thing I'd think about is having the script or EV_GetLocation function called only when an AI is ready to make a bark, and it quickly gets its location from there and makes the bark, and then it's done. Then it's only a one-shot script or function call, which is always better if you can do it. The catch there is I think that'd call for a custom AI script. The issue is if the a future version of the game ever updates that AI script, the custom scripts won't be updated in that version. But since AI scripts should be self-contained, I mean changes almost always take deprecated old stuff into account so it doesn't break old FMs, a custom AI script shouldn't break the FM with new versions of the game. Those AI just won't have any new bells or whistles, which may still be worth it. Or you just quickly add the new things in and kick out a new version if you need to. Of course another option is that new functionality is added to the core game itself with some new spawnargs added to AI, where barks can be made Location specific. For that matter, the AI scripts might be updated to be more friendly to adding barks to existing AI generally, now that we have a good text-to-voice app to make them. Then all mappers get the ability to do this. That might be nice, if it isn't a big performance hit or otherwise troublesome.

My old answer to this question used to be, well, you know, you could always make a quick FM for everybody to solve that problem. A person could make a contest sized FM in like 1~2 weeks.

This is the first idea that comes to me. The easiest thing you can getkey from the AI is the literal xyz coordinate location. So you could have a script make a simple distance check from that to the player's position via good old Pythagoras's Theorem. If you trigger a "nearby" state at a distance that's close enough, that will probably put them in the same room or anyway nearby. And you can get the player's location, so you can still modulate the barks based on that. In the background of what you're talking about is that with the new text-to-voice AI they have now, we can make new barks that sound exactly like the original voice actor. That makes it possible to add to existing AI barks, so we can make convo barks in the same voice as the system barks, or we can make new system barks, etc. I think there's a lot of good potential with that for unique and more interesting AI interactions in FMs.

Part of the location system is a script hook, where you can trigger a script based on location. But of course it's geared to the player's location. But it itself is just a script, so it's easy to just make a new copy, keep just what you need, change the variable names, and instead of a player location check at the top, you make an AI location check. And then you can have that new location script trigger a AI-location-script to keep track of the AI's location. (I tend to use the spawn args of dummy objects to hold data like this, but however you want to do it.) Then have it or another script trigger the barks based on that location value. And because it's all being done by script, you can package it with your FM to work. No sourcecode change necessary. The catch is, I don't know if id4's location system even recognizes AI. I think it may only be able to send back the player's location. If that's so, either you have to then change the source code for it to track AI location (which might give a performance hit?). Or another way is what I originally did for the location system, which was to use trigger brushes (the "object inside boundary" trigger brush type) at the entrances of locations and let those trigger the script that does the work. That should work but is more fiddly since you have to make sure the AI can't break its logic going back and forth many times. It's definitely possible. (Anything is technically possible. It's an open source game.) It might take some work to make it robust and not fiddly. Edit: A thing to keep in mind is that most AI are mostly frozen when you're not near them anyway. If I were trying something like this, I'd just use the location system for the player as usual, so it's the AI barking differently based on the player's location, not the AI's location, and then just design the level so that works out properly. (Most AI that the player will ever hear will be in the same location as the player. So the player location is a fine proxy.) Then you can just use the current Location system script as I mentioned at the top.

I've been watching too many quantum physics videos. I thought you were gonna talk about the collapse of quantum wave functions. But anyway, Tels made an algorithm that made a procedural dungeon for his own TDM branch. I don't know what the relationship was to this algorithm, but the result sort of looked like this.

The value is that authors can make their own dialog instantly, listen to it, change it instantly, and go through 20 iterations in a half hour, and do it all night long. In particular, you can keep doing takes of the same line until it gets the prosody how you like it. You also only need about 1 minute of a sound clip to make a perfect rendition of a person's voice. And it doesn't even have to really be a good voice actor. You can use your own voice or family members, etc. The system makes it sound good as far as voice acting. Using a real person is great, but it can't really compete.

I remember reading about Spar talking about the S/R system in the dev forum, which was interesting for me. (This would probably have been years after it all happened because I was a latecomer too, although IIRC he was still around then, but I was really absorbed with reading old threads anyway.) Unlike many of us, he'd never made FMs for Thief. So his knowledge of Thief's S/R system came from the reports of people that had come from Thief mapping, and he did his best to reproduce what they were saying. He was a bit worried about if it would meet mappers' expectations. But the system he made was pretty cool, and I think even a bit more intuitive than Thief's system. (They ended up not too far apart anyway.) But it made me think sometimes not knowing exactly what a thing is, but having a vision for it can be liberating... because you can follow the vision without being bound to the past. I guess that's not such a big insight into him. He had a thoughtful leadership style, and I guess no more or less human than any of us. The lesson I got from that story kind of stuck with me though.