Obsttorte

There is alread one: https://bugs.thedarkmod.com/view.php?id=5888 @AraneidaeIt's the right way to bring up bugs and create an entry in the bugtracker. However, you cannot expect that things get solved automatically just because they got reported! It's a matter of the impact the issue has, how many people consider it serious and most and for all, whether someone who is capable of addressing the issue has the time, motivation and some clue on how to solve the issue.

That's already possible. You have to "grab" below the two text fields. May I suggest that you familiarize with the software before making suggestions

Yeah. It would probably be the best approach if this is a special scenario for only one ai to create a custom one for that purpose. Allthough it would be easier to give useful tips if it would be clear what @cvlwis aiming for.

The script function getNextKey allows you to go through all spawnargs with a specific prefix (like def_attach for attached entities).

Well, if the player can walk through it but not the ai then it is probably hard-coded behaviour transferable to ai. The question is whether this makes sense, as the ai may rely on bumping into the body to detect it when in darkness. The entities bound to the ai are def_attached, so you could look up script functions related to that. If it is for a specific ai, you could either check the entity definition or create a modified version where the attachments are non-solid to begin with if you don't need them to be.

@cvlwAre you sure it is the ai that you are colliding with? They have lots of stuff attached to them (armor, weapons et al.) and I am not sure whether the content flags get transfered to attached entities upon change.

Now, that is useful. Funny how long it takes sometimes until someone comes up with such a small yet huge tweak.

That's already possible. Chech your video/advanced settings. There is an option to adjust the hud size.

You can specify translations within guis so that you get the appearence of a moving background, even though only still images are used. Many briefings use this approach. If you need help with how to set this up or want a video and have some images to work with available I am happy to help.

Sounds like one part of the William Steele series by Grayman, don't know which one though.

That is clear. But the scripting system isn't object oriented and there are no virtual functions afaik. There might be script functions that are bugged (I haven't tested all of them), but that's rarely the case (out of the top of my head I know of only one script function that I had to fix).

Do you have an example? I don't think I ever came across something like that.

Is ai in your case the name of the ragdoll entity? Because as far as I remember it is not the same as the initial ai that got knocked out (it gets replaced if I am not mistaken). The ragdoll to be used or more precisely the respective entity definition is refered to in the spawnarg ragdoll, so you could also try to alter the definition and make it nonsolid from there. If this would be the case an error would be promted in the console.

The moveables get indeed used rarely afaik as they are very performance hungry. A compareable effect can be achieved via the light shader at a way lower cost.

Alter the base entity definition!!! And no, the light sources are still moveable, even grabable. But the latter would be handled by your script instead of the engine, which is, as I understood it, what you are aiming for.

That's because they are still grabable. The pickup is done by the engine code. You have to make the light holders non-grabable.

I just tested around a bit and it is indeed not possible to frob the particles directly as stated by @Dragofer. An approach that works quit nicely is a setup in which the player can decide whether he wants to pickup or extinguish the light upon frobbing by moving his mouse up or down during the frob. Upwards let the player pick up the candle, downwards extinguishes it (could be changed to toggle). If the player doesn't move his mouse, then nothing happens. It would again incorporate to alter the defs of the respective light base classes so they are non-frobable and the equip_action_script is used as frob_action_script, too, as well as a minor modification of the respective script called there, but would preserve the already existing mechanic of extinguishing light sources that are currently in the grabber by using them.

There is the issue that we have frobable candles without holders, too. And yes, the flames as are are probably not frobable. But you can have an invisible frobable object on top of the candle that alters the look of the flame. I valid assumption considering that in most fms it is the other way round - you have items you don't need. I for one can at least not remember any fm where I thought: "oh, if I would only have item xy". I mean, to each its own. I just wonder whether the amount of work you put in stands in a proper relation to the benefit it may hold.

It may interfere with something else. But I am not a houndred percent sure what you are aiming for. player lantern noisemaker arrows If you want to have both the possibility to take out extinguishable light sources directly AND beeing able to pick them up in both lit and unlit state I would suggest that you make the flame frobable. If the player frobs the candle, it will be picked up. If the player frobs the flame, it gets extinguished.

For what purpose? Then I may ask whether something new is needed. As far as I get it, having to pick up a candle, then use it and put it down again is annoying to say the least. But as stated, there are actual missions that handle this differently. It's just that mission authors don't really care a lot or they or the players find it better that way (because they like they can pick the candles up?).

Base defs rarely ever change, so altering them is a pretty safe approach. But I see where you are coming from. Then I'd suggest that pushing the frob button with nothing frobhilighted might be an approach. There is already a script function to test on whether the player is pushing the frob button iirc. This could be accompanied by a check on whether the player picked up an extinguishable light source by doing so and then dropping the candle. Obviously the cleanest solution would be to have a dedicated key for blowing (that sounds odd )

That doesn't really answer my question! I especially don't understand why you want to add additional clutter to the player inventory just to be able to put out some candles, which can be simple done by frobbing them?! As stated above, if you don't like picking up the candles first, change the base class definitions. You invest tons of work for a neglectable effect, honestly.

There are already candles that can be taken out directly by frobbing them. It's just the choice of the mappers on whether they want to use those or the moveable ones. If you want to overwrite this behaviour I would suggest to alter the entity definitions of the respective base classes. EDIT: the candlesticks for example inherit from atdm:moveable_candle_base. If you copy the equip_action_script to frobaction script and set grabable to 0, you should already get the desired behaviour. And what is this code supposed to do? I don't understand why you are going for an inventory item to blow out candles.

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

One side should suffice. As the door is normally only hidden from one side . But yeah, that's basically it and is preferable as it also allows the ai to pass the secret door once opened (by the player). I didn't found anything in the code that checks whether the door is reachable from the lever (or vice versa). Besides the question on how feasable this setup is, are you sure this is the case?