Jump to content
The Dark Mod Forums

stgatilov

Active Developer
  • Posts

    6879
  • Joined

  • Last visited

  • Days Won

    242

Everything posted by stgatilov

  1. dev17095-10833 is available. Yes, but it won't start on 2.12 then, so this will be applied in missions database only when 2.13 is close.
  2. Thief taught me archaic English words and not getting lost inside huge buildings P.S. Splinter Cell Chaos Theory coop missions is the best two-player coop experience I've ever had. As for single player... let's say neither of us two finished it.
  3. Yes, that's because of persistent info improvements: https://bugs.thedarkmod.com/view.php?id=6509#c16675 I'll add it to known issues, but it will only be fixed during 2.13 beta.
  4. Maybe you can share a map or a piece of it for inspection?
  5. I remember someone ran TDM inside Parallels VM on M1. In theory, Wine should work today. Just want to hear confirmation
  6. It seems that Wine on MacOS + Apple Silicon can run Windows x64 binaries without virtualization. I wonder if someone tried to run TDM on Macbook with Apple Silicon?
  7. Here: https://drive.google.com/drive/folders/1Cryn6uKyTG6LB5ulr7kD8LMEXi7Lt88P?usp=sharing This is old map with a few new features painfully inserted by me. So e.g. it uses all the old ways of doing GUI in campaigns which you should not use today. But you can see how it moves persistent info around.
  8. Read the linked comment in bugtracker. And ask me any questions.
  9. I wanted to add a warning, but quickly realized that it is hardly possible. It is even impossible to statically decide how stages are split into interaction blocks! The full writeup is here: https://bugs.thedarkmod.com/view.php?id=5718#c16735 I suggest adding "interaction separator" keyword to materials syntax. If at least one interaction separator is present, then: Implicit bump stage is not added (backend will use _flat anyway). Stages are split into interaction blocks by interaction separators only. If a block contains several active stages of the same type, backend selects the first one and ignores the rest. If stage of some type is missing, backend uses _flat, _black, _black respectively instead. The stages within interaction block are stable-sorted by type, but this is merely technical detail since only respective order of same-type stages matters. With interaction separator, mappers don't need to remember the complicated and inconsistent rules regarding how they must write multi-interation materials, since they denote the stage blocks themselves.
  10. Perhaps the famous bow crash:
  11. I think I have seen this, but don't remember if there was some fix or it just stopped happening.
  12. I have not seen any mention about order of stages in the docs. But Doom 3 is such a thing where requirements are imposed by implementation. The implementation of material stages sorting most likely has not changed since Doom 3. It clearly expects bumpmaps to go first in each packet. Moreover, I would argue that "fixing the issue" would only increase confusion. Because D1 B2 D2 B3 looks like a valid combination that would work in unexpected way, no? It is much better to restrict the rules and prints warnings, then to allow any order of stages and silently work in some way... which can be not the way mapper intended it. Because most of the materials use single interaction pass. If there is one bumpmap, then everything is assumed to be single interaction pass and is sorted accordingly. I think the question is: is bumpmap stage required if diffuse or specular is set? If it is not required and is implicitly replaced with _flat, then the rules should definitely not be relaxed. In fact they should be restricted further, but we cannot do it.
  13. Right now there is a working implementation by @Frost_Salamander of the following. If you add spawnarg "efx_preset" "WOODEN_SMALLROOM" to location entity, then this preset will be used for this location. The main issue with this implementation is that you can only specify predefined presets. If you want to assign custom-made EFX to several locations, you have to copy/paste it in .efx file as you do it now. There is another idea which looks like this: You can set spawnarg "efx" "MyCosyAttic" on location entity "loc15", then it will use effect named "MyCosyAttic" instead of effect named "loc15". For each builtin preset like "WOODEN_SMALLROOM" engine automatically defines efx effect named "preset_WOODEN_SMALLROOM". So if you don't want to have .efx file, you can use spawnarg "efx" "preset_WOODEN_SMALLROOM" straight on location entity. The only downside of this idea is that you still cannot define new presets. But you can share effects between locations. Do we have mappers who want to write custom efx effects and want to share them between locations? Or is the first solution with "efx_preset" enough for us for the years to come? Or maybe someone wants to be able to define custom presets and we should think on another proposal?
  14. This is wrong. Bump stage must be the first in each packet, otherwise everything breaks. To be clear: single-interaction materials can have stages out of order I think. Multi-interation must be a sequence of packets, each packet must start with bump stage.
  15. You might as well ask: what is the motivation to specify interaction properties as 3 seemingly independent stages? I think the answer is that when Doom 3 ran on shader-less platforms (hello from 2001), each stages was rendered separately and blended into total result. Perhaps it was important bumpmap stage was rendered first. Today the stages are always combined into diffuse+specular+bumpmap packets. The sorting logic in game is much more convoluted: It splits all stages into groups, such that each group (except maybe the first one) starts with bump. Then every group is sorted in order: ambient, bump, diffuse, specular. It is not important where ambient stages are. So according to what I see, the engine does not support setting bump/diffuse/specular stages in arbitrary order and never intended to support it. It expects bumpmap to be first in every "interaction packet". The simplest solution here is to invent a condition which looks like wrong order and post warning in this case. For instance, if we have a bump at the end without matching diffuse, it is most likely an error. If we have several diffuse/specular maps in single group, it is also an error. UPDATE: Ok, there is a special condition when first stage is not bumpmap. And I think it does not work properly... only provides an illusion that bumpmap not at first place is supported.
  16. I see there is test map in the ticket, I'll try to have a look. Unlike "ambient stages" which are processed as they are written, interaction stages don't work as stages. The backend C++ code heavily reworks them. I guess some keywords are not supported at all, and some are occasionally broken...
  17. This can't be done with mission.cfg anyway.
  18. Yes, I'm asking because I'd like to know that too
  19. The remaining questions from my side: Do we need the ability to override cvars during briefings/debriefings/menus? Do we need sys.unsetcvar script event which works like unsetm console command?
  20. There are two ways to override cvars in a mission: mission.cfg file can set non-archived cvars (starting with 2.12). sys.setcvar in game script can override cvars (starting with 2.13 / dev17044-10746). Of course, there has never been any effort to classify cvars into public and private, no thinking of backwards compatibility of relying on cvars, etc. So overriding cvars should be considered a last resort feature. mission.cfg allows to statically override cvars on FM level. The change takes effect during all missions in a campaign and all briefings/debriefings/menus. However, you cannot adjust cvar value during gameplay, so only one constant literal value can be set. The implementation is simple: mission.cfg file is executed from your mission when TDM engine starts all non-archived cvars are reset to their defaults when TDM engine restarts (due to FM change) sys.setcvar allows to override cvars on gameplay level. These overrides behave like the variables in game scripts, i.e. they are saved/restored to savefile and reset on game start/end. You can adjust the same cvar several times with different values, and savefile will capture the override that is currently active. The minor downside is that these overrides automatically don't carry over between missions in campaign, and they cannot work in briefings/debriefings/menus. Note that sys.setcvar has been available for a long time already, but previously it had different meaning. Previously it set the cvar as if the player set it himself. So the values stuck between restarts, missions, FMs (even saved to darkmod.cfg for archived cvar). Now it always sets the "mission override" for cvar. You can test cvar mission overrides manually using two new console commands: setm {cvarname} {newvalue} --- set mission override for the cvar with given value unsetm {cvarname} --- drop mission override for the cvar It is not perfectly obvious what should happen if mission-overridden cvar is changed by user. Right now the main value of cvar is changed and mission override is broken/erased in this case. So be wary that user can mess with your overrides just like you can mess with his cvars.
  21. Here is the latest version. I did major cleanup: fixed warnings, adjusted things for recent TDM, made indentation consistent. briefing_button.zip briefing_flowing.zip
  22. This is NaN value being spread by bloom. Usually it happens AMD GPUs, since NVIDIA apparently drops NaNs from framebuffer today. I hope this is some old TDM version
  23. I doubt there are any non-marginal CPUs which can't run 64-bit executables. However, there can be 32-bit OSes installed on 64-bit CPUs. You know, just push the wrong button on install/download, and welcome to 32-bit cell
×
×
  • Create New...