Leaderboard

As my custom assets work has increasingly shifted from models towards scripting, I'll open a new thread here to contain any scripts that I write which can be reused in other missions, starting with the A ) Presence Lamp This is a Lost City-style lamp that brightens and dims depending on the presence of the player or an AI. It fades between 2 colours and can trigger its targets whenever it switches fully on or off, so it should also be viable in various other situations. The standard setup consists of the following: - a trigger_multiple brush. The spawnarg "anyTouch" controls whether AIs, too, are able to activate it - a presence lamp, highly recommended with a colorme skin - one presence light, or any other light with appropriate spawnargs The targeting chain is trigger brush -> lamp -> light When the player or an AI stands in the trigger_multiple brush, the lamp switches on and starts a short timer. Subsequent triggers reset the timer. If the timer runs out because no one's standing in the trigger brush anymore, the lamp switches itself off. Notes - Multiple trigger brushes can target the same lamp, and one trigger brush can target multiple lamps. However, each presence lamp can only target one light, so if you want i.e. a bouncelight you'll need to hide an additional silent presence lamp somewhere and target it from the same trigger brush. - The lamp and the light use their own colour spawnargs respectively, since setting 0 0 0 on a lamp would make it appear pitch black. - Technically the trigger brush can be exchanged for anything else that triggers the lamp every 0.5s (this number can be changed via "update_interval" on the lamp), i.e. a trigger_timer. - This was originally named the proximity lamp and was one of many scripting jobs for The Painter's Wife. I've renamed it to "presence lamp" because the mapper may place the trigger brush(es) wherever he wishes: proximity to the lamp is not a factor. Credits go to Bikerdude for putting together the crystal lamp models. Download Presence Lamps - Google Drive Place or extract the .pk4 into your FM archive, then look up the presence lamp prefabs. If you already are using other custom scripts, remember to add the presence lamp's .script to your tdm_custom_scripts file. B ) Teledoor This is a Skyrim-style door which opens just a bit into a black_matt "void" before teleporting the player to a different area of the map, which may represent the other side of the door. This is used for connecting physically separated map areas with each other, such as when there's an exterior/interior split of a building or ship to allow for more mapping freedom. [Full Thread] C ) Mass Teleport This is a teleportation setup designed to seamlessly teleport the player and any moveables between two identical-looking areas. This allows the mapper to link 2 physically distant areas with each other while maintaining the illusion that they're connected. The teleportation zones should be free of AIs as they can't be teleported like this. [Post] D ) Automaton Station A station for Sotha's automatons (includes the automatons) which can be switched on and off by patrolling automatons. (Part of core assets as of 2.10) [Post] E ) Camgoyle A sentient turret originally made for the FM Written in Stone. It's based on the new security camera entity and augmented with scripting to allow it to fire magical projectiles at the enemies it detects. People are more than welcome to use it and to convert it into something else, such as a mechanical turret. [Post] [Download] F ) Audiograph The audiograph is an Inventor's Guild device for playing back recordings stored on spindles, which are small metal cylinders the player can pick up and store in his inventory. [Post] G ) Turret A new companion to security cameras familiar to Thief players. It will become active as soon as an enemy is detected by a targeted security camera, firing projectiles to fend off the intruders. Similar to the security camera and the camgoyle sentry, turrets are highly customisable in their behaviour and appearance. [Thread] G ) Fog Fade Dynamically change fog density depending on what location the player is in. [Thread]

I think it's the nature of a community-driven project like TDM that people should be the change they want to see. Implementing a character takes a lot of steps and it's rare that a single person has the knowledge and time/motivation to do all of them. So if you have - or can reasonably learn - some of the skills needed to get some of those steps out of the way, then that's the best thing you can do to make it happen. In this case, that'd probably be completing & exporting the animations, and sticking around to make the modifications that'll inevitably be necessary. That way, whoever should pick up this character doesn't need to be both a Blender-based animator and an asset manager or coder. That's basically the approach we're going for with the dragon, too.

A working dog would certainly be a lot more useful than a dragon, and significantly easier as well due to the size, lack of wings, etc.

Now all is ok ! Great new mods, thanks !

No I mean memories of TDS not TDM.

Could you please install some 32-bit trash and check whether 32-bit build works properly without setting device explicitly? I find it amusing that it works properly in 32-bit build. It seems to be normal, but completely pointless. It is entirely precise and completely useless information, just like in an anecdote about programmers. Here is discussion about this, which says this weirdness exists for compatibility with old Creative's implementation. Look at the code: //gets list of all available devices --- their names are printed to console as "found device ..." const char *devs = alcGetString(NULL, ALC_ALL_DEVICES_SPECIFIER); //opens default device in OpenAL --- that's what happens if you don't set s_device openalDevice = alcOpenDevice(NULL); //gets the name of device --- that's what is printed to console as "using ..." alcGetString(openalDevice, ALC_DEVICE_SPECIFIER); It sounds obvious that querying the name of particular device and getting the names of all devices should return the same names. But it does not , because the function which queries the name of the device was in core OpenAL and was useless, and the function to get the list of all devices was added later as OpenAL extension specifically to cope with this problem. As far as I see, I cannot get the detailed name of an opened OpenAL device. But it looks like I can query ALC_DEFAULT_ALL_DEVICES_SPECIFIER to get the name of default device (i.e. the one which gets opened by alcOpenDevice(NULL)). This way I can probably print the proper name to TDM console

This is magic - you did it: Specifying the ALC1220 audio chip in the darmod.cfg file gives me sound in the 64-bit version! Thank you so much for your help and insights, both of you. I just changed to Linux less than two years ago and still feel I have a lot to learn (never managed to get JACK running, and Ardour is unusable for me and can't even play a simple wav-file without stuttering due to xruns - well, maybe Pipewire will one day simplify things for us poor users...?) But at least this problem seems to be solved. Thanks again!

Phew, it's almost exactly been 3 years since my first post about my VR modification for TDM. Three more versions of the game have been released in the meantime, and with them come performance improvements that I feel it's finally viable to continue my work on the VR adaptation So without further ado, head on over to https://github.com/fholger/thedarkmodvr and grab the latest release. It's based on the future 2.09 version, but is fully compatible with a 2.08 install. Although I've tried to make the VR version use its own set of resources (separate `darkmod_vr.cfg` and shader folders), I'd recommend you make a backup or copy of your TDM installation to be able to get back to the flat version cleanly without effort. Please heed the README in the repository, particularly about the choices of VR backends. Some noteworthy information for this new version: performance should be considerably improved from the old alphas. That doesn't mean it's perfect - although the CPU bottleneck is now completely gone, the game is now severely fill-rate limited. So if you have a current-gen headset with high resolution and/or a weaker video card, forget about any supersampling or AA. I also strongly recommend to stick to stencil shadows and disable soft shadows and ambient occlusion - the latter isn't that impressive in VR, anyway, and simply not worth the GPU cost. And even then, there will be some scenes in some missions where reprojection is just unavoidable, even with the beefiest GPU. That being said, I have tried a multitude of maps, and I think it's very playable. the UI is finally usable! Both the menu and ingame HUD elements are projected to a virtual screen in front of your sitting position. It's not the most elegant or immersive solution for the HUD, but it works vertical mouse movement is excluded from the VR view - this was suggested by some of you way back, and I think it makes the experience much more enjoyable. It can make it a little hard, though, to aim with the mouse for actions like frobbing items, because there's currently no visual indication to where the mouse is pointing. I'm planning to add one asap, but in the meantime, you can equip a weapon to get a vague sense of your mouse orientation. If you do want to re-enable vertical movement in the view, set 'vr_lockMousePitch' to 0 in the console. Other than that, I hope you enjoy this new version. Let me know which improvements you'd like me to work on first. Also, there are probably any number of render and other bugs still left in there somewhere. If you find one, please report them over at the Github tracker (https://github.com/fholger/thedarkmodvr/issues), so I can keep track of them. Latest Update:

This was amazing thank you to everyone involved. I had a great time exploring this huge map and I know I probably missed a lot! pwl

I think it should choose "ALSA default": it looks like the best default and comes first in the list. Why it doesn't work --- that' probably question to ALSA configuration.

Is it possible that when s_device "default" is set, that it is looking for 'CARD=0,DEV=0'? I'm asking because I'm not a programmer and have no idea how a lot of this works. If that is the case, then maybe when s_device "default" is set it doesn't look for 'CARD=Generic,DEV=0'?

seta g_showPlayerShadow 1 While not perfect it brings back old memories and I prefer it on.

Small progress update: I found some dormant Doom3 BFG code to calculate light scissors which give a tighter and also more correct bound. That means there should be fewer lighting/shadow glitches, if any. Together with the tighter light scissors, I made a few other improvements that should hopefully provide a minor performance improvement. Nothing game changing, but everything counts My plans over the weekend are to get a working indicator for the mouse aim and perhaps fix underwater and similar views. I'm also still looking into the mismatched text rendering, but so far haven't found the cause. EIther way, with any luck I'll publish a new alpha over the weekend that should hopefully come a few steps closer to a good seated gaming experience.

I had tried "ALSA Default", with no luck, when I was trying to fix the same issue. I'm pretty sure the device listed as DEV=0 is what is needed, but not the one listed as Loopback. I'm 99% positive that using the following will fix this issue. If not, then try the loopback device.: seta s_device "HD-Audio Generic, ALC1220 Analog (CARD=Generic,DEV=0)" Here's what my condump looks like for openal. Notice the addition of "(ACTIVE)" once the device is working: ----- Initializing OpenAL ----- Setup OpenAL device and context OpenAL: found device 'ALSA Default' OpenAL: found device 'HDA NVidia, HDMI 0 (CARD=NVidia,DEV=3)' OpenAL: found device 'HDA NVidia, HDMI 1 (CARD=NVidia,DEV=7)' OpenAL: found device 'HDA NVidia, HDMI 2 (CARD=NVidia,DEV=8)' OpenAL: found device 'HDA NVidia, HDMI 3 (CARD=NVidia,DEV=9)' OpenAL: found device 'HDA NVidia, HDMI 4 (CARD=NVidia,DEV=10)' OpenAL: found device 'HDA NVidia, HDMI 5 (CARD=NVidia,DEV=11)' OpenAL: found device 'HDA NVidia, HDMI 6 (CARD=NVidia,DEV=12)' OpenAL: found device 'HD-Audio Generic, ALC1220 Analog (CARD=Generic,DEV=0)' (A CTIVE) OpenAL: found device 'HD-Audio Generic, ALC1220 Digital (CARD=Generic,DEV=1)' OpenAL: using 'OpenAL Soft' OpenAL: HRTF is available OpenAL vendor: OpenAL Community OpenAL renderer: OpenAL Soft OpenAL version: 1.1 ALSOFT 1.19.1 OpenAL: found EFX extension OpenAL: HRTF is enabled (reason: 1 = ALC_HRTF_ENABLED_SOFT) OpenAL: found 256 hardware voices ----- Initializing OpenGL ----- And, yes, it is normal for it to say it is using OpenAL Soft.

Setup OpenAL device and context OpenAL: found device 'ALSA Default' OpenAL: found device 'HDA ATI HDMI, HDMI 0 (CARD=HDMI,DEV=3)' OpenAL: found device 'HDA ATI HDMI, HDMI 1 (CARD=HDMI,DEV=7)' OpenAL: found device 'HDA ATI HDMI, HDMI 2 (CARD=HDMI,DEV=8)' OpenAL: found device 'HDA ATI HDMI, HDMI 3 (CARD=HDMI,DEV=9)' OpenAL: found device 'HDA ATI HDMI, HDMI 4 (CARD=HDMI,DEV=10)' OpenAL: found device 'HDA ATI HDMI, HDMI 5 (CARD=HDMI,DEV=11)' OpenAL: found device 'Loopback, Loopback PCM (CARD=Loopback,DEV=0)' OpenAL: found device 'Loopback, Loopback PCM (CARD=Loopback,DEV=1)' OpenAL: found device 'HD-Audio Generic, ALC1220 Analog (CARD=Generic,DEV=0)' OpenAL: found device 'HD-Audio Generic, ALC1220 Digital (CARD=Generic,DEV=1)' OpenAL: using 'OpenAL Soft' Hmm... it lists many devices, but then chooses device with name OpenAL Soft, which does not even exist in its list Could you please find the line in darkmod.cfg: seta s_device "default" And replace it with: seta s_device "ALSA Default" Also try all the other names listed in console excerpt. P.S. Actually, PranQster suggest the same.

Hope that helps. Happy Taffing!

Very cool! I'm not sure a dragon is a logical next step for filling out the AI roster, but its definitely impressive. I think this could be a cool animated set piece in a mission, but jumping right into making this a fully functioning enemy type that works in missions is crazy. To your comment above, spiders are general easier because they're essentially a ball with legs that can turn on a dime. There's lots and lots of problems with trying to do a quadruped this size, not to mention making it fun to sneak around and engage with. My sense is that something like this could work really well as an animated set piece/ scripted thing. For instance a mission where you need to steal from a sleeping dragon and waking it up fails the mission. Start with that and then think about making a fully functioning AI type.

Other major issues with something this large would be Inverse Kinetics for walking, turning, and keeping the wings and tail from constantly clipping into things. I don't know how difficult that would be. After five years we still haven't even got the werebeast into a fully working state. You would still need some additional animations as well: search pain breath weapon (what's the point of a dragon without one?) turn 180/360 I couldn't disagree more, actually. TDM is medieval steampunk and tries to avoid high fantasy tropes like orcs, elves and dragons. That said, I'm sure there would be mappers who would love to use a dragon if it was fully functional.

As a minor note, tdm_installer will soon allow publishing user-made versions --- that's what "Custom Manifest URL" is for. It is not implemented yet, but soon will be. I'm not sure if it would be easier than simple posting exe + shaders directory though.

That glosses over how it would actually work. How do you establish whether the player is silhouetted against a bright surface? How much of the player has to occlude a bright surface? How bright does the surface have to be? How many traces would you use and what numerical values would you give to the difference between the player and the surface behind them? How far does the trace go and is there any falloff over that distance? How would you translate this info into a numerical value, and how would it relate to the numerical value already used by the lightgem? For every one of those questions there are several hurdles to clear in making it work correctly, and that's not even considering the performance implications.