Obsttorte
-
Posts
6522 -
Joined
-
Last visited
-
Days Won
111
Posts posted by Obsttorte
-
-
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.
-
1
-
1
-
-
1 hour ago, snatcher said:
To keep thing simple, I think the problem could be solved if we somehow could reduce the size of the font in the objective list
That's already possible. Chech your video/advanced settings. There is an option to adjust the hud size.
-
1
-
-
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.
-
2 minutes ago, Frost_Salamander said:
Not off hand no. Say you have an abstract class or interface you need to implement and it has a method called 'doSomething()'. In the implementing class you have to implement the method, but say it doesn't make sense to have it do anything, so you just implement it and have it do nothing. There could be various reasons for this, like early in a project and it's just not implemented yet, or bad design, or using base classes from a totally different game...
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).
-
1
-
-
5 minutes ago, Frost_Salamander said:
well I meant more like it's implemented but does nothing just to satisfy interface requirements, like you see in some OO code. Not sure if that's a thing here or not.
Do you have an example? I don't think I ever came across something like that.
-
6 hours ago, cvlw said:
I have tried $ai.disableClip() and $ai.becomeNonSolid()
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.
Just now, Frost_Salamander said:Is this because the script events are just not implemented? I get this sometimes too and wonder if there is a way to tell? It's just a lot of trial and error it seems...
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.
-
1
-
-
52 minutes ago, wesp5 said:
This would be a huge change basically removing all moveable light sources. Or is there a command like e. g. setGrabable(0) (this one isn't recognized) to do this only after you extinguished them, when they became pretty much useless anyway?
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.
-
1 hour ago, wesp5 said:
But I would really like to fix the issue that candles you just extinguished by frobing get taken automatically, because the main idea behind the direct frobing was to remove possible sounds when picking them up. Obsttorte, can you please help me out here?
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.
-
3 minutes ago, Dragofer said:
Probably more realistic to frob the candle vs. the holder.
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.
1 hour ago, snatcher said:Assuming you have these items in the first place!
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.
-
8 hours ago, wesp5 said:
Speaking about this, it has always annoyed me that in my imprementation even if you directly frob-extinguish a candle, it will be taken afterwards. Looking at the script below, this is the default action for unlit candles, but Obsttorte, could we delay this a bit so it does not happen if we just have extinguished it?
void frob_candle( entity candle )
{
string skin = candle.getKey( "skin" );
string skin_lit = candle.getKey( "skin_lit" );//sys.println("DEBUG: candle was frobbed\n");
if (skin == skin_lit)
{
// turn off
// sys.println("DEBUG: turning light off on " + candle.getKey("name") + "\n");
lholder_toggle_bound_flames( candle, 0 );
}
// else let the player grab the candle
else
{
// if this entity is bound to something, grab the bind master
entity bind_master = candle.getBindMaster();
if (bind_master) { candle = bind_master; }
$player1.holdEntity( candle );
}
}It may interfere with something else. But I am not a houndred percent sure what you are aiming for.
8 hours ago, snatcher said:Any purpose.
- Lit: to explore a dark corner.
- Unlit: to make noise and lure AI to a point.
- 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.
-
1
-
7 hours ago, snatcher said:
What if I actually want to pick the candle up?
For what purpose?
7 hours ago, snatcher said:then we aren't putting anything new on the table
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?).
-
4 hours ago, snatcher said:
Call me crazy but the less base files we touch the more versatile a solution is and the less maintenance it requires.
Base defs rarely ever change, so altering them is a pretty safe approach. But I see where you are coming from.
4 hours ago, snatcher said:If we refer to the original "vision" in the OP, the blow would activate when nothing is selected in the inventory
4 hours ago, snatcher said:Any help pointing to the right direction is appreciated.
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
)
-
2 hours ago, snatcher said:
See it in action (note the download).
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.
2 hours ago, snatcher said:I can't figure it out @Obsttorte. Your video is interesting but hardly of any help.
These are the basis of what I currently do:
do { this_entity = sys.getNextEntity("def_attach", "light_candleflame_sp", this_entity); if (this_entity != $null_entity) { if (this_entity.distanceToPoint(playerEyePos) < 50 && this_entity.hasFunction("LightsOff")) { this_entity.callFunction("LightsOff"); } } } while (this_entity);And what is this code supposed to do? I don't understand why you are going for an inventory item to blow out candles.
-
-
3 hours ago, Frost_Salamander said:
what did you do there just put the door handling entity on both sides of the door?
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).
3 hours ago, Frost_Salamander said:What I was trying to say was if the commoner didn't have a path to the controller he would try to open it directly.
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?
Development versions (2.11)
in The Dark Mod
Posted
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.