Search the Community

Yes, definitely needs to be distinguishable. Clear glass with light bulb visible would be the best way: You know that if you see clear glass and the bulb inside you can shoot it. The distinction isn't always possible to make without first trying it out though... paintings are the best example, you always need to get close to see if a painting can be looted. As for players learning about this, we should add those lights to the tutorial level where the basics of TDM are taught: In one of the hallways we'd have examples with the message "solid lights can't be shot, but ones with fragile glass and a lightbulb can be broken with broadhead arrows", the player is given arrows and can shoot at different lamps to compare. As for explosive barrels those would be cool to have too! In their case they should already be doable with a script, just that no one's ever done them: Remove the barrel, spawn the same explosion as the fire arrow or mine, and some temporary lasting physical debris if possible. Breakable lights would need support added to the builtin spawnfunc.

The coin is a little joke in the mission end stats. It exists solely to mock you, similar to the newspaper stating it's missing. There is no actual coin in the mission. Because it's missing, just like the newspaper says. You can clearly see how TDM players do not believe much in thieving-free missions. There has to be loot, right? Rather than pack their belongings and leave, they chase after a coin that does not exist, only because the stat screen tells them there is a coin even though there is none. TDM is a game about stealing, after all. There's no room left for locking your apartment, stacking your furniture onto a cart, and leaving. But perhaps sometimes that's all you can do. Maybe that is what you should do. Ignore the coin. Ignore the ugly stain on the wall, it's no good. Don't even look at it. Pack your belongings and forget. Ignorance is bliss.

And... running another update and the problem is solved. Sorry for the noise.

On Debian (testing) dev17035-10724 runs very "laggy" for some reason (even the menu). Last time I experienced the same "laggyness" was on a non-accelrated VNC connection to another machine.

It is not included in the Modpack. It is a little side project, that's all I know today. You know the drill: do what you please with the stuff I release. And if you can make it better or different: do it!

In case anyone decides to pursue this further, here are a couple more references: https://discourse.gnome.org/t/pointer-warping-on-wayland/9197 https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/158 Seems like this feature is also common in PCB design software. The "correct" solution would be to use Wayland's pointer locking interface and relative mouse events, which is essentially what the FreezePointer class accomplishes by continuously warping the pointer back to its original location. The complication is that the way it works now all goes through wxwidgets which then goes through gtk3 on Linux. To fully implement this, I think someone would have to: Create a platform-specific alternative to the cross-platform FreezePointer that we have now Make sure it's only called on Wayland, and only if the pointer locking API is available Work your way through the wxwidgets / gtk3 layers to get hold of the native wayland surface and pointer handles Reconcile the Wayland mouse events with the mouse events received by wxwidgets If someone was motivated enough to pick this up, it might make sense to try to build this in at the wxwidgets level and try to get it accepted there. It would help keep platform-specific code in the right place and also make a couple other projects happy.

This was a great purchase for me, covers all my needs, and brings me up to immunity to any massive chip shortage as a result of geopolitics. It appears to be running a core at 4.2 GHz basically forever even with low usage, but is quiet most of the time. Clearly faster than the i5-6600T despite the years of quad-core stagnation. The higher TDP and hyperthreading really helps. I doubt there's any noticeable improvement going from HD 530 to UHD 630 iGPU, but it does gain the better H.265/VP9 HW decode that came immediately after Skylake.

That's the exact one I meant. I've tried it in my FM (a wait node converted into a follow node), but it doesn't seem to work once the character reaches the spot where it's supposed to trigger. The character just stands and waits in place, as usual or as with the wait node. Well, I don't really need a follow node in the FM I'm currently making, so I'll still have plenty of time to wait until a fully functional follow node becomes available. (There's also some potential path node workarounds if it doesn't get resolved, anyway.) Thanks, Amadeus. Interesting. The FM I might make in the future that might need the follow type node is still really far away, so it's unimportant now.

So what is Distortion for in the game? Both Distortion and Filtered Distortion appear as true in the Settings ini

I'm assuming we're talking about Stone 24pt font here, used in subscripts & elsewhere. Images of letters are arranged into a bitmap by a process that doesn't have to conform to a tidy alphabetic grid. See Figure 2 of my new article https://wiki.thedarkmod.com/index.php?title=Font_Bitmaps_in_DDS_Files In the figure, you can see there's an accented "a" to the left of the W, whose foot is presumably within W's bounding box. I think I looked at this earlier & concluded that I couldn't shrink W's bounding box enough in the DAT file. So probably the pixels of the W need to be moved to the right... I haven't tried such surgery yet.

Nothing regarding the skin, though I didn't have much time to look this morning. Sure! The map is "talents", and you should be able to find the proper models/skins from the post above. File size was too big, despite compression. Here's a file containing the models and skins. You should be able to find the related ones using the directories in previous posts. models and skins.7z

So the sound has full volume on distances up to minDistance, and no volume at distances above maxDistance. I have not found any special meaning for maxDistance = 0 in the code, so I assume such a sound will never be heard due to zero volume. Also, there are some default values littered around the code. Most importantly, sound shader gets minDistance = 1 and maxDistance = 10 by default. Also I think I have seen min=0, max = 10 somewhere in the code. There is little difference between minDistance = 1 and minDistance = 0. Mostly the difference is that fading does not happen within 1 meter of the sound source. Supposedly, setting minDistance = maxDistance = 0 will cause sound to be completely muted. If you want a sound to always have full volume, I think you should set e.g. minDistance = maxDistance = 1000. Of perhaps set "global" flag instead, which disables distance computation completely. Although this probably has different effect (like maybe global sound passes through walls too). Or if you want it to be sharply disabled at 10 meters, then set minDistance = maxDistance = 10... but I see no point in sounds that can be disabled based on distance without any fade. Finally, as I have described at the very beginning of the post, "minDistance" "0" as spawnarg has no effect on current TDM versions. I don't see mindistance/maxdistance settings in these two prefabs in SVN. Maybe this were the issues that someone fixed recently. Or... could it be that you confuse spawnargs with sound shader settings? Actually, I don't see the distance settings on sound shaders either.

Why not use the modified weapon scripts from the April Fool's FMs? Those seem to be working just fine on this dev build

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 notice that what Blender does is not lock or hide the mouse cursor, but allows it to move, then snaps it back to the other side of the window so you can drag infinitely in one direction. I.e. if you are dragging to the left, when the cursor reaches the left-hand window edge, it immediately re-appears at the right-hand window edge and continues moving to the left. I wonder if re-writing the code to use the Blender approach would solve the problem? Perhaps the back-end code can handle instantaneously changing the mouse pointer position more reliably than trying to lock it in place.

So what is the training mission for then? Apparently it's not showing standard tdm gameplay necessarily. Edit: Maybe it's not really worth it to keep discussing this. I mean I don't want to derail too much what the topic is actually for.

There might be another way, or at least it's what I thought of as a non-developer: Use a different way to transform mouse movement into camera rotation or viewport offset. Is there no alternative to calculating the distance from the pointer to the window center before resetting the pointer to the middle? There must be other mouse look implementations that could work. Most obvious alternative: We can detect how much the pointer moved on the screen compared not to the center, but to its previous position wherever that may be. While of course still trying to lock it in the middle, but if that fails at least it doesn't cause the view to go crazy: The only issue then will be the cursor reaching the screen edge and having to be re-engaged so you can keep scrolling in that direction, which is also a big annoyance but comparatively less bad and not as noticeable unless you do long-range movements in one go. Any reason why we couldn't give this option a try?

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.

The script changes standard weapon behavior and you think it's not needed to inform the player?

I made a small update today removing two modpack skills that were indeed not regular features of the original game, namely Whistle and Peek Door. The real reason though was that I never really use any of them! If I want to alert a guard, I can always hit something with my blackjack and I almost forgot about the peering through a keyhole feature before I noticed that it works with handles without a keyhole e.g. in the current mission I beta test. I kept the numbers scroll, because this basically gives you access to something the game already has only any time, and the Blow skill, as a last resort if mission creator use uncommon flames, again like in the current beta. Also this way there is a bigger distinction between Snatcher's modpack with all the cool new stuff and my patch!

Why? Do you have resentment toward these 10 missions in particular? Do you not care if you break any and all missions on your whim and then release a public build? Breaking existing missions and then making a public dev build available with broken FMs doesn't really seem like a great thing to do. I get that missions get broken from time to time because improvements need to be made to the core game, but this is essentially a public release (even though it is a "dev build" it is still a "public dev build" available to anyone and everyone, and with that comes certain expectations). You didn't even notify the affected FM authors beforehand. This is just not cool.

What is the problem with bugtracker 5600? Does the player start without a bow now?

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.

So because of bugtracker 5600, does that mean that 10 FMs (Written in Stone, Northdale 1 and 2, Volta 2, Hazard Pay, etc.) do not work in this new dev build, and yet, the dev build was released anyway? That's not cool.... The bow is kind of an important gameplay element, especially for Hazard Pay. Why even release this build if it breaks 10 existing FMs?

According to the user list on the wiki , there are five bureaucrats: * Greebo * Modetwo * Springheel * Taaaki * WikiAdmin My best guess would be that @taaaki has access to the servers that are running the bugtracker, the forum and the wiki. For the sake of community growth, I would also propose a more streamlined process for new users to get a wiki account. Make it easy for new contributors to contribute.