Jump to content
The Dark Mod Forums


Development Role
  • Posts

  • Joined

  • Last visited

  • Days Won


Everything posted by cabalistic

  1. Well, that'd be that, then. Unfortunately, fixing the menu elements to use an index buffer isn't an entirely trivial fix, or I'd have done it sooner, but I guess we'll have to put it on the agenda somewhere
  2. I wonder if it's related to index buffers. Menu elements are (afaik) the last elements that are drawn from a CPU-provided index list instead of a GPU index buffer. Far as I know, the spec doesn't require one, or at least I couldn't find anything to the contrary, but it's possible some drivers expect them, anyway?
  3. No, the updater is outdated and afaik does not download the hotfix (?). Please use the new tdm installer, download it if necessary: https://www.thedarkmod.com/downloads/
  4. Please run the tdm installer again and upgrade to the 2.09a hotfix release. It fixes the particular error you've encountered. Can't guarantee that it won't run into a different error, but we won't know until you try
  5. It's an experimental setting, it's not in the menu and not enabled by default. Shadow maps are still a work in progress.
  6. If you want shadow maps to have comparable performance, you need to set "r_shadowMapSinglePass 1". In its default mode, it's well known to be slower than stencil.
  7. As long as the feature is broken, it will not become an option or officially supported in any way, hence why it is disabled now. The only reason it's even still in the code is the vague hope it might be fixed at some point in the future.
  8. The cost scales with the complexity of the highlighted object. A simple gold coin isn't really a concern, but a guard or other complex geometry may be a different matter. So be sure you test the right thing. Also, the hack means that while the outline is generally hidden by depth, it is not a perfect match. It will often slightly protrude into the depth-occluded region, which is not a critical concern, but it does look a little ugly to my eye.
  9. If it were just personal visual preferences, sure. But if it being on actually impedes mappers due to stuff being visible that shouldn't be, then making it optional does not in any way solve that problem. Therefore I consider the feature broken.
  10. I'm not frustrated, I am not emotionally attached to the feature in any way. It was an idea that was suggested to check out, and I did. Learned some things in the process, it's all good But I'm strongly opposed to leaving a broken feature in the game. We already have enough obscure features that are prone to break because they are not commonly used. If the feature isn't suitable for widespread adoption, then it's better to remove it and keep the code base clean and maintainable. How much time I did or didn't spend on the feature doesn't matter - that'd be a sunken cost fallacy.
  11. It's one of those things that appears to be simple to do, but really isn't. At the end of the day, there are really only two ways to do it: Mark the highlight mesh in the stencil buffer, then draw an extruded version of the mesh, skipping any pixels marked in the stencil and thus producing the outline. Works with depth out of the box, but will typically produce a hard border, not a soft glow. However, creating the extruded mesh is not a trivial thing for any non-convex mesh. Might be that Unity has tools for this, but we don't, and spending the time to implement something like this for an effect that's already controversial, anyway, seems like a huge waste of effort. There are some techniques with geometry shaders that can be used here, but you still need to preprocess the mesh data for them to work. Do an image-based effect. Draw the object to a separate color buffer, then blur it to create a soft screen-space silhouette. Can then be applied to the original buffer, again using a stencil mask to cut away the insides of the object. This is what TDM currently does, it looks pretty decent and is relatively easy to do. However, it has no concept of depth, at all. I've tried some hackery on top to get it to respect depth, which is what r_frobIgnoreDepth 0 does, but it's not pretty. Might be able to do better, but that would eat more development time with uncertain outcome. In the end, the current implementation is what you can do in TDM with moderate effort. Anything better requires significantly more effort, and given the lukewarm reaction to the feature, I really don't think it's worth that development time.
  12. r_frobIgnoreDepth 0 isn't a good idea for a default setting. As stated before, it's a rather expensive hack, and it can produce visual artifacts (of the kind where the outline is partially leaking into depth-occluded territory) that are not fixable. If the outline is so controversial, better to remove it entirely than enable it with that hack.
  13. It depends what you want to do and what inputs you need. Depth of Field might be doable that way, not sure. Motion blur is absolutely not doable that way or even at all, right now.
  14. Yeah, and I just don't think this by itself is interesting. Again as a reference, in Phasmophobia it is potentially interesting because you talk with the Ghost during normal gameplay and also with your team in Coop, so there is a clear incentive to use voice. Furthermore, there is at least a potential for jump scares that may get you to accidentally make a noise during the parts you are supposed to be quiet. In contrast, when playing a game like TDM on your own where there is little incentive to talk, I imagine most people will be silent, anyway, and the probability for making an accidental noise that isn't triggered by external circumstances (e.g. a room mate asking you something, noise from the street etc..) is, in my opinion, fairly low. OpenAL, to my knowledge, is a pure output library and has no microphone handling. Would require at the least a new library, possibly even separate handling per platform. Definitely not an afternoon project.
  15. Voice input can be an interesting game mechanic, but in my opinion there needs to be an actual incentive to use your voice in the game in the first place. This works great in games like Phasmophobia, for example, because you need to use your voice during gameplay to accomplish objectives, but then during ghost hunts you need to be quiet to not die. With this proposal, I'm skeptical that distracting guards is a good enough reason to use voice. Plenty of ways to distract guards, already, I'm not sure voice adds enough here. And since the majority of the game time you are trying to be stealthy (unlike in Phasmophobia), I think it would mainly punish the player / force them to be quiet most of the time, anyway.
  16. This unfortunately misses the point a bit. The problem is not the open source license, per se, the problem is that Valve requires (or at least required?) a legal party or entity that is responsible for the app/game. So if any legal challenges about TDM (e.g. assets that we did not actually have permission to include) reach the Steam platform, Valve can offload them to the legal entity. But TDM doesn't have a natural legal entity, and so far no individual has stepped forward to take on that role. Nor would I advise anyone to, because it is potentially tricky and not without risk. I imagine this is going to be similar for any other store, as well. And that's why there has not been any progress in getting TDM on Steam or any other store, and I don't think that's likely to change.
  17. The drawback is that it has a fairly huge performance cost, and yeah, that the depth will block it. Inline is theoretically possible, but not trivial, and will not resolve the issue in all cases.
  18. You can go that route, but two things that are important to point out: 4 words may be cutting it close, probably better to choose 5 to 6, at least for important accounts. you must not pick the words, they must be chosen randomly! If you pick the words, there will be patterns in the sequence which significantly weaken the strength of the password. I know it's in the name of the method and you're probably aware, but many people still have a tendency to try to pick or "massage" the generated words, so I wanted to emphasize it Still, remembering too many of those phrases simultaneously is not an easy feat, so I'd still recommend a password manager, even if it's just a backup for your memory...
  19. It's not uncommon. Drawing outlines is one of those things that sounds like it should be pretty simple, but is actually technically difficult. Even harder is drawing outlines that are properly occluded by depth. The option `r_frobIgnoreDepth 0` is a total hack that has numerous drawbacks, but it is also the only method I'm aware of doing it without spending an obscene amount of time on the implementation.
  20. I said backed up, not stored, didn't I? My Keepass file is automatically synced with cloud storage, and as a consequence I have multiple fairly recent copies on my laptop, PC and my server. You do still have the problem that you need different passwords for different accounts. If you use the same encrypted passwords for all your accounts, that is most certainly not secure. I guess you could just use the domain name in your scheme, if your encryption is strong enough. You'll just have to hope that the websites didn't put some braindead rules for passwords into place that your encrypted output doesn't conform to
  21. You should seriously reconsider that stance. Passwords that you can remember are very likely not secure enough, particularly because you probably share them between accounts to some extent. Good password managers encrypt your passwords securely so that you can easily back them up to cloud storage.
  22. And that's the point, isn't it? The frob highlight isn't designed to be some obscure optional feature that players can enable if they like it. Highlighting the selected object is a necessary part of the game interface, because otherwise you can't really properly interact with the game world. Does the highlight have to take the form of a shining outline? No, of course not. There is a technical reason that we need to replace the current highlight system, which is going to happen one way or another. Since we are replacing it, anyway and since there have been more than the occasional complaint that the existing highlight is barely visible depending on the scene lighting, an outline was suggested as a possible alternative that we could try. If the outline isn't popular, it can be removed again, that's perfectly fine. I'm not attached to it in any way. We'll just have to find a different new implementation that more closely resembles the existing highlight. But it is *not* the goal to have several different highlights that the players are meant to choose from to their liking. We already have too many obscure options to maintain for too few developers, I don't want another unnecessary choice on top. So let's agree on an actual highlight a majority can live with instead of putting a controversial option behind an obscure menu entry.
  23. But you CAN turn it off. Just not via a menu option. And I would argue that those other options don't belong in the menu, either.
  24. I'm honestly not convinced this belongs in a menu option. You can always change or disable it via cvars as an advanced user, but menu entries should be limited primarily to those options that have the most use to the majority of players, otherwise the menus just get overloaded with a plethora of options nobody will fully understand. If we conclude that the majority of players actually has a use for turning the highlight off, it would be better to kill the feature.
  25. Can a moderator please lock this thread? It has run well past its usefulness.
  • Create New...