Jump to content
The Dark Mod Forums

SteveL

Member
  • Posts

    3666
  • Joined

  • Last visited

  • Days Won

    62

Everything posted by SteveL

  1. I'm pretty sure they can do that already just with a tweak to the material definition, no special shader program needed, although we probably haven't implemented it for decals yet. We recently discovered that we can have light-interacting translucent materials complete with specular and bump maps. Obsttorte and Arcturus were the first to come up with it I think. It was always possible in the engine, but it has somehow been common "knowledge" from the beginning of idtech4 that it isn't possible -- which it turns out isn't true.
  2. You only have to do it once, ever. Once you've put your files into the right structure, you can install your mission in both TDM and DR whether it's zipped up into a pk4 or not. Make a folder myMission/ in your darkmod/fms folder. Put your top-level folders in there named like they are in TDM: maps/, materials/ etc Add your files and add your darkmod.txt and startingmap.txt to the myMission/ folder. If you want to override any of TDM's standard files, you just add the same-named file to your mission folder. Your version will override the game's own version. After that you can install your mission and run it in TDM, and edit the files at will. You don't need to make a pk4 until you want to distribute it. Then you just have to zip up your myMission folder and rename it .pk4 More info here: http://wiki.thedarkmod.com/index.php?title=How_to_pack_your_Mission
  3. From the last set of comparison shots in the bedroom, I like the moonbo blue. It's the one that desaturates the colours in a cool-toned night-time way without attracting attention. The full-on blueness in your factory where you have blue lights too looks gratifyingly tense though @Spooks: Like grayman said, the ambient setting on location entities modifies the main ambient_world, it's not in addition. @everyone: There's a bug with setting location ambients to 0 0 0 by the way (to be fixed in 2.05), so use 0.004 0.004 0.004 if you want to remove ambient light from a location.
  4. Good news, after discussion with grayman (who's curating the 2.04 beta build) we can include this fix in 2.04. It sounds like a useful tool to me, for big maps anyway. Mappers can create their own modules in DR and clone them like any entity. In game, they won't increase the entity count, and you can have as many copies as you like in a visleaf without adding any draw calls.
  5. Now working ok. I only tested basic functionality: cloning the group in DR, the visible model and CM. But it all seems to work as intended. DR handles them ok, at least as far as cloning, retexturing, and manipulating the brushes within the group. The entitiy doesn't spawn, although it issues a console warning that we can suppress. It works for combos of brushes and patches too. I've not tested everything but I'll put in on the tracker for us to try in 2.05.
  6. I've had a look and it's only partly broken. You need to set a spawnarg on worldspawn to activate it: moveFuncGroups 1 It's broken because it ignores the entity origin when recreating the brushes as worldspawn. So all the func_groups get centred around the map origin. I'm just having a crack at fixing it in my dev build.
  7. You'll need to use a filtering blend I think. Right now the colour representing the light coming off the water is being added to the colour of the light reflected by the background, so the overall result is brighter than either. If you make your diffuse map a blend of any kind, it'll stop using the bumpmap so that's no good. You could tone down the background by using an extra material stage as the filtering blend, exactly like putting a thin sheet of dark glass just under the water surface: Without testing, I'm not sure whether that'll darken just the background, or the water surface too. I think it'll be just the background, but on second thoughts darkening the water too might look best. To do that you'd move the new stage to after the diffusemap and bumpmap. The idea now is it's only meant to darken the background so it gets listed and drawn first, before the water gets drawn on top. If you move it last, it'll darken the background and the surface. You can adjust the amount of darkening by changing the rgb 0.5 to any value between 0 (background fully black) to 1 (no darkening at all, like the current shader)
  8. It's not just a delay. You have to time the release of the mouse button to the end of the repeating sound sequence. With practice it becomes easy, easy enough to do it consistently on the first iteration, but if it annoys you there's a menu setting for auto lock picking that'll mean it works after a simple time delay.
  9. I don't understand why logfile 2 didn't work. I use it all the time when I'm dealing with a crash. Maybe I misremembered where the logfile should be written. If it's not in your main darkmod folder then it's probably in your bespoke darkmod/fms/my_map folder. Anyway, glad you sorted the problem.
  10. Intersecting models shouldn't be a problem either. Basically you shouldn't be getting a crash, even if we can make the problem go away by tweaking the map. Please post the log if it happens again later and we'll take it from there.
  11. You shouldn't be getting a crash. If your dmap does show changes after a crash, then it must be crashing after dmap has finished, while it's writing the collision model or the AI navigation (AAS) files. Hopefully the log will pinpoint the bug.
  12. SteveL

    Water

    At a guess, I'd say that the tiny density numbers are for doom units cubed, not m3. There are competing mechanisms here -- spawnargs overriding very rough calculations. I put in a fix for the mass of certain moveables in 2.04, and we'd better make sure that it doesn't make everything float in water during beta!
  13. It will if you tell it to. On the console, before you start the DMAP, enter this command: logfile 2 That'll slow down dmap but it'll leave you a valid log file even in the event of a hard crash: qconsole.log in your darkmod folder
  14. DMAP again before you load your map. And if everything is still black, make sure you have lights. Your error message means there was an entity out in the void, not enclosed by your brushes. Maybe a func_static that's in your map but whose origin is out there. Try selecting func_static6 from the entity list in DR (J) then switching to vertex mode (V) to see where the origin is and to move it.
  15. Moving the patch forward is good, if a pain. DECAL_MACRO is used in some decals but not all. It's a bit of gpu magic that is supposed to move the decal slightly towards the player when it gets drawn, just enough to stop z-fighting. But it's problematic due to a bug (or a badly implemented feature or something) in Doom3 that got carried forward into TDM. The engine default settings move the decal 600 times the minimum distance. So when you back off from a decal_macro-ed surface you see window grime gradually crawl over the frame and wall dirt move forward to cover notices on the wall. We're deploying new defaults in 2.04 but it's impossible to find a set of numbers that works for everyone in every spot in every map. We'll probably tweak them again during the beta. If you're just doing a few decals of a particular type, it's probably easier to move them forward manually. If you're going to use a non-macro decal a lot, you can make your own material def using DECAL_MACRO like VanishedOne said.
  16. Yep that's it, although it's not actually a shortest-path algorithm. It's a depth-first search of all paths. All routes that reach the player within 10 portals get their sound contributions summed and the perceived direction of the sound gets averaged across the paths. So it's probably O(bd) complexity like you described above. d is the 10 portal depth, and b is your factor = the number of exit portals from each visleaf. Probably something like 4 or 5 in real maps, but only 1.1 or 1.2 (on average) in the maze example. So raising the number of portals crossed would probably be ok in the specific case of a maze map but it'd be disastrous for most maps.
  17. Not quite. I just took a look in the code, and it turns out s_drawsounds draws an arrow from the sound origin to the perceived location of the sound, after different portal paths have all added their contributions: If you have a dominant portal path for the sound (or just one path), then it'll look like the arrow is pointing to that final portal on that path. It doesn't have access to the route that was used. There's no record of any paths kept in fact: it's done by a recursive search of all paths (up to 10 portals deep). That said, there's an AI debug cvar that lets you see when AI hear sounds made by the player, and I'm sure it shows a path taken by the sound. I'll try to track it down and see how it works too. EDIT: I was forgetting, AI have their own sound propagation system for noises made by the player or alarms etc, completely separate from what the player hears. Sounds heard by the player are handled by the engine, but it doesn't provide any facilities to let AI hear sounds, so TDM has its own system for that.
  18. That's weird. Most bits of the hud are on their own layer. I've never heard of OBS, so I can only offer generic suggestions. Have you tried playing in windowed mode (still full screen size) and capturing the specific window?
  19. Weird, I've never had that problem. I've no suggestions what could be causing it but if you want a second pair of eyes on it post or PM me your shader assembly code and I'll see whether I can spot anything awry. On the scrolling fix, I had this in mind for your vertex shader: MAD result.texcoord, vertex.color, 2.4, vertex.texcoord;where the 2.4 is a constant you'd tweak to set the scrolling speed. You could use a standard vector of values instead of a single number if you needed to scroll in a different direction e.g. { 2.4, -1.5, 0, 0 }. You'd set your particle stage to fade from 1.0 to 0.0 over its entire lifetime. Is that similar to what you did? You could still use vertex color in the fragment shader to fade out the particle, come to think of it, provided that you do want the particle to fade throughout its lifetime.
  20. Yes, apparently, there is a hard limit of 10 portals. I'd not noticed it before either, but it's there in idSoundWorldLocal: MAX_PORTAL_TRACE_DEPTH = 10; It's there to save computational complexity, because the engine traces sounds through every possible branching portal path to the player and adds the various contributions and works out where the sound would appear to be coming from if it arrives at the player at different intensities through different paths. I expect that number was chosen because "that's as many as we'll ever need" rather than through testing. So yes it's a limitation. Do you really need that many portals? In a maze-like map you probably don't need one at every corner because there won't be that much geometry on display. The easiest workaround would be a nice puzzle: place your portals so the the player can't be more than 10 away from the sound If you had to you could link two rooms by a high (inaccessible) tube over the rooms, a bit like an air duct to provide a "bridge" over several portals (best portal the ends of the duct too). But mappers will probably have better ideas.
  21. Interesting problem. We fixed a similar issue for 2.04 in #4132, where adjacent weather patches looked identical. The problem is you want a different setting for each weather patch or particle quad, but it can't be random. It has to persist for that patch or quad from frame to frame. For weather patches, I took the centre of the particle effect's bounding box as part of the random number seed. That persists from frame to frame but will be different for each weather patch. That won't fix your situation. You need each individual quad to have a different offset to its scroll. There's no way to fix that at the entity level as you found out. And you can't fix it in the material definition either, because all the quads for a particle stage are a single draw call -- so any vertexparms or scroll parameters that you set would be shared by all quads in the particle stage. A fix in the vertex shader program would work, if we can think of a number that would (1) differ for each particle quad, and (2) be constant at every vertex of the quad. Tricky. You could take the vertex position and add it to the texcoord, but the vertex positions will differ across the quad and from frame to frame as the quad moves. You might get away with that approach depending on the texture and the quad movement speed, but it'd be a stroke of luck if you did. The only vertex properties set by the engine for entity particles are: vertex position, vertex color, and texcoord. Texcoord is fixed at 0/1 unless you're using an animation strip. Position we've already talked about. That leaves color. Vertex color is set by the engine and it's used to fade out particles over time. Good news: it's constant for all verts of any given quad. Since you're using your own fragment program, you could co-opt vertex color for your scrolling instead, using it in the vertex shader to scroll the texcoords, and ignoring it in the fragment shader. All particle quads of a given age would have the same vertex color, but as long as your particle quads are spawned one at a time, they will all have different ages.
  22. I was about to say, downsize your image. I had the same problem, with no error message, when I was trying to use an image that was too big. But the one you posted is only 80x80.
  23. I'm not sure what you mean. User-preferred bindings take precedence over the defaults. I asked grayman how this worked last week, because we need to override default cvars for the fix to decals drawing over stuff. default.cfg is overridden by Darkmod.cfg which is overridden by autoexec.cfg. I think we overwrite darkmod.cfg at releases, but I'm not sure. darkmod.cfg is where console changes to settings are stored.
  24. I can't see in in the picture, not even zoomed in. Are you seeing a line parallel to the white line?
  25. Thanks for the tip. I'll try this out. CropRenderSize is buggy on modern aspect ratios. It was made for 4:3. I have it tracked for 2.05. Probably not the same problem, but I'll be messing in that code anyway. EDIT: tracked
×
×
  • Create New...