Search the Community

As of the latest 2.13 Dev Build (dev17026-10712): I am unable to reproduce the crash in The Transaction @Daft Mugi@datiswous@Frost_Salamander@snatcher@kingsal @Araneidaecan you repro in 2.13 dev ?

Is it already possible to pass information from the briefing to the mission? I don't think I ever saw this implemented apart from the starter-location selection. TDM is currelently in early dev, maybe a bit soon to start implementing in missions? I think it's better to wait for beta, so no changes will be done to the system.

I revisited this issue and might have had a breakthrough. I noticed that when using the clipper my cursor wasn't changing, and afterwards when the cursor was no longer hidden when the dragging problem starts happening. If I take out the code that is supposed to change the mouse cursor when activating the clipper, the drag behavior remains correct during and after using the clipper tool. If I remember correctly from last time I went down this rabbit hole, Wayland has restrictions on pointer locking and I think it was only allowed while the pointer is hidden. I'm guessing something with changing the cursor is failing and then it doesn't get hidden before the pointer lock happens, causing Wayland to reject the pointer lock request. And when the pointer doesn't get locked, the math to calculate the drag amount goes all wonky. @MirceaKitsuneor others, if you'd like to try a quick and dirty workaround, find the void OrthoView::setCursorType(CursorType type) function and put a return statement on the first line so it doesn't actually change the cursor. I'll see if I can figure out what's actually going wrong when setting the cursors so we can make a proper fix.

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.

Walked through the mission. As everyone else here had some problems with the books puzzle. Also, opened the secret entrance to the laboratory through the wall, with the lever on the other side. Had to replay to open it with a prober books alignment. Otherwise, a very interesting short mission.

As someone who tends to alert guards often and occasionally stir trouble when going through a FM, I noticed some major issues when it comes to AI realism and awareness during combat or when guards face difficult situations. Everything's fine when AI go about their usual patrols... once trouble takes place however, the illusion falls apart as guards act like they're less self aware than a toddler. Indeed AI realism can't be improved past a certain point as there's a limit to the effort the team can put into something so complex... yet I do believe a few improvements can make AI behavior much more realistic and exciting. After analyzing this issue for a long time, I decided to put it all it into a few main points... I apologize for their length as I wanted to go in a bit of detail on each one, hope folks have the time and patience to read them. Biggest issue is AI are unaware of where attacks are coming from. I recently made another thread on how I climbed on a table and blackjacked two guards to death as they sat there doing nothing, something that also happens when shooting them with arrows as guards only explore the nearby area. The issue seems to be that AI don't account for the direction a hit comes from, they only know something hit them but act as if it must be some mystical force of nature: If you're sitting in a parking lot and an asshole neighbor throws a tomato at you from his balcony, you aren't going to cluelessly investigate the road in front of you when the projectile clearly came from behind and hit you in the back of the head, instead you'll storm into the building and start looking for which of the neighbors facing that side of the road may be the culprit. Despite voice barks existing for this exact scenario, we never see AI running to get help from other AI. NPC's will do one of two things: If armed and with enough health they will attack or search for you nearby, if hurt or unarmed flee to a random location. I've never seen an AI consciously run up to another AI asking for help and bringing them to where they spotted me, even when fleeing the AI seems to go to a random location. They don't share knowledge with each other generally speaking: The only awareness AI spread to other AI is alert level, meaning NPC A becomes alert if it sees or hears that NPC B is alert too... beyond that there's no coherence or actual cooperation, the voices may indicate some form of searching together but friendly NPC's are never seen actually engaging. Another big issue is voices being played (or not played) in disconnect with what's actually going on. There are AI voices for most important circumstances but they're very rarely activated: It's a miracle to hear a guard say "someone's been hurt" or "there's a body here" when noticing someone who's unconscious or dead. What seems to happen is if AI was already alerted by another peculiarity such as a noise, they're no longer surprised by anything else and won't play the voices designated for that scenario, so they'll only mention a body if that's the first thing to alert them in any way. Furthermore AI don't actively talk with each other while searching together, everyone acts as if they're on their own and not a team. What happens after a conflict is over. For this discussion I won't focus on better permanent alerts, that has greater difficulty implications and I think I made a separate thread on it a while back. The problem I noticed is once the immediate alert has gone down, AI return to full normality and act abnormally calm: The idle voices change from saying things like "it's a quiet night" to "we've got an intruder" but that's about it. In any realistic scenario even a trained guard would be shocked after being in a fight or finding a body. Below I'll list the immediate improvements I see to those problems, which without having an understanding the code myself am presuming can be changed without too much effort: When an enemy hits the AI with any weapon, the AI should be alert to the estimate location of the shooter. If you're standing atop a tower and fire an arrow at a guard, the guard shouldn't draw his sword and look around their nearby vicinity like a fool, but instead run up to the tower where you're standing granted they can pathfind their way to that location. If the player is far away the destination should be fuzzy and a random location nearby, thus the guard won't run to your exact location but will still climb the stairs and enter a room near it. AI need to learn how to ask for help instead of fleeing to random places when not attacking. If an ally who isn't already alert can be found nearby, the scared AI should explicitly run to their location tell them where you are then have the ally either run to your location (if armed) or go to another ally to get them to your location (if unarmed). Even if an AI is already alert, finding a body or dropped weapon or broken arrow should result in the AI speaking the voice line for that circumstance, only being engaged in combat should suppress it. I'd go further and support repeating those voice lines: A guard yelling "we have a dead body" several times during the first seconds of discovery would make them appear more shocked. Similarly talking to a nearby guard shouldn't be done just once when the two first meet: When multiple AI are searching for you, they should constantly alternate between single voice lines (eg: "I bet you're right over there in those shadows") and looking at another guard to talk to colleagues (eg: "I know I saw him here keep searching"), this would be a huge improvement since guards currently act like they're completely unaware of each other during a coordinated search. Making guards permanently affected after an incident is a trickier one but a few tweaks could improve it. The most immediate solution would be changing the idle animations: Instead of stretching or blowing their noses or eating candy, AI should be seen randomly cowering or face-palming or even playing the scout animation to look around carefully. One suggestion I'd absolutely throw here: If the AI found a dead body from an ally, have them cry occasionally... I think that would be an interesting and unexpected detail, that will also get players to think and feel more about the consequences of their actions and how they affect the world. There are other ones I could get into, but some would be more difficult and likely not worth trying to solve. Most notable and worthy of at least a mention is how AI walk over the bodies of fallen friends as if they're doormats: Obviously there's no way to have them drag bodies to the side, but maybe an avoidance mechanism so they don't look like jackasses trying to profane their dead friends by literally stepping all over them could be a fix for that as well! Let me know what you think of those points and if there are other AI issues you've noticed yourself or better solutions you can think of: I'm not sure if I got everything here but I definitely believe the problems exist and we could make the world more natural and immersive with some simple fixes.

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.

Skins don't require a model path, that's just a convenience feature to allow the skins to be associated with the model(s) in the editor. However I have no idea if an unassociated skin can be used on a func_static. I suppose there's no reason why it couldn't work, but it's not something I've ever tested and I wouldn't be surprised if it fails to do anything (either in the editor or the game).

I have been attempting to create a skin for a model. No matter how closely I follow the wiki tutorial, I can't seem to get it to work. Here is a pic of the model directory, the skin directory, and the skin file I wrote. I even tried to make a standalone copy in the skins folder, in case DR doesn't like digging through folders when pulling up skins. Am I missing something? Am I running into problems because skins cannot be made for .ase files?

AHA, you're indeed correct! Changing the skin names so they start with "a1"' did the trick! This was actually a successful experiment I was trying out! The wiki goes into some detail about making "general skins" that can affect all models. My hope was that, if I made two models using the same skins, then I could just write a single skin file that would change all of them! For example, since "Straight Frame" and "V-Frame" models both use plaster_01 as their main background... ...all I have to do is make a general skin to change that specific plaster texture... ...and then any of the "V-Frame" and "Straight Frame" models can have different backgrounds! It's not a perfect system, as some skins just don't contrast well with the wooden beams, but I should still be able to get a LOT more out of my models now!

Noticed all of these only because I played TDM by doing the opposite of stealth to practice swordfights. None of these bugs appeared as long as I played the game stealthily. Should also note that I used Snatcher's Core Essentials @snatcher on and off, but your mod does not alter the AI anyway, correct? Bugs happened both ways. 1) AI freezes in combat - https://bugs.thedarkmod.com/view.php?id=6371 It happens a lot with auto-parry disabled. It never happened with auto-parry enabled. It never happened with some guards, while it happened many times with specific guards. They unfreeze when player dies, or when AI is forced to re-equip the melee when player returned from a spot that usually causes them to throw rocks. Also experienced behavior of them only slowly walking towards me at the pace of "hunched sneakily searching mode", attacking once finally in proximity. 2) AI may collectively lose the ability to hear any of the players noise caused by footsteps / landing. Still unsure of what causes this, but Lockner Manor has a good layout to get to the result. Just follow the right-most path and repeat the process of winning sword-fights with City Watch, and then jump around the next guard to see if they can hear you. If they can not hear you, likely nobody can. If they still can, just combat them too and you will likely have deaf AI by the time you have dealt with the 3 Watch Guards outside. In my experience, when they hear the death scream well enough to run to its location or start searching - the deafening did not work. 3) Helmeted AI does not react to (nor hear) players overhead sword strikes made directly on helmet, stealthily from behind. Not sure if the same issue as deaf AI bug, but happened at least once while it was active. (Lockner Manor) 4) (Moor?) AI may lose the ability to hear AND see player after nearby swordfights and after two slashes to bloody their face. (I may have also Moss Arrowed them to face). Any sword strikes I make simply go through their model with no audio of impact. Collision still gets player detected. (A Good Neighbor) 5) Crash to desktop when archer puts bow away to take out melee (while I may have collided with them on staircase). (Lockner Manor) 6) Crash to desktop when I shot a shortsword-wielding charging Noble. Sound of a deflected arrow played (same that you hear when shooting a stone wall), when I expected a flesh-hitting sound. (A Good Neighbor) 7?) Sometimes AI says "Ow that hurt" merely because I block their strikes. - Is this an intended feature? Do they take actual damage too? Anyway, I didn't find mentions about many of these issues. Reporting aside, if you want me to experiment with something or find ways to replicate - I don't mind updating this thread, as I plan to mess around with sword-fights anyway. Just posted this initial version should anyone want to chime in with similar experiences, and I wanted to know if some of these bugs could be mission-, or mod-specific. Maybe caused by much or unfortunately timed quicksaving / loading?

Done. @nbohr1moreWould you mind updating this on the server? Its a fairly bad bug, I've updated the OP but here is the link to the new pk4: https://www.dropbox.com/s/u279b60l40p29cq/moongate.pk4?dl=0 - I've fixed the issue with players getting places they shouldn't be. - Fixed an exploit with secrets - Fixed a few minor issues @snatcherIve included the stock tdm_playertools_flashbomb.def

The new behavior is available in the latest dev17026-10712. If you set cvar r_envmapBumpyBehavior to 1, then you get new behavior. The old behavior is for value 0, which is default yet. The missions/core files are not adjusted yet. But I'd say everything is ready to do it.

In the latest dev17026-10712, GUI debriefing is supported. It works exactly the same way as GUI briefing. It would be great if someone tries it For the nearest future, I'd like to support passing information from game script to GUI debriefing. So that you could show different things in debriefing depending on what player did in the mission.

Yes this worked chakkman thank you. Much better. So far I'm enjoying the game in a very Hitman Absolution type of way. The sound effects and sound design overall is simply unpresentable to me. Lack of footstep, nice pick up loot and and satisfying lock pick sound cues makes it hard for me to give the game more than a 6 out of 10. With good sounds this game could have been a 8 or 9.

Another failure by @kingsal. Firstly the mission is way too short. And like his other missions, the quality is supreme, keeps me playing and neglecting real life duties. Never feeling the frustration of getting stuck, never resolving to walkthrough material. Is it a sign of excellent design or rather a lack of challenge? Also extreme attention to detail, engaging maps from room to a room, gorgeous visually. I understand this is just a free-time effort for someone who could instead make money out of his skills but, I'm sure you could do better.

Another plausible scenario is where the player has a number of tasks/missions to complete but they can choose to do them in any order - giving the player a bit more agency, Tied with this, you might want to be able to re-enter a mission - e,g, it's some sort of hub (memories of the 'Pocket Plane' in Baldur's Gate 2 come to mind).

Sorry for the Necro but I can't find he hex for shroud. I just got the the game free off Epic.

Then the composer did their job correctly.

That is fair. I have reported 84 issues in the bugtracker (and contributed to some of the existing ones), proposed articles to the wiki (see above) to demonstrate that I am familiar with the format, and contributed some on the forum. In the event a wiki user does not contribute in a constructive way, it is easy to block them and revert their changes.

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.

No, the 192-bit RTX 3060 12 GB came first. The cut down 8 GB model came over a year and a half later, and probably in small numbers because nobody talks about it much other than "don't get it, it's 20-30% slower". 3060 Ti had 8 GB from the start, and always has, although it looks like they made a GDDR6X version. They would have to change the bus width to accommodate 12 GB. There were rumors of products like 3070 16 GB, 3080 20 GB and so on, but they never materialized outside of engineering samples. If you think things are confusing now, just wait until 3 GB GDDR7 chips materialize within a couple of years. We could see 12 GB cards on a 128-bit bus, 9 GB on 96-bit, and so on.

Sorry, I didn't mean to step on your toes and to dictate the title change on you. I was merely raising concerns, as the title and beginning of this thread reads an awful lot like one of these here... Full disclosure: I haven't played your FM, yet, so maybe I didn't get the full picture. But then again, there are probably more people as clueless as me that don't get it at first either. Futhermore, you had some avatar come in and tell us about the loss of a beloved community member, wheras in myhouse.wad, it was the opposite, i.e., some random dude nobody in the community knew was gone.

I usually share other people's photos of historical and industrial architecture in this thread, but I've decided to finally share some of my own photos that I've accumulated over the years. Over the years, especially the last twenty or so years, I've wandered many of the old town quarters in cities and towns all around my country, taking snapshots. Wereas many of the main streets and major landmarks have long since had nice and beautiful restoration work done, many of the more obscure side streets, back alleys and occassional overlooked corners had interesting sights to behold. I've particularly been fond of old townhouses that show elements from different eras of history, as well as all the wear accumulated over the years and decades. As much as I like that many of these eventually also receive decent restoration work and look nice again, the sight of a well-worn, dilapidated or even ruined house or ocassional public building can prove really stimulating for the imagination. They've got a lot of proverbial "texture" (not just in the surface sense) and "character" that can hike one's imagination, especially with regards to lived-in environments with long histories.