Jump to content
The Dark Mod Forums

SteveL

Member
  • Posts

    3666
  • Joined

  • Last visited

  • Days Won

    62

Posts posted by SteveL

  1. I don't think there's any legal or techie problem with what you proposed. You wouldn't even be selling the file you had created if I understand it right. Patreon is more about taking donations to encourage or enable people to do more work.

     

    Any talk of money on an open-source project tends to bring people out in hives. The general feeling is that commercialization ruins projects.

  2. If an AI leaves Idle State (or Alert Idle State) and rises up through the other alert states, stopping at each one, until he finally reaches Combat State, is that supposed to count as a single occurrence of reaching Combat State (state 5 on the stats screen), or are we supposed to be counting these rises as a single occurrence of reaching each of the states 1, 2, 3, 4, and 5?

    I saw both those scenarios when testing Zybl's patch for scripts querying mission scores. When stepping out into the light in front of a guard, sometimes the alert level would jump straight to 5, sometimes it'd clock up one or more intermediate alerts along the way. If it ramps up step by step, you end up with a higher stealth score for the same misdemeanor which doesn't feel quite right.

  3. We might split up the plans for 2.04 into more than one release. There's plenty of work going on, but there's also plenty still to do and in the meantime there are some important bug fixes waiting to be released. That was being talked about a week or so ago, but I don't know whether anything's been decided: I just got back from a busy trip and I'm way behind on news.

     

    Note that svn has moved on from version 2.03 to 2.04. I think the engine will run ok, but the new game code is incompatible with TDM 2.03. If you want to test that out, you'll have to patch your TDM installation while you test it. Let me know if you plan to do that, and I'll post the necessary file.

    • Like 2
  4. Does anyone know a way to force textures to be opaque in DR? The "forceOpaque" keyword is used by dmap, but it seems it doesn't work in DR.

     

    I tried changing portalsky to be a blended material to fix a problem with it drawing over lit decals, but now it's semi-transparent in DR which might drive people nuts.

  5. Does the game account for a change in direction? Assuming the length of path ABC is constant in both illustrations, wouldn't the indirect path result in a quieter sound? The sound had to bounce off a wall to reach the player. We must assume that some energy was lost in the process. The more acute the angle, the more severe the volume reduction.

     

    Additionally, there's a second hole in the wall. Is the game accounting for this path or mearly stopping short at the closest path? Every visportal in the same node as the player should be evaluated to see if there is a valid path leading through to the source. If so, the same process should play out for each.

     

    You don't need to cast a hundred rays to work this out. All you need is the path from the source to the player the game already calculates. Then you repeat this process, but looking for the next "shortest" path until every visportal connected to the player's current location has been accounted for. If you have a room with 4 visportals, there would be potentially 4 valid paths.

    The game already sums adjusted contributions from all possible paths, and adjust both the volume and apparent source of the sound. I fixed a bug in the calculation a few months ago, that was causing sound cards to pop when multiple paths happened to align.

     

    As for change of direction, I think we fake it through sound loss on the portal.

  6. Can you post the code here or point me to the file/method it is defined in? Monte Carlo is a bad choice here, as it calculates every single timestep. But for the boundaries we only need the last one.

     

    Sure. It's idDeclParticle::GetStageBounds. Feel free to claim the tracker off me if you want to fix it.

     

    It runs 1000 tests, each one testing the position of a random particle quad for each frame of the particle stage's life. Equivalent to testing 1k random quads at each frame. Like you say, it's the "each frame" bit that's causing the problem for long-lived particles. And it's done once for every particle stage, not once for the whole emitter.

     

    We can't just use the last frame. There are probably particles that shrink over time instead of growing. My thought was to use a set number of samples spread over the particle lifetime.

  7. I'll be coming back to it when I get my new skybox working! I'm sure the issues can be resolved to make it look as good as it did in attempt #1 while getting rid of the regular patterns. I spotted a bug in the flies distribution code while looking at your original -- it only uses one of its random number sequences in error instead of 2, although fixing that alone doesn't cure the patterns.

     

    I've tracked the load time issue.

  8. Going back to the feedback on that video, what do our difficulty settings default to? I think there's a case for defaulting to the easiest "nearly blind" etc settings, so that newcomers get a chance to explore. People wanting a tougher time will find the option later but people who can't get started might put it down like the reviewer.

  9. I don't speak Esperanto, so I'd need those subtitles. That said, foreign languages can work well to add atmosphere. Assassin's Creed 2 made great use of Italian+subtitles on their "English" option. Friends of mine who don't speak Italian (I do, no doubt with very bad intonation because I learned it as an adult) were quoting bits at me that they'd memorized from playing the game :)

     

    Strong "foreign" accents (or "wrong" intonation etc) aren't really a problem though IMO. Could you work it into your FM plot? Maybe using our Moor AIs or a context that says the AI are foreign? If that doesn't fit the FM then still no problem, English in a strong foreign accent won't be a problem as long as it's intelligible. English has become the common tongue in the west, so everyone's used to hearing it in every intonation.

     

    Where are you from btw?

  10. Cool. I'm not sure I want the NPCs to highlight though. Can I trigger another visual cue, like a cursor of some sort?

    I'm not sure. We don't have an in-game cursor, so highlighting might be the only way. You have to interact with the 3d world, not a HUD. Highlighting is unsubtle in some circs, but it's consistent in the game too. Players will know what it means. If you're really determined, TDM's HUD is editable and extendible, and scripting could give you an even quicker fix if you wanted to do something different.

  11. On my monitor, there's banding in the original too. Less visible than in #3, but that could be due to the brightness difference. Subtle colour gradients don't look good brightened. #2 looks like the bands have been hidden by oversaturation. The gradient has been lost too, but that could just be in the screenshot given that some detail is back in #3 -- hard to tell without seeing what #3 looks like when the brightness is lowered again. You can tweak the rgb channels in the material shader.

  12. EDIT: Seems I have to delete the contents of the /.darkradiant folder before every new launch.

    That doesn't sound right at all. Are you still having this problem? I don't use Linux so can't help much except to suggest a completely clean install of your 1.8 build, but it's worth bumping the question if that doesn't help. We do have prior using Linux build without this hassle.

     

    I remember in Doom3 you could talk to NPCs by clicking on them (or rather get them to talk to you). Is there a similar function in TDM? I realize it's not a feature one would usually implement in a stealth based game like this, but I'm trying to make a safe house of sorts, where this would be a nice thing to have as there are just friendlies around that may have some valuable information for the player.

    Yes you can set an npc to be frobbable, and trigger something.. a target or a conversation or a script.

  13. There's a config file containing key bindings and other user interface settings that gets borked if you install DR 1.x over the top of 2.x. Deleting that file and reinstalling 1.x over the top should fix it (or you can get a clean copy of the file). I can't remember the name of the file off hand. It was mentioned a lot during 2.0 test threads.

    1. Ah! Nice... Thanks, both. :-) Is it beneficial to turn all things like rafters and corner beams etc into func static? And only leave the walls, ceiling and floors as world spawn?

    Also, do bigger AI's take routes designed for smaller AIs into account when path finding thus affecting performance? I can't find a clip texture that seems to block one but not the other.

    The way I'm designing now, I've assumed that conditional blocking (related to events, ie they can be removed depending on certain events) is a possibility, as I think I've read that somewhere.... I just want to make sure by asking.

    1. That's the way experienced mappers tend to do it. If you're doing anything complicated, it makes for an easier workflow and it's certainly much easier to track down leaks etc when you can filter/hide all the entities in the map and just be left with your sealing caulk. It's not obligatory so you can mix and match, reserving the func_statics for twiddly bits if you prefer.

    No, each AI size has its own set of routes through the map (AAS). These are calculated during dmap. AI will take only one AAS into account, the one that's right for their size.

    Yes, func_aas_obstacle http://wiki.thedarkmod.com/index.php?title=Pathfinding#Dynamic_blocking.2Fclipping_with_func_aas_obstacle. There's an example usage in the Elevators wiki article, but I think they are pretty straightforward. Place one and trigger it on or off using any of the usual triggering mechanisms.

    • Like 1
×
×
  • Create New...