Obsttorte

That sounds like fun. @AluminumHasteIsn't what you are saying contradictory? You hate redoing sections but quicksave scum, which will inevitebly lead to you redoing the same stuff over and over again (assuming you fail).

I don't understand what exactly you are trying to achieve. The code you posted doesn't make much sense to me, as a non-frobable entity cannot be frobhilighted. That was me. It relies on changes I've made to the source code though, iirc, so it won't work before 2.11.

@wesp5Just looked at the code and the frob_action_script that got changed is frob_item. So entities using frob_item will behave like in Dishonored upon frob, while others don't. You have to check the definition files of the other entities and exchange the frob_action_script in the base classes.

I don't care how you call it. But on one hand the personal pronoun is a bit off and on the other hand the term patch implies that it fixes something that is broken, which is not the case. Now that I reread it, it is a modified version of frob_loot, which obviously only get used by loot items. All other stuff uses frob_item. You would have to create a script function that works for both and alter the def files respectively.

I hope you asked Goldwell for permission. Don't go and pick up stuff from other fms without asking the authors. That's odd. It could be that it is either and old version, a modification made by Goldwell or my mind is playing tricks on me and it was always like that (although I don't see why). Paintings are a different story. The canvas is no seperate entity. So when frobbing a loot painting its skin gets changed. This doesn't work well with the modified frob. All my work is free for adaption. If I wouldn't want that I wouldn't freely distribute it. But you could consider stop calling it your unofficial patch.

That's what I've tried first. The issue is that it only contains out of seven frames, of which the first half is barely visible and after that you even get clipping. I will take a look at the equip animation, maybe that's more fitting.

I just reutilized an existing animation (creating modified versions via a text editor, as I haven't found the motivation to learn modeling/animating yet; well, it's been only a decade, so plenty of time left ). I could also use a different one or, if fleshed out, maybe someone with some modeling skills can come up with an animation. That's handled in the source code.

So it is a trinary system, than Still, the rules sound way more continuos to me. But maybe it is just my perception or a misconcept of the formulation as a foreigner. It's like stating that the more throttle you give, the stronger the car accelerates, just to find out that there is only no throttle-->half throttle-->full throttle.

Thrown together, as you named it, so don't expect too much. But it gives an idea of what I've meant.

https://thief.fandom.com/wiki/Fire_Shadow

@SpringheelYou are right, both rules you state are simple and logically consistent, but ... You write about them beeing harder or easier to ko. But that is not the representation in game. This is nothing continuos reaching from un-ko-able to ko-able, but a binary system, in which the ai can either be knocked out or not. So as logical as those rules are, the current system simple isn't based on it. I mean, there is nothing wrong with the current concept in general. It is a gameplay decision in the end. But it might simple be unclear how the average helmeted guard fits in their. I personally wasn't all too aware of that either, and I know the mod for quiet some time now. It makes sense if guards with helmets are mainly used in areas where there isn't much of a necessity to take them out, for example outdoor areas with lots of dark corners whereas in indoor areas unhelmeted guards are used (which would make more sense anyways: Who wears a helmet inside a building all night?). However, this is not really reflected in current fms. Builder guards don't wear helmets afaik but often patrol outside, and there are enough missions with helmeted guards patroling manor corridors. This tells me that most mappers may not be aware of this, either.

Those are usually no animations, but movers. There speed can already be altered via script.

That's what the fire shadow is for.

Maybe he means that the effect of the helmet is a bit inconsistent. If it doesn't protect an unalerted guard from getting knocked out, why does it do so for an alerted one? Either the helmet protects him or not.

The setup is called frob peer. This is setup at mission start via the spawnargs "frob_peer" or "frob_peerX" (with X beeing a number" respectively. So you can get the other door by checking for the peered entity that is a door (there are handles, too, although it might not be an issue if they move faster, too).

It's part of the idActor class. What do you have in mind, weapons?

Besides the modified script file the zip contains a definition that overrides the base entity definition for the door entities, so it uses this script instead of the default one. As snatcher pointed out, if a mapper has created a custom door with its own frob script that one would be unaffected. But I am pretty sure this isn't the case. I haven't tested whether the script affects sliding doors or other frobable movers, so be prepared for odd side effects ( as said, it's a poc).

Yeah, I guess. I could probably utilize the blackjack animation and restrict it to the first few frames or so. I see that I get a prototype done which we can discuss further. Regarding the bugtracker: I have the feeling that some filed entrees are beeing worked on although not assigned in the bugtracker (like the subtitle for A New Job, iirc, at least I think I've read someone worked on it). I am on a 17" now, but used 15" for most of my life (at least the part I've spent in front of a monitor ). I would guess that even for games 24" is already pretty large. And yes, there have been several discussions about improving the blackjacking system, however, mostly internal. So it is no surprise this comes up again from time to time. Maybe it would be worthwhile if we had a behind the scene thread that give non team members an idea what has been discussed or worked on in the early past, that gets updated every few months or so and where noone can reply, to keep it short. Basically like the news on the website.

Making the collision area for blackjacking slightly larger and the surrounding non-solid for the blackjack if an ai is directly in front of the player would be an option. Also a subtle arm raise indicating you are close enough could help. IIRC you are using a relatively large monitor. Many of us may not. Maybe that makes a difference in perception, too, considering that, as stated correctly, blackjacking success depends on depth perception. Personally I don't have such an issue with blackjacking either. But it depends on my mood and in TDM it is definetely harder then it was in thief, which is something I am not sure is intentional.

As the one introducing the feature of savegame restrictions: That was never the reason on why I did it. And for the last fucking time: Increasing difficulty was neither!!! Besides that I agree with you.

@wesp5You are welcome to do so. I want to fix other stuff.

Uhm...based on the fact that this is mainly a discussion among both of us. I mean, I don't even started this thread or can remember where I first posted about this, so... EDIT: Just checked the op. It was in the interactions thread. Well, the loot sweep got way more feedback - and I added it. This here, it would take way more work and in the end it was just a thought, not something I or someone else requested.

Just some notes on the above video. (Should have added that with the video). What you can see there are some script functions that got added and allow to modify the animation speed on the fly. That was actually a request from 14 years ago string getAnimList(int channel) prints a list of all available animations on the specified channel to the console float getAnimRate(int channel, string animName) returns the current animation speed of the named anim on the specified channel returns -1 if anim or channel not available float setAnimRate(int channel, string animName, float rate) sets the animation speed of the named anim on the respective channel to the specified value. returns 1 on success, -1 otherwise negative values are not allowed as they lead to insta-death (why ever) The channels are ANIMCHANNEL_HEAD, ANIMCHANNEL_TORSO and ANIMCHANNEL_LEGS. One use-case that came to my mind was an icebomb, that slows down enemies (and creates ice floes when thrown on water - wait, where did I see that ) Another feature would be some sort of time warp effect that slows down or speed up everything around you (moveables would need a different approach, though) or guards that run slower if they got injured at their legs (which would give broadheads a non-lethal usecase or allow the usage of crow's feet weapons).

If you quickly open a door into a room with someone inside, I guess the first thing that one would expect to happen is that the person turns towards the door. In Thi4f this was even the case for standard door opening, and combined with the peeking through keyholes it works like a charm. I think you try to adapt the mechanic to way more situations then I originally intented. That's fine, but as you are the only person interested in this it won't make it to the core mod anyways. I consider this a proof of concept, and mappers are free to adopt it to their likings for use in their fms.

Consistency doesn't imply that it is always the same. Consistence isn't equivalence. If the conditions aren't the same, the result can differ, too. So I don't consider it inconsistent that the ai takes different amount of damage depending on their alert state. It's a different matter if it differs between missions, as the situation one get into are similar, so players would expect similar results. In the end it comes down to communication, because it is not important whether it is realistic or always the same or whatever to begin with, but first of all only that the player is aware of that. Players should know that the damage dealt differs depending on alert state. If that it isn't clearly communicated, this might need to change, but not the mechanic itself. If a mapper alters a game mechanic, it should be communicated, too. But we shouldn't disallow mappers to go different ways. (Actually I think it would be better if we encourage them to experiment more.)