Obsttorte

I moved over to working on the source code to get the stuff implemented to avoid unnecessary restrictions and as it appears there is already an implementation for a ray-tracing based melee system, probably a leftover from Doom 3. I was able to get it to run and now only need to get the raising animation done. After that it can be tested and fine-tuned.

The point wasn't that you made an assumption, you are of course free to do this. The point was that you made an assumption based on ... nothing. For someone who might be in the position to judge on whether this is possible and how, this reads as "I have no idea but common guys, this can't be hard". Even an assumption should be based on at least a minor amount of knowledge.

The reason why you have to skin models is because they are refering to external files. You can only retexture stuff inside DR if it is made out of brushes and patches, so stored internally (inside the map file). If you use a model several times in the same mission, all of them are references to the same external file which only has to be loaded once and which the engine recognizes to be the same. If you use something build out of brushes and patches, then having several copies of them in the same mission will be dealt as different entities, both when loading the map as well as when dealing with it during rendering. The idea behind prefabs out of brushes and patches is that some rather complex setup used in one mission gets reused in another mission, but preferable once. Stuff that gets placed several times in mission should consist out of models. Those setups can be stored as prefabs, too, but then you cannot retexture them. The fact that mappers use prefabs made out of brushes and patches is mainly a bad habit, not something desireable. It's caused by them relying on coders improving performance and avoiding minor extra work like writing skin files (which takes less then a minute).

Then I probably forgotten about it over the years. It was an assumption as you refered to a wiki article in another thread, obviously a wrong one

I can focus on implementing a version that uses the current ruleset. Nevertheless I consider it worth mentioning that said ruleset is an issue and has been brought up for discussion in the past, and the only way I am aware of to actually get to know it is to read it up in the wiki. Due to the fact that the game comes with a tutorial mission I am not sure that a lot of players consider looking at the wiki (I did not when I started playing TDM).

As argued above: I am not convinced that the majority of the players or even the mappers is really aware of the differences between how different ai are ko-able. Especially due to how unlogical it is. Why are helmets that don't protect the neck or weapons drawn supposed to influence whether and from what angle an enemy can be knocked out? KO's from the front are an exploit imho. If you can only blackjack from behind you have take lighting and the surface below into consideration, and if the ai is patroling the whole surrounding. If you can ko from the front, you can basically wait in the darkness while they come walking towards you. This makes patroling ai actually less of a treat then non-patroling ones. It is of course argueable what "from behind" or "from the front" are suppossed to mean, so where we draw the line. But a guard walking straight at the player should be considered a treat, not an opportunity. That sounds tedious. Players would need to hold down the button until they are in the right spot, and eventually they don't want to execute a blackjack once they find the spot. The animation is really intented as a visual helper. Some players may not even use it. Probably a conflict with some of the mods you are using?!

Well, the angle under which an ai can be ko'ed is discussable, of course. I would assume that it makes most sense both gameplay and immersion wise if the player is still somewhat in the back of the ai, though, so the angles shouldn't be too extreme. It's only partially a departure as (1) helmeted guards are already not ko-able from the front and (2) this is actually spawnarg controlled. So mappers and even players can already change it.

Ok. So here is a first prototype. There is still finetuning needed, but you get the idea. Just place the pk4 in your darkmod folder and start any fm. Raising/Lowering of the blackjack will indicate whether an ai can be knocked out ai can be knocked out only from behind elite guards, undead and those at alert state 5 (can see player) cannot be knocked out Kudos to @kingsalfor the animations.zzz_blackjack.pk4

I second that. Not to mention that the use of fictive names and locations in addition to the whole anachronical setting implies it is a fictive world either way, so placing it on a real world map seems odd to me. I personally never considered my missions to be part of a world were the rest of the missions play, or that all missions are part of the same world. That is neither necessary nor helpful, as it would imply that mappers consider and reference the work of other authors. Some may do this in some extent if they liked the work of someone for example, but I am not sure it is a common thing.

That pretty much nails it. Thank you. While working on it I also thought it would be good to rethink the knockout conditions, as this has been confusing in the past (all in one wash so to speak). The current setup includes the following rules: Guards with helmets can not be knocked out from the front, but guards with helmets can. So the helmet protects the guard from beeing knocked out from the only direction that is NOT covered by a helmet?! Not to mention that the helmets guards are wearing often are shaped like a hat - they don't really protect the neck. Guards that have their weapons drawn have a reduced knockoutability (probably not a word ). Guards without helmets can only be knocked out from the back (as opposed to all sides), guards with helmets not at all. So wielding a sword in front of you protects your back?! In this regard unarmed ai can always be knocked out, as they don't have a weapon to protect their neck I have two issues with the current setup: It is unintuitive: A big helmet protecting the neck as the elite guards wear it is obvious to cause protection against knockouts. A helmet only covering the top of the head is not so much. A weapon not at all. You cannot expect players to remember game rules that rarely apply (depending on how often players attempt knockouts) and are counterintuitive. It is not clear why it is necessary to distinguish between four different cases in regards to knockouts: elite guards - helmeted guards - non-helmeted guards - civilians. It would especially imply that mappers take this into consideration while placing guards. I know I didn't when I made my maps (I only expected a difference between elite guards and regular ones). What is the gameplay benefit of this? I would therefore propose a different approach: AI is only knockoutable from the back. Personally 3 out of 4 ko's I perform are from the front, as I just have to wait in the dark and lean forward. It has been an exploit in the original games and is so here. AI is not knockoutable if they are either ko immune (elite guards and undead) or if they can see the player (alert state 5). The latter means that once the ai stops seeing the player, for example because he threw a flashbomb, a knockout can be performed, which makes the flashbombs and other means for temporarely escaping the ai more useful (compared to reloading). The implementation is currently script based. This allows for simple testing it later by placing it as a mod. The source code has several parts that are refering to ko's, so implementing it there will be more work which is only worth starting once we have agreed on something. Testing and tweaking it makes sense therefore. Feedback and thoughts are welcome.

Well, theoretically I can just revert the raising animation. Or I invert a lowering animation to get a raising one, if you have one spare. The current issue is that as stated the animation is basically a one shot. It's better then nothing considering it is still in a proof-of-concept state, though. In the end two different animations for raising and lowering could spice things up, though. Unfortunately I haven't found the time and motivation to get into Blender yet despite having a thick book standing around that screams "read me, you lazy taffer". So I can't really judge on how long it takes to create those anims.

Check the controls in the settings menu. Under Inventory you find Use Inv. Item (it's the first entree). That's the button you have to press.

@kingsalIt appears that each frame of the animations you provided are identical. Is this intentional or an export fault? Is it possible to create a version of the 10 frame animation that is actually animated (so there is a movement from the initial position to the final pose)? Thanks in advance.

@kingsalWorks like a charme, perfect, thanks Will fine tune it and provide a prototype.

That's what I am saying. If you don't know the details of the implementation then the assumption of no necessity for code changes is pure speculation, wouldn't you agree?! You have to create the skin files per hand anyways. What does this has to do with the prefab system?

That would be great. Thank you very much.

You can export complex geometry built in DR as model and use that instead. If the setup contains interactive entities like doors etc. you can export them seperately and create custom entities with those stuff def_attached. So per se this stuff is already possible without having to possibly break an existing funtionality. What you are talking about is to allow referencing stuff in other map files (that's what the prefab files actually are), which would require both changes in the DR code as well as in TDM. All for the sake of achieving something that is, as said, already possible, only in a slightly more convenient way.

(Original Post) Hey ho. I am currently working on an alternative approach to blackjacking that doesn't rely on animation based hit collision, as it is now. Part of this approach is that the player gets a feedback on whether he can knockout the enemy in front of him via a suitable animation. As I am not familiar with neither modeling nor animating I would humbly ask for someone to help me out here. What I need is an animation that starts in the blackjack's idle state. The blackjack should then be slightly raised. Thanks in advance. ========================================= To test this out you can run the tdm_installer, select custom version and then select the dev16599-10071 dev build that can be found under dev/2.11. In addition you have to use this custom manifest url: http://ftp.thedarkmod.com/custom_builds/blackjack/manifest.iniz EDIT: There is a newer dev build available containing all the changes. The manifest is no longer needed. The ko indication can be toggled via the cvar tdm_blackjack_indicate. =========================================

No Not necessarely, although I am not sure whether the engine falls back to the collision model or to the AABB of the model if no frob box is defined. The first would be sub-optimal, but not a big thing either. I think the main purpose is to make small objects like coins easier to frob by providing them with frob boxes that are bigger then the actual model. I would assume that either the prefab author made a typo or didn't know what he was doing Consider it a bug.

https://wiki.thedarkmod.com/index.php?title=Creating_Multiple_Skins_For_A_Model

Not, if the area is too tight. There has to be enough space for the body to fit. Yes.

That would only make sense if the three existing ones would be already heavely utilized, which is not the case. In addition, how should the player know how gameplay is affected if the amount of possible starting condition exceeds a certain limit (the latest Tomb Raider comes to mind)? Three is a reasonable number players are used to from different games. Having more doesn't seem like an improvement. On topic: there are a few things to consider here, imho. A mission should only fail if the player dies at best. Adding yet another artificial layer to the gameplay like failing the mission because you weren't fast enough is a good source for frustration, not motivation. That beeing said it would be a possibility to change aspects of a mission after a certain amount of time. Besides guard shifts this can be that the sun slowly rises (slightly increasing difficulty the more time you "waste") or that certain approaches won't work anymore (but new approaches might arose) Timed doesn't have to mean that it is clocked. Timed could also mean that the game counts certain aspects (objectives fulfilled, loot found, area explored) that are somehow related to time and initiates a certain action after a specific point is reached. Timed events doesn't imply that it happens dozens of times. Stuff like guard shifts may only happen once per playthrough. To elaborate a bit more on thought #2: During the night, which is the typical scenario, there aren't much persons on the outside. It may even be forbidden to be on the streets during nighttime, so it makes sense that the watches consider the player an outlaw upon sight (well, it makes sense unless there are dozens of civilians walking on the streets). The positive part is that it is dark and you can sneak around unseen easely. When the sun has risen, there are lots of people on the streets. The good thing is, that you could walk around freely now, unless you draw your weapons or do other illegal stuff. In addition, different parts of the map may not be locked up anymore. It is hard to stay out of sight during the day, though. Having time in a mission would allow said mission to shift from one scenario to the other. The player may start at late night, with the sun slowly rising, or in the late evening hours, with the sun slowly falling. Some things might be easier to achieve during day, others might be easier to achieve during night. So the player would have to decide what to do first depending on that. This would only work if the player is provided with enough information to make a profound decision, though. And again, the progress of time doesn't necessarely has to be bound to the game time, it could also be affected by other means, as mentioned above. So the player would not necessarely has to be pushed in a hurry. I even think a mixture would work best (so partially the time passed and the progress made).

Not really, it is actually quiet simple. Fine-tuning it so it looks good and doesn't kill performance or create other unwanted effects takes its time, but besides that it is pretty straight-forward.

You are mixing up two different things here. That files take preference over each other has to do with how the code loads the files (or which ones). In regards to script or script functions it is a matter of how the script interpreting part of the code loads the respective files contents. Those are two different things done in a different matter. You can have a file in a fm that already exists in the core game and it will overload the latter. But you cannot simple create a script function with a name already in use and expect the engine to replace the first one with the latter. This is not a common thing in programming and therefore not to be found in the scripting language. If you want to replace existing functions you have to replace the files containing them.

Is this aimed at me or at Araneidae? If the first, I am not active at any other community nor do I know anyone outside of this community familiar with idTech4 coding. The only word that I can spread is: If you want things to get implemented or fix, the most reliable way is to learn coding.