Jump to content
The Dark Mod Forums


  • Posts

  • Joined

  • Days Won


Everything posted by VanishedOne

  1. According to https://www.beyond3d.com/content/articles/95 ET:QW has alpha-to-coverage. Maybe that's what makes the grass look nice?
  2. Oh Builder, the old order-dependency problem. I'd been hoping that, since the engine can perform light interaction on surfaces that are meant to be drawn over other surfaces, we might dare to hope for actual alpha blending on lit materials someday (instead of e.g. using alpha testing for grass edges, as seen in some maps).
  3. I'd be cautious about introducing automated bits of visual language as a gameplay/mapping feature, as opposed to an aesthetic adjustment to taste. It's now easier than it used to be (in the days of selectable simple/enhanced light interaction shaders, one of which almost-but-not-quite disabled specular RGB scaling) for a mapper to understand and control what materials are doing by comparing how things look in TDM to the material decls. Having surface types like water or noisy floors given special treatment outside the explicit material decls would make things more, not less, enigmatic for mappers. (There's actually an open bug relating to floor tiles that don't have the tint the material decl indicates they should because RGB scaling in cubemap stages doesn't work unless there are no light-interactive stages.) On bright glass, I think my first ever question on this forum was about why my glass block in an alabaster room could be plainly seen without any light. Other people have mentioned additive blends and alpha blended cubemaps, but another (not mutually exclusive) possibility is the 'translucent' keyword. Back then, the state of understanding was that it just made materials not interact with light. We now know that translucent materials can interact with light (someone found you can use 'diffusemap _black' in glass), but precisely what's going on isn't well documented; what I think happens is that light interaction is performed as for opaque materials but the pixels aren't cleared to black first, so the effect is like an additive blend but with light interaction.
  4. To add to that, even 'PBR' texture types aren't an assurance that you're actually getting something created with numbers based on physics. On Sketchfab I've seen models with 'metallic' window glass (for reflectivity, I suppose) and even metallic meat. (Well, we do have a quasi-mediaeval setting; maybe we could say it's adulterated...) I think it's just in the nature of the beast that TDM will never have as consistent an art style as projects with dedicated art teams.
  5. Is AmbientRimColor here related to the ambientRimColor material keyword? I'm not aware of that having been used yet except in experiments.
  6. idDevNet has been either giving me 'can't find the server' errors or redirecting to Bethesda.net. Here's an archive link: https://web.archive.org/web/20200613234848/https://www.iddevnet.com/doom3/
  7. Re. Sketchfab, free assets there are typically CC-BY, occasionally with additional NC and/or SA. (Edit: having checked my downloads, I did find at least one ND.) If you've bought anything then yes, check the licence terms. Re. dubiously sourced textures, here's an earlier thread: https://forums.thedarkmod.com/index.php?/topic/20311-external-art-assets-licensing/
  8. I've used FX before: the priest in ITB has a melee attack involving a hammer of holy fire, which briefly spawns a dynamic light. I agree the system is surprisingly little used. One of my ideas (inspired by the footprints in Down By the Riverside) was for an invisible monster that would leave decal footprints via frame commands for FX bound to the foot joints. I ran into a minor drawback when I discovered the decal command applies a random rotation, so it would have to be a generic blob instead of a footprint shape. But with a big blob, and some sparks, and maybe a screen shake, I think it could still be effective.
  9. Yes, my impression is that Thief's flashbombs were intended partly as escape tools (indicated e.g. by the 'ace up my sleeve'), which doesn't go well with the time needed to draw the bow. The flash arrow idea probably does go better with a player-versus-undead scenario, like the holy swords that occasionally turn up in Thief FMs.
  10. Yes, I was about to post something similar. Not everywhere suits glowing crystals or bioluminescent fungi, which are the other usual nonextinguishable options. Still, like the choice of whether to include rope arrows or vine arrows or lots of stackable crates, it's something a mapper could work with if s/he so chose. Possibly more interesting if it had other uses like disabling bots or cameras. Shouldn't be hard to set up with S/R: give the electric lights a response that changes the light shader (I should think a slight flicker would be best for conveying that the light is broken, not off). Maybe release some spark particles. It's simpler than the 'smashing the bulb' idea, where engine support for breaking lights exists but you'd need 'broken' models to switch to and would have to explain to players that this nonstandard feature is available in the mission. However, you'd still have either to design the mission with the expectation that every electric light could be disabled, or somehow convey to the player which ones are vulnerable. I have a test map that replicates the 'lights flicker when a specific entity is near' effect from TDS's Cradle. (In my unfinished mission, it's intended to be for a section where a pagan shaman is up to something in the little-visited depths of an industrial area, and his proximity is making the machines go haywire.) Basically it relies on the lights' being set up to flicker with their sound, then S/R is used to play an extra buzzing sound on them.
  11. It sounds like https://bugs.thedarkmod.com/view.php?id=5256 apart from the problems reproducing it.
  12. The most id-like way is probably via the FX system. You can access it via func_fx. However, the decal splat range will be limited to < 8 units and the decal will only splat directly downwards. (The usual story: id set it up for the demon-spawning effects in D3 and didn't make it a conveniently general system because they didn't need to.) The other way would involve some sort of synchronised particle emitter and func_splat. However, I have a vague recollection that in my tests func_splat didn't splat all entity classes; splatting $world should work, anything else needs testing. (Also it seemed to ignore decalInfo and impose its own decal fade time.) After that you're in the territory of esoteric work-arounds like launching a custom projectile from an atdm:func_shooter.
  13. Comparing my script to the one above, the only thing that stands out is that my equivalents to OnOff() seem to have parameters, e.g. void TriggerNextInSequence(entity me, float threadnum); If anyone likes this telescope (CC-BY-NC), I've already done the format conversion for TDM.
  14. Thanks. I hadn't encountered the dmap problem, and unfortunately I think Tels created SEED and he isn't around any more. Maybe it's similar to the problem in SteveL's inlining experiment: Combining models became available in DR fairly late in ITB's development, otherwise I expect I'd have used it instead of SEED for the nails on drainpipes. I did use DR to combine the stacks of scrolls in the office, which had previously used SEED to combine them at runtime (causing a moment of poor framerate after map load, as I recall). I think I'd already reduced their numbers to fit in the entity limit, though (they also went through a phase of being inlined); combining models in ITB was more about reducing the draw calls.
  15. How do people go about deciding when to combine models in DR, especially when doing it to lower the entity count in larger maps? I'm particularly curious about: How late into the mapping process you start combining. What happens if you change your mind (do you make a backup copy of the arrangement when you combine models?). Whether you take different approaches when using modular building compared to brush-and-patch style. (My sense is that modular style tends to eat into the entity quota faster, since even a wall without windows, doors, etc. will be composed of models unless the modules are brush-and-patch prefabs that can be reverted to worldspawn, but then enough room clutter in a detail pass can eat into it faster still.) Whether SEED combining is still preferred in any cases.
  16. It's described in the later part of https://www.iddevnet.com/doom3/bumpmaps.html
  17. Here are some previous posts on support for smoothing/vertex normals: It's an avoidable problem if you can use ASE instead, but it's a bit of a gotcha, especially if you're trying to convert files obtained from OpenGameArt or Sketchfab or wherever.
  18. Scaling particles accurately (for precision work like matching water particles to a fountain model, not just relative to other particles) is something I still use the in-game editParticles editor for.
  19. You haven't met MirceaKitsune yet, then? If you produce something one or more mappers like, they may use it, to greater or lesser extents. Any more comprehensive aims than that will lead to disappointment, I think. But to give a flavour of my own attitude towards referencing other TDM or Thief FMs, a snippet from a readable in my w.i.p. map:
  20. Custom weapon modelling isn't often seen in TDM, so you may be out of luck unless whoever originally made TDM's weapon models is around. The most recent custom weapon model work I know of is by @MirceaKitsune here, so maybe he knows something useful. And I can't find it now, but someone - this says it was @Obsttorte - demo'd a player pistol once. If you're not aware of it already, here's another possible place to ask: http://idtechforums.fuzzylogicinc.com/
  21. It's not really a substitute by any means, but this may be relevant: https://forums.thedarkmod.com/index.php?/topic/16730-tutorial-technique-to-texture-rotated-brushes/
  22. Okay, installing python-is-python3/python-dev-is-python3 let me finish compilation. Although I don't have a script tab or script dropdown, despite not having deliberately disabled script support. Edit: possibly related lines from darkradiant.log: (140103598541440) ModuleLoader: Loading module '/usr/local/lib/darkradiant/modules/script.so' (140103598541440) WARNING: Failed to load module /usr/local/lib/darkradiant/modules/script.so: (140103598541440) /usr/local/lib/darkradiant/modules/script.so: undefined symbol: _Py_ZeroStruct
  23. Could this line in config.log be related? PYTHON_LIBS='Usage: /usr/bin/python-config --prefix|--exec-prefix|--includes|--libs|--cflags|--ldflags|--extension-suffix|--help|--configdir' Digging around a bit I found this: # Python 3.8 requires the --embed switch to produce working linker flags PC_PYTHON_VERIFY_VERSION([>=], [3.8.0], [PYTHON_LIBS=`$PYTHON_CONFIG --libs --embed`], [PYTHON_LIBS=`$PYTHON_CONFIG --libs`]) I have Python 3.8.2 on my system but --embed doesn't appear in the options list for python-config. Edit: Further investigation suggests my python-config may be the python2 version. From output of `aptitude search python-dev`: i python-dev-is-python2 - symlinks /usr/bin/python-config to the DEPRECATED python2-config Edit: yes, that seems to be it. From https://launchpad.net/ubuntu/+source/what-is-python/3
  24. Making all in script make[3]: Entering directory '/media/rfjs/DATA/code/DarkRadiant/plugins/script' /bin/bash ../../libtool --tag=CXX --mode=link g++ -std=c++11 -std=c++17 -g -O2 -DNDEBUG -Wall -Wno-unused-variable -Werror=return-type -module -avoid-version -lstdc++fs Usage: /usr/bin/python-config --prefix|--exec-prefix|--includes|--libs|--cflags|--ldflags|--extension-suffix|--help|--configdir -L/usr/lib/x86_64-linux-gnu -pthread -lwx_gtk3u_gl-3.0 -lwx_gtk3u_stc-3.0 -lwx_gtk3u_xrc-3.0 -lwx_gtk3u_html-3.0 -lwx_gtk3u_qa-3.0 -lwx_gtk3u_adv-3.0 -lwx_gtk3u_core-3.0 -lwx_baseu_xml-3.0 -lwx_baseu_net-3.0 -lwx_baseu-3.0 -lsigc-2.0 -o script.la -rpath /usr/local/lib/darkradiant/modules ScriptingSystem.lo ScriptCommand.lo ScriptModule.lo ScriptMenu.lo ScriptWindow.lo SceneNodeBuffer.lo PythonModule.lo interfaces/DialogInterface.lo interfaces/EClassInterface.lo interfaces/BrushInterface.lo interfaces/RadiantInterface.lo interfaces/PatchInterface.lo interfaces/SelectionInterface.lo interfaces/MapInterface.lo interfaces/EntityInterface.lo interfaces/MathInterface.lo interfaces/ModelInterface.lo interfaces/CommandSystemInterface.lo interfaces/FileSystemInterface.lo interfaces/GridInterface.lo interfaces/SceneGraphInterface.lo interfaces/ShaderSystemInterface.lo interfaces/SkinInterface.lo interfaces/SelectionSetInterface.lo interfaces/SelectionGroupInterface.lo interfaces/SoundInterface.lo interfaces/GameInterface.lo ../../libs/math/libmath.la ../../libs/wxutil/libwxutil.la /bin/bash: --exec-prefix: command not found /bin/bash: --includes: command not found /bin/bash: --libs: command not found /bin/bash: --cflags: command not found /bin/bash: --ldflags: command not found /bin/bash: --extension-suffix: command not found /bin/bash: --help: command not found /bin/bash: --configdir: command not found make[3]: *** [Makefile:617: script.la] Error 127 make[3]: Leaving directory '/media/rfjs/DATA/code/DarkRadiant/plugins/script' make[2]: *** [Makefile:446: all-recursive] Error 1 make[2]: Leaving directory '/media/rfjs/DATA/code/DarkRadiant/plugins' make[1]: *** [Makefile:755: all-recursive] Error 1 make[1]: Leaving directory '/media/rfjs/DATA/code/DarkRadiant' make: *** [Makefile:496: all] Error 2
  25. I'm trying to follow the DR compilation instructions, using a Linux Mint system (apparently Mint is different enough from its near relatives to be unable to resolve dependencies for the Debian and Ubuntu .deb files). I installed packages based on the list given for Ubuntu 19.xx / 18.xx / 17.xx, except that apparently libwxgtk3.0-dev is now called libwxgtk3.0-gtk3-dev. I get the following errors during `make`: Making all in script make[3]: Entering directory '/media/rfjs/DATA/code/DarkRadiant/plugins/script' CXXLD script.la /bin/bash: --exec-prefix: command not found /bin/bash: --includes: command not found /bin/bash: --libs: command not found /bin/bash: --cflags: command not found /bin/bash: --ldflags: command not found /bin/bash: --extension-suffix: command not found /bin/bash: --help: command not found /bin/bash: --configdir: command not found make[3]: *** [Makefile:617: script.la] Error 127 make[3]: Leaving directory '/media/rfjs/DATA/code/DarkRadiant/plugins/script' make[2]: *** [Makefile:446: all-recursive] Error 1 make[2]: Leaving directory '/media/rfjs/DATA/code/DarkRadiant/plugins' make[1]: *** [Makefile:755: all-recursive] Error 1 make[1]: Leaving directory '/media/rfjs/DATA/code/DarkRadiant' make: *** [Makefile:496: all] Error 2 A bit of Googling suggests those -- strings are options for python-config, so why they're being treated as shell commands has me mystified.
  • Create New...