Obsttorte
-
Posts
6522 -
Joined
-
Last visited
-
Days Won
111
Posts posted by Obsttorte
-
-
6 hours ago, Skaruts said:
Well, that's why I said "I don't think it requires...", and not "it doesn't require...". But I explained my reasoning. I'm only discussing an idea here.
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.
-
6 hours ago, Skaruts said:
With a prefab made of brushes you don't have to create skins, you can just replace textures as you please, and the prefab can exist in a single file.
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).
-
1
-
-
9 hours ago, Springheel said:
The rules are also explained in the tutorial mission. It's also one of the loading screen tips of both starting missions.
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).
-
1 hour ago, Springheel said:
I'm not sure why that should change the rules for how blackjacking has worked previously. Civilian AI and unalerted guards without helmets have always been vulnerable to KO from any direction.
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.
15 minutes ago, snatcher said:Player presses the attack button and gets your (kingsal) animation. Player keeps pressing the attack button and only when the KO is an OK, the player gets the full raised animation. Player releases the attack button for the attack.
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.
35 minutes ago, snatcher said:Hi Obsttorte,
I am sorry but I don't understand. The blackjack never raises, only reacts on key release, and I cannot KO anyone.
What am I missing, please?
29 minutes ago, snatcher said:Ok, Ok! I see it now! It seems I can only KO guards with helmets though. Regardless, it looks and feels really good!
Probably a conflict with some of the mods you are using?!
-
2 hours ago, kingsal said:
I might be misunderstanding something , but I think any unaltered guard should be KO able from the front/ side (accept full helmeted guards).
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.
-
1
-
-
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
-
3
-
8 hours ago, wesp5 said:
I always wondered why Bridgeport is set in France when all the names clearly suggest is it located in England. Isn't this only due to only single in-game map? Does this really make sense?
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.
-
1
-
-
2 hours ago, kingsal said:
ready10.md5anim
@ObsttorteHere is the anim with all 10 frames (still WIP )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.
-
34 minutes ago, Dragofer said:
You'd probably want a lowering animation, too?
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.
-
-
1
-
-
11 hours ago, Skaruts said:
Well, not really. The way I was suggesting it, the map wouldn't reference anything from the file, or else you'd have the issue Springheel was talking about.
That's what I am saying.
11 hours ago, Skaruts said:The details of the implementation, I don't know. But I don't think TDM would require any changes.
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?!
11 hours ago, Skaruts said:The only problem I see with exporting as models is that it requires you to then manually edit files to support skins on it.
You have to create the skin files per hand anyways. What does this has to do with the prefab system?
-
56 minutes ago, kingsal said:
I started making new animations for the black a while ago so I'll dig them up and see if my set up will work with the core content. At the very least, I can get you something simple to start with.
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.
-
- Popular Post
- Popular Post
(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.inizEDIT: 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.
=========================================
-
6
-
1
-
35 minutes ago, Frost_Salamander said:
- Is the frob box supposed to become solid when the entity is not frobable? If so, why?
- This prefab works fine without the frob box, is it really needed?
- If the frob box is needed, why is it so big?
- 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.
-
1
-
-
14 hours ago, cvlw said:
- Is it possible to unshoulder a body in a tight space?
- For mapmaking, is it possible to prevent entry to an area if a body is shouldered? Or maybe force an unshouldering when entering an area?
- Not, if the area is too tight. There has to be enough space for the body to fit.
- Yes.
-
1
-
7 hours ago, Melchior said:
Which brings up another point: EXTRA mission difficulty settings beyond the 3 ?
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).
-
6 hours ago, kin said:
Looks interesting. I guess the reason that its is not used often may be the difficulty of implementing it in a scene? It would be perfect if someone could just brush it on surfaces for example with a deticated tool.
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.
-
4 hours ago, snatcher said:
I did notice if I place a script folder besides a mission pk4 my scripts take preference. That's a good thing but still, I think tdm_user_addons.script should be the ultimate ruler
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.
-
1 hour ago, nbohr1more said:
On that note, since we are an open source project if you wish to appeal to any outside parties or communities who understand Doom 3 AI coding to see whether anyone is interested in developing a patch, feel free to spread the word. It may also be worthwhile to create a thread about this in the "I want to help" forum so that potential new developers see this when deciding what to offer TDM to elevate their chances of gaining trust and joining the team (etc).
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.
[2.11] New Blackjack System (available via dev build)
in The Dark Mod
Posted
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.