View Issue Details

IDProjectCategoryView StatusLast Update
0000048The Dark ModCodingpublic13.03.2020 19:35
ReporterSneaksieDave Assigned To 
PrioritynormalSeveritymajorReproducibilityalways
Status newResolutionopen 
Summary0000048: Stim Response through walls
DescriptionOriginal entry was just about extinguishing torches through walls (http://modetwo.net/darkmod/index.php?s=&showtopic=4320&view=findpost&p=80794)

Ishtvan indicated this was due to S/R going through walls, so the revised focus of this entry is that.
TagsNo tags attached.

Relationships

related to 0001104 resolvedgrayman Gas arrows leak through glass and doors 
related to 0000090 closedSpringheel Sound propagation right through closed doors 

Activities

SneaksieDave

SneaksieDave

29.06.2008 16:41

developer   ~0001394

Just for completeness, let's also make mention of communication stims here; currently they are based on radius, not soundprop, as with the example above of a water arrow's water stim going through a wall to reach a torch.

If the fix for these cases turns out not to be the same (perhaps occlusion for the water stim and soundprop for the communication stim?), we should split these into separate issues. However, it is assumed the solution is not known at this time.
grayman

grayman

27.06.2012 15:59

administrator   ~0004671

To add to this, a water stim falling through a floor puts out flames on the floor below where it hits. Think of two fireplaces on two floors of a house, one over the other, connected to the same chimney flue. Douse the upper one and the falling water stim lives long enough to fall through the floor and douse the lower one.
CodeMonkey

CodeMonkey

07.10.2012 11:15

reporter   ~0004867

@grayman,

The simplest solution I can see, is to add a simple bool value(ie, bool TaskCompleted) to the base class that indicates whether a stim has done it's job or not. It could then be set on a per stim basis, so, once it extinguishes one flame, it could be disabled, to keep that from happening. (There may already be a mechanism that could be used to disable a stim, the bool was just to illustrate the point.)

Not the most ideal solution, but, it could at least prevent the bug you mentioned until something better can be implemented.

Anyways, just throwing it out there, feel free to ignore it.
tels

tels

08.10.2012 08:00

developer   ~0004886

Last edited: 08.10.2012 08:02

View 2 revisions

I don't think it is as easy as a "let the stim only work once". Actually for water stims, we do want them to work on two flames if it hits these at the same time.

What we don't want to have is it to work on things on the other side of the wall or another floor.

Me thinks we need bool that decides wether the stim works across "areas" or not (an area here being a room being zoned of with visportals). Then we could f.i. set that bool to false on water stims, meaning a water arrow douses a torch in one area (and then stores the area num) and then ignores and receivers in other areas. (This check needs to be implemented in the receiver, I think).

This way a water arrow can be shot through a door, but not douse a torch through the wall or across floors.

Mappers need to portal of these ares so it properly works (f.i. not adding a visportal to a doorway would make both sides of the wall part of the same area, so the water arrow still fails), but adding these visportals is good praxis and should be done, anyway.

Edit: Forgot to mention: the complexity here is that the stim area needs to be checked against the receiver area, where the stim stores the area it starts of (because it can move and expand into other areas later) and each receiver checks its own area against that area IF the stim is an "source area only" stim.

CodeMonkey

CodeMonkey

08.10.2012 10:05

reporter   ~0004889

Last edited: 08.10.2012 10:10

View 4 revisions

You still have to solve the visual issues as well. (Disable particles that cross the "area" boundaries?)

Gas arrows and glass surfaces are a prime example of the need to solve that problem.

As for my original post, actually, that's generally what developers do, cheat, they rarely realistically solve problems, it only has to look proper, the "sky dome\box" is a good example of developers cheating. (Anyways, I was suggesting it more as "hack" until a proper solution could be implemented.)

tels

tels

08.10.2012 10:11

developer   ~0004890

Last edited: 08.10.2012 10:13

View 2 revisions

The visual issue is not as important. Plus much harder to solve, because the visual particle is completely sep. from the invisible stim/response, and there is actually no way to influence the particle generation/rendering unless we start to hack at this subsystem, too.

(The particle system has other problems, too, esp. releated to areas and portals etc. But lets ignore that for now)

Gas arrows would also be exempt from that fix, because a gas arrow near a open visportal should gas a guard on the other side of portal.

Might be an exception for close portals (if there is a door and the door is closed, the gas should/should not leak through).

And of course, if there is f.i. a trapdoor in the floor with a visportal in it, shooting an arrow at the side wall and the water falling down *should* douse a torch down there.

The more I think about it the more complicated it sounds. We might first to draw up a list of all potential cases with the current and expected outcome and then we might think what we need to change.

So instead of maybe an area-check we just need a visual check - is the first starting point of the stim (or the current?) visible from the current working point of the response? If no, there is something solid in between, so ignore it. But this also could break valid use cases (a metal grate should not stop a gas arrow or a water arrow, but a glaspane or a solid wall should, but the grate could fall the visible check due to a tiny metal bar being in the way).

CodeMonkey

CodeMonkey

08.10.2012 10:22

reporter   ~0004891

Last edited: 08.10.2012 10:43

View 4 revisions

I agree, this requires careful planning, there are far too many special cases to contend with.

Make a virtual method that can be implemented per stim, that way custom behavior can be mapped out, and have a bunch of switch cases handling each scenario?

Maybe raycasting could help determine the path for water?

I don't know, I'll have to think about it. :(

---

Adding collision boxes to particles is another possibility, but, it comes with a long list of problems too.

This definitely isn't a trivial issue.

---

I think you're right, just map out each case, and then create individual solutions per scenario, I can't envision a "one size fits all" solution to this problem, each one is going to have to be tailor made.

tels

tels

08.10.2012 10:40

developer   ~0004892

raycasting: The engine has a methods called "tracepoint" etc these take a point, or a box etc and "trace" it along a path and stop at the first hit against certain materials (like monster_clip, solid etc.) That way you can determine if there is something in the way.

If we just want the stim to act when there is a line of sight, I think a boolean per stim, and a method to query wether this is false (if boolean is false, or boolean is true but have line of sight) or true (boolean is true and have NO line of sight) would be the most simplest way. Then each response would call this method and ignore the stim if the return is true.

Anyway, maybe you want to pick an easier item as your first assignment? ;)
tels

tels

08.10.2012 10:45

developer   ~0004893

I forgot to mention that a single traceline from point to point hitting a solid and thus giving a false positive occurs elsewhere, too. F.i. checks if the AI can see something, or the player is visible etc all suffer from the same problem.

Usually this is/was solved by making multiple traces (spread out over multiple frames because traces are extensive) and then seeing if any of them hits. Sometimes even selecting multiple points (from both eyes of AI to shoulders/feet/eyes of player) just to minimize the chance that a stray item blocks the trace and thus the engine thinks there is some thing in the way.

Stim/response could select a random point inside the stim source and a point randomly spread out X units around the response and do multiple traces every time the response would fire and only ignore the stim if all of them are blocked.

Anyway, we probably should discuss such things on the forum, there is an awful lot about the engine you can't know yet and the bug tracker isn't really the best method for learning this.
CodeMonkey

CodeMonkey

08.10.2012 10:52

reporter   ~0004894

I was just trying to help get the thought process going, but, if I'm distracting you, I'll leave you to it.
grayman

grayman

09.04.2013 19:56

administrator   ~0005289

This is fixed for gas stims. (0001104)

I will need to address falling water stims, however. They can probably use a variant of the gas stim solution.

Issue History

Date Modified Username Field Change
26.01.2007 19:51 SneaksieDave New Issue
29.06.2008 16:41 SneaksieDave Note Added: 0001394
29.06.2008 16:44 SneaksieDave Relationship added related to 0000090
29.06.2008 18:08 greebo Status new => acknowledged
27.06.2012 15:59 grayman Note Added: 0004671
07.10.2012 11:15 CodeMonkey Note Added: 0004867
08.10.2012 08:00 tels Note Added: 0004886
08.10.2012 08:02 tels Note Edited: 0004886 View Revisions
08.10.2012 10:05 CodeMonkey Note Added: 0004889
08.10.2012 10:07 CodeMonkey Note Edited: 0004889 View Revisions
08.10.2012 10:08 CodeMonkey Note Edited: 0004889 View Revisions
08.10.2012 10:10 CodeMonkey Note Edited: 0004889 View Revisions
08.10.2012 10:11 tels Note Added: 0004890
08.10.2012 10:13 tels Note Edited: 0004890 View Revisions
08.10.2012 10:22 CodeMonkey Note Added: 0004891
08.10.2012 10:26 CodeMonkey Note Edited: 0004891 View Revisions
08.10.2012 10:31 CodeMonkey Note Edited: 0004891 View Revisions
08.10.2012 10:40 tels Note Added: 0004892
08.10.2012 10:43 CodeMonkey Note Edited: 0004891 View Revisions
08.10.2012 10:45 tels Note Added: 0004893
08.10.2012 10:52 CodeMonkey Note Added: 0004894
06.04.2013 14:10 grayman Assigned To => grayman
06.04.2013 14:10 grayman Status acknowledged => assigned
06.04.2013 14:11 grayman Relationship added related to 0001104
09.04.2013 19:56 grayman Note Added: 0005289
24.11.2017 16:37 grayman Assigned To grayman =>
24.11.2017 16:37 grayman Status assigned => new