Jump to content
The Dark Mod Forums


  • Posts

  • Joined

  • Days Won


Everything posted by VanishedOne

  1. You might be thinking of this, perhaps?
  2. Yes, Q4 and ET:QW both had their own implementations but D3 never did. (It appears from the leaked D3 demo that at one stage its parser was going to use the C preprocessor, or something like it. DECAL_MACRO is a leftover from that era but is no longer implemented in the same way; probably id never used the preprocessor for anything else and decided it wasn't worth it.) Someone did make this though: https://forums.thedarkmod.com/index.php?/topic/18843-material-generator-bash-script/
  3. Speed potion assets (model and shop inventory icon, but no inventory shop icon) have existed since way back, much like the gas mine model for which Sotha made a def. The original plan was probably to implement it in a similar fashion to D3's powerup code (there's a comment "// TDM: leave this in for speed potions or something" in Player.cpp where most of the powerup code was stripped out). (By the way, the RoE version of the D3 gamecode has commented-out code for a "powerup_haste".) I made script-based implementations of speed and slow-fall potions a while back, initially very buggy ones once people started trying them out in various situations, though as far as I know all reported bugs are fixed.
  4. Here's the earlier thread: According to this, LGS tried adding a 'Loud Room' property to Thief 2 but it ended up unused.
  5. Cheers! If there's to be another patch, I'd just like to alert you to missing surfaces on the sides of this archway in the Plague Ward: (Seeing pyramid images everywhere is quite amusing if you've played Control, where an inverted black pyramid is the symbol of the mysterious Board residing on the Astral Plane...)
  6. Does anything come up in the console afterwards? It should say something like "Wrote <filepath>".
  7. There's the Inn Business approach - use the campaign system to run the same map multiple times, allowing for persistent items/variables - but it only works for a finite number of revisits. Having finished your masterpiece, I just wanted to ask about one room:
  8. I think what I've got is the official release from the downloader, but after the briefing it dumps me at the console, having apparently tried to load an incorrect map name (startingmap.txt says movingday31, the files provided are movingday54). Edit: ah, I think I've found the problem. At some point I must have downloaded a prerelease version called movingday; the final version is called ptb0; therefore the earlier one didn't get overwritten. False alarm then, sorry.
  9. I'm also getting a crash to desktop (Linux, TDM 2.10 final). It seems to happen after the game creates an autosave (the one called Desert). I'm playing on Normal so I can't comment on save rooms. Ordinary manual quicksaving is unaffected.
  10. There's some vehicle-related code still in AFEntity.h/AFEntity.cpp (unlike the idAFEntity_ClawFourFingers class, which was stripped out of TDM), but I don't know whether it's in a working state; presumably it needs a suitably rigged MD5. I was thinking more of the bullet time feature (though some might consider it Dishonorable). I think that's what the timegroup stuff is for: https://github.com/TTimo/doom3.gpl/search?q=timegroup&type=
  11. Another thing to be aware of is that the TDM gamecode (as opposed to the renderer) seems to have been built on top of the D3 SDK (before the whole engine went open source) and therefore not on the RoE gamecode. That's why the xray stuff didn't work properly before 2.10. So on top of what's been removed or altered, there are RoE features that never existed in TDM to begin with.
  12. Here is what id's notes had to say about custom images in foglights. I could never get them to have any effect on the appearance, and have long suspected that that note is a relic from an earlier phase of development. id's D3 mappers seemed to like putting fogs in areas below/above the playable area, to give a sense you were walking over deep pits, so I think the vertical falloff may have been designed around that use case.
  13. It isn't limited to transparent materials - see e.g. textures/darkmod/stone/flat/smooth/alabaster_opaque - but your second point is well made.
  14. Materials can pass the depth buffer to a fragment shader as _currentDepth. (And _currentRender is a copy of the framebuffer.)
  15. Apart from one which implements its 'camera' using a trigger brush. Edit: scratch that, I missed the word 'prepackaged'. As one of the people encouraging customisability, what I'm after is to avoid the present case in which assumptions down to the camera's spark particles are hard-coded. As I wrote on the tracker, I agree that it would be poor mission design if visually identical cameras had wildly divergent behaviour.
  16. maskColor and maskAlpha are reasonably common when working with alpha masks: textures/darkmod/glass/clear for example. I've never seen a use for maskDepth though. Polygon offsets would probably be used more if they didn't break light interaction (one learns the hard way why setting DECAL_MACRO can be a bad idea); I basically associate privatePolygonOffset with D3-esque burnaway effects. Isn't the depth hack a particle thing from before sort particles? I have the impression that vertexColor is fairly rare because it needs a mesh with vertex colour data, and it's mainly used with inverseVertexColor for vertex blended meshes, although you can also use it for baked AO and the like. (The ET:QW wiki suggests using vertex colours to fade out the edges on water meshes, but I think https://forums.thedarkmod.com/index.php?/topic/18036-messing-with-sea-water/ has been the focus of TDM experiments on soft water edges...)
  17. I should think adding shader effects to the spyglass overlay would be done by adding a stage to the tdm_spyglass_overlay material to invoke a postprocess shader. You could look at water materials like textures/water_source/water_clear for an example of a stage calling a shader program.
  18. I think blend modes with dedicated names tend (apart from blend none) to be pretty widely used and easy to learn: blend add for anything self-lit, blend filter for darkening effects like grime, blend blend as the basic choice for alpha blending. Other blend modes I'd consider more advanced, since you really need to know what the syntax means to work out how they interact with background colours: stuff like the blood decals that use blend gl_zero, gl_one_minus_src_color is quite non-obvious.
  19. TDM flashbombs have no effect on undead, actually: supposedly the rationale is that undead don't physically see you (zombies hunt by scent), even though this makes no sense in a game with shadow- and line-of-sight-based stealth. The out-of-universe rationale is to make holy water more valuable. Even experienced mappers get caught out by this: The Rats Triumphant gives you some completely useless flashbombs. Flashbombs will harm the ghosts in my w.i.p. though.
  20. It warms my heart to know that while half the world's hobby communities are engulfed in culture wars, there are still places where the high drama erupts over GUI design. On a more practical note: being able to add a background image to the preview might be useful for testing blend modes. It looks from the screenshot as though the list of stages has them identified by blend mode: maybe the currently selected stage could be highlighted in the right-hand textbox too, to make it easier to tell which blend add stage you're manipulating right now?
  21. Base holy water damage is supposed to be 140, and health for a basic zombie is 150. Maybe something weird is going on with damage scaling, though I don't see where. Edit: I had an idea about this (presently untested): radius of the holy water stim: 24 units. Zombie's height: ~82 units. I don't see anything to make the stim test for intersection with the zombie's body instead of its origin; and an AI's origin is at its base... I think the stim is supposed to move downwards, like the water stim, but maybe it's missing if it's too far to the side, since the origin is at the (ahem) dead centre of the footprint. Edit2: okay, in my tests I can kill the (initially unalerted) zombie in the expected two shots. I sometimes one-shot him if I aim near the origin. I'm not sure whether the sneak attack multiplier is supposed to apply here. Maybe he can be alerted before the sim falls to near the origin?
  22. Going a little offtopic here, but since you mentioned it: it seems from its script that holy water is less effective than you'd expect against multiple targets. // greebo: TODO: This won't cut it for holy stims damaging multiple undead if (stimSource.getIntKey("stim_already_fired") == 1) { //sys.println("Ignoring stim coming from " + stimSource.getName()); return; }
  23. https://thief.fandom.com/wiki/Periscope_Eye https://thief.fandom.com/wiki/Watcher One option re. water arrows would be to invent a relay-type thingy for the power or alarm system: something like an antenna with lightning effects. If you see one near a camera, you can break the camera's connection to the alarm system for a bit. (Cf. how in T2 some turrets are autonomous, others rely on a nearby Watcher to alert them. It could also be used for other security devices, like in TDS's museum.)
  24. The thing with the water arrow idea is, sitting in place watching areas is what a security camera does, so there isn't that big a difference between temporarily and permanently disabling one unless you need to traverse an area repeatedly. T2 Watchers are sometimes used like Bafford gate guards, to direct the flow of gameplay by making an ingress point impossible to stealth through. If they can be disabled with fairly common tools, that isn't really viable. Camera looking straight down a well lit corridor? Water arrow. Camera pointed directly at a valuable object? Water arrow. I'm not against the idea as such - I think carefully timing your water arrow hit and grabbing of the loot could be fun too - but I think there are definite reasons why a mapper might want to deploy waterproof cameras.
  • Create New...