MirceaKitsune

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.

Another set of ideas and improvements I'm very happy with landed today; As suggested, the topmost information (starting at aug level two) now contains the melee skill as well as the ranged skill (accessed via AI spawnargs "def_melee_set" and "def_projectile"). They still use the internal technical names but it's better than nothing! Speed and jump enhancement were merged. In the empty slot created a new aug was added: Path markers! A small glare effect (tdm_moon_glare.prt) is added to each path_corner on the map, allowing the player to see which spots are frequently patrolled by AI and what their routes are. This makes a great companion for the sonar as a visual cousin to it. At lower levels only paths that are frequently used will show up, while at max level all of them will... this is determined by the number of targets that path_corner has as follows: Level 4 = 4 or more targets, Level 3 = 3 or more targets, Level 2 = 2 or more targets, Level 1 = 1 or more targets (meaning every valid path_corner). Here's how they will look like: Now that a final set of functionalities seems to have been determined, I can start associating each one to a limb. Like I said when a body part reaches 0 health, associated augs are permanently uninstalled and need to be installed again after their limb has been healed to allow it. The most logical arrangement I'm going to go for: Torso 1: Enemy knockout Torso 2: Enemy soothing Torso 3: Healing Torso 4: Stealth Head 1: Crosshair, enemy info Head 2: Path markers Head 3: Loot sonar Head 4: Infrared vision Arm Left: Flame extinguishing Arm Right: Door Unlocking Leg Left: Glide (slow fall) Leg Right: Speed + jump enhancement

I wonder if the mirror might be interacting badly with the ceiling texture I'm using, textures/darkmod/stone/flat/slate01_light: Maybe that shader has something the mirror doesn't like in mixture with a skybox? But since others can't reproduce this one there's no point in dwelling over it, it may be a random map bug that could go away after I tweak things. Speaking of mirrors: I tried giving the floor on my test map the newly updated textures/washroom/mirror texture. It seems mirror floors work perfectly and without issues All characters and entities are reflected, no flickering or clipping or anything, even the player sees theirself! This will be fun to attempt in some cathedrals or other buildings if performance allows.

Confirming the latest beta fixed AntiAliasing for me as well, nice to have it working again The mirror bug I'm experiencing with my FM is still there although I think it looks a little different now.

What would be the best function or spawnarg to get the melee skill of an AI? Perhaps something that could work for archer skills as well so it's not just for melee? I agree the name is pretty much a placeholder, there's little to not use for it just something to fill each upgrade level with. Changing the acuity of all AI sounds a bit too hacky, as this would also offset their hearing toward other AI or world events. Plus the player hears their own footsteps at the same volume so it doesn't make sense. For now it seems best to skip this one... maybe I can find something better in its place? For tonight I finished implementing the ideas in my last post: Crosshair and HUD info are now one. A door unlocking aug was added... it only works for normal doors and not chests as there are some weird issues with the froblock entity, but this is better as it leaves some doors up to the standard lockpicks. Knockout aug works as a self defense mechanism. I began preliminary work on updating the HUD to include the new augs, this should be ready tomorrow then the upgrade items are the last part. Note that the bottom row will be unused, this is mostly a mockup using one test overlay which I'll next separate into individual pieces.

Took some new decisions while I was away, I think you're going to like these as well First of all how augmentations will relate to limbs: Each aug will be specific to a body part... like healing to the torso, infrared to the head. As long as that limb stays above 0 health, the performance of the aug will not be affected and you can keep using it. However if you allow a limb to reach 0 health and disappear from the HUD, all augs installed on it will be permanently lost! Once your limb is healed again the player will need to find new items to install and start upgrading lost augmentations from scratch. This offers a way to make the system cyclical so that there's a way to reset, while further encouraging the player to pay attention to their limb damage on top of the little penalties already associated with it. I decided on a new augmentation to replace the one lost in the merger: The player gains the ability to unlock locked doors by merely looking at them, granted they can be lockpicked of course. The level of the augmentation determines the amount of pins a door can have before frob-highlighting automatically unlocks it: Level 1 will only unlock simple doors with 1 pin, level 4 can unlock doors with up to 4 pins. I should have the script functions needed: I can get the door with $player1.getFrobbed then unlock it with door.Unlock() which from what I'm reading should do the trick... the string length of door.getKey("lock_picktype") (eg: "sts" == 3) will tell me how many pins the door has. The knockout aug will be turned into a self-defense system: I'm going to make it activate when the player is damaged. The level changes the damage threshold under which the AI gets blasted, the effect will always be immediate. This means that when a guard hits you with his sword, he's going to drop to the ground the moment he dealt damage you.

Crosshair and Information augmentations were merged into one as follows. Level 1: The crosshair appears, this time all colors work right away. Level 2: The name / class of the traced AI is printed below the crosshair. Level 3: The alert level of that AI is also printed below it. Level 4: The health of the AI is also printed below that. I'm thinking of merging speed enhancement and jump as well, given they do roughly the same thing and use the same script pieces to do it. However this would leave me down by yet another augmentation slot, and I'm panning to stick to 12 defaults now that I went this route. What would you suggest putting in its place, which is within the realm of the script system to support? Share some creative ideas that I haven't thought of and I'll take a look when I get back! Knockout aug was also fixed to be less powerful. The range is now set at a low 50 units, meaning an AI cannot be knocked out from a distance but only if the player is basically touching them. The effect now occurs on a timer, it's this timer that is affected by the level as follows: Level 1 = 6 seconds, Level 2 = 4 seconds, Level 3 = 2 seconds, Level 4 = 0 seconds (instant at max level). The player can essentially knock out a violent AI by bumping into them, but if the aug isn't upgraded they may have to bump them for a few seconds to succeed, increasing the risk of the player getting hurt before it works: I gave this new functionality a few tests and it feels very balanced to me. Oh... and I plan on doing a little mixup which will give the limb damage more use: Each augmentation will be tied to a certain limb which it's implemented in. If that limb reaches 0 health, all augmentations associated with it stop working until it gets restored. In exchange I'm thinking of removing all death penalties from limbs, so losing your torso or head will no longer kill you... after a conversation last night I thought more on it and agree that normal health reaching 0 is the only thing that should kill the player while limbs are just for penalties.