MirceaKitsune

A separate suggestion, I noticed this while doing the above tests: Please add r_shadowMapSize as an option to the menu, under the advanced shadow settings ideally just after the shadow softness / quality sliders (that's the sample count). This option implies a huge "good visuals" versus "bad performance" ratio and should be accessible for users to customize. Allow it to have at least the values 512, 1024, and 2048... possibly 256 for people with really poor hardware, and / or 4096 for folks with a powerful graphics card that want maximum sharpness. 1024 is a good default to stick to from what I'm seeing so I'd leave this unchanged. In my test just now, going from 2048 to 1024 granted me an additional 20 FPS, while 1024 to 512 offers yet another 20 FPS. The visual difference is also quickly noticeable however, with the shadow map becoming more square each step. I was at 2048 before noticing this and now went down to 1024 to enjoy better frame rates, even if the lower quality can be easily noticed on an 1080p screen.

Just wanted to report that I use all 3 of those cvars since switching to the beta. The first two improve performance without any noticeable visual differences or undesired side effects. The third (r_shadowMapCullFront) is the only one that introduces minor visual inconsistencies... more specifically causing shadows or AO to be culled close to an object. Here's a comparison screenshot without then with this cvar: Reminder: I use the vanilla AMD drivers (amdgpu + Mesa) on Linux (openSUSE Tumbleweed). It's often the AMD Linux drivers that have weird issues, so if it works for me it's rather surprising that others are experiencing issues. I'd do that. I also have r_usePersistentMapping enabled and everything else works well with it.

This is honestly among my top favorite FM's of all time. Replayed it for a second time and it was nice to see it again! Very nice and well thought out, well detailed with a lot of content crammed into a relatively small map. I wanted to report an issue I just now encountered in case it can still be patched up:

Then a wizard with psychic powers he is

Very nice FM overall. It's rarer to see proper outdoor FM's, with the right amount of detail and the geometry not looking fake, this definitely achieved that and felt very natural. Was going to mention the lightning performance and super low-res web texture, but you already clarified those in the first post. All I can offer is two small visual issues I encountered:

I noticed the black transparency bug on another decal again, FM Sneak & Destroy. getViewPos included this time.

Is it not something predefined? It seems unsafe to guess and use this way, if it might change in the future and then the mod would break and need to be edited to reflect a new handle. Overall it sounds like it might work, but is pretty hacky to use in this form. I'll think if to at least write down some suggestions in this regard.

But custom scripts can't access it. That's because you need the overlay handle of the GUI element using that GUI float. I tried using the custom overlay specific to my mod, and unsurprisingly $player1.getGuiFloat(mygui, "gui::lightgem_val") always returns 0.

Thanks, I'll keep that in mind. I think that if I open a new thread there, it will be after the next update: I want to add the last component (upgrade items) first and clean up anything that might still be obviously wrong. Hopefully it won't be too long till that point... just need to design a nice little lwo model for the items, then come up with a solution for vanilla FM's that won't have them thus I'll need to spawn those somehow.

It took one heck of an amount of work, but it's finally been done: Functional skills / augmentations are now in principle implemented! The update contains the same player damage system but with limb based enhancements fully working as well Today I finally separated the individual HUD components for each aug and made the icons operational, which is enough to post a beta for version 2.0 of this plugin. I improved and replaced some of the icons at the last moment, making them more visible and better suited for the effects they represent. Remember this version is still mainly for testing purposes! The skills are yet to be tested in a real FM, and most importantly there's no upgrade items implemented yet: The player will currently start out with all augmentations automatically upgraded to level 4, the next (and final) step is adding upgrade items to slowly gain them during a FM. Here's the latest pk4. Delete any previous version, then as usual simply drop this into your TDM folder which should automatically enable all the functionality in any FM. Testing would be appreciated; There are things I may not be able to change due to limits in the scripting system, but if there's any annoyance I can fix I shall look at it in the next update. player_2.0.pk4

A couple of bugs I found today. First of all I happened to replay the FM Special Delivery this time. This FM will crash and is unplayable with later TDM versions, if in the store at the start of the game you choose to buy the Speed Potion. It seems to be due to its scriptobject not being found... maybe it would be a good time to add the finished version of this potion to core? Second one, and I noticed this since the first 2.09 beta: The red and green glows when using items appear really sharp, as if in lower color resolution. Unfortunately I forgot to turn off the sharpen filter and see if that's causing it. Lastly I recently replayed Snowed Inn as mentioned above. Saw a little peculiarity which might be an alpha drawing issue in the renderer: There's a certain drawing on a wooden wall in a part of the map. When shining the flashlight at it, the corners of the decal plane become black rather than staying transparent. This only happens if the flashlight is on and perhaps shining at the right angle, without it transparency works just fine. Might count as a FM spoiler so just in case.

I can definitely add to this. I ditched Windows 8 years ago, haven't had it on my system since... still can't believe how long I lived on it till finally making this choice. Indeed the only issue is some games being harder to play, especially newer ones as old ones typically work fine under WINE. I didn't notice it much as I rarely touch commercial games any more; Unlike free projects like TDM, which are made by the community and we can fully edit, I don't feel those truly belong to us rather that some company who makes boring stuff just so we give it our money. We must not forget that TDM isn't just the only FOSS game of its genre: It's one of the only projects with AAA assets and graphics... albeit by 2010's standards, but in my book I would still call them that. Alongside it and Xonotic, most open-source games have pretty cheap assets and a lot of bugs unfortunately... TDM however has long achieved commercial quality, and for something remarkably complex in its core design and the features required.

I replayed Snowed Inn last night, definitely one of my favorite FM's. I remembered it has quite a few improved assets: Better footstep sounds, loot sounds, and other improved and more realistic audio overrides. Also a better looking objectives screen with slightly higher resolution graphics. I really must ask: Unless there are licensing issues involved, is there a reason why we don't make those vanilla and replace the old ones? They're in the same style but better and more accurate! It could be a nice addition to the new 2.09 release

I think it would be odd to expect mappers to compile code and distribute a dll with their map. On the other hand scripting is definitely something you can expect from most map builders: I tried to make a FM without any scripts, then ran into limitations so I looked up the basics and in a few minutes I easily wrote a script for what I needed. Thus I agree that more focus on scripting would be a good idea, it's very easy to learn / use as well as very powerful with the right abilities. And like I said there aren't that many missing features! There are mainly two clear limitations that come to mind... more in total but these two stood out: The first is having no way to read the value of the lightgem, which is a big one and can hopefully be lifted easily by adding a $player1.getLightgem() hook (there's already one to set an offset for it). The other has to do with getting and setting the value of the breath, in case you want to modify the air as easily as you can health (there's allegedly an obscure way using the heal function which I might try if all else fails). Other hooks I could have used was the ability to force the player in crouch mode, or disable run so they're stuck walking and unable to run... I'd have really needed these two for my player damage mod. Also a way to change the volume of player (and why not AI) footsteps, so you can make the player more silent and harder to hear when walking around. Beyond these and a few others the script system offers most of what you need, just requires a few extra touches in my opinion.

Thanks for the clarification, that explains quite a bit! So there's a separate dll for a separate piece of C++ containing some gameplay code... that makes a lot of sense now. And yeah it would be ideal to have more hooks for the simple script system as well, maybe I'll make a list of the limitations I ran into with my mod and suggest some if that's okay.

How did TDM code its functionality before idTech 4 became FOSS and went standalone then, with no source code to edit? I thought it did so because all specific game code was purely script based. Not sure how I feel about this. I was hoping only basic functionality was coded in the engine, like the rendering or pathfinding or ragdolls or foot IK and so on: The rest I thought was all scripted... like telling the AI what animations to play, when to become alert, checking when they see an enemy, where to walk to, etc. There is of course code specific to the player or AI, but my belief was it's just common generic stuff (determining movement and visual optimizations and such). IMO this would be the correct way as an engine is usually a general use system... in fact I thought you could still play Doom 3 using the TDM engine binary, obviously not vice versa due to mandatory new features in our engine fork. Then again I'm learning these days that the scripting system is VERY limited, far more than I thought it was. I'm grateful it allowed for my augmentations mod to be coded in the end, but there's a ton of hooks for modifying player / AI / etc that can ideally be added someday to make modding via scripts possible.

I know this can be a matter of personal feeling, but at this point it feels off enough to ask: Did any cvars relating to AI difficulty change in recent versions, or perhaps their functionality altered in 2.08 or 2.09? My difficulty level is set to Nearly Deaf / Nearly Blind, yet the AI reacts almost immediately and will reach an alert level for the smallest reason. Asking here since I feel it was a bit less reactive before so I'm imagining something must have changed, either in the scripts or outdated settings perhaps.

The augmentation system is one step closer to completion! Today I finally implemented the power system, with draining and regeneration as well as the visual bar (follows all HUD settings adjusted in the main menu). Different augmentations drain different amounts of energy at different times, some only while working others all the time. Regeneration is itself achieved via photosynthesis, meaning the player must stand close to a light source in order to regain power... this should add an interesting gameplay element by pushing the player to expose theirself and sit in bright areas when enemy AI aren't looking. At the moment the only thing I'm waiting for before posting a 2.0 beta is finishing the per-augmentation HUD icons. There's still a single HUD element with everything drawn exclusively for visualization, to which I also added the power bar as can be seen below. I have a bunch of icons which look okay(ish) in my book, but may still browse OpenClipArt for even better ones as I'm not satisfied with a few of the designs and how they appear at the small size required for the HUD.

The engine code contains TDM specific functionality? I thought it only offers functions to compute the light, but such a value would first have to go through a script IIRC. TDM had a lightgem system before idTech 4 was open sourced too, so I assume it was scripted before the code could even be modified unless I'm missing something. For now I found a workaround for what I need to do, as it doesn't need to know the lightgem value specifically.

Oh wow: You can't even read the light value at a given origin rather than per-entity? How does anything work without that? I mean doesn't the player script read the light value at the player's location in order to know how to set up the lightgem? If all else fails I'll use the gui value in that case... I was thinking that's a failsafe if other methods are more complicated. Update: Looked into it and it's a mess I can't make sense of. gui::lightgem_val isn't set anywhere in tdm_base01.pk4/scripts where all TDM related scripts are stored, meaning it should not be working even in the default game! The issue with using getGuiFloat is that it requires a GUI handle, and using one I made myself won't report that value and always gives me 0. I'll wait on further advice on how to approach this.

Since the beta is an opportunity to fix issues, including ones that existed in 2.08: Is there a chance for alt-tab switching under Linux / KDE to be fixed? I'm referring to this bug: https://bugs.thedarkmod.com/view.php?id=5293 Alt-tabbing itself works fine. But if you switch to another window, moving the mouse cursor over the TDM window in the background causes it to jump in the middle of the screen. This is normal when the window is focused but shouldn't happen when something else is selected and you only move the cursor across to operate other applications.

How do I read the current light gem level of the player in a script, to know how visible and exposed to light the player is at that moment? getLightLevel() seems to be a property of light entities rather than players / AI... a search through the default scripts doesn't help much either.

No obvious bugs that I can see in the latest 2.09 beta. I just realized the first beta had yet another bug I missed: Ambient music also played at half volume and I could barely hear it... it now plays at the correct intensity again. This might not be 2.09 specific per say, but I should point out I still keep seeing guards getting stuck in front of doors every once in a while. By stuck I mean they will open the door, but then spin in a circle in front of it even 10 times in a row, before either deciding to walk away or finally go through. I've seen it on more than one FM and with the default door / doorframe models.

It's mainly for logical reasons: I wanted each effect to be tied to a limb... if that limb is damaged to the point where it stops working, the augs on it should fail too. Upon second thought however, I think permanently losing the augmentation when a limb reaches 0 is too big of a penalty, and would encourage players to fallback to a previous save just to not lose their upgrades. So for now I decided to simply disable augs when their limbs reach 0 health, but have them come back once the limb has health in it again. I see. It seems to work just as fine though: It informs the player what the AI can throw at them, which is the information that matters in the end.

Technically kind of: Limb damage is taken based on the player's velocity at the time of damage, with nearly none taken if damaged while standing still. This means that how you move while fighting an enemy AI or walking through a damage zone (eg: lava) determines which limbs are hurt the most: Strafing sideways exposes the arms, moving back and forth exposes the chest, jumping exposes the head (when going up) and legs (when falling down)... holding an object offers added protection to the torso at the detriment of the arms, while crouching or touching the ground protects the legs. Also fall damage will always affect the legs and slightly the arms... this is a natural consequence emerging from the proper patterns, but it gives the player knowledge of what to expect if risking a fall from a height (before getting the glide augmentation). Healing is automated based on the sensitivity of each limb at the moment. If someday I add a GUI component, I may allow customizing the distribution or choosing which limb to use a health potion on... this one is not something I plan on doing anytime soon though.