Search the Community

I fixed this double button. As for the button labels, I don't know what to say. Ideally the C++ code should be expanded to model each forward/backward transition and detect where it goes, then assign the labels. And the GUI script should call this new "label initialization function".

Hi huntaffer, Yeah and know what? In a parallel universe mods are managed in-game in a dedicated screen. You enable and disable the mods you want, click ok, and the game reboots. We aren't in that universe though but I may some day reach out to @Skaruts when he's done with his TDM Packer and see how bored he is and if he is up for a TDM Mod Manager I am not sure a dedicated topic exists for this bug but consider posting something here: Looking and listening through a keyhole. The more reports / complaints the higher the chances of a solution! My understanding is that this should be fixed in the source code. Yes, this mod can be done. I didn't play Thief 3 (can't stand the camera jittering) but are you sure you want to turn moss arrows into "gas arrows in disguise"? I cannot model or animate and this is beyond my abilities but I could make you shoot deadly skulls! (not joking)

This helps. I have gotten all the help I need now on this problem. edit: I have a question about texturing. What is a reason that textures might appear intact in the editor, but be transparent in-game? I'm getting patches of texture that are cut out of the corners of brushes, when the brushes themselves are not divided. I think it's related to duplicating. I duplicated a staircase for instance and all the duplicates have a texture completely missing on the side. In the case of some duplicated walls though, around 25% of the texture is showing. edit: Appears to resolve itself randomly after making edits. Whatever is happening during these edits to bring things back to normal, it isn't very apparent to me

I would like the development team to consider applying the GPL3 licence to the following Text file which was created by @Tels, @Greebo and @Dragofer. tdm_internal_engine.mtr (darkmod>materials) The reason for this request is that it is a critical core file and without it the engine (when built from source) cannot launch at all. I would also like to query whether the following script files created by @Obsttorte and @Dragofer: tdm_audiograph.script tdm_camgoyle.script tdm_grandfather_clock.script tdm_safe_lock.script tdm_safe.script tdm_turret.script were intentionally released under the CC-BY_NC_SA_3 licence or if this was an oversight? I ask since all other .script files included with TDM (and which are all called by the engine source) all contain GPL3 headers while these files have no licence information at all so naturally fall under the CC-BY_NC_SA_3 licence. Additionally in investigating which text files are required by the engine depending on scenario (and while I understand that the number of developers who are no longer on the development team may affect how many of these files can be licenced) I wondered if these too may be open for consideration as to their licence? tdm_base.def tdm_soundprop.def cursor.gui mainmenu_background_custom.gui mainmenu_background.gui mainmenu_briefing_video.gui mainmenu_briefing.gui mainmenu_credits_background.gui mainmenu_credits.gui mainmenu_custom_defaults.gui mainmenu_custom_defs.gui mainmenu_debriefing_video.gui mainmenu_defs.gui mainmenu_download.gui mainmenu_failure.gui mainmenu_loadsave.gui mainmenu_main_ingame.gui mainmenu_main.gui mainmenu_message.gui mainmenu_music.gui mainmenu_newgame.gui mainmenu_objectives.gui mainmenu_quit.gui mainmenu_settings_audio.gui mainmenu_settings_controls.gui mainmenu_settings_gameplay.gui mainmenu_settings_gamma.gui mainmenu_settings_guisize.gui mainmenu_settings_language.gui mainmenu_settings_video.gui mainmenu_settings.gui mainmenu_shop.gui mainmenu_success.gui mainmenu_utils.gui mainmenu.gui msg.gui tdm_objectives_core.gui tdm_subtitles_common.gui tdm_subtitles_message.gui tdm_gui.mtr tdm_tables.mtr tdm_guis.sndshd all.lang english.lang These provide the foundation of a working base main menu. TDM's main menu also includes several undocumented commands (that neither show in listcmds nor listcvars) which are useful to know for anyone wishing to use the base source code. I have listed the .lang files solely because of the #StringNum associations, I appreciate that they are not truly required for the above to be a foundation. While looking into how far I could break TDM in removal of files, I came across this thread by @Fiver suggesting a Libre version of TDM: https://forums.thedarkmod.com/index.php?/topic/22346-libre-version-of-tdm/ I believe that in that instance all text based files would need to be GPL3 licenced, leaving only videos, sounds, textures, models and the like as still being under the CC_BY_NC_SA_3 licence since remaking the files would likely result in most cases with near-identical looking files to the original. Thankyou for your consideration.

I added this to 2.13 SVN I did a rough translation of the new texture quality menu but did not translate the new 2.13 player toolscatalan.lang Feel free to modify further

It might be best to simply encourage them to come to the forums

There's a person messaging the Dark Mod twitter account, saying they can do a Catalan translation of the game. I pointed them in the direction of the Wiki and the forums, but they're saying they want to email someone about it. I'm not really involved in the translation side of things, so I don't have any useful input here. Any ideas?

Just played this, had to see what all the fuss was about . I enjoyed it actually, despite the shortcomings pointed out by others. You just simply need to watch those Springheel tutorials and go through beta test and it would be infinitely better. My own minor critiques: Spelling mistakes: 'Mummified' is spelled wrong in the objectives 'Maintenance' is spelled wrong in the instructions The stairs going up to the top floor is janky to walk on. This can be fixed by covering the stairs with a slanted brush made of clip texture, or appropriate nodraw_solid texture (e.g. tdm_nodrawsolid_carpet) The gate disappearing at the end felt weird. Just making it a door that opens or stopping the FM as you approach would have been better IMO.

I decided to share my in-depth thoughts on this. On one side I don't want to be discouraging or throw lessons like I know better... on the other side I want to encourage other creators to make awesome content. I think you have the basics in order, but would advice practicing more for the next FM. I'll address everything of importance that I noticed... some of these are important for creating a working FM, others are based on my experience and how I do things. Visual: Most areas appear pretty simple and rough, the rooms look too much like cubes textured with flat materials that lack detail. While not everything needs to look AAA all the time, I'd encourage adding more detail to the world and using fitting textures with more complexity where appropriate. I'd also check out the building modules. Skybox: A big problem is you can see and touch the skybox. Being able to see the world edge and walk into an invisible wall isn't recommended. You usually want some kind of wall or structure between the player and any portal_sky surface. Portals: You aren't using visportals. This is a small mission with few entities so performance happens to be good, but every FM requires portals. You add them by filling spaces in and between walls with a brush that has a nodraw texture on all sides and a visportal texture on one face, every interactive door and window should have one, the brush must perfectly fit in those spaces without leaving gaps or you'll get a dmap error. You can press N in-game to see them, I'd use that to look at how other missions portal their maps. Just think of them as virtual windows that only show entities and other portals that can be seen through them, your goal is to design the architecture in such a way that they cover each other as much as possible from any position and angle. Clips: Since you likely haven't used those either, clip brushes are another aspect worth mentioning. Apart from the standard clip texture that used to keep the player from reaching certain areas, encase all large static models (eg: furniture) in a brush textured with monsterclip or AI won't detect collisions and attempt to walk into them. Lighting: Light placement was okay. I'd be careful about putting too many candles next to each other, lights are performance intensive so you want to have as few as possible covering an area. Only issue was ambient light which is too strong, both visually and in making the player visible, I suspect I alerted everyone because it's so bright I scared the whole map when jumping through the window. When the player is crouched without moving in a completely dark area, the light gem should be at its minimum value, adjust ambient light based on that. Ambiance: The map has no music, this isn't a big deal but for a good FM you'll need to learn about locations and using the location_info / location_separator entities to separate portal rooms and give each one an unique song and ambient color. Objectives: Having just two objectives is fine for a tiny FM, usually you'll also want a loot objective based on difficulty level. Only issue with the main objective was that it's difficult to grab the leg; It's lit by a lamp that can't be turned off, lots of AI walking around at once so it's also hard to catch a break when no one is looking... always be on the lookout for those things and what options the player is given. The final objective telling the player to leave once all is ready should use a location check rather than interacting with an item. Tools: The FM doesn't provide any of the starting items that are normally available... blackjack and sword, lockpicks, spyglass, lantern, compass. This isn't always a bad thing, in mine I like having the player pick them up from the world, but generally you'll want them to be available. Navigation: The layout was good and navigates well. There was only a problem at the end, where the map requires you to take a fall that deals damage; If this is intended I don't think it's a problem, there's one FM I played recently that requires you to take some damage as you proceed, but most aim to let the player have a no-damage run without having to confront any AI if you can help it (excluding knockout or assassination objectives). I hope this helped, let me know if I can help with more info. Here's a screenshot of the world edge I was referring to, you can also tell the excess ambient brightness which is reflected in the lightgem.

Of course. The depth hack works as intended and basically stops weapons and weapon attachments from clipping through the map geometry. I confirmed this by setting it to false in the engine code and noticed that the weapons/items clipped without the hack enabled. I think the issue happens when an object is fully outside of the map. You can see this if you "noclip" to an out of bounds zone, the weapon will stop being rendered. So, when the player leans against a wall, the items in the hand, which are fairly small, will be completely outside of the map and thus stop showing on screen. To fix this, I simply added a square plane to the object model to make it bigger than it actually is, and added the "nodraw" texture to this plane so it wouldn't be visible. This way, the object is big enough that some part of it is always inside the map, forcing it to be rendered. The easiest way to add this invisible plane is by exporting the object model we want as an ASE file in Dark Radiant - so we can open and change it - and then manually adding the geometry and material of the plane to the file. I edited the first item in blender to add the invisible plane and then saved its geometry and material in a template file that I can now use to just copy and paste to any new models I want to add to the mod. It seems to work well. The only important part is exporting the model in Dark Radiant with origin at "0 0 0", since the first plane was created for an item with that origin.

My proposal to the Team was to internally add names to all objects: entityDef atdm:moveable_bones_skull { "inherit" "atdm:moveable_bones_base" "editor_displayFolder" "Moveables/Graveyard" "model" "models/darkmod/graveyard/bones/skull.lwo" "mass" "3" "snd_bounce" "tdm_impact_largeclaypot_01" "item_name" "Skull" } Why? It doesn't matter. This has no impact on the game but it could allow for who-knows-what in the future. A use-case is to display item names onscreen when you grab one. If anything, to let players know in some situations if an item is selected and which item it is. I never asked this to feature in the game but I understand the way I presented the initiative could have been perceived differently. No, it only takes more memory. As explained by @stgatilov string literals (anything between quotes) take a small but considerable chunk of (scripting) memory. The more "" there are the more memory is required. My mod makes heavy use of string literals and while we are within safe margins the mod increases (scripting) memory usage by around 15%, hence the "waste of resources", which are better spent elsewhere. And here it remains if anyone wants to use it.

perhaps, going to toy a bit with the settings in other games it probably wont work as the texture requirements exceed avaliable vram by quite a lot (horizon zero dawn for one) only lowering vram gobbling monsters work there.

If it's not, that could be a reason for the texture pop-in issues you experience.

Mine is a 100hz ultrawide asus. Snd yeah it does make a difference though nut with the stuttering which might be the wrong word, its more like texture pop in but since darkmod is not streamed like some engines it is different.

the biggest problem with adding 12gb to the 3060 is mostly that the card cannot handle 4k in all but older titles and even with those it has problems , the 3070 does have the muscle for stutter free gaming in 4k but is limited by vram. There are no 3070 cards besides user modified ones with more than 8gb, the user modified 16 gb version showed that it made a big difference in 4k but not so much in lower resolutions. the RX6600XT is mostly equal to the 3060 perfomance wise the 8gb 3060TI is a much better card than the 12 gb 3060. https://gpu.userbenchmark.com/Compare/Nvidia-RTX-3060-Ti-vs-Nvidia-RTX-3060/4090vs4105 unfortunatly the same can not be said about the ti model of the 3070 which at best is only about 5% faster than the standard 3070 and still only has 8gb vram

a 12 gb 3060 would have made more sense putting that in a 3070 or even the ti model but nooo we cant have mid range cards even attempt to outdo our top end . sad thing is it wont... it only gives a boost at 4k resolutions and nowhere near what a 3080 can achive sigh.

Yeah you can read that in the documentation: https://www.reedbeta.com/blog/understanding-bcn-texture-compression-formats/#bc4 And there you can also read what the benefits are of the format.

tried win 7 on it just for fun and it runs pretty well though a bit on slow side booting as this pc uses mechanical harddrives. threw dark sector on it because i had some problems running it on my ultrawide and 4k screen and it runs quite good to on xp. should be pretty cheap for anyone interrested to throw together a retro box, the parts are usually cheap as dirt even the 6800 ultra can be had for a pittance these days. win98 can actually also use the 700x series from geforce but not the 800x series win9x has no support for the cuda driver needed with those cards. the ati's from that time are also an option but performance wise they cant hold up to the geforce cards but who gives a damn with games on win9x . i dont mind giving advise for those who want to try building one as the specifications are a bit strict if you want the latest and greatest hardware that is compatible with win9x. also some of the hardware needs patched drivers if say you want to use sata with win9x (yes it is possible i use it) . for soundcard use creative pcie128 for max compatibility. gfx card geforce 600x series or ati from around that time. 700x series if your board has pcie. cpu it does run on the core2 series but win9x is limited to one core, you could also go with a pentium model with one core but if you intend to dual boot with xp or maybe 7 the core 2 is better. harddrives with unpatched drivers you are limited to PATA with the patched ones you can actually run win9x on an ssd but this might be to fast for some and also makes it a living hell to debug if some driver burps. ram DDR1 or DDR2 with specs matching the board.

Finally managed to fix the clipping issues with the items. Here's a video showing a comparison between a model with the fix applied (unlit lantern) and another without (lit lantern).

It does! Actually... I was naming objects based on the name of the def but I started looking at custom objects in mission and noticed sometimes mappers keep the definition but change the model of the entity. I have now changed strategy and I now check (for the most part) the name of the model. Not only naming is more reliable and accurate now but it allows me to name (most) custom objects created by mappers. Work in progress. There still are edge cases though that deserve attention and a decision. In example model "apple.lwo" would be named as "Apple" (I try not to take extensions into account) but, what if a mapper use "applepie.lwo" as the name of his/her model? The pie would be called "Apple" I'll do my best. I built the functionality of displaying names of bodies (on grab), inventory items (on drop), objects (on grab)... in Core Essentials. The Modpack is continuously evolving and I simply don't want to deal with duplicated code.

Unfortunately, I don’t think this is possible—at least not with the way the mod is currently implemented. All the models and animations are tied to the “unarmed” weapon entity, not the player entity. In order to have the legs and the rest of the body, we would need to add the models and animations to the player entity and modify the source code to allow the body to be visible, kind of like how it's done here. I did initially try this method but realized that the existing model/animations are a bit of a mess and it would be a LOT of work to make it look good. Also, I chose to do it this way to allow the mod to be compatible with everything, since the script and def files for the "unarmed" entity aren’t modified by any FMs (as far as I know—I haven’t tested them all). I assumed that someone may have tweaked the player files for their FM, as those are far more relevant than the "unarmed" files (which are essentially blank in the vanilla game). If I had overwritten them, I’d risk breaking their mission. There has been some discussion in the forums about having full body awareness and there didn't seem to be a lot of interest in it. Plus, it could end up being immersion-breaking. Imagine standing on a small rope and then looking down, only to see your feet just kind of floating in midair.

Amazing, this is a very interesting mod. It's not exactly something I like, I somehow like it when I have my lamp out without the hand, I just imagine he uses it on his hip or so. For the compass, well...Magic for all I care. Adding this into default TDM would be great, as an option. However, what really intrigues me from this is the possibility that it could be upgraded into also making it so you can see your own legs and shadows? If possible, that'd be even greater! Also, this mod makes me realize that the Player Model needs a complete overhaul, the meshes, UV textures and even bones are so bad, hah!

If you have missing textures in your map that give warning messages, like: WARNING: Couldn't load image: default But you don't know where they are and they could also be on specific faces, you can use this DR filter and fix them: It hides everything that has textures applies except where texture _default is used. Texture _default is what DR saves in the map when there is no texture applied.

Automatic BC4 compression can be enabled for the new parallax maps. This is most likely true. As far as I understand, most of the specular maps should be grayscale. It does not mean we can enable the compression for all maps. But the loading code already checks whether all channels are the same and switches to single-channel format automatically if it is true, so it is possible to use BC4 instead in this case. Also there are light falloff textures. But they are few, small, and they'd better be uncompressed. Also there are light projection textures. Sometimes they are single-channel, in which case it makes sense to compress them it mapper wants to do it explicitly. Luckily, no. It is possible to set texture swizzle on the texture during creation, then it will automatically broadcast red channel to RGB on all fetches. That's how grayscale images work right now.