VanishedOne

It sounds like https://bugs.thedarkmod.com/view.php?id=5256 apart from the problems reproducing it.

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

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.

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 l

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 unle

It's described in the later part of https://www.iddevnet.com/doom3/bumpmaps.html

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.

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.

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:

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/

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/

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

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 s

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_b

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: --inclu