stgatilov

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

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

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

I'd say it goes into the first case.

As you know, 32-bit binaries were deprecated 4 years ago. But they are still available as a separate download, so people can still play TDM on 32-bit Windows or 32-bit Linux (x86 architecture). Given that Windows 11 and Ubuntu 19 don't provide 32-bit builds at all, I wonder how many people still use 32-bit TDM binaries.

Do you really want to try? I'd suggest looking at idSoundWorldLocal::MixLoopInternal. That seems to be the only place where effect is found by area index, then by area name, then default. If you manage to add a member like idSoundWorldLocal::listenerEfxPreset and ensure it is set properly, then you most likely can pass the preset name here (perhaps via something like idEFXFile::FindPreset). In my opinion, the location spawnarg should get top priority. If missing or empty, then the ordinary approach with .efx file works.

dev17042-10732 is public. We decided to restore the ability to create cvars, so the broken missions are "unbroken" as they are. Although I'll still try to hunt down and remove overriding scripts in the future.

Speaking of actions for the missions which only tweak zoom delay. What would you prefer right now? Mission broken on the latest dev build (as it is now), but working as intended in the latest release. Mission working as intended on the latest dev build, but working without customization on the latest release.

Another possible option is to use cvars for these constants. However, such an option would be available only when proper mission overrides for cvars are implemented.

The idea is that mapper can set spawnargs on map entity to override defaults from entityDef. If some entityDef is used only to dynamically spawn entity without any map entity, then it does not fit. I guess this is the case with arrow weapons, sadly. UPDATE: At some moment we discussed an option to specify "patches" to core entityDefs, but the idea never got far.

I created discussion here and mentioned authors (maybe I missed someone though). Unlike the previous thread about main menu GUI overrides, I think the new one does not look aggressive . The main question there is why this was done, and how to adapt to avoid this problem now and in the future. Indeed, all the missions will be fixed by 2.13 even if some authors don't respond. Dev builds regularly break something, although usually it is done unintentionally. I added "known issues" point on the dev build, which happens pretty rarely. I apologize for the negative emotions this change has caused. Sometimes I am too rough in communications. Moreover, I am not a creative kind of person, I'm more a technical type of person. Thus I believe in interface boundaries, so in my mind the blame for breakage is always on the side that violates these boundaries. Anyway, I know I'll have to fix the breakage, probably myself if necessary.

Speaking of ARROW_ZOOMDELAY. Just changing it from 6 to 3 will not add any customization options. I think all the macro constants should be converted into spawnargs. Hopefully, we have a proper entityDef that can hold these spawnargs.

Do we have any volunteer to participate in fixing these missions? The first (and perhapsthe most important) step is to download these missions, diff tdm_weapon_arrow.script against stock version, and list all the things that are actually customized.

I totally agree that players usually don't care whether some non-customizable constant like bow shoot time is same as in core or not, as long as the mission plays well. This is a problem only for TDM development. But I don't know a proper way of solving this: mappers usually want to customize something "right now", and waiting for new release is rarely an option. And often customizations are not implemented until someone really wants them (or right away uses them), so that's also the chicken-and-egg problem here.

Good question. Maybe because I don't feel myself too guilty breaking these missions? Maybe because I know that fixing them will be a long story. And I feel confident that we (or more likely I ) will be able to fix all of them by 2.13. You might have noticed that I have also enabled two behavior changes in the latest build (1 2). In these cases it is not even mappers' fault that behavior change is needed. I have a script which can update all missions at once so that they work properly both in 2.12 and dev builds. But somehow I feel I should wait for at least some feedback on the new behavior before doing a massive change to dozens of missions.

Probably something like: $player1.setImmobilization("missionspecific", IM_ATTACK); ... $player1.setImmobilization("missionspecific", 0); No idea whether it works or not --- maybe it blocks using weapons, maybe also wielding them.

dev17035-10724 is available.

As a matter of fact, I implemented passing info from briefing to game and from game to debriefing: https://bugs.thedarkmod.com/view.php?id=6509#c16671 At some moment I think I should put this info to wiki... This will be available in the future dev build. P.S. By the way, you can also override which .map file to start, although I'm very skeptical that this feature is worth the trouble you'll get in maintainability. Small variations of the same map should be better implemented by writing the "main" game script.

As you probably know, overriding core files which are not specifically designed for that is fragile and unsupported. Indeed, it usually works... until it does not Here is the list of missions which completely override tdm_weapon_arrow.script: ahouseoflockedsecrets @Moonbo byanyothername @joebarnin cauldron_v2_2 @kingsal good @Amadeus hazard @kingsal northdale1 @Goldwell northdale2 @Goldwell seeking @Amadeus@Dragofer@Wellingtoncrab snowed_inn @Goldwell @kingsal written @Amadeus @Dragofer I have just got rid of creating cvars dynamically (5600), and shooting the bow stopped working in these missions. Because they distribute an old version of the script which runs in "debug mode" that relies on dynamic cvars. Core version was updated some time ago and this debug mode was removed. I'd like to ask authors: why did you decide to override this script? Perhaps we can add some customization points and delete overrides?

If it really crashes, then you can record crashdump and send it to someone with debugger. This often allows to learn what is wrong (but not necessarily where is the error).

You can check if transform has no scaling (3x3 submatrix is orthogonal up to epsilon) and leave sound spawnargs "as is" in this case. I think that would make more sense than setting them on every movement.

I believe the engine sets mindistance = 1 and maxdistance = 10 if they are not set explicitly in the sound shader. At least that's what I see here: https://github.com/stgatilov/darkmod_src/blob/trunk/sound/snd_shader.cpp#L154 Anyway, if DR sets spawnargs to the same values as in sound shader, that's not a problem for the suggested change in the meaning of zero value. But setting maxdistance = 0 will be

But sound spawnargs are merely overrides. You should not set them at all if you don't intend to override the values set in sound shader. Also, how does moving anything affect sound distances? Whenever you move sound, you should only change its position/orientation and nothing else, shouldn't you?

Are you going to build two separate missions knowing that player will only see one of them? I think this is "cool in theory", but in reality using such a feature requires tremendous amount of work from mapper, so nobody will use it.

That is interesting question. I think no? In principle, I guess I can cover it as well. If I want to expose persistent info from mission as gui vars, I can as well copy some gui vars into persistent info before mission.