Search the Community

Could it be anything to do with the shape of the geometry? Is a curved staircase looking at the images. Or the thickness? Thou by that image those stairs are anything but thin. Is just that I have seen thin walls leak light, while ticker ones do not and I have seen this, in more than one engine even in lightmapped ones. Also is that brush geometry or a imported triangle mesh? You will correct me if wrong but afaik the engine treats triangle mesh's, a tad differently from brush geometry, like it doesn't automatically inline the triangle mesh geometry, into the overall baked brush geometry (unless your force it), so it leaves a invisible "gap" there where the mesh connects with the brush wall? Could be floating point accuracy problems, like you recently talked about?

Welcome to the forums Ansome! And congrats on making it to beta phase!

"...to a robber whose soul is in his profession, there is a lure about a very old and feeble man who pays for his few necessities with Spanish gold." Good day, TDM community! I'm Ansome, a long-time forums lurker, and I'm here to recruit beta testers for my first FM: "The Terrible Old Man", based on H.P. Lovecraft's short story of the same name. This is a short (30-45 minute), story-driven FM with plenty of readables and a gloomy atmosphere. Do keep in mind that this is a more linear FM than you may be used to as it was deemed necessary for the purposes of the story's pacing. Regardless, the player does still have a degree of freedom in tackling challenges in the latter half of the FM. If this sounds interesting to you, please head over to the beta testing thread I will be posting shortly. Thank you!

Oops, in that last release, I accidentally didn't check character spacing in the codepoint range 128-159. And sure enough, there were problems with character 131 & 132, which needed 4 more pixels of horizontal box shifting than the 3 pixels they got earlier. So here's a better version: fontimage_24.dat of Feb 24

What do you mean by moving them around? You move them from the models folder into another folder? Models must be placed in the models folder. Otherwise, DM/DR cannot find them anymore causing the problems you mentioned in your post.

Hi, I'm messing around with patches to see what can be done with them, and I have a couple of questions. None are critical issues, as a matter of fact, I doubt I'd notice them or cared if I were playing someone else's map, but as I'm learning, knowing what can't be done is sometimes as important as what can be done. Here's the thing: is it possible to bevel a surface not parallel to one of the orthogonal axes, in other words, a slanted bevel? To be more specific: I'm having problems with snapping it to the grid; it doesn't want to. I mean, I have done the bevel, and it looks nice from a distance, but the slanted surface refuses to snap to the grid, which causes a visible, although small, seam (or at least I assume that's the reason.) And projecting the texture is also a bit of pain. Let's see if I can attach a picture... OK... [a few/lots of minutes later] messing around with it one side now looks much better (almost imperceptible seam, tbh,) but the other side still looks off. I still can't snap to the grid the four corners (interestingly, it's the main brush, the frustum, the one that refuses, not the bevel, which is perfectly snapped). I can snap three of the four corners, but there is always one that shifts on its own will, even when using the smallest grid. See the next two pictures, where I have the main brush and the patch selected; the dots overlap except that one. And if I snap that one, another will shift (clockwise? I think.) I mean, that's like... what, 1/3 of 1/8 of a Doom Unit? 1mm? Not game-breaking, really, and nothing that can't be hidden with some trim or just in shadows, but I wonder if there's a technique for this or what I did wrong. [Hmmm, after some thinking, I wonder if my issue was creating the original cube on grid X and then cutting the triangular corner for the bevel on a different grid size so the corners were weirdly placed... I'd have to test that out] And speaking of seams, is it possible to make a smooth texture transition from the surface of a cylinder (or ring or whatever) to its cap? See the third picture, which is the rounded base of a column. If it's not (or it takes a lot of effort or editing), then it's no big deal, as there are more important things to worry about. But if there's a quick & easy way (natural projection hasn't worked for me in this instance), it would be good to know. Thanks!

Here is another update to the English Stone font's DAT file used for subtitles and some readables: fontImage_24.dat This supercedes the Jan 30th update. As agreed, now all character spacings - as given by xSkip - are preserved (from this file in TDM 2.11). Exception: the Jan 30th repair of garbage metadata for "<" and ">" remains, including xSkip repair. ASCII Characters (lower 128). The earlier Jan 30th post summaries those ASCII characters that needed metadata changes to avoid adjoining stray marks. (The detail report below updates newer reversions and minor revisions.) ANSI Characters (upper 128). An analysis was also made of the status of the Stone 28 pt font's characters in the upper codepoint range of 128-255. This could be of interest if the subtitle system was some day expanded to include European languages, and continues to use the historic codepage method. The analysis also prompted some additional DAT tweaks now. Broadly, implementation of the upper-range characters (standard or TDM-specific, as defined in the TDM wiki's I18N - Character mapping I18N) is incomplete for Stone 24 pt. The status is: 43% (55 chars) Good as is. 9% (12 chars) Good enough after DAT tweak included in this update. 6% (7 chars) Missing and shown as hollow box. 30% (38 chars) Missing accent/diacritic. 7% (9 chars) Otherwise weird. But often suggestive of glyph work started but not completed. In addition, 7 chars within categories (3-5) were "improved", but are still not good. To really solve categories (3-5) requires DSS bitmap surgery (and corresponding DAT adjustments), which is beyond the scope of planned work. DAT tweaks of ANSI characters (like with ASCII) were careful to avoid changes to xSkip. Tweaks can be further grouped by problem solved.... In category (2): - (4 chars) Char is clipped, with stray mark from adjoining character on other side. - (7 chars) Stray mark, without char clipping. As improvements in categories (3-5): - (3 chars) Stray mark, without char clipping - (4 chars) Out of valid range on top edge A categorized itemization about treatment of specific problems and characters, with further details, is here: Information about methods, including new tools, to conduct this analysis and tweaking will be forthcoming, mostly after the 2.12 release.

in case you wonder my beard was white when i hit 25 only started getting some grey streaks in my hair in the last two years hehe. and for those younger here enjoy your youth while you have it at around 40 the problems start (just look at those receeding hairlines atrocious!!!), well if the hair was my only problem i could live with it hehe i also got gall stones kidney stones and a nasty fall which broke my back in two places at around that time. So enjoy it while you can or stay away from ladders

Are you aware of the pointfile feature? Dmap writes these .lin files into the maps directory. Display them with File->Pointfile and look for red lines that visualize problems like leaks and visportal problems. Which faces of a brush are sealing depends on the material assigned to the face. I don't know exactly which ones seal and which don't.

The problem does not show up with all related dev builds. However, I cannot test with the last build (16854-10518), which I simply cannot start and get the report EDIT: As per our friend dragofer's suggestion, I made a blank script file in this build and removed the turrets from the WIP for a test. Then I can start the game and the mission and can save/load without problems. Summary: 16842-10488: no problems 16854-10518: cannot test (see above) 16854-10518 (modified scriptfile, no turrets) : no problems beta 1: problem appears

No, you are right, that was my mistake. Thank you for asking that, cause this would have caused me problems during beta testing as every AI must be on the same team in this mission. Anyway, this happens when both are on the same time (tested three times, each time the same result): https://streamable.com/0n3yqg This is much better...but far from perfect. During the second try the other guy returned, but did not assist his friend.

New script for mappers: my flavour of a fog density fading script. To add this to your FM, add the line "thread FogIntensityLoop();" to your map's void main() function (see the example in fogfade.script) and set "fog_fade" "1" on each foglight to enable script control of it. Set "fog_intensity_multiplier" on each info_location entity to change how thick the fog is in that location (practically speaking it's a multiplier for visibility distance). Lastly, "fog_fade_speed" on each foglight determines how quickly it will change its density. The speed scales with the current value of shaderParm3, using shaderParm3 = 1000 as a baseline. So i.e. if shaderParm is currently at 1/10th of 1000, then fade speed will be 1/10th as fast. Differences to Obsttorte's script: https://forums.thedarkmod.com/index.php?/topic/14394-apples-and-peaches-obsttortes-mapping-and-scripting-thread/&do=findComment&comment=310436 my script uses fog lights you created, rather than creating one for you. Obsttorte's script will delete the foglight if entering a fogfree zone and recreate it later more than one fog light can be controlled (however, no per-fog-light level of control) adding this to the map requires adding a line to your void main() script, rather than adding an info_locations_settings entity with a custom scriptobject spawnarg in my script, mappers set a multiplier of fog visibility distance (shaderParm3), while in Obsttorte's script a "fog_density" spawnarg is used as an alternative to shaderParm3 smaller and less compactly written script fogfade.scriptfogfade.map

I haven't used DR in a while, and saw that my old layout was gone. Trying to muck about and re-establish some half-assed approximation of that took a while. Problems I had: "View -> New XY View" . OK, I need an YZ view, does that cover it? Took a while to determine, yes it does, you have to use Ctl-Tab to get to alternatives. (Never used that much in the past, once I had my 3 orthogonal views). HOWEVER, with this new system, sometimes I would create the 2D view, but couldn't then direct Ctl-Tab to it. Bug? It became clear after a while that there were some places you could dock, and some not, and that the blue haze would indicate that. And that those locations might change depending on what you did before. One problem for me was I had a 2D view that I wanted to dock in the right lower corner, but it would only do a full-height docking. And after a full-height dock, there was no way to grab a corner handle to make it less than full height. I'm not asking for that feature... I just wish I had a reasonable understanding of the best way to sequence and manage the horizontal and vertical splits. So: Do update the now-obsolete section of the user manual, and ideally provide a thorough video to illustrate the new system. (Sorry, datiswous, your vid above is not it.) Hint: That unrushed video, with audio, should demonstrate how to approximate each of the old layout styles.

@MirceaKitsune - have you raised a bug report for this particular problem (searching in the wrong place if shot by an arrow)? I think I have found the cause of it and can write it up in the bug tracker. In short, I believe the intended behaviour is that the victim is supposed to search halfway between him and the shooter (presumably chosen because he shouldn't really know where the shooter really is) but the code that sets this point gets overridden shortly afterwards by code that sets the search point to his current location. It's quite instructive (if you like that sort of thing) to read up the various bugs reports on AI behaviour that have been raised down the years. In particular, bug 3331 contains a number of fixes to problems similar to those reported in this thread.

Congratulations on the release! Downloading now!

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.

Here's my first FM. A small and easy mission, inspired by Thief's Den and The Bakery Job, where you must find and steal a cook's recipe book in order to save a friend from going out of business. Download (version 4): Mediafire (sk_cooks.pk4) TDM Website's Mission Page The in-game mission downloader Thanks to: The people who helped me get this far, both in the forums and on Discord. The beta testers: MirceaKitsune, Mat99, Baal, wesp5, Cambridge Spy, jaxa, grodenglaive, Acolytesix ( Per the author in the beta testing thread. ) Skaruts has given permission to the TDM Team to add Subtitles or Localization Strings to this mission. (No EFX Reverb.) If anyone from the Community or TDM team wishes to create these we will gladly test them and update the mission database.

damn btw dont do this if you have problems with the current avaliable nvidia driver 435 since it is broken in some games. So obviously i tried the beta version... well now i can reinstall

With TDM 2.12, after the credits finished, the "Mission Complete" screen did not display. I found that the screen was black and I could hear my footsteps when I tried to move around. I think the reason for the mission not completing successfully was that the "Do not kill or harm allies" objective was never marked as "1 = STATE_COMPLETE" instead it was left as "0 = STATE_INCOMPLETE". Note, I didn't use noclip throughout the mission. Same as: https://forums.thedarkmod.com/index.php?/topic/18054-fan-mission-the-accountant-2-new-in-town-by-goldwell-20160509/&do=findComment&comment=458491

How about using TDM automation framework (and maybe pcem/qemu)? More info see: https://forums.thedarkmod.com/index.php?/topic/19828-automation-features-and-discussion/

File Update for Improved Subtitle Font As requested a while ago, to address the stray marks and other problems seen with current subtitle font, Stone, I am providing a short-term fix for characters in the printable ASCII range 32-126, using corrected metadata: fontimage_24.dat This is intended to replace tdm_fonts01.pk4\fonts\english\stone\fontimage_24.dat No change is needed in the related .dds files for this. Briefly, problems with stray marks found to the left of a character were due to picking up pixels from an adjoining character in the glyph bitmap dds files. Adjusting the location of the source box and related metrics fixed these. Affected were: % C E T W Y | The | character also got improved spacing, as did J Finally, the entirely screwed data for the angle brackets was corrected. This coming month I hope to work up a wiki page with diagrams to better explain what I learned about the mysteries of the idTech4 font .dat and .dds files. To see what the results look like with corrected fontimage_24.dat in place (as an override), here is my testing FM: testSubtitlesASCII.pk4 A longer-term fix (beyond 2.12 release) would also address ANSI and TDM-specific-mapped charaters in the range 128-255. To look at that, I have a similar experimental tester for ANSI (unripe to release). It shows substantial issues in that range. And then there's also consideration of fontimage_12.dat and fontimage_48.dat. And the russian-character variant.

Solus and SteamOS are not the same https://www.slant.co/versus/2694/2714/~steamos_vs_solus Solus is actually better according to reviews hehe. And true OpenBox is a bit limited but i find it to be an ok alternative if you develop something from the ground up like NomadBSD. BSD does not have a lot of active desktop Operating Systems but NomadBSD is quite nice though minimalistic. It uses OpenBox and the desktop is in the mac style, originally it used an XFCE port and there are still some traces of XFCE apps left -> atleast one i know of because if you try to access the color composer in the file manager it complains about the lack of several XFCE libraries minor whoopsie on the developers part i reckon since that part is now handled by OpenBox. Despite this it works fine and is mostly used as a live OS to boot from usb. had a bit of a problem with it on this PC though as it seems to have problems with my hardware making it slower than molasses to boot. An alternative is GhostBSD which is a more complete desktop for BSD using MATE. It unfortunatly does tend to break quite often, and the package manager seems a bit out of date which might be because a lot of the desktop system was ported from linux and the newer ones have not quite catched up yet on BSD. Despite this i find the BSD kernel to be great, it focusses a lot more on security than most linux kernels and the main BSD distros tend to be quite stable (FreeBSD NetBSD OpenBSD etc.) you can still install a desktop on say FreeBSD if you know how to hammer it all together so that it boots into the desktop but for the most part the main BSD's are shell only.

I cannot speak for the mission creators, but if was one i would say: "thanks for the suggestions. please adjust them yourself, if you want to do it. The needed source and info are publisched online. it takes time to repair the problems. I (dont) have time for it. Maybe you get some experience by repairing this yourself, to create some new content yourself."

yeah win11 is not that different from win10 except for some rather ludicrous hardware expectations like cpu and tpm. i can get behind the tpm requirement though truth be told one could use an usb stick for the same (storing encrypted keys), but the cpu requirement is kinda fubar since i use a gen 4 for running win10 with no problems whatsoever and it also runs 11 just fine despite not being on the approved list. sure you can fool win 11 to install on it but there are no guarantees that microsoft wont disable that down the line so no thanks :). manjaro was one of my earlier favorites in the linux world, sadly the last time i tried it, it would not play ball with my hardware and also had a bit of the same problem most other mainstream distros have where you could install stuff not native to the kernel and hence break everything, i find what solus did to be gratifying since a lot of people who have not grown up in the linux world and who are not able to identify and correct these annoyances should feel more at home. sure theres still a bit of reading to be done but you dont need to be a rocket scientist to use it