Jump to content
The Dark Mod Forums

OrbWeaver

Active Developer
  • Content Count

    7643
  • Joined

  • Last visited

  • Days Won

    23

Everything posted by OrbWeaver

  1. That's why I'm with Andrews and Arnold (AAISP), the most geek-friendly and anti-censorship ISP in the UK. Here is their CEO's response to the ludicrous behaviour by the ISPA: https://www.revk.uk/2019/07/doh-and-vpns-and-trust.html I particularly like the fact that A&A are not members of the ISPA, but decided instead to donate the cost of an ISPA membership fee to Mozilla instead. I look forward to the point where everything on the internet is encrypted, DNSoHTTP and VPNs are commonplace, and the censorshits can get the fuck out with their "filtering obligations".
  2. I don't disagree with any of that. It really is one rule for the elites and another rule for the rest of us, particularly with authority figures and politicians. For example, in the UK the government have passed laws allowing widespread surveillance of internet users while conveniently excluding MPs and their communications from the scope of the law. Similarly, the anti-sex-discrimination laws that apply to normal workplaces have specific exclusions to allow gender quotas for political candidates. But let's not needlessly introduce race (or other personal characteristics) into the discussion when it doesn't have any actual relevance. All that does is create artificial division which doesn't benefit anyone except the elites themselves. If the "little people" want to stand up to the elites, they need to work together, not divide themselves into meaningless groups based on superficial characteristics and then spend time squabbling over things which happened decades or centuries ago and which none of us have any control over.
  3. Thanks, fixed in Git.
  4. And that has precisely what to do with the ownership of computer games? Are you saying that if there were fewer black men serving unjust sentences in US jails, the games industry would stop using DRM?
  5. At least one good thing has come out of this unexpected forced upgrade is that we no longer have to use the most buggy, user-unfriendly and just plain garbage WYSIWYG post editor that the internet has ever seen. This one actually seems to work well.
  6. I actually like the light theme. I hope when it is changed, there will be an option to choose between the light and the dark themes.
  7. I'm happy to update the script for API changes and bring it into my repository along with the LWO and ASE exports, but I don't have any experience with the MD5 animation system so testing it would be somewhat challenging. Probably the most reliable way to do it would be to get hold of an example BLEND file along with the correct exported result (from earlier Blender versions) and then treating this export as canonical test data which the updated script needs to produce. In fact I should do that with the ASE and LWO scripts too, to make it easier to check for future breakages without having to do a full export and manual inspection in game.
  8. I suppose machine learning is the next big thing in image scaling and video compression. Codecs of the future will not simply analyze macroblocks and decompose them into frequency components, but will analyze textures, shapes and lines and reconstruct these at the desired resolution. After all, if you're looking at an image of gravel, you don't actually care if every stone is exactly the same as the source material. If the codec can reconstruct a similar-looking gravel texture this will look perfectly fine for the viewer.
  9. Is the intention that the DVD will be burned/stamped and then sent to people by post (perhaps to get around low bandwidth limits in certain parts of the world), or just made available as an ISO image for download? If it's the latter, I suspect many people will wonder what benefit it provides over directly downloading the specific things you are interested in and then burning them to whatever backup medium you find most comfortable (which might be an optical disk, USB stick or some kind of network-attached storage). Although I personally like optical media for backup, it doesn't seem to be all that popular these days, and if you're going to download an ISO just to extract files from it manually, surely you might as well just download the mod in the usual way? On the other hand, having the DVD commercially produced and then sent to people who might be living in areas with low internet bandwidth might be greatly appreciated by those users, but I have no idea what the costs involved would be (I seem to recall Ubuntu used to offer such disks, but I don't think they are offering them any more).
  10. I can make loops, if any help is needed with this aspect. I use REAPER and follow a process I have documented here.
  11. Very strange; I can't see any obvious reason why on-the-fly compression would change the final framerate (except during the initial compression phase, if it is doing this in realtime). I wonder if the on-the-fly compression was somehow giving a different result, or maybe not even working at all due to some cvar conflict. Well, I haven't written exporters for the formats myself so am just reading about it from various sources, but everything I have seen so far points to DXT5 compressing color in exactly the same way as DXT1, with differences only in the alpha channel. The 3Dc page you link to says: i.e. the two channels that this format stores (which is all that should be needed for tangent-space normal maps) are each individually compressed using the scheme that provides the high-quality gradients in DXT5 alpha channels, rather than the lower-quality DXT1 scheme for encoding color channels which tends to make normal maps look bad. This is very different from simply using regular DXT5 for normal maps. If you follow the link through to the DXT5 page, it confirms that stock DXT5 provides no benefit for color: UPDATE: Actually it seems I am partially wrong about this with respect to Doom 3, because of this feature (as reported by Wikipedia): So if this feature really does exist and is still present in the engine, you are better off using DXT5 because you will gain the higher alpha-quality compression for the red channel (i.e. this is half of what the 3Dc scheme is doing).
  12. C++11 support was available in GCC around version 4, I believe, and should be enabled by default in GCC 6.0. So if your build is complaining that GCC 7 doesn't support C++11 there must be something very weird going on with your compiler versions.
  13. The video memory savings could be achieved by dynamically compressing to DDS format after loading TGAs from disk (which the engine will do if you don't have the "use precompressed DDS" cvar set). I believe the main motivation for using DDS files on disk is to reduce mission size and loading times. The only difference between DXT1 and DXT5 is the way they handle alpha information — the RGB color information is encoded in exactly the same way. Since normal maps do not make use of alpha (unless there have been some changes to the rendering since the Doom 3 days), using DXT5 for normal maps is unlikely to provide any benefit.
  14. Note that modern versions of Ubuntu package several different versions of GCC. On my system I have gcc-4.8, gcc-5 and gcc-7 all installed and available at the command line. As greebo says, you should make sure that you are compiling DarkRadiant with the default compiler version which was used to compile the system wxWidgets libraries. A quick look at the release notes suggests this might be GCC 8.3, but I don't yet have 19.4 so I can't confirm for sure.
  15. One thing that always bothers me about lanterns in movies and TV shows is that when people want to see where they are going, they hold the lantern up in front of their face. I used to have an oil-fired lantern and if you hold it in front of your face in darkness, you can't see anything else except the lantern. You are holding up a bright light source in your field of vision when everything else around you is dark. If you actually want to see where you are going you have to hold the flame off to one side so that you can't see it directly. But I suppose if they do this in the movies you won't be able to see the actor's face any more.
  16. So it seems there is a problem in the model selector. I did actually fix a crash in the model selector quite recently, so building the version from my repository might be worth trying since it will have this fix. The build commands in that bug report do not relate to building DarkRadiant. It seems like you are building pybind11 but inside the DarkRadiant directory, I'm guessing because those build steps were listed in the DarkRadiant Compilation Guide on the Wiki. I have no idea why those commands are suggested or why it would be necessary to build pybind11 before building DarkRadiant; it is certainly not something I have ever done. Perhaps building pybind11 manually on Arch is needed to get Python support working, but Python is optional in DarkRadiant, so I would just skip it for now unless you specifically want to test Python scripts. To build DarkRadiant, you should only need the commands listed in the README under the heading Compiling on Linux. ./autogen.sh ./configure make sudo make install or if you just want to make a test build and not install it system-wide, you can pass a different prefix directory e.g.: ./autogen.sh ./configure --prefix=/tmp/dr make make install /tmp/dr/bin/darkradiant
  17. That's a great first step. Now you can run DarkRadiant under the debugger, you can get a full backtrace. Where you see that (gdb) command prompt, enter bt and hit Enter. This should give a long list of functions identifying the crash (not just the top one which is displayed automatically). Perhaps not yet. We don't know if this is actually a bug in DarkRadiant or something weird about how the Arch Linux package is built. I notice from the link you posted that the packaged version of DarkRadiant is 2.1.0, from 2017. Is that correct? That is quite an old version of DarkRadiant; there have been quite a lot of updates since then and we are up to 2.6.0 now.
  18. You may find the DarkRadiant online user guide helpful, especially the section on compiling maps and investigating leaks. In order to investigate a crash, we will need a backtrace of the crash itself. Since you are on Linux, this can be done using either the gdb or lldb debuggers. You need to run DarkRadiant under the control of the debugger (with a command like gdb /usr/bin/darkradiant), and then when the program crashes, use the bt command in the debugger console to get a backtrace.
  19. On the other hand, if mappers are actively avoiding using stone surfaces because they feel the footsteps are too quiet, that might be a good reason to bump them up a bit. If I'm not mistaken the stone sounds currently in use are the ones I myself recorded, so I certainly won't complain if people want to make them more audible. A volume of -10 (up from -12) seems OK to me, although much more than that and I think they would start to get overpowering. tdm_sfx_movement_footsteps_player.sndshd tdm_footstep_stone_walk { minDistance 1 maxDistance 30 volume -10 editor_displayFolder sfx/movement/footsteps/player sound/sfx/movement/footsteps/player/stone_walk01.ogg sound/sfx/movement/footsteps/player/stone_walk02.ogg sound/sfx/movement/footsteps/player/stone_walk03.ogg sound/sfx/movement/footsteps/player/stone_walk04.ogg }
  20. Ah, in that case it makes sense that wood sounds louder to the player too. I was assuming we had the same division into "loud" and "quiet" surfaces as in T1/T2, and therefore all surfaces in the same category should have a similar volume.
  21. But tile should be louder and wood and stone, surely, because tile is a loud surface? Assuming the surface types are intended to behave the same way as they did in the original games.
  22. Playing through a mission today, I felt that the wood footsteps are a little too loud. They seem to "pop out" as noticeably louder than walking on stone, whereas as far as I am aware both stone and wood are intended to be quiet surfaces. This is the adjustment I made in my local install to get the wood volume to approximately match the stone volume. The only change is that the volume line has been reduced by 4 dB (from -16 to -20). I did not touch the creep/crouch versions as these seemed OK to me. Feel free to test and agree/disagree. sound/tdm_sfx_movement_footsteps_player.sndshd tdm_footstep_wood_walk { description "Made by GoldChocobo" minDistance 1 maxDistance 30 volume -20 editor_displayFolder sfx/movement/footsteps/player sound/sfx/movement/footsteps/player/wood_walk01.ogg sound/sfx/movement/footsteps/player/wood_walk02.ogg sound/sfx/movement/footsteps/player/wood_walk03.ogg sound/sfx/movement/footsteps/player/wood_walk04.ogg }
  23. I confirm that this hotfix does fix the graphical issue with my AMD card (Radeon R9 290), and as far as I can tell does not introduce any problems (at least I could complete Mission 1 on Easy difficulty).
  24. An initial version of this is now implemented in my repository. By defining a file called assets.lst in the top level of a resource directory (e.g. "materials/assets.lst" or "models/assets.lst"), you can tell DR to exclude certain model or materials from the in-editor tree views. The file has a simple key-value format, e.g. darkmod/candlesticks/some_broken_model.lwo=hidden Any model or MTR file listed as "hidden" will no longer show in tree views, but will still display as normal if you load a map with the asset in it. Note because of how this is implemented, it works at a file level not an individual asset level, so if you want to hide just one material from an MTR file, you will need to move it into a separate MTR file and hide that entire file (hopefully this isn't too much of a problem since you can place materials definitions in files arbitrarily). Currently this is only implemented for models and materials, which I assume are where the bulk of this deprecation work will need to happen. There is no reason why it can't be extended to other types of assets like sound shaders if necessary, but separate work will be needed for each asset type since they all have their own distinct parsing code.
  25. Some of the photos from the devastated Notre Dame could work very well for the next "haunted cathedral" mission.
×
×
  • Create New...