Skaruts

Since we're still on the subject of randomness... just a few days ago randomness got me caught by a guard. This is in my own mission that I'm making. The guard is sitting, and every once in a while he walks to a furnace to warm his hands. When he does that, as soon as he faces the furnace and starts warming his hands, you can sneak behind him to the other side of the room. Except this one time, he stopped at the furnace, and before he started to warm his hands, the game decided he should stretch his arms first. Because of that, he didn't turn to face the furnace as I was expecting, and he caught me sneaking... Indeed. I think random variations can be great, but imo one should be careful with varying the patrol time too much. Depending on the length of the patrol. In the mission I'm making myself, I almost made that mistake on an NPC with a very short patrol. I ended up preferring to swap one action for another randomly, so there's always an action, and the patrol time is always the same. For longer patrols I personally think maybe a variation of up to 5 seconds can be ok. Because there's also another thing to keep in mind: the player may have to wait for the AI. So I think it's better if the AI isn't randomly deciding to take its sweet time coming back or going away. Another one I think it's fine is random patrol ends: one of the guards in my mission, on one end of his patrol, will randomly stop at one of two places reading papers on the wall. But those two places are very close to each other, so the difference is minimal, but he's he's facing different directions, so there's a slight trap there. I think it's fine because it's something the player can easily pick up on. I don't mean to fully discourage the usage of randomness. Whether or not randomness is good, really depends on how you answer this question: is the player limited to just gambling forward and quickloading (bad), or is it still possible for the player to reliably anticipate the AI (good)? Keep in mind, you can make a fully predictable AI be really hard to work around, through thoughtful placement of sentinels and patrols. The goal of guard placement is to create a puzzle the player must solve. And, imo, the difficulty should be in the puzzle. Also keep in mind that certain randomness will affect what happens after the player quickloads. It's annoying as hell when it's not what the player is expecting. Thief 1 and 2 did that a lot too...

Personally I can't quite pin-point what makes missions fun for me, but I can pin-point things that have ruined the fun for me. The biggest is unpredictable AI. If the AI isn't predictable, then a player can't strategize and the gameplay is merely a gamble where you just quicksave and blindly press forward hoping randomness is on your side. For example: Random AI paths/waits. When I see a guard go left, and then I strategize based on that, and when I'm ready to apply my strategy... the guard goes right. Or when I got caught by an AI that started patrolling, and I quickloaded thinking of waiting for the AI to pass by, but... the AI decides to wait in its post for an extra 10 seconds this time... Random head turns. I really get thrown off when I'm sneaking behind a guard and he randomly looks behind and catches me. This also ruins strategic planning. Another thing that throws me off is when you have to step into complete light to open a door, and there's a guard on the other side looking at it every 5 seconds. I just lose trust in that mission's sense of fairness.

I was writing the mission briefing and I ended up making the loot loosely tied to the goal, so I decided to keep it. Basically, the mission is a favor for a friend who isn't able to properly compensate you for it, but the victim is wealthy, so whatever loot you find along the way can serve as compensation for your trouble. Yea, that's exactly what I would expect, and I would also expect some players to be confused about whether they're supposed to loot or not. That's my motivation as well. I just started replaying Thief 2 and I'm stuck in the first mission because I can't find enough gems... and it's driving me mad that I can't just move on. Same for T3's first mission. I have the game patched so the first mission is a real mission, and not just the tutorial, but then I can't move on because I need a 3rd special item and 30% more loot, even though it seems I've turned every stone... It's annoying af. (I know I can skip missions with a key combo, but I was hoping to avoid that.)

What if the loot objective wasn't even there, in cases where loot is entirely optional and without ties to the plot? My current mission looks like this: Find Tasteless Bert's Recipe Journal (Optional) Get any loot you can find Get back out the way you came in Seems rather redundant to have it there. Players will get loot if they want anyway. Or could it confuse players, since it's a bit unexpected and unorthodox?

Could it be at the top of the screen? I could live with that, though. Seems ideal.

@Dragofer @snatcher alright then, thanks for the clarifications.

Hmm... I just saw it in a video, it's also an item in the inventory, but you have to use it to see the stats. It's actually less ideal, imo.

What patch is that? Sorry, I'm very unaware of non-vanilla TDM stuff, so I really have no idea what exists, aside from the FMs. That sounds like the stats tool I was asking for, though.

The stats are an item in the inventory, so each time I pick something up I have to switch back to the stats (I've bound it to a key, but still...). Each time I need to use or drop something, like a key, I can't be monitoring the stats. And again, I keep having to switch back and forth. It's not ideal, at least to me. The other version, which I think is dragofer's, that I've seen on youtube, is a paper message thing on the top left. I don't know exactly how it works, but I'd like to try it out.

@Dragofer does your version work in 2.12? I'm confused about what to download. I tried one z_addon_stealth_statistic_2_07.pk4 that I found somewhere in this thread, but it didn't work. I tried out @kcghost's version (it works on 2.12), but I found that it interferes too much with my usage of inventory items, so I'd like to try out yours to see if it's more comfortable to use. I think I've seen a youtuber use it before.

@demagogue I'm not being able to get them checkmarked, anyway. I used a trigger to see if they would, and they didn't (I used an extra dummy objective to be sure the trigger was working, and that one did get checkmarked). I suspect it may have to do with them being set to "ongoing". Like I mentioned before, the kills objective is already fulfilled from the start, anyway, and it's not checkmarked. Still, I don't think that would work. It just adds complications that I think are unnecessary. The kills objective could simply be checkmarked, but the loot objective (or any similar ones) couldn't. You'd have to check if the played actually did get loot or not. That would require some actual scripting, I suppose, which I don't think should be required for this kind of thing. I still think this is something that should be handled by the game. The issue here is simply there not being a visual feedback for the completion of "ongoing" objectives, and the completion of those is only at the end of the mission. The game should simply check whether or not the objectives were fulfilled and override the "ongoing" thing and checkmark them. Although, a player would only have a few seconds to see their objectives checkmarked. I think this would be more meaningful if the game allowed the player to review the objectives after the mission. If that was a thing, then those objectives wouldn't have to get checkmarked until after the mission. The issue above wouldn't be an issue.

How do you do that, though? I tried changing its success logic to make it depend on the "go to exit" objective, but that didn't make any difference. Still didn't get checkmarked at the end. I mean... it's the end of the mission. I don't think there's any assumptions to be made. If the player didn't kill by then, then the objective can only be fulfilled. Same for the loot one I made. The "no kills" objective is different from the loot one, in that it's "satisfied at start" and "irreversible". If the player kills, the mission fails, rather than the objective. It's only not checkmarked from the beginning because it's "ongoing", I think. But I still don't see any reason why it shouldn't get checkmarked at the end.

Not sure if this is a bug, or something that could be worked around in DR, but ongoing objectives don't get marked as completed at the end of missions. Here's a small video to illustrate this: https://i.imgur.com/qRkcmJ7.mp4 The "No kills" objective is the pre-made one from the mapstartpack_complete.pfb prefab. I didn't make any changes to it, apart from the displayed text. I attached my test map here, where I've been experimenting with these objectives, and it's easy to reproduce this behavior in it (as seen in the video). On a related note, TDM could display the complete list of objectives after the mission is completed (alongside the mission statistics). I think that would be a nice thing to have. loot_obj_test.map

I was thinking of trying something different for the loot objective in a mission I'm making. I don't really mind the traditional way, but sometimes it can get the player stuck, and I don't like having to think about a percentage of loot that seems fair (which, I think, depends highly on the mission's layout). But I'm not sure how to go about this. My first thought was that I could make it optional, and show up in the list of objectives as something like (Optional) Get any loot you can find. I tried having it that way for a while and, personally, I think it's fine (except the objective logic doesn't work as I want it to; but that aside). I'm not sure what makes loot fun. But I'm sure we all get some loot, even if it's entirely optional. I'd love to hear some thoughts on this, or even, if anyone has tried different things, I'd love to hear about it.

To be clear, my assumption was based on there already being several different object grouping systems in place, and my conception of this new potential kind of prefab being just another kind of grouping system, and so, even if I don't know how it would be implemented (because I'd have to look at DR's code to know more), I'm safe to assume that it is in principle possible. Of course, it might not be possible given further details, but that's where I was trying to get us to. Anyway, thanks for your other reply. That cleared things up a lot.

Well, that's why I said "I don't think it requires...", and not "it doesn't require...". But I explained my reasoning. I'm only discussing an idea here. With a prefab made of brushes you don't have to create skins, you can just replace textures as you please, and the prefab can exist in a single file.

Well, not really. The way I was suggesting it, the map wouldn't reference anything from the file, or else you'd have the issue Springheel was talking about. The map would have to keep track of the prefab only internally. The details of the implementation, I don't know. But I don't think TDM would require any changes. My assumption is that these objects could exist in the map in some similar way to layers, selection sets, etc, and I presume TDM doesn't even know they exist. But perhaps you're right. I'll have to look into how to create custom entities. The only problem I see with exporting as models is that it requires you to then manually edit files to support skins on it.

I like this idea, actually. Every time I make a prefab, I use it all over the place, only to then realize I did something wrong and now I have to fix it in like 10 or 20 places, or not fix it at all. Would be nice to be able to change once, and see it reflected everywhere, even across different maps. Currently, DR doesn't recognize prefabs as anything other than a regular group of objects. In other words, it's only a prefab while its in the .pfb file. Once you place it in the map, then it's only a bunch of objects like any other bunch. This requires that DR would recognize a prefab as an actual object. But it would have the potential to make building certain things much easier. That's indeed a concern, though. Maybe changing the original prefab could have no effect on anything. Perhaps the prefab, once placed in the map, could be stripped of any relation to the prefab in the file. And so, copying it around the map would still make it so changing one copy would affect all others, but those changes wouldn't carry across maps, and changing the original one wouldn't affect your map at all. (Though this would mean that placing that prefab in the map again, from the file, would make it belong to a new set of copies with no relation to the existing set). And in that case, DR could then provide an interface for replacing a prefab with another, and you could use that to update the ones in the map, where replacing one copy would replace all others of the same set. This would give the user complete control over when and how updated prefabs should affect their map.

I've been thinking about this for some time. I think the layers and filtering systems could be greatly improved, and, having used Hammer extensively in the past, I can't help but bring my ideas from it. Because, tbh, I think Hammer's way of doing this is the very best example of how we could improve layers and filters (for some odd reason, no other editor that I've used does a good job at this -- not even TrenchBroom). And the reason I'm putting layers and filters in the same sentence here, is because they're actually the same thing (or ought to be). I'll explain that below. On layers: One of the issues with layers is that the interface is a bit bulky. I've had to make extensive use of them since I started a complete overhaul of the mission map I'm currently building, because it's easier to work with layers than with regular grouping (because you need to ungroup to edit stuff, then probably isolate things, then re-group them). But I've been finding layers quite unwieldy as well. This is how my current layers list looks like: It doesn't fit my screen anymore. But you might notice another issue: I've resorted to using underscores and prefixes (or CAPS) to try to keep them organized, because there's no way to group layers by their relationship. But I think there's also something to be said of the rename/delete buttons, which could be on a drop down menu, to save screen space. As it is, I've had to keep reducing the size of my DR window to allow more and more space for the layers panel, as the names grew wider and the buttons became hidden. Another issue is the buttons that are at the bottom will go off into oblivion when you have so many layers. I think they might be better off in a toolbar at the top. Yet another issue, is you can't hide things that belong to more than one layer, if one of them is set to visible. The visible one will always override visibility to on. Say you have stairs on floor1 and floor2, and you want to nudge floor1 stuff but not the stairs. In that case it's easy to deselect just the stairs and nudge away, but you might easily imagine it becoming complicated when you have many more things to deselect that overlap between two or more layers. You'll forget some, and you may not notice your mistake soon enough. So it would help if you could select floor1, then hide floor2, and it would hide all the overlapping content with it, removing it all from the selection. As another facet of this issue, I have a layer there called new___thug_house, which was supposed to contain the entire house, but doesn't have anything in it anymore, because when it did, then I couldn't hide anything by hiding the other layers. And so at this point, the only way I have to select the entire house, is by clicking all the layers one by one (which is one reason I didn't create even more layers related to it). On filters: The main issue with filters is that you have to either keep browsing the menu, or remembering whatever hotkeys you reserved for it. E.g., I have ALT-P, ALT-SHIFT-P for patches or paths, and ALT-C, ALT-CTRL-C and ALT-SHIFT-C for clips, collisions and caulks, but I often forget which is which, so, for me, there's always a bit of recap trial and error involved in using some filter hotkeys. I suspect this is also a limiting factor on how many filters DR offers by default, or even how many users can feasibly create. Because the menu would grow even more unwieldy if DR would support even more filters, and you can only feasibly have (and remember) so many hotkeys with a consistent pattern. Now, Hammer did this this pretty well. And the way it did it shows layers and filters ought to be the same thing. It was all in one place. To be perhaps a bit pedantic, let's face it, the concept of "layers" doesn't apply anywhere in the context of a map (TrenchBroom is doing the same mistake). If we call a spade a spade, then "groups" is what layers actually are. Or more accurately, "visibility groups", which is what Hammer rightfully called them (VisGroups, for short). Here's what VisGroups look like in Hammer: They are compact and still fit my screen (on a map that reached the limits of Hammer (8192 brushes)). But even if they didn't, the tree structure makes it easy to collapse them. And it also makes it easy to organize things. In the way Hammer did it, you can also toggle off a parent visgroup and then toggle on a child visgroup to override visibility. Or, you can do that with unrelated overlapping visgroups as well. The last group you toggle on/off will override the objects it contains to visible or hidden. Now, you might notice there's an "Auto" tab at the top. This is where filters come in. As you're editing your map, Hammer automatically creates visgroups for all the things you have as filters in DR and more. There's no need for menu access or hotkeys, they're all right there at the tip of a single mouse-click, and are listed in the same place as other visgroups (Monster clips would be listed under "Tool Brushes -> Clips", but this was a deathmatch map, so there aren't any). And if you need to disable all filters you can just toggle the parent node off. DR actually has one advantage in this: it already allows the user to create custom filters. So with a system like this one, it could support more (and more specific) filters by default, as well as allow users to expand it.

How is the workflow in TB for TDM? I mean, are there any shortcomings, limitations, etc?

The other odd part about the nodraw thing, is that my materials don't even change any of the nodraw_solids. In fact, the nodraw_solids aren't even in the files I edited. So I'm not convinced they're the problem. As for the bug, I don't know if it's DR or dmap, really. But just yesterday I had to create a random throw-away brush, because there was a func_static which I had made non-solid, but its collision was still there after three consecutive dmaps. After I created that brush, then the collision was gone. This happens to me somewhat frequently. That said, I'm gonna use DR without my materials for a while and see if the issues persist, just to be sure.

Actually I'm confused. Something isn't right, but I can't quite pin it. I just tested this in a test map and nodraw_solids are working fine with my materials. I may have found a what seems to be a bug in DR, which may have been what confused me before. May be a known bug (if it's a bug), but I didn't know about it until today: if you only change the material on a brush from one nodraw_solid to another and then dmap it, nothing will change in the game. That surface will keep making the sound from the previous material that was there. You have to also edit the brush itself (e.g. shrink or enlarge it a bit) in order to make it work. At least that happens on my end, regardless of my custom materials.

@OrbWeaveris there anything about the materials that gets saved into the map file itself by DR? Because I'm having issues with nodraw_solids that make me think that's the case. (Sorry for revamping this after so long, but I've been away from TDM all this time (again), and just starting noticing this now.) Just one thing first: when I'm using my materials for mapping, I'm not using them for dmapping. I use a batch file similar to the one suggested by @Zen3001in a post above, which temporarily renames them. So as far as the game itself is concerned, it's using all the defaults. Now, the issue is that nodraw_solids aren't properly working in-game. Collisions are fine, but the sounds are not. A nodraw_solid_metal will not sound like metal (will do some generic sound I think, similar to jumping on a mattress). Given that nodraw_solids should work just by being there, as far as I know, I thought this might be caused by my materials. So I removed all custom stuff from the TDM folder, and tried dmapping the map again, but still didn't fix it. I went back in DR, resized the brush a bit and re-saved the map, and only then dmapping fixed the issue. Suddenly nodraw_solids were making respective sounds. So that makes me think DR probably writes some crucial material information to the map file that makes my custom materials problematic. And if that's the case, then we shouldn't be using these custom materials at all...

Changing every "v141_xp" to "v141" did the trick indeed. Everything compiled fine, no errors, and the game runs fine. Thank you. Can I just ask, what are each of the projects for? On a cursory look, it seems like I probably don't have to care about any of them except DarkModTools, which is the actual engine. But I'd like to know for sure. Also, the code for DarkRadiant isn't included, right? (I don't see any mentions of it.)

I'm trying to compile TDM from source, to explore the engine for total conversion projects. But my hardware is a bit old, and the versions 2.08+ run into this black-menu issue (my gfx card is an ATI Radeon HD 4870, and the proposed solutions don't work), so I have to stick with older versions. So I tried compiling version 2.07, but it failed to compile. I'm not experienced with Visual Studio, so I'm not sure what to do. I get errors like this one: I tried right-clicking the solution and selecting "retarget solution", but it didn't fix it. I'm still getting the same errors. I'm not sure how to install the build tools says it requires. I'm on Windows 7 (x64), using VS 2017, so I'm not even sure I could use these build tools. Version 2.10 compiles fine, though, but I don't suppose there's something in the code I could easily switch off to make it run on my hardware.